[coreboot] Recent v2 abuild breakage
c-d.hailfinger.devel.2006 at gmx.net
Thu Oct 16 16:05:41 CEST 2008
On 16.10.2008 12:16, Carl-Daniel Hailfinger wrote:
> The recent v2 abuild breakage we're seeing since the move to a new
> massively multiprocessor server may have been caused way back by r3564.
> AFAICS it seems the dependency rules on romcc cause it to be compiled
> twice if certain race conditions happen.
> The v2 build system is sort of a mystery to me, so the following may or
> may not work. I think I can fix this by compiling romcc into a temp file
> and moving the temp file in the right place afterwards. That makes sure
> no two compiler processes try to output to the same file at the same
> time and it also makes sure that the romcc binary will always be runnable.
> Any hints or better fixes are appreciated.
This should fix it.
Can we PLEASE kill v2 ASAP? Thanks!
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
--- LinuxBIOSv2-tmp2/src/config/Config.lb (Revision 3659)
+++ LinuxBIOSv2-tmp2/src/config/Config.lb (Arbeitskopie)
@@ -162,9 +162,16 @@
action "doxygen corebootDoc.config"
+# Yes, the rule doesn't seem to make sense, but multiple images could try to
+# create a romcc binary at the same time, clobbering each other.
+# Our makefile architecture won't allow us to easily have the romcc target
+# in the main makefile, so keep it here and move the race condition winner
+# in place. That way, romcc may get compiled twice, but the binary will always
+# be in a correct and valid state if it exists because the move is atomic.
- action "$(HOSTCC) -g $(HOSTCFLAGS) $< -o $@"
+ action "$(HOSTCC) -g $(HOSTCFLAGS) $< -o romcc.tmpfile"
+ action "mv romcc.tmpfile $@"
More information about the coreboot