Parallel make bug in busybox

[Jeremy Chadwick]

On Sat, Aug 13, 2016 at 10:29:38PM +0200, Denys Vlasenko wrote:
> On Fri, Aug 12, 2016 at 8:53 AM, Richard Purdie <rpurdie at rpsys.net> wrote:
> > We (as in the Yocto Project/OpenEmbedded) do a lot of builds of busybox
> > One way I did find of breaking the build was:
> >
> > make; rm libbb/appletlib.o include/NUM_APPLETS.h; make
> >
> > which results in:
> >
> > CC      shell/ash.o
> > shell/ash.c:59:25: fatal error: NUM_APPLETS.h: No such file or
> > directory
> >
> > since NUM_APPLETS.h doesn't get regenerated by "make prepare" after its
> > deleted.
> 
> Makefile hell....
> 
> I can reproduce this, yes.
> 
> When I then run
> 
> make --debug=a -p libbb/lineedit.o >LOG
> 
> I find gobs of data in LOG, and grepping for NUM_APPLETS.h
> 
> 
> include/NUM_APPLETS.h: applets/applet_tables
> #  Implicit rule search has not been done.
> #  Modification time never checked.
> #  File has not been updated.
> #  recipe to execute (from 'applets/Kbuild', line 48):
>         $(call cmd,gen_applet_tables)
> ...
> ...
>   Considering target file 'include/NUM_APPLETS.h'.
>    File 'include/NUM_APPLETS.h' does not exist.
>    Looking for an implicit rule for 'include/NUM_APPLETS.h'.
>    No implicit rule found for 'include/NUM_APPLETS.h'.
>    Finished prerequisites of target file 'include/NUM_APPLETS.h'.
>   Must remake target 'include/NUM_APPLETS.h'.
>   Successfully remade target file 'include/NUM_APPLETS.h'.
> 
> 
> Erm... no, you did not "successfully remade target file",
> stupid machine! It does not run anything! while thinking that
> it "successfully remade target file". (I double-checked).
> 
> My google-fu turned up nothing.
> Any ideas whats' going on?

I normally don't respond to things "vaguely" and like giving concise
evidence/details, and I haven't looked at these Makefiles, but:

A common pitfall with make is it being used on systems which are not
running ntpd.  make relies on file mtime, and clocks can drift forward
or backwards, which can confuse make if the timekeeping hardware tends
to drift rapidly.  ntpd (unlike, say, a cronjob that runs ntpdate)
can deal with this by using adjtime(2) or ntp_adjtime(2) to "skew"
the clock in very tiny amounts (often granular enough that make and
most anything else doesn't notice).  I think chrony also functions
similarly in this regard.

Another thing I've seen with parallel make going "haywire" is when
using commands that shell out to external utilities that create files
natively that later recipes rely on.

I would suggest experimenting with .PHONY and/or .NOTPARALLEL.  Refer to
the GNU make manual (the docs on .PHONY are good):
https://www.gnu.org/software/make/manual/html_node/Special-Targets.html

-- 
| Jeremy Chadwick                                   jdc at koitsu.org |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Making life hard for others since 1977.             PGP 4BD6C0CB |