On Tue, 2019-08-27 at 01:21 -0400, Dennis Clarke wrote: > On 8/26/19 10:59 PM, Paul Smith wrote: > > On Mon, 2019-08-26 at 19:33 -0400, Dennis Clarke wrote: > > > I'll dig into this but on RHEL 7.4 x86_64 we see : > > > > > > src/job.c: In function 'reap_children': > > > src/job.c:754:17: error: incompatible type for argument 1 of 'wait' > > > EINTRLOOP (pid, wait (&status)); > > > > That is REALLY disturbing, because it means that configure couldn't > > detect either waitpid() or wait3(), both of which have been available > > since approximately forever. Something went badly wrong with the > > configure run on this system. > > I know and it was a show stopper for me. I just had to stop and stare > at my coffee cup after trying this across a bunch of machines.
If I'm reading the downloads you provided correctly it seems there are a bunch of extra flags being added to the compile and link lines: > CFLAGS='-std=iso9899:1999 -m64 -g -march=opteron -Wl,- > rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -O0 -malign-double > -mpc80' > export CFLAGS > > CPPFLAGS='-I/opt/bw/include -D_POSIX_PTHREAD_SEMANTICS -D_TS_ERRNO' > export CPPFLAGS > > EDITOR=/bin/vi > export EDITOR > > LDFLAGS='-Wl,-rpath=/opt/bw/lib,--enable-new-dtags' > export LDFLAGS > > LD_RUN_PATH=/opt/bw/lib > export LD_RUN_PATH I wonder if some of these options are causing the problem? I'm not sure what /opt/bw contains or why these extra -D options are given. What are the results if you simply invoke ./configure without any settings for any of these build variables? > > Note that this is not a new error: > > it's always been like this. What's new is (a) the test which shows > > the problem, and (b) that it _doesn't_ fail on some sufficiently new > > systems. > > Right !! I did this and had others watching and we were all wondering > why Debian stable was happy and Debian sid had a fit. Of course there > was also the x86_64 versus i686 architecture there too. Well, the situation is a bit complicated. First, it depends on whether GNU make configure chooses the glob/fnmatch that comes with GNU make or the system version. If it chooses the one that comes with GNU make, you will see the error (!!) because our glob/fnmatch is too old. If it chooses the system version (configure detects that you have GNU libc) then it depends on whether the system version has this bug fixed in it or not. For Debian, it doesn't look to me like Debian sid had this error though; I didn't see any failure of the wildcard function in the logs for that. There were other problems, seeming to do with order of output etc. > > I thought about trying to handle this but (1) it's a bit annoying and > > (2) I didn't know if there were any systems that used this latter > > behavior. Looks like there might be. > > Sounds like whiskey in my coffee cup tomorrow to look at this all again. I have a patch that may work for this posix_spawn() issue. The only really tricky part is getting the error message right. If you wanted to just give it a try on one of the systems you could add the --disable-posix-spawn option to configure and see what happens. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
