%% Paul Eggert <[EMAIL PROTECTED]> writes: pe> It does smell like a 'make' bug to me, though I suppose it could pe> be a kernel or shell bug too. Can you please try the following pe> things?
pe> My suspicion is that your "make" is mishandling these dependencies: pe> cmp.o diff3.o diff.o sdiff.o: paths.h pe> by spinning off multiple subproceses to build cmp.o, diff3.o, etc; pe> and that these subprocesses are each attempting to build paths.h pe> separately. Make will not spin off any subprocesses to handle the .o's that "try to build paths.h"... unless your rule to build a .o includes an invocation of a recursive make which seems unlikely... ? And, at any rate, the algorithm for GNU make will never allow the commands to build a target to be spawned before all of its prerequisites are completed... barring a signal handling problem of the type which is fixed in 3.80 (and assuming no bugs in the kernel/libc in the area of SA_RESTART, signal handling, multiple reads from a single pipe, etc.) pe> If my guess is right, we might have the following sequence of pe> actions, where "1:" denotes subprocess #1 and "2:" denotes pe> subprocess #2: pe> 1: check whether paths.h exists and is up to date; it's not pe> 1: start subshell to create paths.h pe> 1: subshell creates paths.h as an empty, but up-to-date, file pe> 2: check that paths.h exists and is up to date pe> 2: compile diff3.o pe> 2: compilation fails because paths.h is still empty pe> 1: subshell writes data to paths.h I don't understand why subprocess 1 and 2 would be "checking that paths.h exists and is up to date" unless they are both instances of make... and if you have multiple instances of make running in the same directory at the same time, you _definitely_ will have race conditions! It is not the function of make's job server to keep multiple instances of make from bumping into each other: it just limits the total number of concurrent jobs the build will invoke at the same time. Is there something unusual about how the makefile(s) in this package are constructed? pe> If my guess is right, "make --debug=jobs" should report pe> information confirming the suspicion, assuming you can reproduce pe> the bug when the debugging flag is set. I agree, though, that the output of this could be interesting. -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
