Re: parallel build failure with .c.o rule interrupted mid-step!

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 05 Mar 2025 17:40:11 -0800
    From:        "Greg A. Woods" <woods%planix.ca@localhost>
    Message-ID:  <m1tq0Db-00Mo5fC@more.local>

  | Yes, I think of -v as showing what the shell has read, which is
  | basically true in how it works if I understand correctly,

You do.   Personally I find it to be mostly a waste of space, but
that's perhaps just me.

  | and of course -x shows what it is about to execute.

Yes.

  | In working on this test makefile I quickly found my $ENV had a really
  | big comment before the test where it was deciding it wasn't interactive
  | and so make was showing that whole big comment over and over again!

Then -q makes sense (if you need -v).

  | Hmmmm.... that's exactly what can happen if you set up make with .SHELL
  | to work more like a POSIX shell with full error and echo control, etc.
  | E.g. if there are commands with '-' or '@' flags on a make rule.

The commands in a rule would not be a problem, the only issue if you alter
the -v or -x flags while in $ENV (setting -q in there would be useless)
as I assume .profile is unlikely to be read in a shell invoked by make.

  | If I remember correctly /bin/sh adds 's' to $- when it is reading a
  | script file from stdin,

When it is reading its commands from stdin, yes.   sh < file, cat file|sh
or just "sh" (or sh -s of course).

  | which is, I believe, exactly what make is
  | normally doing (here it is set up in the job's child process):

Hmm - that's a dangerous way to operate, it reverts sh back to having
Thompson shell style semantics - the shell's command input is being
shared as stdin for all the commands that are run, so if anything being
run does anything to affect the position of stdin, almost anything is
possible (particularly as with Bourne type shells, it is much harder
to predict where the shell will have stdin positioned when a command
is executed.   Sending commands through a pipe would be safer, at
least then commands can't alter the position via lseek() only an
actual read would do it, and that would be easier to observe.

I doubt it is the cause of the issue you're seeing though, but it
looks as if you might have found that.   Try
	trap '' PIPE
as an early command in the build recipe.

kre