Re: GNU make 4.2.90 release candidate available

[Paul Smith]

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.