Subject: Re: FVWM: configure fails at "argument types of select()"

From: Michael Hamlin <[email-masked]>
Date: Fri, 1 Jun 2001 19:31:33 -0400 (EDT)

Here's a follow up with more information to anyone who can help.
Again, please copy any replies to [email-masked].

pavo:~/bin/fvwm-2.2.5>uname -a
SunOS pavo 5.7 Generic_106541-11 sun4u sparc SUNW,Ultra-1
pavo:~/bin/fvwm-2.2.5>gcc -v
Reading specs from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.5.1/2.7.2.2/specs
gcc version 2.7.2.2

I wouldn't know what is interesting enough to post to the list; except
perhaps for one thing:
  fvwm-2.2.5   managed to finish the configure,  but fvwm-2.3.32 did NOT.

configure: failed program was:
#line 5031 "configure"
#include "confdefs.h"
#ifdef HAVE_SYS_TIME_H
#include <sys/time.h>
#endif
#ifdef HAVE_SYS_TYPES_H
#include <sys/types.h>
#endif
#ifdef HAVE_UNISTD_H
#include <unistd.h>
#endif
#ifdef HAVE_SYS_SELECT_H
#include <sys/select.h>
#endif
#ifdef HAVE_SYS_SOCKET_H
#include <sys/socket.h>
#endif
int main() {
extern select (int,
 fd_set *,      fd_set *, fd_set *,
 struct timeval *);
; return 0; }

I went and looked in the header files to find the source of the errors.

/usr/include/sys/siginfo.h:74: parse error before `pthread_attr_t'
/usr/include/sys/siginfo.h:74: warning: no semicolon at end of struct or
union
/usr/include/sys/siginfo.h:76: parse error before `}'

063:  /*
064:   * The sigevent structure is also defined in <time.h> as per X/Open
065:   * and POSIX requirements.
066:   */
067:  #ifndef _SIGEVENT
068:  #define _SIGEVENT
069:  struct sigevent {
070:          int             sigev_notify;   /* notification mode */
071:          int             sigev_signo;    /* signal number */
072:          union sigval    sigev_value;    /* signal value */
073:          void            (*sigev_notify_function)(union sigval);
074:          pthread_attr_t  *sigev_notify_attributes;
075:          int             __sigev_pad2;
076:  };
077:  #endif  /* _SIGEVENT */

/usr/include/sys/socket.h:47: parse error before `sa_family_t'
/usr/include/sys/socket.h:47: warning: data definition has no type or
storage class

045:  #ifndef _SA_FAMILY_T
046:  #define _SA_FAMILY_T
047:  typedef uint16_t        sa_family_t;
048:  #endif

Appears as a syntax issue in the first one (semicolon to end the union
definition BEFORE the close parenthesis?).  The second looks like a
missing definition of "uint16_t".  The next error in socket.h is caused
by similar missing symbol "uint32_t", and later errors appear to be
problems with these data typedefs that failed in the first two errors.

There follows many pages of the same "parse errors" in siginfo.h
and socket.h, every time configure tries to compile something.

I went back and configured fvwm-2.2.5 from scratch and examined the
log, and found the -same- errors.. so why was 2.2.5 able to build,
but not 2.3.32 ?

thanks for your time.

michael
[email-masked]

----
"I don't believe violent video games lead to violence, but this was different. 
They'd play these games for hours and hours and hours," Baumgart said.

--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dan Espen <[email-masked]>
Date: Fri, 01 Jun 2001 20:09:30 -0400

>From what I can tell, the configure tests have been upgraded
between 2.2.5 and 2.3.32 with some fixes from the
autoconf maintainers.  It looks to me like they
are working better in the 2.3.32 series.

I tried compiling the code you show above on one of our Solaris 7
machines and it compiles without a problem.  I think it should
on your machine also.

I made it look like this:

#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/select.h>
#include <sys/socket.h>
extern select(int, fd_set *, fd_set *, fd_set *, struct timeval *);
int main() {
; return 0; }

Maybe your feature tests aren't returning all the things they
should be, I looked in my config.h to see which of the flags were
defined.

Right now, I'm out of ideas.  Maybe someone else on the list
has an idea?

-- 
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: "Paul D. Smith" <[email-masked]>
Date: 03 Jun 2001 21:25:05 -0400

%% Michael Hamlin <[email-masked]> writes:

  mh> pavo:~/bin/fvwm-2.2.5>uname -a
  mh> SunOS pavo 5.7 Generic_106541-11 sun4u sparc SUNW,Ultra-1
  mh> pavo:~/bin/fvwm-2.2.5>gcc -v
  mh> Reading specs from
  mh> /usr/local/lib/gcc-lib/sparc-sun-solaris2.5.1/2.7.2.2/specs
  mh> gcc version 2.7.2.2

Please note that you're trying to compile on a Solaris 7 system with a
GCC build on a Solaris 2.5.1 system.  This is very unlikely to work,
_especially_ with a version of GCC as old as 2.7.2.2.

I suggest you get a version of GCC compile on Solaris 7, and try that.
You can get prebuilt versions at sunfreeware.com, if you don't want to
build it yourself.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>    HASMAT--HA Software Methods & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dan Espen <[email-masked]>
Date: Sun, 03 Jun 2001 21:44:44 -0400

> You can get prebuilt versions at sunfreeware.com, if you don't want to

I don't know about older versions of gcc, but I've been using
gcc 2.8.1 built on Solaris 2.5.1 for a long time now.  I've used it
on everything up to Solaris 8.

---

From: Tomas Ogren <[email-masked]>
Date: Mon, 4 Jun 2001 04:18:13 +0200

> > %% Michael Hamlin <[email-masked]> writes:
[..]
> on everything up to Solaris 8.

But using one compiled on 2.5.1 on 7 is begging for trouble...
I haven't had any problems with 2.95.x on Solaris 2.6 or 8.

/Tomas
-- 
Tomas Ögren, [email-masked], http://www.ing.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,ing,acc}.umu.se
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Tomas Ogren <[email-masked]>
Date: Mon, 4 Jun 2001 04:25:18 +0200

[..]
> But using one compiled on 2.5.1 on 7 is begging for trouble...

I forgot to say.. gcc uses its own copy of the system include files. So
you're using 2.5.1 system includes on 7 which can't be healthy..

/Tomas

---

From: Dan Espen <[email-masked]>
Date: Mon, 04 Jun 2001 11:17:34 -0400

> you're using 2.5.1 system includes on 7 which can't be healthy..

I'm still looking at gcc 2.8.1, the results could be different
for other versions of gcc.

I just ran the sample in question under truss.  Although it does
look for gcc include files first, in this case, it only uses include
files from the system include directories.

Thats not to say that a gcc upgrade wouldn't solve this problem.

---

From: "Paul D. Smith" <[email-masked]>
Date: 04 Jun 2001 18:28:24 -0400

%% Dan Espen <[email-masked]> writes:

  de> I'm still looking at gcc 2.8.1, the results could be different
  de> for other versions of gcc.

Indeed.

The scoop is this:

Older versions of GCC were ANSI-compliant and wanted to work on systems
which very often (in those days) didn't have compliant system headers.
This meant that developers were seriously stuck: they either had to
turn off most of the warnings and other good stuff in ANSI C, or they
had to modify their system headers themselves, or they had to live with
tons of bogus warnings.

So, GCC's install step would examine the system headers, correct these
bogosities, and install the corrected copies in a location private to
GCC.  GCC would look there _first_ for any system header and only
include the "real" system header, from /usr/include, if there wasn't a
private one.

The bad thing about this is that when you built GCC for one version of
the OS, then upgraded to a new version of the OS without reinstalling
GCC, now your compiler was using system headers from the old OS.  Very
bad, esp. for vendors like Sun who feel no compunction about completely
rewriting/rearranging their system headers wth just about every release.

Of course, as new versions came out, the system header copy became less
important as the vendors fixed their own headers.

But, GCC was left for a long time around 2.7.* without any upgrade at
all, so long after it was necessary GCC was copying the system headers
for Solaris.

When 2.8.* and EGCS came out, they fixed this and stopped copying the
system headers: now it has only the fundamental ones like stdarg.h,
etc.

The short story is as I said before: it's very dangerous to use GCC's
before 2.8 with a version of Solaris that it wasn't compiled for.

Even with newer GCC's it _can_ cause problems, but very very rarely.

---

From: Nix <[email-masked]>
Date: 05 Jun 2001 00:28:58 +0100

> system headers: now it has only the fundamental ones like stdarg.h,

Note that this is only the case for Solaris; for nearly all other
systems, GCC does fix headers.

And, yes, fixing headers is a huge kludge; but there's no other real way
to do it. (GCC 3 will be able to warn that a fixed header is outdated,
at least.)

> Even with newer GCC's it _can_ cause problems, but very very rarely.

I'd hedge my bets there and say `less often than before' :) If you're
doing much C++, especially with exceptions, even more especially with
shared libraries or threads, expect breakage when building on one
Solaris OS and running on another.

-- 
`"This code is gross!"  meaning "This code has over 144 compilation errors."'
                                     --- Correct use of English, from jer
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].