We (as in the Yocto Project/OpenEmbedded) do a lot of builds of busybox and one of the failures we've seen recently was:
https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/908 /steps/BuildImages/logs/stdio It basically shows multiple executions of: "make -f scripts/Makefile.build obj=applets" in parallel which leads to multiple parallel executions of: "applets/applet_tables include/applet_tables.h include/NUM_APPLETS.h" which leads to temporarily truncated files and an eventual: > libbb/appletlib.c:142:5: warning: "NUM_APPLETS" is not defined [ > -Wundef] > #if NUM_APPLETS > 8 > ^~~~~~~~~~~ > libbb/appletlib.c: In function 'find_applet_by_name': > libbb/appletlib.c:151:5: warning: "NUM_APPLETS" is not defined [ > -Wundef] > #if NUM_APPLETS > 8 > ^~~~~~~~~~~ > libbb/appletlib.c:164:13: error: 'NUM_APPLETS' undeclared (first use > in this function) > while (i < NUM_APPLETS) { > ^~~~~~~~~~~ since perhaps applet_tables.h was empty when this ran. I haven't been able to reproduce this at will, it seems related to way the makefile calls make within make, probably leading to a breakdown of locking. I'd prefer not to have to mark the recipe as parallel make unsafe but its looking risky at the moment. 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. I'm hoping someone with a bit more experience of busybox's makefiles/kbuild might be able to spot the issues and fix them? One nastier workaround would be to generate copies of the header files, then move them into position so an invalid copy couldn't be read if the race really can't be fixed. Cheers, Richard _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
