The patch is attached to the ticket separate from my
comment:

https://savannah.gnu.org/bugs/download.php?file_id=37212

For the first change, it makes no sense to me to propagate a
timestamp on a remade rule to an unremade rule.  Which the
f_mtime() function is doing (verified in debugger) when
called from remake.c:179 (of git tree 4c9e10f).  We could
try to ensure that f_time is never called when it is not
safe to propagate a timestamp to all the double colon rules,
but it is more robust to make f_mtime() itself do the check
so that f_mtime() can be used more freely.

For the second change, notice that the problematic timestamp
propagation was happening at remake.c:179 but, in the
non-parallel case, a loop forcing all the double colon
targets to be remade before that happens at remake.c:358.
But for the parallel case, that loop only queues jobs and
all of the rules will be considered later after the next
reap_children() after the timestamp mistake occurs.

The loop is referenced in the changelog:

1999-12-02  Paul D. Smith  <psmith@gnu.org>

       * remake.c (update_file): Move the considered test outside the
       double-colon loop, _but_ make sure we test the double_colon target
       not the "current" target.  If we stop early because one
       double-colon target is running, mark all the rest considered and
       try to start their prerequisites (so they're marked considered).
       Fix for PR/1476 suggested by Tim Magill <tim.magill@telops.gte.com>.

I don't know what bug 1476 was and don't know how to find it
on the internet, but I suspect it was to fix an issue
regarding an insufficient number of double-colon rules being
run due to the timestamp propagation in f_mtime.  I could be
wrong, but I'll believe this loop is unnecessary until
somebody explains to me why we need it.  I left it in only
to make my change more conservative in that it only impacts
parallel builds with double colons.

Disclosure: I do not understand why other, earlier, calls to
f_mtime() have not been an issue.

Now, supposing I'm wrong about something or that I
misunderstand something, it does not matter much, because it
is easy to prove that my change does not affect any of
make's behavior unless it is running parallel and it
includes double-colons.  A situation that is currently badly
broken and a situation, which, empirically, my change fixes.
So I feel justified in submitting the patch even with an
incomplete understanding.

This patch (double-colons-parallel-bug44742.patch) corrects the attached test case (double_colon_parallel_test.diff).

I believe it fixes this bug.  Test and let me know.

(file #37211)

It definitely does ruin the build. My question is, is this by design or simply a long-standing bug in GNU make? It doesn't happen on BSD make, for instance.

Thanks for taking a look! I tried patching my local GNU make 4.1 per your suggestion, and it hasn't helped. Here is a fuller set of steps to repro:

<code>
# initial setup
cpanm --dev --look PDL
cpanm ExtUtils::MakeMaker@7.05_19 # 7.05* has double-level
perl Makefile.PL
cd Basic/Core

# first time, and show failure with -j4 linkext
make -j4 linkext
ls ../../blib/arch/auto/PDL/Core/Core.so # not found

# keep old files to save time
cp Version.pm Version.pm.KEPT ; cp Types.pm Types.pm.KEPT

# show works with -j4 dynamic
rm -rf ../../blib ; make clean >/dev/null; mv Makefile.old Makefile ; cp Version.pm.KEPT Version.pm ; cp Types.pm.KEPT Types.pm ; make -j4 dynamic ; ls ../../blib/arch/auto/PDL/Core/Core.so

# show works with -j1 linkext
rm -rf ../../blib ; make clean >/dev/null; mv Makefile.old Makefile ; cp Version.pm.KEPT Version.pm ; cp Types.pm.KEPT Types.pm ; make -j1 linkext; ls ../../blib/arch/auto/PDL/Core/Core.so

# show fails again/still with -j4 linkext
rm -rf ../../blib ; make clean >/dev/null; mv Makefile.old Makefile ; cp Version.pm.KEPT Version.pm ; cp Types.pm.KEPT Types.pm ; make -j4 linkext; ls ../../blib/arch/auto/PDL/Core/Core.so
</code>

This is a problem for EUMM since it's a bug that affects already-existing GNU make, so I'm going to have to find a way to make this not happen for current GNU make. However, it also seems like it would be worth finding and fixing this.

(file #34568)

Sorry but I can't understand your repro case, or at least I can't reproduce it.  The makefile you link here doesn't appear to be a stand-alone repro case; if I run it by itself I just get errors about missing Makefile.PL.

If I install cpanm then run the command in your "full repro by" line, it builds (after I install some other Perl prerequisites) but I don't get the error you see: running with/without -j4 it always successfully creates the Core.so file.

If I try the commands you list below, removing, running make clean, etc. (it's not clear whether the "Makefile" you're copying is the one you attached here or the one left over from "make clean", but neither seem to work for me) I don't have any .KEPT files and I get errors about not being able to locate PDL/Types.pm.

However, someone sent me a fix which may be related to this.  If you edit the file remake.c in the GNU make sources around line 351 and change:

            if (new > status)
              new = status;

to this:

            if (new > status)
              status = new;

(Note there is another similar if-statement earlier in the function which already has "status = new"; they should both be that way.)

See if that change helps; I cannot reproduce your problem so I cannot check it myself.