+Masahiro Hi Andreas,
On 29 January 2015 at 11:05, Andreas Bießmann <andreas.de...@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.de...@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@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@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@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@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@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot