Kevin O'Connor wrote:
I've received a few reports of people having problems building seabios within the coreboot build system. In my investigation I've uncovered at least two problems:
Thank you for identifying these problems!
I would suggest that we add two simple tests to coreboot to catch these problems, until the problems can be completely avoided if that is at all possible.
1 - on my machine, (with CONFIG_ANY_TOOLCHAIN=y) I can't build seabios from corebooat at all because of the LD definition. The .xcompile file gets created with:
LD_x86_32:=ld.bfd -b elf32-i386 -melf_i386
and this gets passed to SeaBIOS as:
make -C payloads/external/SeaBIOS [...] LD="ld.bfd -b elf32-i386 -melf_i386"
unfortunately, the seabios build expects the LD variable to be a program - not the combination of a program and parameters. This breaks the build. (This also seems to happen with AS="as --32".)
If you think it's acceptable for SeaBIOS these variables could be split into two; LD+LDFLAGS, AS+ASFLAGS, etc.
2 - others are reporting problems with python3 even on seabios master (when using coreboot's build chain). This is actually a symptom of a much larger issue - for some reason section names are being corrupted by the tool chain. Here's a quick test case:
echo 'int Foo __attribute__((section( ".data.varfseg." __FILE__ "." "123" )));' > foo.c ; gcc -c foo.c -o foo.o ; objdump -x foo.o | grep varfseg
this should show section names like ".data.varfseg.foo.c.123", but on impacted machines the section names are actually showing up as ".data.varfseg.". This truncation of the section names results in SeaBIOS not being able to weed out unneeded content from the final binary, and it results in the seabios build getting confused on build options.
We should test for this as early as possible; ie. in buildgcc.
Great if SeaBIOS tests for it too.
//Peter