bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU make 4.2.90 release candidate available


From: Paul Smith
Subject: Re: GNU make 4.2.90 release candidate available
Date: Mon, 26 Aug 2019 22:59:34 -0400
User-agent: Evolution 3.32.1-2

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.

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]