On filesystems with subsecond resolution, like ext4, we can't trust the
timestamp of aconfig.h.in since autoheader leaves it truncated to second
resolution (apparently touch -r and cp -p can do this at the very least)
while configure has full subsecond resolution, so it can look newer even
when it was cleanly created first, leading to the build system looping
trying to recreate all of that again ...
So in the initial stage of a clean build we can get something like this:
$ make spotless
$ make autoconf
rm -rf MCONFIG configure config.log aconfig.h *.cache
autoconf
rm -f aconfig.h.in aconfig.h
autoheader
$ stat configure aconfig.h.in
File: ‘configure’
Device: 807h/2055d Inode: 9443466 Links: 1
Access: 2014-07-31 03:27:27.599293442 +0930
Modify: 2014-07-31 03:27:27.711290270 +0930
Change: 2014-07-31 03:27:27.711290270 +0930
File: ‘aconfig.h.in’
Device: 807h/2055d Inode: 9443467 Links: 1
Access: 2014-07-31 03:27:27.000000000 +0930
Modify: 2014-07-31 03:27:27.000000000 +0930
Change: 2014-07-31 03:27:27.903284841 +0930
And with a parallel build, that can then leave 'make all' racing to
remove and recreate aconfig.h (and possibly more things), while it
begins to build the first targets. Which then fail horribly like
we see here:
https://buildd.debian.org/status/fetch.php?pkg=tftp-hpa&arch=i386&ver=5.2%2B20140608-1&stamp=1406736363
Possibly we also need to move the actual build job into the rule for
the 'all' target, so that the build system update prerequisites are
guaranteed to be completed before it runs (as opposed to running in
parallel with them), but this change might be enough for now.
Signed-off-by: Ron Lee <ron@debian.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
if you try to build tftp-hpa in parallel, it may fail as the tftp and tftpd
subdirs may try to link before the libcommon.a has a chance to be generated
in the common subdir
trivial patch attached to address this
-mike
