Subject: Configure fails on checking argument types of select

From: [email-masked]
Date: Tue, 5 Oct 1999 07:10:08 -0500 (CDT)

Full_Name: Michael Kirby
Version: 2.3.8
CVS_Date: 
OS: SunOS 5.7
X_Server: 
Submission from: (NULL) (208.140.33.201)

I download the 2.3.8 tar file, and run configure, and it bombs on checking
argument types of select.
This is a brand new sun installation, so I can't imagine I have anything 
misconfigured (although its possible).

It does work from the same account in SunOS 5.6.

Does fvwm not work on SunOS 5.7?

Thanks,
Mike

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

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 5 Oct 1999 16:40:46 +0200

> It does work from the same account in SunOS 5.6.

Please post the error message configure generated and the tail
of config.log (where the failing test is logged).  We are
constantly trying to keep fvwm compatible to any OS version.

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: "Michael Kirby" <[email-masked]>
Date: Tue, 5 Oct 1999 11:45:05 -0400

> constantly trying to keep fvwm compatible to any OS version.

The requested files are attached.

I notice that I seem to have a compilation error with gcc.  I've seen 
this before, and I am wondering whether or not I am running the 
right version of gcc (I'm running 2.7.2), or whether or not it is 
installed properly (like do I need to specify include paths properly).

It is possible that the include files in question work fine for Solairs 
2.6, but 2.7 has issues.  Is there a recommended version of gcc for 
use with this?  Or how about pre-built binaries?

Thanks,

Mike

---
[email-masked]
To obtain my PGP public key, mail "SEND PUB KEY" in the 
subject to "[email-masked]"

Tail from Configure:

checking for sysconf... yes
checking for uname... yes
checking for div... yes
checking for sigaction... yes
checking for siginterrupt... yes
checking for getpwuid... yes
checking for sig_atomic_t... yes
checking whether setvbuf arguments are reversed... no
checking for select... yes
checking for unistd.h... (cached) yes
checking for sys/types.h... yes
checking for sys/time.h... yes
checking for sys/select.h... (cached) yes
checking for sys/socket.h... yes
checking argument types of select()... configure: error: can't determine argument types

Tail from config.log:

configure:5168: gcc -c -g -O2  conftest.c 1>&5
In file included from /apps/jas/packages/gnu/sparc-sun-solaris2.5/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2/include/time.h:90,
                 from /usr/include/sys/time.h:405,
                 from configure:5147:
/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 `}'
In file included from configure:5159:
/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
/usr/include/sys/socket.h:56: parse error before `socklen_t'
/usr/include/sys/socket.h:56: warning: data definition has no type or storage class
/usr/include/sys/socket.h:187: parse error before `sa_family_t'
/usr/include/sys/socket.h:187: warning: no semicolon at end of struct or union
/usr/include/sys/socket.h:189: parse error before `}'
/usr/include/sys/socket.h:234: parse error before `socklen_t'
/usr/include/sys/socket.h:234: warning: no semicolon at end of struct or union
/usr/include/sys/socket.h:246: parse error before `}'
/usr/include/sys/socket.h:312: parse error before `socklen_t'
/usr/include/sys/socket.h:312: warning: no semicolon at end of struct or union
/usr/include/sys/socket.h:315: parse error before `}'
/usr/include/sys/socket.h:385: parse error before `socklen_t'
/usr/include/sys/socket.h:386: parse error before `socklen_t'
/usr/include/sys/socket.h:399: parse error before `socklen_t'
/usr/include/sys/socket.h:400: parse error before `socklen_t'
configure: In function `main':
configure:5164: conflicting types for `select'
/usr/include/sys/select.h:97: previous declaration of `select'
configure: failed program was:
#line 5145 "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 (unsigned, 
 void *,	void *, void *,
 const struct timeval *);
; return 0; }

---

From: [email-masked]
Date: Tue, 05 Oct 1999 18:08:39 +0200

> use with this?  Or how about pre-built binaries?

You're probably better off getting binaries for gcc, which you can find at 
sunfreeware.com. If your picky, use those to compile a local gcc.

Either way, the resulting compiler(s) should work a lot better than 2.7.2 
does, and not just for fvwm.

In general, as your header-files and libraries have changed with the 
OS-upgrade, upgrading (or rebuilding) gcc is a good idea. See:

  http://www.fwi.uva.nl/pub/solaris/solaris2/Q6.28.html

/Mattias

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 5 Oct 1999 18:18:34 +0200

> /usr/include/sys/siginfo.h:76: parse error before `}'
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This looks as if the file /usr/include/sys/siginfo.h is broken on your
machine.  Seems to happen quite often with commercial UNIXes.  Can you
see any blatant bugs in that file?  Please send us the relevant portion
of this file (to [email-masked]).

Bye

Dominik ^_^

---

From: [email-masked] (Paul D. Smith)
Date: 05 Oct 1999 12:22:27 -0400

%% "Michael Kirby" <[email-masked]> writes:

  mk> I notice that I seem to have a compilation error with gcc.  I've seen 
  mk> this before, and I am wondering whether or not I am running the 
  mk> right version of gcc (I'm running 2.7.2), or whether or not it is 
  mk> installed properly (like do I need to specify include paths properly).

  mk> It is possible that the include files in question work fine for Solairs 
  mk> 2.6, but 2.7 has issues.  Is there a recommended version of gcc for 
  mk> use with this?  Or how about pre-built binaries?

In general, it's not the version of GCC that matters.  GCC 2.7.2 will
work on Solaris 2.7, _BUT_ you must have compiled GCC on Solaris 2.7.

That is, you can't use a GCC built on Solaris 2.6 to compile programs on
Solaris 2.7.

This is because GCC makes copies of some of the standard header files in
order to fix them up.  Then, when you compile on a different version,
the headers GCC has don't match well with the other headers on the
system (Sun is notorious for making extensive changes to system header
files with every release).

You didn't specify how your GCC was built, but I bet it was built on
Solaris 2.6.

As further info, the latest versions of GCC don't do nearly as much, if
any, of this header copying.  If you get GCC 2.8.1 (I think) or above
(the latest is 2.95.1) you _should_ be able to use the same GCC on
multiple versions of Solaris.  But I haven't tried this myself.

You can get prebuilt GCC binaries from:

  http://www.sunfreeware.com/

You won't be able to configure and build FVWM until the compiler
situation is resolved.

HTH.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "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-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Brad Giaccio <[email-masked]>
Date: Tue, 5 Oct 1999 12:24:23 -0400

On Tue, Oct 05, 1999 at 11:45:05AM -0400, Michael Kirby wrote:
Content-Description: Mail message body
>                  from /usr/include/sys/time.h:405,

You have a compiler built for solaris 2.5 not for 2.7 you need to have a
compiler built on 2.7 in order to compile try.

http://smc.vnet.net/sol7/ and get the package for gcc, please read the
instructions carefully.  And make sure you don't hose the other gcc if
its nfsed.

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: "Michael Kirby" <[email-masked]>
Date: Tue, 12 Oct 1999 14:11:28 -0400

I feel like an idiot, for not being able to figure this out.

I got the binaries for gcc from the sunfreeware site. (very handy site 
by the way).  I also installed XPM (both of them are in the default 
locations in /usr/local).

The problem is it isn't finding XPM.  I've tried setting the --with-xpm-
* settings set, but none of them seem to change anything.

The configure error log indicates that it is finding the XPM.h file, but 
is not able to determine the correct version.  Unfortunately, it 
doesn't seem to print out any error message (like incompatable 
headers, or whatever).  It just says "no" at the bottom of the 
configure output.

Any ideas???

Mike

On 5 Oct 99, at 18:08, [email-masked] wrote:

> > I notice that I seem to have a compilation error with gcc.  I've
> > seen this before, and I am wondering whether or not I am running the
> > It is possible that the include files in question work fine for
> > Solairs 2.6, but 2.7 has issues.  Is there a recommended version of
> > gcc for use with this?  Or how about pre-built binaries?
> 
> You're probably better off getting binaries for gcc, which you can
> find at sunfreeware.com. If your picky, use those to compile a local
> gcc.
> 
> Either way, the resulting compiler(s) should work a lot better than
> 2.7.2 does, and not just for fvwm.
> 
> body of a message to [email-masked]. To report problems, send mail
> to [email-masked]
> 

---
[email-masked]

---

From: [email-masked] (Paul D. Smith)
Date: 12 Oct 1999 15:13:45 -0400

mk> The problem is it isn't finding XPM.  I've tried setting the --with-xpm-
  mk> * settings set, but none of them seem to change anything.

  mk> The configure error log indicates that it is finding the XPM.h file, but 
  mk> is not able to determine the correct version.  Unfortunately, it 
  mk> doesn't seem to print out any error message (like incompatable 
  mk> headers, or whatever).  It just says "no" at the bottom of the 
  mk> configure output.

  mk> Any ideas???

Not until you provide some details.  Exactly what flags are you trying
to give to configure?  Where exactly are the xpm.h and libxpm.a files
installed?  What version of FVWM are you trying to build?

Look in the config.log file and search for "xpm" and you should see
something there about what exactly went wrong.

---

From: "Michael Kirby" <[email-masked]>
Date: Tue, 12 Oct 1999 15:24:52 -0400

On 12 Oct 99, at 15:13, Paul D. Smith wrote:

> to give to configure?  
--with-xpm-library=/usr/local/lib/X11 --with-xpm-
includes=/usr/local/include/X11

> Where exactly are the xpm.h and libxpm.a files
> installed?  

/usr/local/include/xpm.h 
/usr/local/include/X11/xpm.h
/usr/local/lib/libXpm.a
/usr/local/lib/X11/libXpm.a

> What version of FVWM are you trying to build?
> 

2.3.8

> something there about what exactly went wrong.

configure:2372: checking for Xpm 3.4f or better
configure:2389: gcc -o conftest -g -O2  -I/usr/local/include/X11  -I/usr/openwin/inc
lude  conftest.c  -L/usr/local/lib/X11 -lXpm  -L/usr/openwin/lib -R/usr/openwin/lib
 -lSM -lICE -lX11 -lsocket  -lnsl 1>&5
configure: failed program was:
#line 2381 "configure"
#include "confdefs.h"
#include <X11/xpm.h>
   int main(int c, char **v) {
   return c == 1 ? 0 :
     XpmIncludeVersion != XpmLibraryVersion() ? 1 :
     XpmIncludeVersion < 30406 ? 2 : 0 ;}

Mike

---
[email-masked]

---

From: [email-masked] (Paul D. Smith)
Date: 12 Oct 1999 15:38:25 -0400

>> Not until you provide some details.  Exactly what flags are you trying

  mk> --with-xpm-library=/usr/local/lib/X11 --with-xpm-includes=/usr/local/include/X11

OK, the latter is likely incorrect.  Typically you don't put the "/X11"
on the end.  X header files are always #included as <X11/foo.h> so you
don't want the X11 in the -I option.

Use:

  --with-xpm-library=/usr/local/lib/X11 --with-xpm-includes=/usr/local/include

  >> Where exactly are the xpm.h and libxpm.a files

  mk> /usr/local/include/xpm.h 
  mk> /usr/local/include/X11/xpm.h
  mk> /usr/local/lib/libXpm.a
  mk> /usr/local/lib/X11/libXpm.a

Weird.  Why do you have two copies of xmp.h and libXpm.a?  That's just
asking for trouble, esp. if they're different versions :-/.

Did you copy them?  Maybe they're left over from some old version?

Anyway, you _don't_ want the ones in /usr/local/include and
/user/local/lib; you _do_ want the ones in /usr/local/include/X11 and
/usr/local/lib/X11 (actually, the /usr/local/lib vs. /usr/local/lib/X11
is up to you; whichever you prefer--but definitely you need the header
in /usr/local/include/X11).

  >> something there about what exactly went wrong.

  mk> configure:2372: checking for Xpm 3.4f or better
  mk> configure:2389: gcc -o conftest -g -O2  -I/usr/local/include/X11  -I/usr/openwin/inc
  mk> lude  conftest.c  -L/usr/local/lib/X11 -lXpm  -L/usr/openwin/lib -R/usr/openwin/lib
  mk>  -lSM -lICE -lX11 -lsocket  -lnsl 1>&5
  mk> configure: failed program was:
  mk> #line 2381 "configure"
  mk> #include "confdefs.h"
  mk> #include <X11/xpm.h>
  mk>    int main(int c, char **v) {
  mk>    return c == 1 ? 0 :
  mk>      XpmIncludeVersion != XpmLibraryVersion() ? 1 :
  mk>      XpmIncludeVersion < 30406 ? 2 : 0 ;}
 
It doesn't print anything else?  Interesting.

Well, I see the compile line has this:

  ... -I/usr/local/include/X11  -I/usr/openwin/include ...

Since it won't find X11/xpm.h in /usr/local/include/X11, it's probably
the case that you have an old, crusty version of X11/xpm.h in
/usr/openwin/include, and that's what the configure test is using.

Try the above configure flags and see if that works.

---

From: "Michael Kirby" <[email-masked]>
Date: Tue, 12 Oct 1999 17:08:38 -0400

>   --with-xpm-library=/usr/local/lib/X11 --with-xpm-includes=/usr/local/include

Did it.
 
> Did you copy them?  Maybe they're left over from some old version?

The installation from sun installs them there. 

> in /usr/local/include/X11).

I deleted the ones in /usr/local/include and /usr/local/lib.

> /usr/openwin/include, and that's what the configure test is using.

I did a find . -name "xpm.h" -print in the /usr/openwin directory, and 
got nothing.

> Try the above configure flags and see if that works.

I got exactly the same behavior.

I also tried copying and pasting the code that is in the configure 
log, and running it.  I got an error saying it couldn't load libXpm.so.

So I modified my LD_LIBRARY_PATH to contain the 
/usr/local/lib/X11 path.  

This seemed to fix it.

2 comments.

1) Do we need to set this?  I would hope that making this is 
independent of any user shell settings?  Or am I doing something 
elsse wrong, and this was just an akward fix.

2) I think there should be a better error message when it fails (it 
didn't display any message in the config.log file), but when I ran it 
standalone, it gave a clear message.  I'm not sure if this is 
configurable, or something difficult to change because its related to 
configure.

Thaks for your help.  I knew this would be a stupid user problem.

Mike

---
[email-masked]

---

From: "Michael Kirby" <[email-masked]>
Date: Tue, 12 Oct 1999 17:42:07 -0400

> Thaks for your help.  I knew this would be a stupid user problem.

Okay...I'm not quite done being stupid.  I do a make, and 
everything compiles just fine.  I su to root, and do a make install, 
and I get an error with FvwmTalk that aborts the remainder of the 
install.

The error is :

Making install in FvwmForm
echo "#!/bin/sh" > FvwmTalk
sh: FvwmTalk: cannot create

It makes just fine on the construction.  I am root, and this is a local 
file system, so I would think that this isn't a permission problem.  If 
you look in the FvwmForm directory, ther eis a FvwmTalk that 
contains a 2 line bourne shell script.  

There is plenty of disk space.  The target seems to be 
/usr/local/libexec/fvwm/2.3.8/  There are other files there, but no 
FvwmTalk.

Ideas?

Maybe there is some environment variables that need to be set to 
do a make install??

Thanks,
Mike

---
[email-masked]

---

From: [email-masked] (Paul D. Smith)
Date: 12 Oct 1999 18:19:09 -0400

mk> I also tried copying and pasting the code that is in the configure
  mk> log, and running it.  I got an error saying it couldn't load
  libXpm.so.

Oh.  That old bugaboo.  You didn't say you had a shared lib version of
libXpm... I should have remembered to ask.  You're using Solaris?
Obviously.

Well, on Solaris there's a little fun fact that -L options to the linker
are _not_ automatically added to the runtime linker path (the thing that
looks for .so's when you run a program).

You have to explicitly add -R... for each -L... to get that.  Tres
annoying, and autoconf is not smart enough to handle this situation.

So, you have to do something like this (note: sh syntax!):

  $ LDFLAGS=-R/usr/local/lib/X11 ./configure ....

so that the makefile will put -R/usr/local/lib/X11 on the link line and
the runtime linker can find the shared library.

  mk> 1) Do we need to set this?  I would hope that making this is
  mk> independent of any user shell settings?  Or am I doing something
  mk> elsse wrong, and this was just an akward fix.

It's ultimately an autoconf bug: they should DTRT here.  However, I
don't see any signs that they're moving to fix it on the autoconf list.
I'm not sure, myself, what we (FVWM) can/should do about this; I believe
we document this in INSTALL.fvwm... yes, I see it there.  Let me know if
this could be made clearer.

  mk> 2) I think there should be a better error message when it fails
  mk> (it didn't display any message in the config.log file), but when I
  mk> ran it standalone, it gave a clear message.  I'm not sure if this
  mk> is configurable, or something difficult to change because its
  mk> related to configure.

This is basic to configure, unfortunately.  Unless we rewrite the macro
from scratch I don't think there's any way to discover this particular
problem.  The output is thrown out at a low level.

---

From: Dan Espen <[email-masked]>
Date: Tue, 12 Oct 1999 18:33:27 -0400

> contains a 2 line bourne shell script.  

Its a little strange, but the rules to create the 2 line
script in the build directory run during both make and make install.

I can't imagine why you can't write over the file as root, if
you are root on the file system that FvwmTalk is being written to.

Note that its first written in the build area and then installed
in the installation area, so you have to have permissions in both
areas.

> Maybe there is some environment variables that need to be set to 

Nope.

--
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-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: "Michael Kirby" <[email-masked]>
Date: Wed, 13 Oct 1999 12:55:23 -0400

> you are root on the file system that FvwmTalk is being written to.

That's it right there.  I am doing the make as "me."  "Me" has a 
home account NFS mounted on another machine.  Once I build it, I 
am su-ing to root, and running make install.  root has access to 
the installation directory, but not to write to the "Me" account on 
another machine.

I think that a make install (assuming that make has successfully 
run), should NEVER write to the file system of the source directory.

Thanks for all your help.  I seem to have it running just fine.  My 
next project will be to try to get gnome running too :-)

Mike

---
[email-masked]

---

From: [email-masked] (Paul D. Smith)
Date: 13 Oct 1999 14:06:57 -0400

mk> I think that a make install (assuming that make has successfully 
  mk> run), should NEVER write to the file system of the source directory.

I agree, this is definitely a no-no.

Can you submit a bug report on it, so we won't forget to fix it before
2.4?  Thx.

---

From: Dan Espen <[email-masked]>
Date: Wed, 13 Oct 1999 20:46:18 -0400

> Can you submit a bug report on it, so we won't forget to fix it before

The behaviour in question is not just in FvwmForm, its also in FvwmTile
and FvwmCascade, and in the utils directory in fvwmbug.sh.

This is when part of the change was introduced:

Wed Apr 28 20:45:51 1999  Steve Robbins  <[email-masked]>

	* FvwmRearrange/Makefile.am (FvwmCascade):
	* FvwmRearrange/Makefile.am (FvwmTile):
	* FvwmForm/Makefile.am (FvwmTalk): force generation each time.

If I understand why Steve added a dependency on "FORCE", wouldn't
making the dependency on "Makefile" work even better?