Re: diffutils 2.8.4 bug when make -j is used

[Paul Eggert]

> From: Chris Bainbridge <address@hidden>
> Date: Sun, 13 Oct 2002 11:43:51 +0100

> make 3.79.1. bash 2.05a. 
> 
> I've been testing some more. I have only seen the problem at make
> -j5 or -j6.  Even then its intermittent. I tried it on 2
> computers. It doesn't show up at all on a p3-700, only on
> p4-1600.

Yes, I'm afraid that timing bugs like this tend to be intermittent.

It does smell like a 'make' bug to me, though I suppose it could be a
kernel or shell bug too.  Can you please try the following things?

 * Try using GNU make 3.80 instead.  It has some fixes in this area, and
   perhaps your bug is already fixed in 3.80.

 * If that doesn't work, try "make -j5 --debug=jobs" with make 3.80,
   and send us the output of a failed build.

My suspicion is that your "make" is mishandling these dependencies:

        cmp.o diff3.o diff.o sdiff.o: paths.h
        paths.h:
                (echo '#define DEFAULT_DIFF_PROGRAM "$(bindir)/'`echo diff|sed 
'$(transform)'`'"' && \
                 echo '#define LOCALEDIR "$(localedir)"') >$@

by spinning off multiple subproceses to build cmp.o, diff3.o, etc;
and that these subprocesses are each attempting to build paths.h separately.
If my guess is right, we might have the following sequence of actions,
where "1:" denotes subprocess #1 and "2:" denotes subprocess #2:

  1: check whether paths.h exists and is up to date; it's not
  1: start subshell to create paths.h
  1: subshell creates paths.h as an empty, but up-to-date, file
  2: check that paths.h exists and is up to date
  2: compile diff3.o
  2: compilation fails because paths.h is still empty
  1: subshell writes data to paths.h

If my guess is right, "make --debug=jobs" should report information
confirming the suspicion, assuming you can reproduce the bug when
the debugging flag is set.