Re: GNU make 4.2.90 release candidate available

[Dennis Clarke]

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.

The entire configure log is there in the tarball and I may stare at it
tomorrow.

> Thanks for sending me links to the other stuff.  I haven't looked at
> them all yet but there seems to be a combination of two things:
>
> First the glob.c/wildcard error. 


Yeah .. that one.   :-\

> 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.


>  It's not clear this can be fixed, at least for GNU libc-based
> systems of a certain vintage.  In any even it's probably a bug that
> needs to be file with the system.

Everything I have is very very recent.

> The second group appears to be for systems that handle posix_spawn()
> errors differently.  If you check the POSIX spec you'll see that error
> handling for posix_spawn() is very tricky.  

POSIX .. I have heard of that :)

> Some systems will fail
> posix_spawn() if the program to be invoked doesn't exist (this is how
> GNU/Linux and MacOS work).  Other programs will have posix_spawn()
> succeed, but then fail the process later.  I think this latter behavior
> is what you're seeing on the systems where you get a lot of errors.
> The diffs I've seen so far are about missing "no such file" messages.
>
> 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.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional