So over the weekend I started some testing on different systems just to get a feel for where the code is, portability-wise.
I discovered that the enhancement to use posix_spawn instead of fork/exec results in a number of failed regression tests on older systems. The problem doesn't appear on systems with newer glibc versions which is why I didn't notice it on my development GNU/Linux system. However on GNU/Linux with oldeer glibc, and also on MacOS, regression tests are failing because when we run posix_spawn() to start an executable which doesn't exist we get no error return as we do with exec. For vfork/exec if we use the fast path to start a program that doesn't exist we get this result: $ echo 'all:;./foobarbaz' | make -f- ./foobarbaz make: ./foobarbaz: No such file or directory make: *** [/tmp/GmBtW6cg:1: all] Error 127 But for older glibc and for MacOS, we get this result: ./foobarbaz make: *** [/tmp/GmHL4Q0x:1: all] Error 127 Note there is no error here. This is not good both because it is very confusing and because it means regression tests fail, but it seems the result of a known and accepted deficiency of posix_spawn, as you can read about here: http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm (the "Asynchronous Error Notification" section near the end). The only idea I have so far is to try to detect when this situation occurs (by looking for the 127 exit status) then using stat() to check to see if the binary exists (I suppose I need to check for executable status) and generating the error on my own. I may need to check the PATH as well since we really invoke posix_spawnp(). Ugh. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make