[U-Boot] Bug in buildman?

[Simon Glass]

+Masahiro

Hi Andreas,

On 29 January 2015 at 11:05, Andreas Bießmann
<andreas.devel at googlemail.com> wrote:
> Hi Simon,
>
> I add some more descriptive text.
>
> On 29.01.15 18:41, Simon Glass wrote:
>> Hi Andreas,
>>
>> On 31 December 2014 at 05:44, Andreas Bießmann
>> <andreas.devel at googlemail.com> wrote:
>>> Hi Simon,
>>>
>>> while test-building 2015.01-rc4 I encountered following strange
>>> behaviour of buildman:
>>>
>>> ---8<---
>
> This time create non existing /tmp/bar and run the build for all avr32
> boards on the last commit.
>
>>> andreas at andreas-pc % ./tools/buildman/buildman -b buildtest -o /tmp/bar
>>> -v avr32
>>> boards.cfg is up to date. Nothing to do.
>>> Building 1 commit for 10 boards (6 threads, 1 job per thread)
>
> Ok, it starts 6 threads ...
>
>>> 01: Prepare v2015.01-rc4
>>>      avr32: +   atngw100mkii
>>>     0    4    6 /10     0:00:02  : atngw100mkii
>
> Ouch ... six errors, what's going on here? Let's print the errors and
> summary ...
>
>>> ./tools/buildman/buildman -b buildtest -o /tmp/bar -v avr32  82.57s user
>>> 16.90s system 249% cpu 39.899 total
>>> andreas at andreas-pc % ./tools/buildman/buildman -b buildtest -o /tmp/bar
>>> -v -lsed
>
>>> +(grasshopper,atngw100,favr-32-ezkit,atstk1006,atstk1004,hammerhead)
>>> Could not find linker script.
>
>>> w+(atngw100mkii,atstk1002,atstk1003,mimc200) ../tools/kwbimage.c:803:8:
>>> warning: ‘headersz’ may be used uninitialized in this function
>>> [-Wmaybe-uninitialized]
>
> Oups some complains about missing linker script and something is wrong
> with kwbimage .... Let's see what's going on with grasshopper, I know
> this builds fine, so let's see:
>
>>> andreas at andreas-pc % ./tools/buildman/buildman -b buildtest -o /tmp/bar
>>> -v -lsed grasshopper
>>> boards.cfg is up to date. Nothing to do.
>>> Summary of 1 commit for 1 boards (1 thread, 6 jobs per thread)
>>> 01: Prepare v2015.01-rc4
>>>      avr32: +   grasshopper
>>> +(grasshopper)   Could not find linker script.
>>> +(grasshopper) make[1]: *** [prepare1] Error 1
>>> +(grasshopper) make: *** [sub-make] Error 2
>
> Ok, missing linker script. That is wrong, I know grasshopper builds
> fine! So run another build for just the grasshopper board with another
> output directory (/tmp/grasshopper) ... thus a fresh build.
>
>>> andreas at andreas-pc % ./tools/buildman/buildman -b buildtest -o
>>> /tmp/grasshopper -v grasshopper
>>> boards.cfg is up to date. Nothing to do.
>>> Building 1 commit for 1 boards (1 thread, 6 jobs per thread)
>
> Ok, this time it starts just one thread.
>
>>> Cloning repo for thread 0
>>> 01: Prepare v2015.01-rc4
>>>      avr32: +   grasshopper
>>>     0    1    0 /1      grasshopper
>
> Yep, it builds fine (besides the warning) ...
>
>>> ./tools/buildman/buildman -b buildtest -o /tmp/grasshopper -v
>>> grasshopper  14.11s user 2.69s system 183% cpu 9.171 total
>>> andreas at andreas-pc % ./tools/buildman/buildman -b buildtest -o
>>> /tmp/grasshopper -v -lsed grasshopper
>>> boards.cfg is up to date. Nothing to do.
>>> Summary of 1 commit for 1 boards (1 thread, 6 jobs per thread)
>>> 01: Prepare v2015.01-rc4
>>>      avr32: +   grasshopper
>>> w+(grasshopper) ../tools/kwbimage.c: In function ‘kwbimage_set_header’:
>>> w+(grasshopper) ../tools/kwbimage.c:803:8: warning: ‘headersz’ may be
>>> used uninitialized in this function [-Wmaybe-uninitialized]
>
> Ok, the warning is about kwbimage.c. I know this warning and it will be
> fixed soon.
>
> So there must be something wrong when it builds more than one board at a
> time. I guess it has something to do with the threads.

Unless I am much-mistaken this is a Kbuild/Makefile problem rather
than anything to do with buildman. You can use -T to control the
number of threads.

>
>>> buildman complains about missing linker script for most boards which is
>>> an error when building all avr32 boards. While it detects the correct
>>> warning for still not fixed kwbimage.c maybe-uninitialized when building
>>> just the single board which had an error before. Both builds are based
>>> on v2015.01-rc4 and built in different locations.
>>
>> Sorry for not getting back sooner - twice I read your email and tried
>> to understand what is going on.
>
> Sorry for being not clear with my error description. I hope the
> additional thoughts may help.

Yes I understand now.

>
> This happens on current Debian stable (which has python 2.7.3-4+deb7u1)
> but not with Debian testing (which has python 2.7.8-2) nor with my MAC
> box (which has Python 2.7.9, thanks to macports).

I'm copying Masahiro, as I recall he fixed a problem something like
this recently.

Regards,
Simon