Re: [coreboot] coreboot fails to build in master tree

[Timothy Pearson]

On 05/08/2015 08:20 PM, David Hendricks wrote:
> Hi Timothy,
> We were unable to replicate the failure you're seeing, however it did
> appear that there may be an issue with the builder's environment. There
> were also some patches that appeared to be committed in the wrong order,
> thus causing a missing header error, but there were no merge conflicts
> and after all the patches were merged things were fine. Sol uploaded a
> dummy patch and the coreboot-gerrit builder had no trouble with it.
>
> Do you have more details about the environment in which you're seeing
> this failure?

That's interesting.  Good to know it's isolated at least instead of 
breaking all builds.

Example full build logs are available here:
ASUS KFSN4-DRe: 
https://www.raptorengineeringinc.com/coreboot/autotest/logs/1431127557-0-101...

QEMU x86_64 Q35: 
https://www.raptorengineeringinc.com/coreboot/autotest/logs/1431127541-1-101...

The builders are up to date Debian Jessie systems.

coreboot fails to build in master tree

[Julius Werner]

> Example full build logs are available here:
> ASUS KFSN4-DRe:
> https://www.raptorengineeringinc.com/coreboot/autotest/logs/1431127557-0-101...
>
> QEMU x86_64 Q35:
> https://www.raptorengineeringinc.com/coreboot/autotest/logs/1431127541-1-101...
>
> The builders are up to date Debian Jessie systems.

The errors in these two logs are different than the one you posted.
Are you sure you linked the right ones (do you maybe see multiple
failures)?

In these logs fmd_scanner.o builds fine:

[...]
    HOSTCC     cbfstool/fmd_parser.o
    HOSTCC     cbfstool/fmd_scanner.o
    HOSTCC     cbfstool/fmap.o
[...]

...and then later partitioned_file.o fails without a real error
message, not quite sure what's up there:

[...]
    HOSTCC     cbfstool/fit.o
    HOSTCC     cbfstool/partitioned_file.o
util/cbfstool/Makefile.inc:57: recipe for target
'build/util/cbfstool/partitioned_file.o' failed
cc -O2 -Wall -Werror -iquote ../../src/include -iquote
../../src/src/arch/x86  -c -o cbmem.o cbmem.c
cc   cbmem.o   -o cbmem

Anyway, the failure you copied in your mail looks like it's probably
related to standard library header differences between systems. One of
your /usr/include/xxx.h headers defines a global variable 'input'
while ours doesn't. Not sure if there's really a good way to guarantee
that an identifier isn't going to be declared by some weird header
inclusion chain on any system we'd possibly want to compile on. Maybe
we should just remove -Wshadow from host utilities?