* [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-24
@ 2014-08-25 6:30 Thomas Petazzoni
2014-08-25 16:16 ` [Buildroot] Analysis of build results Thomas Petazzoni
0 siblings, 1 reply; 37+ messages in thread
From: Thomas Petazzoni @ 2014-08-25 6:30 UTC (permalink / raw)
To: buildroot
Build statistics for 2014-08-24
===============================
success : 116
failures : 16
timeouts : 0
TOTAL : 132
Classification of failures by reason
====================================
xapp_luit-1.1.1 | 1
util-linux-2.24.2 | 1
uboot-tools-2014.07 | 1
perl-gd-2.53 | 1
sispmctl-3.1 | 1
upmpdcli-0.7.1 | 1
xscreensaver-5.22 | 1
libgeotiff-1.3.0 | 1
procps-ng-3.3.9 | 1
zmqpp-36413487f05b165dfc82a... | 1
libmatroska-1.3.0 | 1
make: *** [core-dependencie... | 1
webkit-1.11.5 | 1
elfutils-0.155 | 1
xserver_xorg-server-1.16.0 | 1
xapp_xfs-1c8459eafc04997751... | 1
Detail of failures
===================
arm | elfutils-0.155 | NOK | http://autobuild.buildroot.net/results/e2449b2a4f2239e832adc2f51f0c7266808b7068/
bfin | libgeotiff-1.3.0 | NOK | http://autobuild.buildroot.net/results/24ab80be6cc20bbdb2f1860a373f1d15e36ac0c6/
bfin | libmatroska-1.3.0 | NOK | http://autobuild.buildroot.net/results/f9689e9606844f24d13fa08c3cb9f6b9bb3adf70/
arm | make: *** [core-dependencie... | NOK | http://autobuild.buildroot.net/results/13019e563771ab2a6929427798e191546cde1fd9/
arm | perl-gd-2.53 | NOK | http://autobuild.buildroot.net/results/38aeac634b332866ae50b6b59361d7385500ce37/
arm | procps-ng-3.3.9 | NOK | http://autobuild.buildroot.net/results/f1de9bdf857ca0347ecd23c0d39179dadfd9ec97/
mipsel | sispmctl-3.1 | NOK | http://autobuild.buildroot.net/results/6473088e751d3ab3a5227e9d7876966934e66378/
bfin | uboot-tools-2014.07 | NOK | http://autobuild.buildroot.net/results/1530f8247d1652da5779994f298141b1572ce74f/
bfin | upmpdcli-0.7.1 | NOK | http://autobuild.buildroot.net/results/8e0db6a753c7d2af2cdb11f025879c9cdb57a25d/
nios2 | util-linux-2.24.2 | NOK | http://autobuild.buildroot.net/results/fd30974bf2f976c600717268ce340f73d48dda34/
sh4 | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/55205239b74015b7b9e8dce898d89e5246e81846/
bfin | xapp_luit-1.1.1 | NOK | http://autobuild.buildroot.net/results/13a97461e3b6098e59cfcd829e6bcafa51e50bb4/
bfin | xapp_xfs-1c8459eafc04997751... | NOK | http://autobuild.buildroot.net/results/7a89f79499e167cc98449a045604d25d4fc88484/
powerpc | xscreensaver-5.22 | NOK | http://autobuild.buildroot.net/results/2c10e5bda7c5426feb95f8e9d7052945274aefa2/
microblazeel | xserver_xorg-server-1.16.0 | NOK | http://autobuild.buildroot.net/results/4d37c5594c0916c27c897b0d2545d1c5cc492598/
bfin | zmqpp-36413487f05b165dfc82a... | NOK | http://autobuild.buildroot.net/results/97bcfe2d3765945cd7a7ba30cda21b08bf53ca86/
--
http://autobuild.buildroot.net
^ permalink raw reply [flat|nested] 37+ messages in thread* [Buildroot] Analysis of build results 2014-08-25 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-24 Thomas Petazzoni @ 2014-08-25 16:16 ` Thomas Petazzoni 2014-08-25 16:26 ` Phil Eichinger ` (4 more replies) 0 siblings, 5 replies; 37+ messages in thread From: Thomas Petazzoni @ 2014-08-25 16:16 UTC (permalink / raw) To: buildroot Hello, Joerg, Phil, Ezequiel, Simon, Alexander, see below. On Mon, 25 Aug 2014 08:30:11 +0200 (CEST), Thomas Petazzoni wrote: > arm | elfutils-0.155 | NOK | http://autobuild.buildroot.net/results/e2449b2a4f2239e832adc2f51f0c7266808b7068/ -shared and -static in the same command line :) > bfin | libgeotiff-1.3.0 | NOK | http://autobuild.buildroot.net/results/24ab80be6cc20bbdb2f1860a373f1d15e36ac0c6/ checking for TIFFOpen in -ltiff... no configure: error: You will need to substantially rewrite libxtiff to build libgeotiff without libtiff Don't know, need to reproduce. > bfin | libmatroska-1.3.0 | NOK | http://autobuild.buildroot.net/results/f9689e9606844f24d13fa08c3cb9f6b9bb3adf70/ Seems like it's trying to build a shared library in a pure static library context. > arm | make: *** [core-dependencie... | NOK | http://autobuild.buildroot.net/results/13019e563771ab2a6929427798e191546cde1fd9/ Peter's machine trying to build XBMC. Peter, when will you start using autobuild-run so that we can solve such issues in a common fashion? > arm | perl-gd-2.53 | NOK | http://autobuild.buildroot.net/results/38aeac634b332866ae50b6b59361d7385500ce37/ Issue caused by the host Perl being too old. I continue to suggest to mark perl-gd as broken for the 2014.08 release. > arm | procps-ng-3.3.9 | NOK | http://autobuild.buildroot.net/results/f1de9bdf857ca0347ecd23c0d39179dadfd9ec97/ So after the compiler has been used to build gazillions of packages, procps-ng decides that the C compiler does not work: checking whether the C compiler works... no configure: error: in `/home/test/autobuild/instance-3/output/build/procps-ng-3.3.9': configure: error: C compiler cannot create executables See `config.log' for more details make: *** [/home/test/autobuild/instance-3/output/build/procps-ng-3.3.9/.stamp_configured] Error 77 Need to reproduce. And someone should work on improving autobuild-run to store the config.log file when available. > mipsel | sispmctl-3.1 | NOK | http://autobuild.buildroot.net/results/6473088e751d3ab3a5227e9d7876966934e66378/ Static linking issue. Phil, since you are the original submitter of the sispmctl package, can you look into this issue? > bfin | uboot-tools-2014.07 | NOK | http://autobuild.buildroot.net/results/1530f8247d1652da5779994f298141b1572ce74f/ Someone tries to strip FLAT binaries. > bfin | upmpdcli-0.7.1 | NOK | http://autobuild.buildroot.net/results/8e0db6a753c7d2af2cdb11f025879c9cdb57a25d/ libupnpp/log.cxx:31: error: no matching function for call to 'std::basic_ofstream<char, std::char_traits<char> >::open(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::_Ios_Openmode)' I love C++. Joerg, since you are the original submitter of the upmpdcli package, can you look into this issue? > nios2 | util-linux-2.24.2 | NOK | http://autobuild.buildroot.net/results/fd30974bf2f976c600717268ce340f73d48dda34/ sys-utils/prlimit.o: In function `main': prlimit.c:(.text.startup+0x440): undefined reference to `prlimit64' prlimit.c:(.text.startup+0x5d0): undefined reference to `prlimit64' collect2: error: ld returned 1 exit status Ezequiel, an idea? > sh4 | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/55205239b74015b7b9e8dce898d89e5246e81846/ Some tuning is needed to get webkit to build on SH4. However, I would propose to mark Webkit as not available on SuperH, until we bump to a newer Webkit version. ./DerivedSources/JavaScriptCore/LLIntAssembly.h: In static member function 'static JSC::JSValue JSC::LLInt::CLoop::execute(JSC::CallFrame*, JSC::OpcodeID, bool)': ./DerivedSources/JavaScriptCore/LLIntAssembly.h:2548:33: error: 'Double2Ints' was not declared in this scope CXX Source/JavaScriptCore/parser/libjavascriptcoregtk_1_0_la-Lexer.lo > bfin | xapp_luit-1.1.1 | NOK | http://autobuild.buildroot.net/results/13a97461e3b6098e59cfcd829e6bcafa51e50bb4/ luit.o: In function `_main': luit.c:(.text+0xbce): undefined reference to `_fork' depends on BR2_USE_MMU > bfin | xapp_xfs-1c8459eafc04997751... | NOK | http://autobuild.buildroot.net/results/7a89f79499e167cc98449a045604d25d4fc88484/ osglue.o: In function `_CloneMyself': os/osglue.c:(.text+0x58): undefined reference to `_fork' depends on BR2_USE_MMU > powerpc | xscreensaver-5.22 | NOK | http://autobuild.buildroot.net/results/2c10e5bda7c5426feb95f8e9d7052945274aefa2/ Another compiler that doesn't work: checking for C compiler default output file name... configure: error: in `/home/test/autobuild/instance-2/output/build/xscreensaver-5.22': configure: error: C compiler cannot create executables See `config.log' for more details. > microblazeel | xserver_xorg-server-1.16.0 | NOK | http://autobuild.buildroot.net/results/4d37c5594c0916c27c897b0d2545d1c5cc492598/ In file included from fbbits.c:27:0: fb.h:94:2: error: #error "GLYPHPADBYTES must be 4" #error "GLYPHPADBYTES must be 4" Weird, that's typically when the X.org server is built for an unsupported architecture. We never built the X.org server on Microblaze so far? > bfin | zmqpp-36413487f05b165dfc82a... | NOK | http://autobuild.buildroot.net/results/97bcfe2d3765945cd7a7ba30cda21b08bf53ca86/ Did I say I love C++ ? The same issue appears on other architectures apparently: http://autobuild.buildroot.org/?reason=zmqpp-36413487f05b165dfc82ad307a5a1c36a795e607. Simon, you're the original submitter of the zmqpp package. Could you take a look? Or maybe Alexander since he has also contributed a bump of the zmqpp package? Thanks! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2014-08-25 16:16 ` [Buildroot] Analysis of build results Thomas Petazzoni @ 2014-08-25 16:26 ` Phil Eichinger 2014-08-25 17:47 ` Thomas Petazzoni 2014-08-25 21:07 ` Peter Korsgaard ` (3 subsequent siblings) 4 siblings, 1 reply; 37+ messages in thread From: Phil Eichinger @ 2014-08-25 16:26 UTC (permalink / raw) To: buildroot On 25 August 2014 18:16, Thomas Petazzoni < thomas.petazzoni@free-electrons.com> wrote: > Hello, > *snip* > mipsel | sispmctl-3.1 | NOK | > http://autobuild.buildroot.net/results/6473088e751d3ab3a5227e9d7876966934e66378/ > > Static linking issue. > > Phil, since you are the original submitter of the sispmctl package, can > you look into this issue? > Yep, no problem, going to need it on mipsel soon anyway. Cheers, Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140825/40f11b40/attachment.html> ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2014-08-25 16:26 ` Phil Eichinger @ 2014-08-25 17:47 ` Thomas Petazzoni 0 siblings, 0 replies; 37+ messages in thread From: Thomas Petazzoni @ 2014-08-25 17:47 UTC (permalink / raw) To: buildroot Dear Phil Eichinger, On Mon, 25 Aug 2014 18:26:04 +0200, Phil Eichinger wrote: > > mipsel | sispmctl-3.1 | NOK | > > http://autobuild.buildroot.net/results/6473088e751d3ab3a5227e9d7876966934e66378/ > > > > Static linking issue. > > > > Phil, since you are the original submitter of the sispmctl package, can > > you look into this issue? > > > > Yep, no problem, going to need it on mipsel soon anyway. Ok, thanks. However, notice that the issue is not mipsel related, but related to static linking. I'm pretty sure the same issue can be reproduced on other architectures. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2014-08-25 16:16 ` [Buildroot] Analysis of build results Thomas Petazzoni 2014-08-25 16:26 ` Phil Eichinger @ 2014-08-25 21:07 ` Peter Korsgaard 2014-08-25 21:13 ` Jörg Krause ` (2 subsequent siblings) 4 siblings, 0 replies; 37+ messages in thread From: Peter Korsgaard @ 2014-08-25 21:07 UTC (permalink / raw) To: buildroot >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: Hi, >> arm | make: *** [core-dependencie... | NOK | http://autobuild.buildroot.net/results/13019e563771ab2a6929427798e191546cde1fd9/ > Peter's machine trying to build XBMC. Peter, when will you start using > autobuild-run so that we can solve such issues in a common fashion? I'm just back from holidays now, but it's on my shortlist to move to autobuild-run asap (E.G. still within August). -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2014-08-25 16:16 ` [Buildroot] Analysis of build results Thomas Petazzoni 2014-08-25 16:26 ` Phil Eichinger 2014-08-25 21:07 ` Peter Korsgaard @ 2014-08-25 21:13 ` Jörg Krause 2014-08-26 6:17 ` Alexander Lukichev 2014-08-28 12:52 ` Ezequiel Garcia 4 siblings, 0 replies; 37+ messages in thread From: Jörg Krause @ 2014-08-25 21:13 UTC (permalink / raw) To: buildroot On 08/25/2014 06:16 PM, Thomas Petazzoni wrote: > >> bfin | upmpdcli-0.7.1 | NOK | http://autobuild.buildroot.net/results/8e0db6a753c7d2af2cdb11f025879c9cdb57a25d/ > libupnpp/log.cxx:31: error: no matching function for call to 'std::basic_ofstream<char, std::char_traits<char> >::open(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::_Ios_Openmode)' > > I love C++. > > Joerg, since you are the original submitter of the upmpdcli package, > can you look into this issue? I love C++, too :-) Especially C++11, which is not supported by GNU Toolchains for Blackfin. Patch is send to the mailing list. ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2014-08-25 16:16 ` [Buildroot] Analysis of build results Thomas Petazzoni ` (2 preceding siblings ...) 2014-08-25 21:13 ` Jörg Krause @ 2014-08-26 6:17 ` Alexander Lukichev 2014-08-28 12:52 ` Ezequiel Garcia 4 siblings, 0 replies; 37+ messages in thread From: Alexander Lukichev @ 2014-08-26 6:17 UTC (permalink / raw) To: buildroot Hi Thomas, all, 2014-08-25 19:16 GMT+03:00 Thomas Petazzoni < thomas.petazzoni@free-electrons.com>: > > bfin | zmqpp-36413487f05b165dfc82a... | NOK | > http://autobuild.buildroot.net/results/97bcfe2d3765945cd7a7ba30cda21b08bf53ca86/ > > Did I say I love C++ ? > > The same issue appears on other architectures apparently: > > http://autobuild.buildroot.org/?reason=zmqpp-36413487f05b165dfc82ad307a5a1c36a795e607 > . > > Simon, you're the original submitter of the zmqpp package. Could you > take a look? Or maybe Alexander since he has also contributed a bump of > the zmqpp package? > > I'll try to solve some of those, at least I'll look into it. There seems to be several issues there, though. -- Best regards, Alexander Lukichev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140826/ddf46931/attachment.html> ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2014-08-25 16:16 ` [Buildroot] Analysis of build results Thomas Petazzoni ` (3 preceding siblings ...) 2014-08-26 6:17 ` Alexander Lukichev @ 2014-08-28 12:52 ` Ezequiel Garcia 2014-08-31 16:58 ` Frank Bergmann 4 siblings, 1 reply; 37+ messages in thread From: Ezequiel Garcia @ 2014-08-28 12:52 UTC (permalink / raw) To: buildroot (Ccing Frank) On 25 Aug 06:16 PM, Thomas Petazzoni wrote: > > nios2 | util-linux-2.24.2 | NOK | http://autobuild.buildroot.net/results/fd30974bf2f976c600717268ce340f73d48dda34/ > > sys-utils/prlimit.o: In function `main': > prlimit.c:(.text.startup+0x440): undefined reference to `prlimit64' > prlimit.c:(.text.startup+0x5d0): undefined reference to `prlimit64' > collect2: error: ld returned 1 exit status > > Ezequiel, an idea? > This is probably the same missing fallocate64 deal. The function is simply not available, yet detected (Frank: please correct me if I'm wrong). By doing something similar to what we do for e2fsprogs: +ifeq ($(BR2_nios2),y) +UTIL_LINUX_CONF_ENV += ac_cv_func_prlimit=no +endif + I can avoid the SYS_prlimit64 usage. However, we then get conflicting types: CC sys-utils/prlimit.o CC sys-utils/lscpu.o sys-utils/prlimit.c:139:12: error: conflicting types for 'prlimit' In file included from /home/zeta/buildroot/buildroot-nios2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/sys/resource.h:25:0, from sys-utils/prlimit.c:28: /home/zeta/buildroot/buildroot-nios2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/bits/resource.h:313:12: note: previous declaration of 'prlimit' was here I wonder if anyone has an idea to disable the prlimit build, and all the commands that depend on it. Notice that we have a similar issue on other packages, but the proposed solution's have been too hacky to be accepted: http://lists.busybox.net/pipermail/buildroot/2014-May/096203.html -- Ezequiel Garc?a, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2014-08-28 12:52 ` Ezequiel Garcia @ 2014-08-31 16:58 ` Frank Bergmann 2014-08-31 21:13 ` Ezequiel Garcia 0 siblings, 1 reply; 37+ messages in thread From: Frank Bergmann @ 2014-08-31 16:58 UTC (permalink / raw) To: buildroot On 28.08.2014 Ezequiel Garcia wrote: > (Ccing Frank) > > On 25 Aug 06:16 PM, Thomas Petazzoni wrote: >>> nios2 | util-linux-2.24.2 | NOK | http://autobuild.buildroot.net/results/fd30974bf2f976c600717268ce340f73d48dda34/ >> >> sys-utils/prlimit.o: In function `main': >> prlimit.c:(.text.startup+0x440): undefined reference to `prlimit64' >> prlimit.c:(.text.startup+0x5d0): undefined reference to `prlimit64' >> collect2: error: ld returned 1 exit status >> >> Ezequiel, an idea? >> > > This is probably the same missing fallocate64 deal. The function is simply not > available, yet detected (Frank: please correct me if I'm wrong). > > By doing something similar to what we do for e2fsprogs: > > +ifeq ($(BR2_nios2),y) > +UTIL_LINUX_CONF_ENV += ac_cv_func_prlimit=no > +endif > + > > I can avoid the SYS_prlimit64 usage. However, we then get conflicting types: > > CC sys-utils/prlimit.o > CC sys-utils/lscpu.o > sys-utils/prlimit.c:139:12: error: conflicting types for 'prlimit' > In file included from /home/zeta/buildroot/buildroot-nios2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/sys/resource.h:25:0, > from sys-utils/prlimit.c:28: > /home/zeta/buildroot/buildroot-nios2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/bits/resource.h:313:12: note: previous declaration of 'prlimit' was here > > I wonder if anyone has an idea to disable the prlimit build, and all the > commands that depend on it. > > Notice that we have a similar issue on other packages, but the proposed > solution's have been too hacky to be accepted: > > http://lists.busybox.net/pipermail/buildroot/2014-May/096203.html I see a new toolchain on the mentor site: 2014.05-47 from August. Maybe this release fixes some of the issues we have with the current toolchain. I will make some tests in the next week(s). Regards, Frank Bergmann. ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2014-08-31 16:58 ` Frank Bergmann @ 2014-08-31 21:13 ` Ezequiel Garcia 0 siblings, 0 replies; 37+ messages in thread From: Ezequiel Garcia @ 2014-08-31 21:13 UTC (permalink / raw) To: buildroot On 31 Aug 06:58 PM, Frank Bergmann wrote: > On 28.08.2014 Ezequiel Garcia wrote: > >(Ccing Frank) > > > >On 25 Aug 06:16 PM, Thomas Petazzoni wrote: > >>> nios2 | util-linux-2.24.2 | NOK | http://autobuild.buildroot.net/results/fd30974bf2f976c600717268ce340f73d48dda34/ > >> > >>sys-utils/prlimit.o: In function `main': > >>prlimit.c:(.text.startup+0x440): undefined reference to `prlimit64' > >>prlimit.c:(.text.startup+0x5d0): undefined reference to `prlimit64' > >>collect2: error: ld returned 1 exit status > >> > >>Ezequiel, an idea? > >> > > > >This is probably the same missing fallocate64 deal. The function is simply not > >available, yet detected (Frank: please correct me if I'm wrong). > > > >By doing something similar to what we do for e2fsprogs: > > > >+ifeq ($(BR2_nios2),y) > >+UTIL_LINUX_CONF_ENV += ac_cv_func_prlimit=no > >+endif > >+ > > > >I can avoid the SYS_prlimit64 usage. However, we then get conflicting types: > > > > CC sys-utils/prlimit.o > > CC sys-utils/lscpu.o > >sys-utils/prlimit.c:139:12: error: conflicting types for 'prlimit' > >In file included from /home/zeta/buildroot/buildroot-nios2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/sys/resource.h:25:0, > > from sys-utils/prlimit.c:28: > >/home/zeta/buildroot/buildroot-nios2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/bits/resource.h:313:12: note: previous declaration of 'prlimit' was here > > > >I wonder if anyone has an idea to disable the prlimit build, and all the > >commands that depend on it. > > > >Notice that we have a similar issue on other packages, but the proposed > >solution's have been too hacky to be accepted: > > > >http://lists.busybox.net/pipermail/buildroot/2014-May/096203.html > > I see a new toolchain on the mentor site: 2014.05-47 from August. Maybe Thanks a lot for the hint! > this release fixes some of the issues we have with the current > toolchain. I will make some tests in the next week(s). > Indeed, the new toolchain seem to be working much better now. Packages that have issues with the 2013.05 toolchain build fine with the new one, such as util-linux, e2fsprogs (reverting the fallocate64 modifications), fio, and dhcpd. As far as I can see, they have fixed the issues with fallocate64, prlimit64 and the broken linux headers. As agreed with Peter on the IRC, I'll push a patch adding the new toolchain and leave the old one around for a while. Any further test is welcome. -- Ezequiel Garc?a, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-29
@ 2014-08-30 6:30 Thomas Petazzoni
2014-08-30 9:07 ` [Buildroot] Analysis of build results Thomas Petazzoni
0 siblings, 1 reply; 37+ messages in thread
From: Thomas Petazzoni @ 2014-08-30 6:30 UTC (permalink / raw)
To: buildroot
Build statistics for 2014-08-29
===============================
success : 133
failures : 21
timeouts : 1
TOTAL : 155
Classification of failures by reason
====================================
gnupg2-2.0.25 | 2
python3-3.4.1 | 2
alsa-lib-1.0.28 | 1
gd-2.1.0 | 1
libplist-1.6 | 1
fxload-2008_10_13 | 1
opencv-2.4.8 | 1
czmq-v2.2.0 | 1
expedite-1.7.7 | 1
host-icu-51.2 | 1
lftp-4.5.2 | 1
libiscsi-1.6.0 | 1
make: *** wait: No child pr... | 1
taglib-1.9.1 | 1
zeromq-4.0.4 | 1
upmpdcli-0.7.1 | 1
btrfs-progs-3.14.2 | 1
xapp_xfs-1c8459eafc04997751... | 1
enlightenment-0.17.3 | 1
lttng-tools-2.4.1 | 1
Detail of failures
===================
sh4 | alsa-lib-1.0.28 | NOK | http://autobuild.buildroot.net/results/a810c2f27dee1978808461c05cbdcbf51a214e09/
arm | btrfs-progs-3.14.2 | NOK | http://autobuild.buildroot.net/results/ddcc70143ce2c2882894184e4ce195a11407e027/
arm | czmq-v2.2.0 | NOK | http://autobuild.buildroot.net/results/404c80e23bbeb21e7c44cd28a187f2bdfa1d82c5/
powerpc | enlightenment-0.17.3 | NOK | http://autobuild.buildroot.net/results/d0adacc2961e1aee919f366d1c2982c142c8631e/
x86_64 | expedite-1.7.7 | NOK | http://autobuild.buildroot.net/results/5d0ec95e9a65ce342757b2af53762bd9d3950d14/
microblazeel | fxload-2008_10_13 | NOK | http://autobuild.buildroot.net/results/b849c8cd01acc86ca0507237e9b72ab7cf2cb563/
i486 | gd-2.1.0 | NOK | http://autobuild.buildroot.net/results/bbc8f65035ab31f30d90e8979e3d6e855a2d3957/
arm | gnupg2-2.0.25 | NOK | http://autobuild.buildroot.net/results/8842ad68bc3ec820a6ffb849770983957f35009d/
arm | gnupg2-2.0.25 | NOK | http://autobuild.buildroot.net/results/a43fdda52628afb2127fa915f8dc0fe5f271d1df/
arm | host-icu-51.2 | NOK | http://autobuild.buildroot.net/results/9e1dfe72d6dcfeaa1c9f6415936e3957d55d06cd/
x86_64 | lftp-4.5.2 | NOK | http://autobuild.buildroot.net/results/b16d964f275d4d8703665236b969cc19f7ef20be/
bfin | libiscsi-1.6.0 | NOK | http://autobuild.buildroot.net/results/8b9dc2848cc001d1f88cbf0ad93c9276d12af8d3/
bfin | libplist-1.6 | NOK | http://autobuild.buildroot.net/results/9a364e3d91634a2da2bc481da1dee0ad0e870941/
arm | lttng-tools-2.4.1 | NOK | http://autobuild.buildroot.net/results/3009327a72705f97501a9c997d56683a57d3881f/
x86_64 | make: *** wait: No child pr... | TIM | http://autobuild.buildroot.net/results/89641bf6251eb605c807e0092f5280d0274911c9/
powerpc | opencv-2.4.8 | NOK | http://autobuild.buildroot.net/results/3dc3e10e412d87937adae4d20a67cc4557bb328b/
mips64el | python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/f6088f98372199bdf4fc02ea4e82818c68e30a54/
mips64el | python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/940015d84ee574e785ef8aa7d4502f157399524f/
bfin | taglib-1.9.1 | NOK | http://autobuild.buildroot.net/results/a9cfe66c57bffc5a4560b2e4dcb41994da59e294/
bfin | upmpdcli-0.7.1 | NOK | http://autobuild.buildroot.net/results/d453d4dba313970f7440701f747b7b50d51120d7/
microblazeel | xapp_xfs-1c8459eafc04997751... | NOK | http://autobuild.buildroot.net/results/540b42436f6248adf131d2940b9528ed2f0fd5d6/
bfin | zeromq-4.0.4 | NOK | http://autobuild.buildroot.net/results/6e7afb29f3af0b4782d2a71be326133a3d3c474d/
--
http://autobuild.buildroot.net
^ permalink raw reply [flat|nested] 37+ messages in thread* [Buildroot] Analysis of build results 2014-08-30 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-29 Thomas Petazzoni @ 2014-08-30 9:07 ` Thomas Petazzoni 0 siblings, 0 replies; 37+ messages in thread From: Thomas Petazzoni @ 2014-08-30 9:07 UTC (permalink / raw) To: buildroot Hello, On Sat, 30 Aug 2014 08:30:10 +0200 (CEST), Thomas Petazzoni wrote: > sh4 | alsa-lib-1.0.28 | NOK | http://autobuild.buildroot.net/results/a810c2f27dee1978808461c05cbdcbf51a214e09/ The usual vfork() uClibc issue. I've now reported the problem to the uClibc developers. They ask me to see if the problem still occurs on uClibc master, so I'm currently building a toolchain with the latest uClibc version. > arm | btrfs-progs-3.14.2 | NOK | http://autobuild.buildroot.net/results/ddcc70143ce2c2882894184e4ce195a11407e027/ [LD] libbtrfs.so.0.1 Trying to build a shared library in a pure static context. I'll have a look. > arm | czmq-v2.2.0 | NOK | http://autobuild.buildroot.net/results/404c80e23bbeb21e7c44cd28a187f2bdfa1d82c5/ checking for zmq_init in -lzmq... no configure: error: cannot link with -lzmq, install libzmq. make: *** [/home/test/autobuild/instance-3/output/build/czmq-v2.2.0/.stamp_configured] Error 1 make: Leaving directory `/home/test/autobuild/instance-3/buildroot' I guess it's the -ldl issue investigated by J?rg? > powerpc | enlightenment-0.17.3 | NOK | http://autobuild.buildroot.net/results/d0adacc2961e1aee919f366d1c2982c142c8631e/ e_start_main.c:478:42: error: 'PT_GETSIGINFO' undeclared (first use in this function) r = ptrace(PT_GETSIGINFO, child, NULL, &sig); I think we had a similar issue for a different package, but I don't remember the details. Gustavo, maybe? > x86_64 | expedite-1.7.7 | NOK | http://autobuild.buildroot.net/results/5d0ec95e9a65ce342757b2af53762bd9d3950d14/ CXXLD expedite /home/test/autobuild/instance-2/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/libgcrypt.so.20: undefined reference to `gpg_err_set_errno' (It's with BR2_PREFER_STATIC_LIB disabled). > microblazeel | fxload-2008_10_13 | NOK | http://autobuild.buildroot.net/results/b849c8cd01acc86ca0507237e9b72ab7cf2cb563/ This looks like either a gcc or binutils bug. I've reported the issue upstream as a binutils bug, see https://sourceware.org/bugzilla/show_bug.cgi?id=17329. It's the combination of an optimization flag, and the -g flag that causes the issue. > i486 | gd-2.1.0 | NOK | http://autobuild.buildroot.net/results/bbc8f65035ab31f30d90e8979e3d6e855a2d3957/ Static lib issue, forgets to link with -lpthread. > arm | gnupg2-2.0.25 | NOK | http://autobuild.buildroot.net/results/8842ad68bc3ec820a6ffb849770983957f35009d/ > arm | gnupg2-2.0.25 | NOK | http://autobuild.buildroot.net/results/a43fdda52628afb2127fa915f8dc0fe5f271d1df/ I really don't know what to do about this one... > arm | host-icu-51.2 | NOK | http://autobuild.buildroot.net/results/9e1dfe72d6dcfeaa1c9f6415936e3957d55d06cd/ Memory allocation problem, ignore. I've modified the autobuild infrastructure to automatically reject such build failures in the future. > x86_64 | lftp-4.5.2 | NOK | http://autobuild.buildroot.net/results/b16d964f275d4d8703665236b969cc19f7ef20be/ Fixed by http://git.buildroot.net/buildroot/commit/?id=c9ad5ddfb1544a61c271354a1070edfec730bda4. > bfin | libiscsi-1.6.0 | NOK | http://autobuild.buildroot.net/results/8b9dc2848cc001d1f88cbf0ad93c9276d12af8d3/ dlfcn.h usage on Blackfin FLAT. I need to finish my patch that bumps libiscsi. > bfin | libplist-1.6 | NOK | http://autobuild.buildroot.net/results/9a364e3d91634a2da2bc481da1dee0ad0e870941/ CMake package trying to build a shared library even when it's told not to do so. Samuel? > arm | lttng-tools-2.4.1 | NOK | http://autobuild.buildroot.net/results/3009327a72705f97501a9c997d56683a57d3881f/ Compiler affected by a well-known issue causing a build failure of lttng-tools. Exception added to the autobuilder script. > x86_64 | make: *** wait: No child pr... | TIM | http://autobuild.buildroot.net/results/89641bf6251eb605c807e0092f5280d0274911c9/ Ignore. > powerpc | opencv-2.4.8 | NOK | http://autobuild.buildroot.net/results/3dc3e10e412d87937adae4d20a67cc4557bb328b/ Samuel, this is for you. > mips64el | python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/f6088f98372199bdf4fc02ea4e82818c68e30a54/ > mips64el | python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/940015d84ee574e785ef8aa7d4502f157399524f/ Caused by SYS_getdents64 being not provided by the C library, because the glibc used by the toolchain is too old. Exception added to the autobuilder script. Yann, maybe it would be good to see how Crosstool-NG could take into account the various build issues that we have found, and then provide an updated version of the toolchains. > bfin | taglib-1.9.1 | NOK | http://autobuild.buildroot.net/results/a9cfe66c57bffc5a4560b2e4dcb41994da59e294/ Another stupid CMake based package building a shared library when told not to do so. Samuel? :-) > bfin | upmpdcli-0.7.1 | NOK | http://autobuild.buildroot.net/results/d453d4dba313970f7440701f747b7b50d51120d7/ Fixed by http://git.buildroot.net/buildroot/commit/?id=f4905d7a3e1945d79084ca860ac88fbfedc01eaa. > microblazeel | xapp_xfs-1c8459eafc04997751... | NOK | http://autobuild.buildroot.net/results/540b42436f6248adf131d2940b9528ed2f0fd5d6/ /home/buildroot/instance-1/output/host/usr/microblazeel-buildroot-linux-gnu/sysroot/usr/lib/libXfont.so: undefined reference to `dlopen' /home/buildroot/instance-1/output/host/usr/microblazeel-buildroot-linux-gnu/sysroot/usr/lib/libXfont.so: undefined reference to `dlsym' > bfin | zeromq-4.0.4 | NOK | http://autobuild.buildroot.net/results/6e7afb29f3af0b4782d2a71be326133a3d3c474d/ source.c:(.text+0x1a2): undefined reference to `___sync_fetch_and_add_2' Maybe Blackfin doesn't provide the atomic compiler intrinsics? Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-11-10
@ 2014-11-11 7:30 Thomas Petazzoni
2014-11-11 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni
0 siblings, 1 reply; 37+ messages in thread
From: Thomas Petazzoni @ 2014-11-11 7:30 UTC (permalink / raw)
To: buildroot
Build statistics for 2014-11-10
===============================
success : 197
failures : 49
timeouts : 4
TOTAL : 250
Classification of failures by reason
====================================
schifra-0.0.1 | 20
qemu-2.1.2 | 4
libcap-2.24 | 4
libmemcached-1.0.18 | 3
alsa-lib-1.0.28 | 2
fltk-1.3.2 | 2
minidlna-1.1.4 | 1
bmon-3.5 | 1
czmq-v3.0.0 | 1
checking whether /home/peko... | 1
host-mysql-5.1.73 | 1
clamav-0.98.4 | 1
tn5250-0.17.4 | 1
nodejs-0.10.33 | 1
alsa-utils-1.0.28 | 1
mpdecimal-2.4.0 | 1
zeromq-4.0.4 | 1
pulseaudio-5.0 | 1
webkit-1.11.5 | 1
qt5webkit-5.3.2 | 1
libssh2-1.4.3 | 1
rpm-5.2.0 | 1
libshairplay-64d59e3087f829... | 1
python-2.7.8 | 1
Detail of failures
===================
i486 | alsa-lib-1.0.28 | NOK | http://autobuild.buildroot.net/results/6ce1ecdf2bf1f14f1497e9960a1b6689568a3658/
powerpc | alsa-lib-1.0.28 | NOK | http://autobuild.buildroot.net/results/a990b0deb0269e91bcd7fb008eb40a2e00350114/
mipsel | alsa-utils-1.0.28 | NOK | http://autobuild.buildroot.net/results/045782ef114689c2cb7171b15f63f2770139806a/
bfin | bmon-3.5 | NOK | http://autobuild.buildroot.net/results/4d0c3c8b68b37f532378f19041379cb5c5798950/
i686 | checking whether /home/peko... | TIM | http://autobuild.buildroot.net/results/a7763e614d960e044d757eaf971c8a2777485f23/
microblazeel | clamav-0.98.4 | NOK | http://autobuild.buildroot.net/results/2bed33fe03c8e49e7766f14020beea0d8e205fc1/
x86_64 | czmq-v3.0.0 | NOK | http://autobuild.buildroot.net/results/8a8ddc4c9abda5366a3e76ae98f99b821aa52b09/
x86_64 | fltk-1.3.2 | NOK | http://autobuild.buildroot.net/results/58a36291201a848a0a11cbb2b200c2b39434046c/
x86_64 | fltk-1.3.2 | NOK | http://autobuild.buildroot.net/results/fe53d0e9ad7c152105cb37a18e4d712bbde3398d/
x86_64 | host-mysql-5.1.73 | NOK | http://autobuild.buildroot.net/results/a0ff4949d621caf4cada6ae3f66ed38f569d34b9/
powerpc | libcap-2.24 | NOK | http://autobuild.buildroot.net/results/be3466bacf99f8796d4cb73440e40f29041d7848/
powerpc | libcap-2.24 | NOK | http://autobuild.buildroot.net/results/b2140fc00e3de3ac401a49d2920bcf695f6aa184/
powerpc | libcap-2.24 | NOK | http://autobuild.buildroot.net/results/b6ee496683e91d73fd55111beb0e40fc6fc90be7/
powerpc | libcap-2.24 | NOK | http://autobuild.buildroot.net/results/6eadc312e621953345e6c25c89625da6e6d54868/
bfin | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/afadd15313ceb5b2dbe3bcef48a9bc8a5108b061/
sh4 | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/cc599de01d56177a74c5563cc0b9932754a34d55/
bfin | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/bd6575362a3ce97e24b65180fddbc3eae4bc10fb/
bfin | libshairplay-64d59e3087f829... | NOK | http://autobuild.buildroot.net/results/f08787c7965c5594d9560db0aa2adb7b07a65a45/
nios2 | libssh2-1.4.3 | NOK | http://autobuild.buildroot.net/results/80dd3131cacecd629a72c38c1487d7b4ccb47a60/
nios2 | minidlna-1.1.4 | NOK | http://autobuild.buildroot.net/results/df7da91985a7bf2b05093bae7379ef22362a44fc/
bfin | mpdecimal-2.4.0 | NOK | http://autobuild.buildroot.net/results/df9a68c43eaf26a60865bf07c5913d65f051288c/
arm | nodejs-0.10.33 | NOK | http://autobuild.buildroot.net/results/e1fb34818ff1167aa008b4011befb9fd14c81293/
i686 | pulseaudio-5.0 | TIM | http://autobuild.buildroot.net/results/74e233383535f4459216c05fc705ee6b67707ac0/
powerpc | python-2.7.8 | NOK | http://autobuild.buildroot.net/results/69d23eefe2a23ee130f723c9dfa9a1a875698dc7/
i686 | qemu-2.1.2 | NOK | http://autobuild.buildroot.net/results/9efc2b14a28fd21ed2ce492f41de538673d13dce/
i686 | qemu-2.1.2 | NOK | http://autobuild.buildroot.net/results/0f640d6b701bb854ada2023861a234dfe489f038/
x86_64 | qemu-2.1.2 | NOK | http://autobuild.buildroot.net/results/c58f7e10a416e0eaf7e49f0bb5ce9e6f85bc1559/
x86_64 | qemu-2.1.2 | NOK | http://autobuild.buildroot.net/results/5979559734620358a92186a6e67aea46b6034b44/
i686 | qt5webkit-5.3.2 | NOK | http://autobuild.buildroot.net/results/af8f3d3cc018006cee58d57cd9e8c6d8b3de3247/
powerpc | rpm-5.2.0 | TIM | http://autobuild.buildroot.net/results/839b9044e936d992f12dd802b1d7578030e95f2d/
powerpc | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/caf9899e529495b349df1c4a926749b98b4941cc/
powerpc | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/50d5c1f7d234c12b00792c0a3a88885c1e3f1525/
i686 | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/4e6fea56a1ae075ce0a286e20ff891c75762f10d/
mips64el | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/84d3ec783b6d66e30e6fae9bc5d2a14fe9f2997a/
xtensa | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/6d6ea6ef929ad1d47d9773eb1a62d85a16e54fa5/
bfin | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/737c523cf856205a6cfa06da1156a350e8998624/
arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/a713bc6de2c2cdca01a9d8852395cda7c9368e50/
arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/811a7bad83b825e621ee86de216024d67f04a46e/
x86_64 | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/6988e8d23db8e575b409cbddad0a6e2fdf29ba36/
bfin | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/9daaf33512d6b7573acb0c0f62c4a0b26396cf64/
arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/59d80e3d7487dd68b9273af70517adabec65c593/
arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/db8b78cf6f3e7b940510ee94b58b96ece396a6cf/
arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/6ff11e1a03106025883e86739bf73f99e976f817/
arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/9c2396573db3cf1f40f5445c214d4e611989c4ad/
x86_64 | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/90312a2bacc94dd79d8f5540aca7546061b0eb03/
arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/2dc638f751ad635690225404878d13fd1748b81a/
x86_64 | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/b6e63b198b3b3a181a509d57a21282e77b2b196c/
powerpc | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/1d57af90b482b7bf300483ffb3dbfb1d449aa014/
sh4a | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/8d406922b5986ba297aed9cca90adf9a1b995f6d/
powerpc | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/75d45ae59b30ca394c1f409e53af931c27f8120b/
arm | tn5250-0.17.4 | TIM | http://autobuild.buildroot.net/results/0988b54f84baa927f4ea789148f8d5ead0547d9b/
arm | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/6b1123ea69c79bdd73bb85d2c8c3aac153a6f99a/
bfin | zeromq-4.0.4 | NOK | http://autobuild.buildroot.net/results/e63e422c77d9bcec8b58405dbf6a236be0d2a31b/
--
http://autobuild.buildroot.net
^ permalink raw reply [flat|nested] 37+ messages in thread* [Buildroot] Analysis of build results 2014-11-11 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-11-10 Thomas Petazzoni @ 2014-11-11 22:49 ` Thomas Petazzoni 2014-11-11 23:41 ` Gustavo Zacarias ` (4 more replies) 0 siblings, 5 replies; 37+ messages in thread From: Thomas Petazzoni @ 2014-11-11 22:49 UTC (permalink / raw) To: buildroot Hello, Yann, Gustavo, Bernd, Nathaniel, Maxime, Samuel, Peter, please read on, there is some stuff for you below :-) On Tue, 11 Nov 2014 08:30:14 +0100 (CET), Thomas Petazzoni wrote: > Build statistics for 2014-11-10 > =============================== > > success : 197 > failures : 49 > timeouts : 4 > TOTAL : 250 So a 20% failure rate. Not too bad, but we definitely need to improve this. > i486 | alsa-lib-1.0.28 | NOK | http://autobuild.buildroot.net/results/6ce1ecdf2bf1f14f1497e9960a1b6689568a3658/ > powerpc | alsa-lib-1.0.28 | NOK | http://autobuild.buildroot.net/results/a990b0deb0269e91bcd7fb008eb40a2e00350114/ This is the same problem twice: uClibc behaving badly when vfork() is used in static linking configurations. This is now fixed for the internal toolchain backend. The first build failure is with an external Crosstool-NG toolchain using uClibc. Yann, what would be your recommendation here? Is it something you intend to fix upstream in Crosstool-NG? Or should I add an exception for this toolchain to not be used in static linking configurations? The second toolchain is a Buildroot toolchain, so this problem will go away once I rebuild all the external Buildroot toolchain with the latest Buildroot version. > mipsel | alsa-utils-1.0.28 | NOK | http://autobuild.buildroot.net/results/045782ef114689c2cb7171b15f63f2770139806a/ Fixed by http://git.buildroot.net/buildroot/commit/?id=48fe144111652547cf72d2bf3e8e15f36ee40b6d. > bfin | bmon-3.5 | NOK | http://autobuild.buildroot.net/results/4d0c3c8b68b37f532378f19041379cb5c5798950/ in_netlink.c:40:29: error: netlink/netlink.h: No such file or directory in_netlink.c:41:27: error: netlink/cache.h: No such file or directory in_netlink.c:42:27: error: netlink/utils.h: No such file or directory in_netlink.c:43:32: error: netlink/route/link.h: No such file or directory in_netlink.c:44:30: error: netlink/route/tc.h: No such file or directory Gustavo, maybe? > i686 | checking whether /home/peko... | TIM | http://autobuild.buildroot.net/results/a7763e614d960e044d757eaf971c8a2777485f23/ Ignore. > microblazeel | clamav-0.98.4 | NOK | http://autobuild.buildroot.net/results/2bed33fe03c8e49e7766f14020beea0d8e205fc1/ CCLD clamscan ../libclamav/.libs/libclamav.so: undefined reference to `bzDecompress' ../libclamav/.libs/libclamav.so: undefined reference to `bzDecompressInit' ../libclamav/.libs/libclamav.so: undefined reference to `bzDecompressEnd' collect2: error: ld returned 1 exit status Linking issue against the bzip2 library. Bernd? > x86_64 | czmq-v3.0.0 | NOK | http://autobuild.buildroot.net/results/8a8ddc4c9abda5366a3e76ae98f99b821aa52b09/ checking for zmq_init in -lzmq... no configure: error: cannot link with -lzmq, install libzmq. make: *** [/home/test/autobuild/instance-1/output/build/czmq-v3.0.0/.stamp_configured] Error 1 make: Leaving directory `/home/test/autobuild/instance-1/buildroot' Don't know. Anyone to investigate this one? > x86_64 | fltk-1.3.2 | NOK | http://autobuild.buildroot.net/results/58a36291201a848a0a11cbb2b200c2b39434046c/ > x86_64 | fltk-1.3.2 | NOK | http://autobuild.buildroot.net/results/fe53d0e9ad7c152105cb37a18e4d712bbde3398d/ Linking fluid... /home/peko/autobuild/instance-1/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/libxcb-shm.so.0: undefined reference to `xcb_get_reply_fds' /home/peko/autobuild/instance-1/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/libxcb-shm.so.0: undefined reference to `xcb_send_fd' collect2: error: ld returned 1 exit status Bernd, you are our X.org expert. Can you have a look? It might be worth mentioning that fltk 1.3.3 has been released on November 3rd, so we could try to upgrade and see if it fixes the problem. > x86_64 | host-mysql-5.1.73 | NOK | http://autobuild.buildroot.net/results/a0ff4949d621caf4cada6ae3f66ed38f569d34b9/ checking for tgetent in -ltinfo... no checking for termcap functions library... configure: error: No curses/termcap library found Missing host-ncurses dependency. Nathaniel, since this is happening on your build server, maybe you could have a look? > powerpc | libcap-2.24 | NOK | http://autobuild.buildroot.net/results/be3466bacf99f8796d4cb73440e40f29041d7848/ > powerpc | libcap-2.24 | NOK | http://autobuild.buildroot.net/results/b2140fc00e3de3ac401a49d2920bcf695f6aa184/ > powerpc | libcap-2.24 | NOK | http://autobuild.buildroot.net/results/b6ee496683e91d73fd55111beb0e40fc6fc90be7/ > powerpc | libcap-2.24 | NOK | http://autobuild.buildroot.net/results/6eadc312e621953345e6c25c89625da6e6d54868/ The kernel headers problem. We need to re-add a dependency on kernel headers >= 3.0 I believe. Gustavo, what do you think? > bfin | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/afadd15313ceb5b2dbe3bcef48a9bc8a5108b061/ > sh4 | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/cc599de01d56177a74c5563cc0b9932754a34d55/ > bfin | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/bd6575362a3ce97e24b65180fddbc3eae4bc10fb/ Gazillions of: /home/buildroot/instance-0/output/build/libmemcached-1.0.18/libhashkit/rijndael.cc:1210: undefined reference to `___mf_lc_shift' /home/buildroot/instance-0/output/build/libmemcached-1.0.18/libhashkit/rijndael.cc:1210: undefined reference to `___mf_lc_mask' /home/buildroot/instance-0/output/build/libmemcached-1.0.18/libhashkit/rijndael.cc:1210: undefined reference to `___mf_lc_mask' /home/buildroot/instance-0/output/build/libmemcached-1.0.18/libhashkit/rijndael.cc:1210: undefined reference to `___mf_lookup_cache' For no apparent reason: some configs above are static, but some are not. Gustavo, you are our libmemcached guy :-) > bfin | libshairplay-64d59e3087f829... | NOK | http://autobuild.buildroot.net/results/f08787c7965c5594d9560db0aa2adb7b07a65a45/ libshairplay_la-http_parser.o dnssd.c:74:21: error: dns_sd.h: No such file or directory dnssd.c:78: error: expected declaration specifiers or '...' before '*' token dnssd.c:80: error: expected ')' before '*' token dnssd.c:93: error: expected ')' before 'sdRef' dnssd.c:96: error: expected ')' before '*' token Maxime, can you have a look? You are the person who added libshairplay in the first place. > nios2 | libssh2-1.4.3 | NOK | http://autobuild.buildroot.net/results/80dd3131cacecd629a72c38c1487d7b4ccb47a60/ checking for libgcrypt... no configure: error: cannot find OpenSSL or Libgcrypt, try --with-libssl-prefix=PATH or --with-libgcrypt-prefix=PATH Related to http://patchwork.ozlabs.org/patch/364983/ maybe? Someone to look into this? > nios2 | minidlna-1.1.4 | NOK | http://autobuild.buildroot.net/results/df7da91985a7bf2b05093bae7379ef22362a44fc/ checking for avformat_open_input in -lavformat... no configure: error: Could not find libavformat - part of ffmpeg make: *** [/home/buildroot/instance-0/output/build/minidlna-1.1.4/.stamp_configured] Error 1 make: Leaving directory `/home/buildroot/instance-0/buildroot' Some ffmpeg related problem. Bernd, maybe? > bfin | mpdecimal-2.4.0 | NOK | http://autobuild.buildroot.net/results/df9a68c43eaf26a60865bf07c5913d65f051288c/ Tries to build a shared library in a pure static lib context. Since I added mpdecimal, I guess this one is on my plate. > arm | nodejs-0.10.33 | NOK | http://autobuild.buildroot.net/results/e1fb34818ff1167aa008b4011befb9fd14c81293/ Fixed by http://git.buildroot.net/buildroot/commit/?id=e712638b4adc6e18b3ce99ab37b94530e9aa786f. > i686 | pulseaudio-5.0 | TIM | http://autobuild.buildroot.net/results/74e233383535f4459216c05fc705ee6b67707ac0/ Ignore. > powerpc | python-2.7.8 | NOK | http://autobuild.buildroot.net/results/69d23eefe2a23ee130f723c9dfa9a1a875698dc7/ uClibc bug. Vicente has pinged again the uClibc folks. Not sure what we can do about this... > i686 | qemu-2.1.2 | NOK | http://autobuild.buildroot.net/results/9efc2b14a28fd21ed2ce492f41de538673d13dce/ > i686 | qemu-2.1.2 | NOK | http://autobuild.buildroot.net/results/0f640d6b701bb854ada2023861a234dfe489f038/ > x86_64 | qemu-2.1.2 | NOK | http://autobuild.buildroot.net/results/c58f7e10a416e0eaf7e49f0bb5ce9e6f85bc1559/ > x86_64 | qemu-2.1.2 | NOK | http://autobuild.buildroot.net/results/5979559734620358a92186a6e67aea46b6034b44/ ERROR: fdt disabled but some requested targets require it. You can turn off fdt only if you also disable all the system emulation targets which need it (by specifying a cut down --target-list). Yann ? > i686 | qt5webkit-5.3.2 | NOK | http://autobuild.buildroot.net/results/af8f3d3cc018006cee58d57cd9e8c6d8b3de3247/ AttributeError: 'dict_keys' object has no attribute 'sort' make[3]: *** [generated/udis86_itab.c] Error 1 make[3]: *** Waiting for unfinished jobs.... Smells like a python2 vs. python3 issue. Maybe qt5webkit needs a dependency on host-python, and use python2 explicitly? Or maybe it can be fixed to be python3 compatible. Samuel, maybe? > powerpc | rpm-5.2.0 | TIM | http://autobuild.buildroot.net/results/839b9044e936d992f12dd802b1d7578030e95f2d/ Ignore. > powerpc | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/caf9899e529495b349df1c4a926749b98b4941cc/ > powerpc | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/50d5c1f7d234c12b00792c0a3a88885c1e3f1525/ > i686 | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/4e6fea56a1ae075ce0a286e20ff891c75762f10d/ > mips64el | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/84d3ec783b6d66e30e6fae9bc5d2a14fe9f2997a/ > xtensa | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/6d6ea6ef929ad1d47d9773eb1a62d85a16e54fa5/ > bfin | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/737c523cf856205a6cfa06da1156a350e8998624/ > arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/a713bc6de2c2cdca01a9d8852395cda7c9368e50/ > arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/811a7bad83b825e621ee86de216024d67f04a46e/ > x86_64 | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/6988e8d23db8e575b409cbddad0a6e2fdf29ba36/ > bfin | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/9daaf33512d6b7573acb0c0f62c4a0b26396cf64/ > arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/59d80e3d7487dd68b9273af70517adabec65c593/ > arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/db8b78cf6f3e7b940510ee94b58b96ece396a6cf/ > arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/6ff11e1a03106025883e86739bf73f99e976f817/ > arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/9c2396573db3cf1f40f5445c214d4e611989c4ad/ > x86_64 | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/90312a2bacc94dd79d8f5540aca7546061b0eb03/ > arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/2dc638f751ad635690225404878d13fd1748b81a/ > x86_64 | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/b6e63b198b3b3a181a509d57a21282e77b2b196c/ > powerpc | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/1d57af90b482b7bf300483ffb3dbfb1d449aa014/ > sh4a | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/8d406922b5986ba297aed9cca90adf9a1b995f6d/ > powerpc | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/75d45ae59b30ca394c1f409e53af931c27f8120b/ Peter, you really don't want to mark it as broken for now? We can always revert once the issue gets resolved upstream, if it gets resolved before the final 2014.11 is out. In the mean time, it's unnecessarily polluting the build results. > arm | tn5250-0.17.4 | TIM | http://autobuild.buildroot.net/results/0988b54f84baa927f4ea789148f8d5ead0547d9b/ Ignore. > arm | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/6b1123ea69c79bdd73bb85d2c8c3aac153a6f99a/ checking for GLES2/gl2.h... yes checking whether to use OpenGL ES 2 support... configure: error: Cannot enable OpenGL ES 2 support without EGL make: *** [/home/peko/autobuild/instance-0/output/build/webkit-1.11.5/.stamp_configured] Error 1 make: Leaving directory `/home/peko/autobuild/instance-0/buildroot' Bernd, an OpenGL issue for you :) > bfin | zeromq-4.0.4 | NOK | http://autobuild.buildroot.net/results/e63e422c77d9bcec8b58405dbf6a236be0d2a31b/ The atomic intrinsics dependency issue. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2014-11-11 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni @ 2014-11-11 23:41 ` Gustavo Zacarias 2014-11-12 2:30 ` Nathaniel Roach ` (3 subsequent siblings) 4 siblings, 0 replies; 37+ messages in thread From: Gustavo Zacarias @ 2014-11-11 23:41 UTC (permalink / raw) To: buildroot On 11/11/2014 07:49 PM, Thomas Petazzoni wrote: >> bfin | bmon-3.5 | NOK | http://autobuild.buildroot.net/results/4d0c3c8b68b37f532378f19041379cb5c5798950/ > > in_netlink.c:40:29: error: netlink/netlink.h: No such file or directory > in_netlink.c:41:27: error: netlink/cache.h: No such file or directory > in_netlink.c:42:27: error: netlink/utils.h: No such file or directory > in_netlink.c:43:32: error: netlink/route/link.h: No such file or directory > in_netlink.c:44:30: error: netlink/route/tc.h: No such file or directory > > Gustavo, maybe? I blame Maxime's bump :) Patch ready though. >> powerpc | libcap-2.24 | NOK | http://autobuild.buildroot.net/results/be3466bacf99f8796d4cb73440e40f29041d7848/ >> powerpc | libcap-2.24 | NOK | http://autobuild.buildroot.net/results/b2140fc00e3de3ac401a49d2920bcf695f6aa184/ >> powerpc | libcap-2.24 | NOK | http://autobuild.buildroot.net/results/b6ee496683e91d73fd55111beb0e40fc6fc90be7/ >> powerpc | libcap-2.24 | NOK | http://autobuild.buildroot.net/results/6eadc312e621953345e6c25c89625da6e6d54868/ > > The kernel headers problem. We need to re-add a dependency on kernel > headers >= 3.0 I believe. Gustavo, what do you think? I'll say it once more and sorry for the bad language. That toolchain is f***** up in headers-land. We can exclude it via deps, blacklist it or get rid of it. Since it's the headers that are busted i'd vote for option 3, it's just a matter of time before it shows up in some other package. >> bfin | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/afadd15313ceb5b2dbe3bcef48a9bc8a5108b061/ >> sh4 | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/cc599de01d56177a74c5563cc0b9932754a34d55/ >> bfin | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/bd6575362a3ce97e24b65180fddbc3eae4bc10fb/ > > Gazillions of: > > /home/buildroot/instance-0/output/build/libmemcached-1.0.18/libhashkit/rijndael.cc:1210: undefined reference to `___mf_lc_shift' > /home/buildroot/instance-0/output/build/libmemcached-1.0.18/libhashkit/rijndael.cc:1210: undefined reference to `___mf_lc_mask' > /home/buildroot/instance-0/output/build/libmemcached-1.0.18/libhashkit/rijndael.cc:1210: undefined reference to `___mf_lc_mask' > /home/buildroot/instance-0/output/build/libmemcached-1.0.18/libhashkit/rijndael.cc:1210: undefined reference to `___mf_lookup_cache' > > For no apparent reason: some configs above are static, but some are > not. Gustavo, you are our libmemcached guy :-) Incomplete external toolchain libmudflap handling, patch is easy enough to ditch the support, but we're missing the libmudflapth copies basically. It's been deprecated for gcc >= 4.9 though so it probably doesn't make much sense to fix it for external toolchains (if many shipped libmudflap we'd seen this failure a lot more). Regards. ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2014-11-11 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni 2014-11-11 23:41 ` Gustavo Zacarias @ 2014-11-12 2:30 ` Nathaniel Roach 2014-11-12 14:09 ` Jörg Krause ` (2 subsequent siblings) 4 siblings, 0 replies; 37+ messages in thread From: Nathaniel Roach @ 2014-11-12 2:30 UTC (permalink / raw) To: buildroot On 12/11/14 06:49, Thomas Petazzoni wrote: > Hello, > > Yann, Gustavo, Bernd, Nathaniel, Maxime, Samuel, Peter, please read on, > there is some stuff for you below :-) > > On Tue, 11 Nov 2014 08:30:14 +0100 (CET), Thomas Petazzoni wrote: >> Build statistics for 2014-11-10 >> =============================== >> >> success : 197 >> failures : 49 >> timeouts : 4 >> TOTAL : 250 > > So a 20% failure rate. Not too bad, but we definitely need to improve > this. > ---- snip ---- > > >> x86_64 | host-mysql-5.1.73 | NOK | http://autobuild.buildroot.net/results/a0ff4949d621caf4cada6ae3f66ed38f569d34b9/ > > checking for tgetent in -ltinfo... no > checking for termcap functions library... configure: error: No curses/termcap library found > > Missing host-ncurses dependency. Nathaniel, since this is happening on > your build server, maybe you could have a look? > I've checked and the configure script is checking for (or at least works when) libncurses5-dev is installed on the host. When lncurses is installed, the package from that specific config builds fine. So it looks like host-mysql doesn't depend on host-ncurses, or something along those lines. I have removed libncurses5 from the autobuilder per our discussion on it a few months back. ---- snip ---- > > Thomas > Thanks, Nathaniel. ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2014-11-11 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni 2014-11-11 23:41 ` Gustavo Zacarias 2014-11-12 2:30 ` Nathaniel Roach @ 2014-11-12 14:09 ` Jörg Krause 2014-11-16 10:07 ` Yann E. MORIN 2014-11-22 11:10 ` Bernd Kuhls 4 siblings, 0 replies; 37+ messages in thread From: Jörg Krause @ 2014-11-12 14:09 UTC (permalink / raw) To: buildroot On Di, 2014-11-11 at 23:49 +0100, Thomas Petazzoni wrote: > Hello, > > Yann, Gustavo, Bernd, Nathaniel, Maxime, Samuel, Peter, please read on, > there is some stuff for you below :-) > > bfin | libshairplay-64d59e3087f829... | NOK | http://autobuild.buildroot.net/results/f08787c7965c5594d9560db0aa2adb7b07a65a45/ > > libshairplay_la-http_parser.o > dnssd.c:74:21: error: dns_sd.h: No such file or directory > dnssd.c:78: error: expected declaration specifiers or '...' before '*' token > dnssd.c:80: error: expected ')' before '*' token > dnssd.c:93: error: expected ')' before 'sdRef' > dnssd.c:96: error: expected ')' before '*' token libshairplay needs a mDNS library. If dynamic linkage is present through libdl, the library is linked at runtime. If libdl is not present, like in this case of a Blackfin target with FLAT binary format, a mDNS library has to be statically linked. Since the only mDNS library in Buildroot - avahi - needs dynamic linkage, libshairplay cannot be built with static linkage in Buildroot for now. ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2014-11-11 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni ` (2 preceding siblings ...) 2014-11-12 14:09 ` Jörg Krause @ 2014-11-16 10:07 ` Yann E. MORIN 2014-11-22 11:10 ` Bernd Kuhls 4 siblings, 0 replies; 37+ messages in thread From: Yann E. MORIN @ 2014-11-16 10:07 UTC (permalink / raw) To: buildroot Thomas, All, On 2014-11-11 23:49 +0100, Thomas Petazzoni spake thusly: > > i486 | alsa-lib-1.0.28 | NOK | http://autobuild.buildroot.net/results/6ce1ecdf2bf1f14f1497e9960a1b6689568a3658/ > > powerpc | alsa-lib-1.0.28 | NOK | http://autobuild.buildroot.net/results/a990b0deb0269e91bcd7fb008eb40a2e00350114/ > > This is the same problem twice: uClibc behaving badly when vfork() is > used in static linking configurations. This is now fixed for the > internal toolchain backend. The first build failure is with an external > Crosstool-NG toolchain using uClibc. Yann, what would be your > recommendation here? Is it something you intend to fix upstream in > Crosstool-NG? Or should I add an exception for this toolchain to not be > used in static linking configurations? Is that fixed in Buildroot with that patch patch: package/uclibc/0.9.33.2/0062-nptl-remove-duplicate-vfork-in-libpthread.patch It is not in upstream uClibc yet, so I've pinged them about applying that patch. I'm a bit warry of carrying patches in crosstool-NG, that are not upstream. But uClibc is, well, a special case, isn't it? ;-) Maybe I could just vampirise the patches from Buildroot, and be done with it. > > i686 | qemu-2.1.2 | NOK | http://autobuild.buildroot.net/results/9efc2b14a28fd21ed2ce492f41de538673d13dce/ > > i686 | qemu-2.1.2 | NOK | http://autobuild.buildroot.net/results/0f640d6b701bb854ada2023861a234dfe489f038/ > > x86_64 | qemu-2.1.2 | NOK | http://autobuild.buildroot.net/results/c58f7e10a416e0eaf7e49f0bb5ce9e6f85bc1559/ > > x86_64 | qemu-2.1.2 | NOK | http://autobuild.buildroot.net/results/5979559734620358a92186a6e67aea46b6034b44/ > > ERROR: fdt disabled but some requested targets require it. > You can turn off fdt only if you also disable all the system emulation > targets which need it (by specifying a cut down --target-list). O...K... Well, fdt support comes later in my series, and it is a part that is not yet applied. I'll see to re-order the series to be able to just submit the FDT part, before the release. Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2014-11-11 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni ` (3 preceding siblings ...) 2014-11-16 10:07 ` Yann E. MORIN @ 2014-11-22 11:10 ` Bernd Kuhls 4 siblings, 0 replies; 37+ messages in thread From: Bernd Kuhls @ 2014-11-22 11:10 UTC (permalink / raw) To: buildroot [posted and mailed] Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote in news:20141111234919.3178e9d3 at free-electrons.com: >> x86_64 | fltk-1.3.2 | NOK | >> http://autobuild.buildroot.net/results/58a36291201a848a0a11cbb2b20 >> 0c2b39434046c/ x86_64 | fltk-1.3.2 | NOK | >> http://autobuild.buildroot.net/results/fe53d0e9ad7c152105cb37a18e4 >> d712bbde3398d/ > > Linking fluid... > /home/peko/autobuild/instance-1/output/host/usr/x86_64-buildroot-linux-gn > u/sysroot/usr/lib64/libxcb-shm.so.0: undefined reference to > `xcb_get_reply_fds' > /home/peko/autobuild/instance-1/output/host/usr/x86_64-buildroot-linux-gn > u/sysroot/usr/lib64/libxcb-shm.so.0: undefined reference to > `xcb_send_fd' collect2: error: ld returned 1 exit status > > Bernd, you are our X.org expert. Can you have a look? It might be worth > mentioning that fltk 1.3.3 has been released on November 3rd, so we > could try to upgrade and see if it fixes the problem. Hi, using fltk-1.3.2 I can not reproduce the problem. Are any xcb packages installed locally on the autobuilders? Locally this is not the case: fli4l at fli4lbuild64:~/br2$ dpkg -l | grep xcb fli4l at fli4lbuild64:~/br2$ Regards, Bernd ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Daily results for 2020-02-18
@ 2020-02-19 7:48 Thomas Petazzoni
[not found] ` <20200220034343.2370e4e4@windsurf>
0 siblings, 1 reply; 37+ messages in thread
From: Thomas Petazzoni @ 2020-02-19 7:48 UTC (permalink / raw)
To: buildroot
Hello,
Autobuild statistics for 2020-02-18
===============================
branch | OK | NOK | TIM | TOT |
2019.02.x | 18 | 4 | 0 | 22 |
2019.11.x | 19 | 2 | 0 | 21 |
master | 92 | 67 | 0 | 159 |
Results for branch 'master'
===========================
Classification of failures by reason
------------------------------------
erlang-22.2 | 9
host-sdbusplus-4212292bcf13... | 7
libglib2-2.62.4 | 5
apr-util-1.6.1 | 4
brltty-6.0 | 4
toolchain-external-codesour... | 4
libgdiplus-5.6 | 3
unknown | 3
cairo-1.16.0 | 2
host-grpc-1.25.0 | 2
libnss-3.50 | 2
libopenssl-1.1.1d | 2
mesa3d-19.3.4 | 2
acpica-20191018 | 1
augeas-1.12.0 | 1
bash-5.0 | 1
efl-1.22.3 | 1
fontconfig-2.13.1 | 1
git-2.24.1 | 1
gptfdisk-1.0.4 | 1
gst1-plugins-base-1.16.2 | 1
host-llvm-9.0.1 | 1
host-pango-1.44.6 | 1
libsvgtiny-ea9d99fc8b231c22... | 1
mimic-1.1.0 | 1
opencv3-3.4.9 | 1
openvmtools-10.3.5-10430147 | 1
ripgrep-0.8.1 | 1
sdl2-2.0.10 | 1
tio-1.32 | 1
vlc-3.0.8 | 1
Detail of failures
------------------
arch | reason | OK? | url | orph?
-------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
m68k | acpica-20191018 | NOK | http://autobuild.buildroot.net/results/81ee33eb606062a62765d95b66a26f130d280c53 |
powerpc64 | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/d10a06addfdd927fd2ac772b25aaf9a057d20158 |
mips64el | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/16d2a2efed3b13ca648c83b64150da4c2c53afd7 |
powerpc64le | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/603f1be80822977f3181c99b8b01b3f2d531ace7 |
sparc | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/7b4780dd10b471243451f7f89c6b7de0c7e7ec4e |
m68k | augeas-1.12.0 | NOK | http://autobuild.buildroot.net/results/4e1f7f335d2c853e2a5e6ad96c14157ba8f003c7 |
microblazeel | bash-5.0 | NOK | http://autobuild.buildroot.net/results/b9edb405f6cf3322ddbb640c8e89cca57e840fc2 | ORPH
i686 | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/16129b6d867578fc1cbcd36ed3a6cad806c21b10 |
powerpc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/7442b75921b95f5772520b62ff4004bc98251ee4 |
arm | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/979be1e697bb75cc018141e8fa83905696e738cf |
arm | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/240de32ee2a20b56db535147c98220783c48295f |
m68k | cairo-1.16.0 | NOK | http://autobuild.buildroot.net/results/9552e97cd64c447c8582efbe326ddafa42bf9a01 |
m68k | cairo-1.16.0 | NOK | http://autobuild.buildroot.net/results/976d99bc9b052f8d9429e666ac7fff7768ffff6b |
arm | efl-1.22.3 | NOK | http://autobuild.buildroot.net/results/4d7861fd5908c59546de19f6af3c27d061fed60b |
arm | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/3cd8e2c64e8051a95e0e097cdd0878b00afacf8e |
sparc64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/edde1b609fd6b0e6be9870f78c71a6ababa49884 |
aarch64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/b24891ac2f7b661db63c54f52024efc1e23f0339 |
arm | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/491215f51a2f1c725099c53685b34513e3ff55e7 |
x86_64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/d3552e742381c737e5cacc5ca421c154ef93cde1 |
x86_64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/385f0b988fc1ffbf918fb9adc4dd556b2fb367ab |
mipsel | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/26137934eb18531985f5b648f391501835445331 |
powerpc | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/32b5aacc2cae822d169b9a61ec4d7c1292caf877 |
aarch64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/cc1e3df1eec85a9eca98b992f646061fb888512b |
arm | fontconfig-2.13.1 | NOK | http://autobuild.buildroot.net/results/4a5a8cb6411d709acb7ea8c83b3c8e45fdc0a10b | ORPH
nios2 | git-2.24.1 | NOK | http://autobuild.buildroot.net/results/432a2766836107ed5536f861a8fbcab33e1f8cf6 |
m68k | gptfdisk-1.0.4 | NOK | http://autobuild.buildroot.net/results/6db5f9d8663730a54b04c1e624438095598b2573 | ORPH
arm | gst1-plugins-base-1.16.2 | NOK | http://autobuild.buildroot.net/results/b97923f7db5e0d7d5609152078573360937e0318 |
powerpc64le | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/89a2785352caae69cdf6aa02d55475aa4ed506d1 |
riscv64 | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/6e8ef0be643e030434474b58b15b3eff43081e5a |
riscv64 | host-llvm-9.0.1 | NOK | http://autobuild.buildroot.net/results/b922547540022a6fbde238053e2e5373a96ad48b |
i586 | host-pango-1.44.6 | NOK | http://autobuild.buildroot.net/results/30699ba23805d2b267644dc321b8aaec72a6bc89 | ORPH
x86_64 | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/bc06573718c7b05bb2ea081089cb3afa6b3cd2c2 |
mips | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/929fb828553ca99c9fe3480286627f149226b857 |
arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/3cba9e7e96aeb5ca6c68a82b972988a7bc1dc87a |
arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/0e67255cc1b184273749e8fdb721f815b144031d |
arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/6216d389edff9893f8f791ab2fbfe46d8e1276fc |
arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/34644e28467ac49eb4bc676ac0eb48c0978d4eb9 |
microblazeel | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/7ba2762786c08231a69a07558274e52750b7627c |
xtensa | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/17cb7ca0e7ca1359fc2b575a6b6c93d493dd54fb |
riscv64 | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/5b619163f23e356c790a04c027f9b9ba8b650c43 |
arm | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/d9dca72127a005952a7f97ec0297cec2fd3968f4 |
arm | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/68b4aa933fd5a60f4ac2ea023079053f805c621b |
sparc | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/279f4f8f293a4aa73b6534e4cbc90e5583951daa |
sh4 | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/1610673bc92f3cab2b858af8c4b1d0b6c871e614 |
arc | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/e27bf4715cc68ef976b2124663cc1c2d08a06d04 |
arm | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/b43ef2ad840c5bf897d0453f86026b58654f9377 |
powerpc | libnss-3.50 | NOK | http://autobuild.buildroot.net/results/673d2a580afb774c39faf69c859418579cefccde |
powerpc | libnss-3.50 | NOK | http://autobuild.buildroot.net/results/7afbb81c0ebc93a75ec58c067f9758369bcae5d6 |
m68k | libopenssl-1.1.1d | NOK | http://autobuild.buildroot.net/results/f9d3d8534d090a575d163f92920b6ad6cc1531a2 |
m68k | libopenssl-1.1.1d | NOK | http://autobuild.buildroot.net/results/acf87e81130e85e7fb05edf5f6dedf095f16e226 |
arc | libsvgtiny-ea9d99fc8b231c22... | NOK | http://autobuild.buildroot.net/results/67d341c0cc272323d6e231a20796a6848c21d760 | ORPH
x86_64 | mesa3d-19.3.4 | NOK | http://autobuild.buildroot.net/results/49c150649fa50e9dc67939e072cd5a1d3a7aa661 |
x86_64 | mesa3d-19.3.4 | NOK | http://autobuild.buildroot.net/results/86036e0e4e29eeffbe4aa10ca6e075155b675e72 |
m68k | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/61f53630ed85ee0d0d6dbf71012db77f4d7986ad |
xtensa | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/8c49a36b1fe423561473395d8f055c90436d2a5f |
i586 | openvmtools-10.3.5-10430147 | NOK | http://autobuild.buildroot.net/results/e0e7ed448df8bdd6cb13a0989d7a6c7dbaa5bc4e |
powerpc64 | ripgrep-0.8.1 | NOK | http://autobuild.buildroot.net/results/1ee145c19ee2cd5e6c237bc2864bae75e9ee4115 |
i686 | sdl2-2.0.10 | NOK | http://autobuild.buildroot.net/results/0996643e6d235168ca77271f15b21f8c167e400f |
sparc | tio-1.32 | NOK | http://autobuild.buildroot.net/results/7612824c472bd34f352a83aea50a9707442b1b42 |
arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/cba93a681d10692c4e4c5584e4c962bd18a608d4 | ORPH
arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/efd344724a244010e3411bb6599dec42adb8acaa | ORPH
arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/3f7c9d3738db5154cad27e548495643225dde0bc | ORPH
arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/7513ce8a3c501aa31aa1bd1a9908ad090b2b11b1 | ORPH
riscv32 | unknown | NOK | http://autobuild.buildroot.net/results/f0c62cf7edda5c811c7f2eda6212d3889f2920df |
arm | unknown | NOK | http://autobuild.buildroot.net/results/593c94c707508b549547e4b42727ce669229c820 |
powerpc | unknown | NOK | http://autobuild.buildroot.net/results/47667ea26dc4ed87d4aeb4ac9ae86fcd42223c6b |
arm | vlc-3.0.8 | NOK | http://autobuild.buildroot.net/results/ad8058cd98378d8813ab72bc292c8c5b9e41d7a0 |
Results for branch '2019.02.x'
==============================
Classification of failures by reason
------------------------------------
host-ti-cgt-pru-2.2.1 | 2
gnuchess-6.2.5 | 1
safeclib-v03032018 | 1
Detail of failures
------------------
arch | reason | OK? | url | orph?
-------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
arm | gnuchess-6.2.5 | NOK | http://autobuild.buildroot.net/results/8f14ccfe6d011f8072ce46313c8cba5bfcfefe8a | ORPH
arm | host-ti-cgt-pru-2.2.1 | NOK | http://autobuild.buildroot.net/results/c6f28e5cdd042f26f6f0130b5af39639f90a889e |
arm | host-ti-cgt-pru-2.2.1 | NOK | http://autobuild.buildroot.net/results/34cac8b28614b9b6832d3f62e561ad6269be00fe |
i586 | safeclib-v03032018 | NOK | http://autobuild.buildroot.net/results/de6f8318eee7b7c56b7600b086aa150f7f1d41b2 |
Results for branch '2019.11.x'
==============================
Classification of failures by reason
------------------------------------
oprofile-1.3.0 | 1
unknown | 1
Detail of failures
------------------
arch | reason | OK? | url | orph?
-------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
arc | oprofile-1.3.0 | NOK | http://autobuild.buildroot.net/results/9d9c718b36d476976a828e5d548e6a431e1c55a4 |
arm | unknown | NOK | http://autobuild.buildroot.net/results/6389e1c454ab7953603165d2d1fe85a408216db4 |
--
http://autobuild.buildroot.net
^ permalink raw reply [flat|nested] 37+ messages in thread[parent not found: <20200220034343.2370e4e4@windsurf>]
* [Buildroot] Analysis of build results [not found] ` <20200220034343.2370e4e4@windsurf> @ 2020-02-20 13:36 ` Giulio Benetti 2020-02-21 8:23 ` Romain Naour ` (2 subsequent siblings) 3 siblings, 0 replies; 37+ messages in thread From: Giulio Benetti @ 2020-02-20 13:36 UTC (permalink / raw) To: buildroot Hi All, Il 20/02/2020 03:43, Thomas Petazzoni ha scritto: > Hello, > > On Wed, 19 Feb 2020 07:48:39 -0000 > Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > >> master | 92 | 67 | 0 | 159 | > > These results are not really good, so we need to put some effort into > reducing the number of build failures in the autobuilders. See below > for an analysis of the different build failures. Your help is > appreciated to fix those issues. > >> m68k | acpica-20191018 | NOK | http://autobuild.buildroot.net/results/81ee33eb606062a62765d95b66a26f130d280c53 | > > Segmentation fault in elf2flt: > > ld (ld-elf2flt): /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/m68k-buildroot-uclinux-uclibc/bin/elf2flt terminated with signal 11 [Segmentation fault] > > Romain, I am wondering if you already had a look into this. Could you > comment? > >> powerpc64 | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/d10a06addfdd927fd2ac772b25aaf9a057d20158 | >> mips64el | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/16d2a2efed3b13ca648c83b64150da4c2c53afd7 | >> powerpc64le | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/603f1be80822977f3181c99b8b01b3f2d531ace7 | >> sparc | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/7b4780dd10b471243451f7f89c6b7de0c7e7ec4e | > > Per-package directories issue, fixed by > https://git.buildroot.org/buildroot/commit/?id=84b4c19e551288911a230c2b73e96bc6e2ed12f9 > >> m68k | augeas-1.12.0 | NOK | http://autobuild.buildroot.net/results/4e1f7f335d2c853e2a5e6ad96c14157ba8f003c7 | > > Another elf2flt issue: > > ld (ld-elf2flt): /home/giuliobenetti/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/m68k-buildroot-uclinux-uclibc/bin/elf2flt terminated with signal 11 [Segmentation fault], core dumped > > Romain ? :-) > >> microblazeel | bash-5.0 | NOK | http://autobuild.buildroot.net/results/b9edb405f6cf3322ddbb640c8e89cca57e840fc2 | ORPH > > ../input.h:76:3: error: unknown type name 'FILE' > > Not clear what is happening here. Could anyone investigate ? > >> i686 | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/16129b6d867578fc1cbcd36ed3a6cad806c21b10 | >> powerpc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/7442b75921b95f5772520b62ff4004bc98251ee4 | >> arm | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/979be1e697bb75cc018141e8fa83905696e738cf | >> arm | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/240de32ee2a20b56db535147c98220783c48295f | > > I have submitted http://patchwork.ozlabs.org/patch/1241072/ to fix this. > >> m68k | cairo-1.16.0 | NOK | http://autobuild.buildroot.net/results/9552e97cd64c447c8582efbe326ddafa42bf9a01 | >> m68k | cairo-1.16.0 | NOK | http://autobuild.buildroot.net/results/976d99bc9b052f8d9429e666ac7fff7768ffff6b | > > Another elf2flt segfault. Why are we seeing these segfaults? I don't > think we used to have so many. Is it due to the relatively recent > rebuild of all Buildroot toolchains, which perhaps mean we're using a > newer version of elf2flt ? > >> arm | efl-1.22.3 | NOK | http://autobuild.buildroot.net/results/4d7861fd5908c59546de19f6af3c27d061fed60b | > > /data/buildroot/buildroot-test/instance-0/output/host/bin/../arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/poppler/cpp/poppler-page.h:39:22: error: expected ',' or '...' before '&&' token > > Some C++ mess it seems. Romain, any idea ? > >> arm | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/3cd8e2c64e8051a95e0e097cdd0878b00afacf8e | >> sparc64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/edde1b609fd6b0e6be9870f78c71a6ababa49884 | >> aarch64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/b24891ac2f7b661db63c54f52024efc1e23f0339 | >> arm | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/491215f51a2f1c725099c53685b34513e3ff55e7 | >> x86_64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/d3552e742381c737e5cacc5ca421c154ef93cde1 | >> x86_64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/385f0b988fc1ffbf918fb9adc4dd556b2fb367ab | >> mipsel | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/26137934eb18531985f5b648f391501835445331 | >> powerpc | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/32b5aacc2cae822d169b9a61ec4d7c1292caf877 | >> aarch64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/cc1e3df1eec85a9eca98b992f646061fb888512b | > > Fixed by https://git.buildroot.org/buildroot/commit/?id=607040e91381aae35205659e8edd7b2eeb45d420 > >> arm | fontconfig-2.13.1 | NOK | http://autobuild.buildroot.net/results/4a5a8cb6411d709acb7ea8c83b3c8e45fdc0a10b | ORPH > > Another elf2flt issue. > >> nios2 | git-2.24.1 | NOK | http://autobuild.buildroot.net/results/432a2766836107ed5536f861a8fbcab33e1f8cf6 | > > Wonderful, another compiler segfault: > > ref-filter.c: In function 'find_longest_prefixes_1': > ref-filter.c:1914:1: internal compiler error: Segmentation fault > > Giulio or Romain, any idea ? Going to deal with this and let you know when gcc bug is reported and I have a decent work around. -- Giulio Benetti >> m68k | gptfdisk-1.0.4 | NOK | http://autobuild.buildroot.net/results/6db5f9d8663730a54b04c1e624438095598b2573 | ORPH > > Our friend elf2flt strikes again. We really need to fix this issue. > >> arm | gst1-plugins-base-1.16.2 | NOK | http://autobuild.buildroot.net/results/b97923f7db5e0d7d5609152078573360937e0318 | > > Static linking issue. It may be the same problem as the one affecting > libglib2. See below. > >> powerpc64le | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/89a2785352caae69cdf6aa02d55475aa4ed506d1 | >> riscv64 | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/6e8ef0be643e030434474b58b15b3eff43081e5a | > > Still this mysterious failure that happens only on Yann's machine. Yann? :-) > >> riscv64 | host-llvm-9.0.1 | NOK | http://autobuild.buildroot.net/results/b922547540022a6fbde238053e2e5373a96ad48b | > > CMake Error at cmake/config-ix.cmake:438 (message): > Unknown architecture > > Something not careful enough is using host-llvm even though the target > architecture is not supported. Romain ? > >> i586 | host-pango-1.44.6 | NOK | http://autobuild.buildroot.net/results/30699ba23805d2b267644dc321b8aaec72a6bc89 | ORPH > > cannot delete non-empty directory: share/gettext > could not make way for new symlink: share/gettext > > This is a per-package directory issue. > >> x86_64 | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/bc06573718c7b05bb2ea081089cb3afa6b3cd2c2 | >> mips | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/929fb828553ca99c9fe3480286627f149226b857 | >> arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/3cba9e7e96aeb5ca6c68a82b972988a7bc1dc87a | >> arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/0e67255cc1b184273749e8fdb721f815b144031d | >> arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/6216d389edff9893f8f791ab2fbfe46d8e1276fc | >> arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/34644e28467ac49eb4bc676ac0eb48c0978d4eb9 | >> microblazeel | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/7ba2762786c08231a69a07558274e52750b7627c | > > Fixed by https://git.buildroot.org/buildroot/commit/?id=6bf74ce3dbfec8979e379bc1b919f29d09f0d87b > >> xtensa | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/17cb7ca0e7ca1359fc2b575a6b6c93d493dd54fb | >> riscv64 | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/5b619163f23e356c790a04c027f9b9ba8b650c43 | >> arm | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/d9dca72127a005952a7f97ec0297cec2fd3968f4 | > > /data/buildroot/buildroot-test/instance-0/output/host/lib/gcc/arm-buildroot-linux-musleabihf/8.3.0/../../../../arm-buildroot-linux-musleabihf/bin/ld: ../src/.libs/libgdiplus.so: undefined reference to `GifQuantizeBuffer' > > Sergio, could you have a look ? > >> arm | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/68b4aa933fd5a60f4ac2ea023079053f805c621b | >> sparc | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/279f4f8f293a4aa73b6534e4cbc90e5583951daa | >> sh4 | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/1610673bc92f3cab2b858af8c4b1d0b6c871e614 | >> arc | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/e27bf4715cc68ef976b2124663cc1c2d08a06d04 | >> arm | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/b43ef2ad840c5bf897d0453f86026b58654f9377 | > > This is a static linking issue caused by a change in the pkg-config > handling in our meson logic. I have reported this to Arnout at > http://lists.busybox.net/pipermail/buildroot/2020-February/274491.html. > However now I see that Fabrice has proposed > http://lists.busybox.net/pipermail/buildroot/2020-February/274178.html > to resolve the problem, which seems like a good approach. > > Arnout? > >> powerpc | libnss-3.50 | NOK | http://autobuild.buildroot.net/results/673d2a580afb774c39faf69c859418579cefccde | >> powerpc | libnss-3.50 | NOK | http://autobuild.buildroot.net/results/7afbb81c0ebc93a75ec58c067f9758369bcae5d6 | > > These would be fixed by http://patchwork.ozlabs.org/patch/1235413/. > >> m68k | libopenssl-1.1.1d | NOK | http://autobuild.buildroot.net/results/f9d3d8534d090a575d163f92920b6ad6cc1531a2 | >> m68k | libopenssl-1.1.1d | NOK | http://autobuild.buildroot.net/results/acf87e81130e85e7fb05edf5f6dedf095f16e226 | > > elf2flt I love you. > >> arc | libsvgtiny-ea9d99fc8b231c22... | NOK | http://autobuild.buildroot.net/results/67d341c0cc272323d6e231a20796a6848c21d760 | ORPH > > src/svgtiny.c:21:10: fatal error: autogenerated_colors.c: No such file or directory > 21 | #include "autogenerated_colors.c" > > Some generated file is not here. Parallel build issue? Something else? > > We don't have any maintainer of libsvgtiny. Any volunteer ? > >> x86_64 | mesa3d-19.3.4 | NOK | http://autobuild.buildroot.net/results/49c150649fa50e9dc67939e072cd5a1d3a7aa661 | >> x86_64 | mesa3d-19.3.4 | NOK | http://autobuild.buildroot.net/results/86036e0e4e29eeffbe4aa10ca6e075155b675e72 | > > I would suspect these would be fixed by http://patchwork.ozlabs.org/patch/1240964/. > >> m68k | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/61f53630ed85ee0d0d6dbf71012db77f4d7986ad | > > elf2flt issue. > >> xtensa | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/8c49a36b1fe423561473395d8f055c90436d2a5f | > > /home/giuliobenetti/autobuild/run/instance-0/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:17:2: error: #error This file was generated by an older version of protoc which is > #error This file was generated by an older version of protoc which is > ^~~~~ > /home/giuliobenetti/autobuild/run/instance-0/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:18:2: error: #error incompatible with your Protocol Buffer headers. Please > #error incompatible with your Protocol Buffer headers. Please > ^~~~~ > /home/giuliobenetti/autobuild/run/instance-0/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:19:2: error: #error regenerate this file with a newer version of protoc. > #error regenerate this file with a newer version of protoc. > ^~~~~ > > OK, needs to be investigated. opencv3 used to be maintained by Samuel > Martin, but Samuel is no longer active in Buildroot. Any volunteer? > >> i586 | openvmtools-10.3.5-10430147 | NOK | http://autobuild.buildroot.net/results/e0e7ed448df8bdd6cb13a0989d7a6c7dbaa5bc4e | > > /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/i586-buildroot-linux-musl/8.3.0/../../../../i586-buildroot-linux-musl/bin/ld: vmtoolsd-cmdLine.o: undefined reference to symbol 'libintl_gettext' > > Needs to link against the proper libintl library. Anyone to look into this ? > >> powerpc64 | ripgrep-0.8.1 | NOK | http://autobuild.buildroot.net/results/1ee145c19ee2cd5e6c237bc2864bae75e9ee4115 | > > Fails while downloading stuff during the build. I guess this is what is > being fixed by the work on Cargo integration in Buildroot. > >> i686 | sdl2-2.0.10 | NOK | http://autobuild.buildroot.net/results/0996643e6d235168ca77271f15b21f8c167e400f | > > /home/buildroot/autobuild/instance-1/output-1/host/i686-buildroot-linux-uclibc/sysroot/usr/include/EGL/eglplatform.h:134:10: fatal error: X11/Xlib.h: No such file or directory > #include <X11/Xlib.h> > > Anybody to have a look ? > >> sparc | tio-1.32 | NOK | http://autobuild.buildroot.net/results/7612824c472bd34f352a83aea50a9707442b1b42 | > > /home/peko/autobuild/instance-0/output-1/host/sparc-buildroot-linux-uclibc/sysroot/usr/include/asm/termbits.h:16:8: error: redefinition of 'struct termio' > struct termio { > > >> arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/cba93a681d10692c4e4c5584e4c962bd18a608d4 | ORPH >> arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/efd344724a244010e3411bb6599dec42adb8acaa | ORPH >> arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/3f7c9d3738db5154cad27e548495643225dde0bc | ORPH >> arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/7513ce8a3c501aa31aa1bd1a9908ad090b2b11b1 | ORPH > > These would be fixed by my series: > > http://patchwork.ozlabs.org/project/buildroot/list/?series=159621 > >> riscv32 | unknown | NOK | http://autobuild.buildroot.net/results/f0c62cf7edda5c811c7f2eda6212d3889f2920df | > > Not clear why it failed. This is not a reproducible build issue, there > are no errors in the logs. It was built with > BR2_PER_PACKAGE_DIRECTORIES=y, so possibly with top-level parallel > build, and therefore the error might be outside of the log. > >> arm | unknown | NOK | http://autobuild.buildroot.net/results/593c94c707508b549547e4b42727ce669229c820 | > > This one is a reproducible build issue due to elf2flt storing the build > date in the BFLT header. I have already fixed this in upstream elf2flt > https://github.com/uclinux-dev/elf2flt/commit/453398f917d167f8c308c8f997270c48ae8f8b12, > we need to backport this in BR and rebuild our noMMU toolchains. > >> powerpc | unknown | NOK | http://autobuild.buildroot.net/results/47667ea26dc4ed87d4aeb4ac9ae86fcd42223c6b | > > Also no visible error here, also probably a top-level parallel build. > We need to somehow fix the logic we use to extract the error when doing > top-level parallel builds. > >> arm | vlc-3.0.8 | NOK | http://autobuild.buildroot.net/results/ad8058cd98378d8813ab72bc292c8c5b9e41d7a0 | > > video_filter/opencv_example.cpp:200:46: error: could not convert 'cv::Scalar_<double>((double)0, (double)0, (double)0, (double)0)' from 'cv::Scalar' {aka 'cv::Scalar_<double>'} to 'CvScalar' > cvRectangle( p_img[0], pt1, pt2, CV_RGB(0,0,0), 3, 8, 0 ); > > Meh. VLC/OpenCV issue. > > Thomas > ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results [not found] ` <20200220034343.2370e4e4@windsurf> 2020-02-20 13:36 ` [Buildroot] Analysis of build results Giulio Benetti @ 2020-02-21 8:23 ` Romain Naour [not found] ` <94c8edad-773d-2b36-5daf-b6ee60dd747f@micronovasrl.com> 2020-02-22 23:48 ` Romain Naour 3 siblings, 0 replies; 37+ messages in thread From: Romain Naour @ 2020-02-21 8:23 UTC (permalink / raw) To: buildroot Hi Thomas, Le 20/02/2020 ? 03:43, Thomas Petazzoni a ?crit?: > Hello, > > On Wed, 19 Feb 2020 07:48:39 -0000 > Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > >> master | 92 | 67 | 0 | 159 | > > These results are not really good, so we need to put some effort into > reducing the number of build failures in the autobuilders. See below > for an analysis of the different build failures. Your help is > appreciated to fix those issues. This email is missing from the Buildroot Archives [1]. There is something unusual... It seems that "buildroot at buildroot.org" is not in "Cc" but "Redirect Mail". Due to this, only the reply from Giulio was archived. I'm replying using "Cc" for the ml. [1] http://lists.busybox.net/pipermail/buildroot/2020-February/thread.html Best regards, Romain > >> m68k | acpica-20191018 | NOK | http://autobuild.buildroot.net/results/81ee33eb606062a62765d95b66a26f130d280c53 | > > Segmentation fault in elf2flt: > > ld (ld-elf2flt): /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/m68k-buildroot-uclinux-uclibc/bin/elf2flt terminated with signal 11 [Segmentation fault] > > Romain, I am wondering if you already had a look into this. Could you > comment? > >> powerpc64 | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/d10a06addfdd927fd2ac772b25aaf9a057d20158 | >> mips64el | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/16d2a2efed3b13ca648c83b64150da4c2c53afd7 | >> powerpc64le | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/603f1be80822977f3181c99b8b01b3f2d531ace7 | >> sparc | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/7b4780dd10b471243451f7f89c6b7de0c7e7ec4e | > > Per-package directories issue, fixed by > https://git.buildroot.org/buildroot/commit/?id=84b4c19e551288911a230c2b73e96bc6e2ed12f9 > >> m68k | augeas-1.12.0 | NOK | http://autobuild.buildroot.net/results/4e1f7f335d2c853e2a5e6ad96c14157ba8f003c7 | > > Another elf2flt issue: > > ld (ld-elf2flt): /home/giuliobenetti/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/m68k-buildroot-uclinux-uclibc/bin/elf2flt terminated with signal 11 [Segmentation fault], core dumped > > Romain ? :-) > >> microblazeel | bash-5.0 | NOK | http://autobuild.buildroot.net/results/b9edb405f6cf3322ddbb640c8e89cca57e840fc2 | ORPH > > ../input.h:76:3: error: unknown type name 'FILE' > > Not clear what is happening here. Could anyone investigate ? > >> i686 | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/16129b6d867578fc1cbcd36ed3a6cad806c21b10 | >> powerpc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/7442b75921b95f5772520b62ff4004bc98251ee4 | >> arm | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/979be1e697bb75cc018141e8fa83905696e738cf | >> arm | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/240de32ee2a20b56db535147c98220783c48295f | > > I have submitted http://patchwork.ozlabs.org/patch/1241072/ to fix this. > >> m68k | cairo-1.16.0 | NOK | http://autobuild.buildroot.net/results/9552e97cd64c447c8582efbe326ddafa42bf9a01 | >> m68k | cairo-1.16.0 | NOK | http://autobuild.buildroot.net/results/976d99bc9b052f8d9429e666ac7fff7768ffff6b | > > Another elf2flt segfault. Why are we seeing these segfaults? I don't > think we used to have so many. Is it due to the relatively recent > rebuild of all Buildroot toolchains, which perhaps mean we're using a > newer version of elf2flt ? > >> arm | efl-1.22.3 | NOK | http://autobuild.buildroot.net/results/4d7861fd5908c59546de19f6af3c27d061fed60b | > > /data/buildroot/buildroot-test/instance-0/output/host/bin/../arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/poppler/cpp/poppler-page.h:39:22: error: expected ',' or '...' before '&&' token > > Some C++ mess it seems. Romain, any idea ? > >> arm | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/3cd8e2c64e8051a95e0e097cdd0878b00afacf8e | >> sparc64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/edde1b609fd6b0e6be9870f78c71a6ababa49884 | >> aarch64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/b24891ac2f7b661db63c54f52024efc1e23f0339 | >> arm | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/491215f51a2f1c725099c53685b34513e3ff55e7 | >> x86_64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/d3552e742381c737e5cacc5ca421c154ef93cde1 | >> x86_64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/385f0b988fc1ffbf918fb9adc4dd556b2fb367ab | >> mipsel | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/26137934eb18531985f5b648f391501835445331 | >> powerpc | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/32b5aacc2cae822d169b9a61ec4d7c1292caf877 | >> aarch64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/cc1e3df1eec85a9eca98b992f646061fb888512b | > > Fixed by https://git.buildroot.org/buildroot/commit/?id=607040e91381aae35205659e8edd7b2eeb45d420 > >> arm | fontconfig-2.13.1 | NOK | http://autobuild.buildroot.net/results/4a5a8cb6411d709acb7ea8c83b3c8e45fdc0a10b | ORPH > > Another elf2flt issue. > >> nios2 | git-2.24.1 | NOK | http://autobuild.buildroot.net/results/432a2766836107ed5536f861a8fbcab33e1f8cf6 | > > Wonderful, another compiler segfault: > > ref-filter.c: In function 'find_longest_prefixes_1': > ref-filter.c:1914:1: internal compiler error: Segmentation fault > > Giulio or Romain, any idea ? > >> m68k | gptfdisk-1.0.4 | NOK | http://autobuild.buildroot.net/results/6db5f9d8663730a54b04c1e624438095598b2573 | ORPH > > Our friend elf2flt strikes again. We really need to fix this issue. > >> arm | gst1-plugins-base-1.16.2 | NOK | http://autobuild.buildroot.net/results/b97923f7db5e0d7d5609152078573360937e0318 | > > Static linking issue. It may be the same problem as the one affecting > libglib2. See below. > >> powerpc64le | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/89a2785352caae69cdf6aa02d55475aa4ed506d1 | >> riscv64 | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/6e8ef0be643e030434474b58b15b3eff43081e5a | > > Still this mysterious failure that happens only on Yann's machine. Yann? :-) > >> riscv64 | host-llvm-9.0.1 | NOK | http://autobuild.buildroot.net/results/b922547540022a6fbde238053e2e5373a96ad48b | > > CMake Error at cmake/config-ix.cmake:438 (message): > Unknown architecture > > Something not careful enough is using host-llvm even though the target > architecture is not supported. Romain ? > >> i586 | host-pango-1.44.6 | NOK | http://autobuild.buildroot.net/results/30699ba23805d2b267644dc321b8aaec72a6bc89 | ORPH > > cannot delete non-empty directory: share/gettext > could not make way for new symlink: share/gettext > > This is a per-package directory issue. > >> x86_64 | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/bc06573718c7b05bb2ea081089cb3afa6b3cd2c2 | >> mips | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/929fb828553ca99c9fe3480286627f149226b857 | >> arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/3cba9e7e96aeb5ca6c68a82b972988a7bc1dc87a | >> arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/0e67255cc1b184273749e8fdb721f815b144031d | >> arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/6216d389edff9893f8f791ab2fbfe46d8e1276fc | >> arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/34644e28467ac49eb4bc676ac0eb48c0978d4eb9 | >> microblazeel | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/7ba2762786c08231a69a07558274e52750b7627c | > > Fixed by https://git.buildroot.org/buildroot/commit/?id=6bf74ce3dbfec8979e379bc1b919f29d09f0d87b > >> xtensa | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/17cb7ca0e7ca1359fc2b575a6b6c93d493dd54fb | >> riscv64 | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/5b619163f23e356c790a04c027f9b9ba8b650c43 | >> arm | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/d9dca72127a005952a7f97ec0297cec2fd3968f4 | > > /data/buildroot/buildroot-test/instance-0/output/host/lib/gcc/arm-buildroot-linux-musleabihf/8.3.0/../../../../arm-buildroot-linux-musleabihf/bin/ld: ../src/.libs/libgdiplus.so: undefined reference to `GifQuantizeBuffer' > > Sergio, could you have a look ? > >> arm | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/68b4aa933fd5a60f4ac2ea023079053f805c621b | >> sparc | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/279f4f8f293a4aa73b6534e4cbc90e5583951daa | >> sh4 | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/1610673bc92f3cab2b858af8c4b1d0b6c871e614 | >> arc | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/e27bf4715cc68ef976b2124663cc1c2d08a06d04 | >> arm | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/b43ef2ad840c5bf897d0453f86026b58654f9377 | > > This is a static linking issue caused by a change in the pkg-config > handling in our meson logic. I have reported this to Arnout at > http://lists.busybox.net/pipermail/buildroot/2020-February/274491.html. > However now I see that Fabrice has proposed > http://lists.busybox.net/pipermail/buildroot/2020-February/274178.html > to resolve the problem, which seems like a good approach. > > Arnout? > >> powerpc | libnss-3.50 | NOK | http://autobuild.buildroot.net/results/673d2a580afb774c39faf69c859418579cefccde | >> powerpc | libnss-3.50 | NOK | http://autobuild.buildroot.net/results/7afbb81c0ebc93a75ec58c067f9758369bcae5d6 | > > These would be fixed by http://patchwork.ozlabs.org/patch/1235413/. > >> m68k | libopenssl-1.1.1d | NOK | http://autobuild.buildroot.net/results/f9d3d8534d090a575d163f92920b6ad6cc1531a2 | >> m68k | libopenssl-1.1.1d | NOK | http://autobuild.buildroot.net/results/acf87e81130e85e7fb05edf5f6dedf095f16e226 | > > elf2flt I love you. > >> arc | libsvgtiny-ea9d99fc8b231c22... | NOK | http://autobuild.buildroot.net/results/67d341c0cc272323d6e231a20796a6848c21d760 | ORPH > > src/svgtiny.c:21:10: fatal error: autogenerated_colors.c: No such file or directory > 21 | #include "autogenerated_colors.c" > > Some generated file is not here. Parallel build issue? Something else? > > We don't have any maintainer of libsvgtiny. Any volunteer ? > >> x86_64 | mesa3d-19.3.4 | NOK | http://autobuild.buildroot.net/results/49c150649fa50e9dc67939e072cd5a1d3a7aa661 | >> x86_64 | mesa3d-19.3.4 | NOK | http://autobuild.buildroot.net/results/86036e0e4e29eeffbe4aa10ca6e075155b675e72 | > > I would suspect these would be fixed by http://patchwork.ozlabs.org/patch/1240964/. > >> m68k | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/61f53630ed85ee0d0d6dbf71012db77f4d7986ad | > > elf2flt issue. > >> xtensa | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/8c49a36b1fe423561473395d8f055c90436d2a5f | > > /home/giuliobenetti/autobuild/run/instance-0/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:17:2: error: #error This file was generated by an older version of protoc which is > #error This file was generated by an older version of protoc which is > ^~~~~ > /home/giuliobenetti/autobuild/run/instance-0/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:18:2: error: #error incompatible with your Protocol Buffer headers. Please > #error incompatible with your Protocol Buffer headers. Please > ^~~~~ > /home/giuliobenetti/autobuild/run/instance-0/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:19:2: error: #error regenerate this file with a newer version of protoc. > #error regenerate this file with a newer version of protoc. > ^~~~~ > > OK, needs to be investigated. opencv3 used to be maintained by Samuel > Martin, but Samuel is no longer active in Buildroot. Any volunteer? > >> i586 | openvmtools-10.3.5-10430147 | NOK | http://autobuild.buildroot.net/results/e0e7ed448df8bdd6cb13a0989d7a6c7dbaa5bc4e | > > /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/i586-buildroot-linux-musl/8.3.0/../../../../i586-buildroot-linux-musl/bin/ld: vmtoolsd-cmdLine.o: undefined reference to symbol 'libintl_gettext' > > Needs to link against the proper libintl library. Anyone to look into this ? > >> powerpc64 | ripgrep-0.8.1 | NOK | http://autobuild.buildroot.net/results/1ee145c19ee2cd5e6c237bc2864bae75e9ee4115 | > > Fails while downloading stuff during the build. I guess this is what is > being fixed by the work on Cargo integration in Buildroot. > >> i686 | sdl2-2.0.10 | NOK | http://autobuild.buildroot.net/results/0996643e6d235168ca77271f15b21f8c167e400f | > > /home/buildroot/autobuild/instance-1/output-1/host/i686-buildroot-linux-uclibc/sysroot/usr/include/EGL/eglplatform.h:134:10: fatal error: X11/Xlib.h: No such file or directory > #include <X11/Xlib.h> > > Anybody to have a look ? > >> sparc | tio-1.32 | NOK | http://autobuild.buildroot.net/results/7612824c472bd34f352a83aea50a9707442b1b42 | > > /home/peko/autobuild/instance-0/output-1/host/sparc-buildroot-linux-uclibc/sysroot/usr/include/asm/termbits.h:16:8: error: redefinition of 'struct termio' > struct termio { > > >> arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/cba93a681d10692c4e4c5584e4c962bd18a608d4 | ORPH >> arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/efd344724a244010e3411bb6599dec42adb8acaa | ORPH >> arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/3f7c9d3738db5154cad27e548495643225dde0bc | ORPH >> arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/7513ce8a3c501aa31aa1bd1a9908ad090b2b11b1 | ORPH > > These would be fixed by my series: > > http://patchwork.ozlabs.org/project/buildroot/list/?series=159621 > >> riscv32 | unknown | NOK | http://autobuild.buildroot.net/results/f0c62cf7edda5c811c7f2eda6212d3889f2920df | > > Not clear why it failed. This is not a reproducible build issue, there > are no errors in the logs. It was built with > BR2_PER_PACKAGE_DIRECTORIES=y, so possibly with top-level parallel > build, and therefore the error might be outside of the log. > >> arm | unknown | NOK | http://autobuild.buildroot.net/results/593c94c707508b549547e4b42727ce669229c820 | > > This one is a reproducible build issue due to elf2flt storing the build > date in the BFLT header. I have already fixed this in upstream elf2flt > https://github.com/uclinux-dev/elf2flt/commit/453398f917d167f8c308c8f997270c48ae8f8b12, > we need to backport this in BR and rebuild our noMMU toolchains. > >> powerpc | unknown | NOK | http://autobuild.buildroot.net/results/47667ea26dc4ed87d4aeb4ac9ae86fcd42223c6b | > > Also no visible error here, also probably a top-level parallel build. > We need to somehow fix the logic we use to extract the error when doing > top-level parallel builds. > >> arm | vlc-3.0.8 | NOK | http://autobuild.buildroot.net/results/ad8058cd98378d8813ab72bc292c8c5b9e41d7a0 | > > video_filter/opencv_example.cpp:200:46: error: could not convert 'cv::Scalar_<double>((double)0, (double)0, (double)0, (double)0)' from 'cv::Scalar' {aka 'cv::Scalar_<double>'} to 'CvScalar' > cvRectangle( p_img[0], pt1, pt2, CV_RGB(0,0,0), 3, 8, 0 ); > > Meh. VLC/OpenCV issue. > > Thomas > ^ permalink raw reply [flat|nested] 37+ messages in thread
[parent not found: <94c8edad-773d-2b36-5daf-b6ee60dd747f@micronovasrl.com>]
[parent not found: <3e7b016b-eca6-b768-3fca-8fd7e44d0299@micronovasrl.com>]
[parent not found: <20200220190807.505b4fb2@windsurf>]
[parent not found: <00751b5d-ca05-fe42-0e9b-6a1005a09e6d@micronovasrl.com>]
[parent not found: <20200220192344.03785f04@windsurf>]
[parent not found: <bcc10a0e-c54e-5b75-9b77-8922b85a925a@micronovasrl.com>]
[parent not found: <fe7d07df-71a0-e317-6b91-ade479545ec4@smile.fr>]
[parent not found: <28258465-4f79-3f47-189d-bb066b0aa9f7@micronovasrl.com>]
* [Buildroot] Analysis of build results [not found] ` <28258465-4f79-3f47-189d-bb066b0aa9f7@micronovasrl.com> @ 2020-02-22 19:10 ` Romain Naour 2020-02-22 19:44 ` Giulio Benetti 0 siblings, 1 reply; 37+ messages in thread From: Romain Naour @ 2020-02-22 19:10 UTC (permalink / raw) To: buildroot Hi Giulio, CC: buildroot <buildroot@buildroot.org> Le 22/02/2020 ? 19:57, Giulio Benetti a ?crit?: > Hi Romain, > > Il 22/02/2020 19:18, Romain Naour ha scritto: >> Hi Giulio, >> >> Le 21/02/2020 ? 00:09, Giulio Benetti a ?crit?: >>> Hi Thomas, >>> >>> Il 20/02/2020 19:23, Thomas Petazzoni ha scritto: >>>> On Thu, 20 Feb 2020 19:16:37 +0100 >>>> Giulio Benetti <giulio.benetti@micronovasrl.com> wrote: >>>> >>>>> So something like: >>>>> # while true; do make foo && make foo-dirclean; done >>>>> >>>>> but please do you have a 'standard' form where it escapes on error? >>>> >>>> while true; do make foo && make foo-dirclean || break ; done >>> >>> Unfortunately the problem doesn't show up, I've also accelerated the building >>> launching a local script in build/libsvgtiny-xxx/ that call make -j17 && make >>> clean with all the arguments Buildroot provides to accelerate, but nothing. I've >>> tried on my Workstation, my laptop and 1 of my autobuilders. >>> >>> Romain, have you had the chance to try that patch? Can I do something to ease >>> the thing? Also, which specific distro(Distro name, kernel version) do you have? >> >> This a a Fedora 31 disto regularly updated. >> >> This is weird since we already disabled parallel build [1] > > Ah good finding, with this I've also found that [1] is wrong, since this is a > generic package, so need to build with $(MAKE1) instead of $(MAKE) without > LIBSVGTINY_MAKE = $(MAKE1) > but maybe the patch i've sent you could work. > > Can you give a try? I tried to reproduce the issue but libsvgtiny still build fine here... > > If it still fails, since this package contains 4 source files, I could send a > patch that really avoid parallel build. And it must sent anyway a patch to fix > that error. Maybe we can just fix the patch [1] ? Can you send the patch ? BTW, who is using libsvgtiny? There is no package using it, no DEVELOPERS entry, a fragile build system and the version we use is out of date (2011-03-21). Maybe we can drop it? Best regards, Romain > > Please let me know > Thank you > > Best regards! ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2020-02-22 19:10 ` Romain Naour @ 2020-02-22 19:44 ` Giulio Benetti 2020-02-22 21:11 ` Fabrice Fontaine 0 siblings, 1 reply; 37+ messages in thread From: Giulio Benetti @ 2020-02-22 19:44 UTC (permalink / raw) To: buildroot Hi Romain, +Cc me @benettiengineering.com and... Il 22/02/2020 20:10, Romain Naour ha scritto: > Hi Giulio, > > CC: buildroot <buildroot@buildroot.org> > > Le 22/02/2020 ? 19:57, Giulio Benetti a ?crit?: >> Hi Romain, >> >> Il 22/02/2020 19:18, Romain Naour ha scritto: >>> Hi Giulio, >>> >>> Le 21/02/2020 ? 00:09, Giulio Benetti a ?crit?: >>>> Hi Thomas, >>>> >>>> Il 20/02/2020 19:23, Thomas Petazzoni ha scritto: >>>>> On Thu, 20 Feb 2020 19:16:37 +0100 >>>>> Giulio Benetti <giulio.benetti@micronovasrl.com> wrote: >>>>> >>>>>> So something like: >>>>>> # while true; do make foo && make foo-dirclean; done >>>>>> >>>>>> but please do you have a 'standard' form where it escapes on error? >>>>> >>>>> while true; do make foo && make foo-dirclean || break ; done >>>> >>>> Unfortunately the problem doesn't show up, I've also accelerated the building >>>> launching a local script in build/libsvgtiny-xxx/ that call make -j17 && make >>>> clean with all the arguments Buildroot provides to accelerate, but nothing. I've >>>> tried on my Workstation, my laptop and 1 of my autobuilders. >>>> >>>> Romain, have you had the chance to try that patch? Can I do something to ease >>>> the thing? Also, which specific distro(Distro name, kernel version) do you have? >>> >>> This a a Fedora 31 disto regularly updated. >>> >>> This is weird since we already disabled parallel build [1] >> >> Ah good finding, with this I've also found that [1] is wrong, since this is a >> generic package, so need to build with $(MAKE1) instead of $(MAKE) without >> LIBSVGTINY_MAKE = $(MAKE1) >> but maybe the patch i've sent you could work. >> >> Can you give a try? > > I tried to reproduce the issue but libsvgtiny still build fine here... > >> >> If it still fails, since this package contains 4 source files, I could send a >> patch that really avoid parallel build. And it must sent anyway a patch to fix >> that error. > > Maybe we can just fix the patch [1] ? > Can you send the patch ? ...yes, I'm going to send it soon. > BTW, who is using libsvgtiny? There is no package using it, no DEVELOPERS entry, > a fragile build system and the version we use is out of date (2011-03-21). > Maybe we can drop it? Yes, it should at least be bumped, I could take care of it, but I don't know if someone uses this package. Anyway I've seen that tags are set per year, so my effort would be very few to bump it and keep it up to date. Thomas, please let me know if it is a good idea or better drop it. -- Giulio Benetti > Best regards, > Romain > >> >> Please let me know >> Thank you >> >> Best regards! > ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2020-02-22 19:44 ` Giulio Benetti @ 2020-02-22 21:11 ` Fabrice Fontaine 2020-02-22 21:48 ` Giulio Benetti 0 siblings, 1 reply; 37+ messages in thread From: Fabrice Fontaine @ 2020-02-22 21:11 UTC (permalink / raw) To: buildroot Dear all, Le sam. 22 f?vr. 2020 ? 20:44, Giulio Benetti <giulio.benetti@micronovasrl.com> a ?crit : > > Hi Romain, > > +Cc me @benettiengineering.com and... > > Il 22/02/2020 20:10, Romain Naour ha scritto: > > Hi Giulio, > > > > CC: buildroot <buildroot@buildroot.org> > > > > Le 22/02/2020 ? 19:57, Giulio Benetti a ?crit : > >> Hi Romain, > >> > >> Il 22/02/2020 19:18, Romain Naour ha scritto: > >>> Hi Giulio, > >>> > >>> Le 21/02/2020 ? 00:09, Giulio Benetti a ?crit : > >>>> Hi Thomas, > >>>> > >>>> Il 20/02/2020 19:23, Thomas Petazzoni ha scritto: > >>>>> On Thu, 20 Feb 2020 19:16:37 +0100 > >>>>> Giulio Benetti <giulio.benetti@micronovasrl.com> wrote: > >>>>> > >>>>>> So something like: > >>>>>> # while true; do make foo && make foo-dirclean; done > >>>>>> > >>>>>> but please do you have a 'standard' form where it escapes on error? > >>>>> > >>>>> while true; do make foo && make foo-dirclean || break ; done > >>>> > >>>> Unfortunately the problem doesn't show up, I've also accelerated the building > >>>> launching a local script in build/libsvgtiny-xxx/ that call make -j17 && make > >>>> clean with all the arguments Buildroot provides to accelerate, but nothing. I've > >>>> tried on my Workstation, my laptop and 1 of my autobuilders. > >>>> > >>>> Romain, have you had the chance to try that patch? Can I do something to ease > >>>> the thing? Also, which specific distro(Distro name, kernel version) do you have? > >>> > >>> This a a Fedora 31 disto regularly updated. > >>> > >>> This is weird since we already disabled parallel build [1] > >> > >> Ah good finding, with this I've also found that [1] is wrong, since this is a > >> generic package, so need to build with $(MAKE1) instead of $(MAKE) without > >> LIBSVGTINY_MAKE = $(MAKE1) > >> but maybe the patch i've sent you could work. > >> > >> Can you give a try? > > > > I tried to reproduce the issue but libsvgtiny still build fine here... > > > >> > >> If it still fails, since this package contains 4 source files, I could send a > >> patch that really avoid parallel build. And it must sent anyway a patch to fix > >> that error. > > > > Maybe we can just fix the patch [1] ? > > Can you send the patch ? > > ...yes, I'm going to send it soon. > > > BTW, who is using libsvgtiny? There is no package using it, no DEVELOPERS entry, > > a fragile build system and the version we use is out of date (2011-03-21). > > Maybe we can drop it? > > Yes, it should at least be bumped, I could take care of it, but I don't > know if someone uses this package. Anyway I've seen that tags are set > per year, so my effort would be very few to bump it and keep it up to date. It should be noted that to bump it, you'll also have to bump netsurf-buildsystem as well as add libdom package which is used instead of libxml2 since https://source.netsurf-browser.org/libsvgtiny.git/commit/?id=d03a7471001c4701e1fea976aee162b0de375f52 libdom depends on libparserutils and libwapcaplet which also need to be added to buildroot. So that's probably a lot of work for a package that is not used currently by any package. > > Thomas, please let me know if it is a good idea or better drop it. > > -- > Giulio Benetti > > > Best regards, > > Romain > > > >> > >> Please let me know > >> Thank you > >> > >> Best regards! > > > Best Regards, Fabrice ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2020-02-22 21:11 ` Fabrice Fontaine @ 2020-02-22 21:48 ` Giulio Benetti 2020-02-22 22:00 ` Fabrice Fontaine 0 siblings, 1 reply; 37+ messages in thread From: Giulio Benetti @ 2020-02-22 21:48 UTC (permalink / raw) To: buildroot Hi Fabrice, On 2/22/20 10:11 PM, Fabrice Fontaine wrote: > Dear all, > > Le sam. 22 f?vr. 2020 ? 20:44, Giulio Benetti > <giulio.benetti@micronovasrl.com> a ?crit : >> >> Hi Romain, >> >> +Cc me @benettiengineering.com and... >> >> Il 22/02/2020 20:10, Romain Naour ha scritto: >>> Hi Giulio, >>> >>> CC: buildroot <buildroot@buildroot.org> >>> >>> Le 22/02/2020 ? 19:57, Giulio Benetti a ?crit : >>>> Hi Romain, >>>> >>>> Il 22/02/2020 19:18, Romain Naour ha scritto: >>>>> Hi Giulio, >>>>> >>>>> Le 21/02/2020 ? 00:09, Giulio Benetti a ?crit : >>>>>> Hi Thomas, >>>>>> >>>>>> Il 20/02/2020 19:23, Thomas Petazzoni ha scritto: >>>>>>> On Thu, 20 Feb 2020 19:16:37 +0100 >>>>>>> Giulio Benetti <giulio.benetti@micronovasrl.com> wrote: >>>>>>> >>>>>>>> So something like: >>>>>>>> # while true; do make foo && make foo-dirclean; done >>>>>>>> >>>>>>>> but please do you have a 'standard' form where it escapes on error? >>>>>>> >>>>>>> while true; do make foo && make foo-dirclean || break ; done >>>>>> >>>>>> Unfortunately the problem doesn't show up, I've also accelerated the building >>>>>> launching a local script in build/libsvgtiny-xxx/ that call make -j17 && make >>>>>> clean with all the arguments Buildroot provides to accelerate, but nothing. I've >>>>>> tried on my Workstation, my laptop and 1 of my autobuilders. >>>>>> >>>>>> Romain, have you had the chance to try that patch? Can I do something to ease >>>>>> the thing? Also, which specific distro(Distro name, kernel version) do you have? >>>>> >>>>> This a a Fedora 31 disto regularly updated. >>>>> >>>>> This is weird since we already disabled parallel build [1] >>>> >>>> Ah good finding, with this I've also found that [1] is wrong, since this is a >>>> generic package, so need to build with $(MAKE1) instead of $(MAKE) without >>>> LIBSVGTINY_MAKE = $(MAKE1) >>>> but maybe the patch i've sent you could work. >>>> >>>> Can you give a try? >>> >>> I tried to reproduce the issue but libsvgtiny still build fine here... >>> >>>> >>>> If it still fails, since this package contains 4 source files, I could send a >>>> patch that really avoid parallel build. And it must sent anyway a patch to fix >>>> that error. >>> >>> Maybe we can just fix the patch [1] ? >>> Can you send the patch ? >> >> ...yes, I'm going to send it soon. >> >>> BTW, who is using libsvgtiny? There is no package using it, no DEVELOPERS entry, >>> a fragile build system and the version we use is out of date (2011-03-21). >>> Maybe we can drop it? >> >> Yes, it should at least be bumped, I could take care of it, but I don't >> know if someone uses this package. Anyway I've seen that tags are set >> per year, so my effort would be very few to bump it and keep it up to date. > It should be noted that to bump it, you'll also have to bump > netsurf-buildsystem as well as add libdom package which is used > instead of libxml2 since > https://source.netsurf-browser.org/libsvgtiny.git/commit/?id=d03a7471001c4701e1fea976aee162b0de375f52 > libdom depends on libparserutils and libwapcaplet which also need to > be added to buildroot. > So that's probably a lot of work for a package that is not used > currently by any package. Fortunately you've described all the implications for bumping this package, thank you! After this I can tell I won't bump and maintain that package. Well, I've just sent the patch to fix parallel build: https://patchwork.ozlabs.org/patch/1242561/ Kind regards -- Giulio Benetti Benetti Engineering sas >> >> Thomas, please let me know if it is a good idea or better drop it. >> >> -- >> Giulio Benetti >> >>> Best regards, >>> Romain >>> >>>> >>>> Please let me know >>>> Thank you >>>> >>>> Best regards! >>> >> > Best Regards, > > Fabrice > _______________________________________________ > buildroot mailing list > buildroot at busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot > ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2020-02-22 21:48 ` Giulio Benetti @ 2020-02-22 22:00 ` Fabrice Fontaine 0 siblings, 0 replies; 37+ messages in thread From: Fabrice Fontaine @ 2020-02-22 22:00 UTC (permalink / raw) To: buildroot Le sam. 22 f?vr. 2020 ? 22:48, Giulio Benetti <giulio.benetti@benettiengineering.com> a ?crit : > > Hi Fabrice, > > On 2/22/20 10:11 PM, Fabrice Fontaine wrote: > > Dear all, > > > > Le sam. 22 f?vr. 2020 ? 20:44, Giulio Benetti > > <giulio.benetti@micronovasrl.com> a ?crit : > >> > >> Hi Romain, > >> > >> +Cc me @benettiengineering.com and... > >> > >> Il 22/02/2020 20:10, Romain Naour ha scritto: > >>> Hi Giulio, > >>> > >>> CC: buildroot <buildroot@buildroot.org> > >>> > >>> Le 22/02/2020 ? 19:57, Giulio Benetti a ?crit : > >>>> Hi Romain, > >>>> > >>>> Il 22/02/2020 19:18, Romain Naour ha scritto: > >>>>> Hi Giulio, > >>>>> > >>>>> Le 21/02/2020 ? 00:09, Giulio Benetti a ?crit : > >>>>>> Hi Thomas, > >>>>>> > >>>>>> Il 20/02/2020 19:23, Thomas Petazzoni ha scritto: > >>>>>>> On Thu, 20 Feb 2020 19:16:37 +0100 > >>>>>>> Giulio Benetti <giulio.benetti@micronovasrl.com> wrote: > >>>>>>> > >>>>>>>> So something like: > >>>>>>>> # while true; do make foo && make foo-dirclean; done > >>>>>>>> > >>>>>>>> but please do you have a 'standard' form where it escapes on error? > >>>>>>> > >>>>>>> while true; do make foo && make foo-dirclean || break ; done > >>>>>> > >>>>>> Unfortunately the problem doesn't show up, I've also accelerated the building > >>>>>> launching a local script in build/libsvgtiny-xxx/ that call make -j17 && make > >>>>>> clean with all the arguments Buildroot provides to accelerate, but nothing. I've > >>>>>> tried on my Workstation, my laptop and 1 of my autobuilders. > >>>>>> > >>>>>> Romain, have you had the chance to try that patch? Can I do something to ease > >>>>>> the thing? Also, which specific distro(Distro name, kernel version) do you have? > >>>>> > >>>>> This a a Fedora 31 disto regularly updated. > >>>>> > >>>>> This is weird since we already disabled parallel build [1] > >>>> > >>>> Ah good finding, with this I've also found that [1] is wrong, since this is a > >>>> generic package, so need to build with $(MAKE1) instead of $(MAKE) without > >>>> LIBSVGTINY_MAKE = $(MAKE1) > >>>> but maybe the patch i've sent you could work. > >>>> > >>>> Can you give a try? > >>> > >>> I tried to reproduce the issue but libsvgtiny still build fine here... > >>> > >>>> > >>>> If it still fails, since this package contains 4 source files, I could send a > >>>> patch that really avoid parallel build. And it must sent anyway a patch to fix > >>>> that error. > >>> > >>> Maybe we can just fix the patch [1] ? > >>> Can you send the patch ? > >> > >> ...yes, I'm going to send it soon. > >> > >>> BTW, who is using libsvgtiny? There is no package using it, no DEVELOPERS entry, > >>> a fragile build system and the version we use is out of date (2011-03-21). > >>> Maybe we can drop it? > >> > >> Yes, it should at least be bumped, I could take care of it, but I don't > >> know if someone uses this package. Anyway I've seen that tags are set > >> per year, so my effort would be very few to bump it and keep it up to date. > > It should be noted that to bump it, you'll also have to bump > > netsurf-buildsystem as well as add libdom package which is used > > instead of libxml2 since > > https://source.netsurf-browser.org/libsvgtiny.git/commit/?id=d03a7471001c4701e1fea976aee162b0de375f52 > > libdom depends on libparserutils and libwapcaplet which also need to > > be added to buildroot. > > So that's probably a lot of work for a package that is not used > > currently by any package. > > Fortunately you've described all the implications for bumping this > package, thank you! After this I can tell I won't bump and maintain that > package. That's perfectly understandable and I won't do it either so I would "vote" to drop this package as suggested by Romain. > > Well, I've just sent the patch to fix parallel build: > https://patchwork.ozlabs.org/patch/1242561/ > > Kind regards > -- > Giulio Benetti > Benetti Engineering sas > > >> > >> Thomas, please let me know if it is a good idea or better drop it. > >> > >> -- > >> Giulio Benetti > >> > >>> Best regards, > >>> Romain > >>> > >>>> > >>>> Please let me know > >>>> Thank you > >>>> > >>>> Best regards! > >>> > >> > > Best Regards, > > > > Fabrice > > _______________________________________________ > > buildroot mailing list > > buildroot at busybox.net > > http://lists.busybox.net/mailman/listinfo/buildroot > > > Best Regards, Fabrice ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results [not found] ` <20200220034343.2370e4e4@windsurf> ` (2 preceding siblings ...) [not found] ` <94c8edad-773d-2b36-5daf-b6ee60dd747f@micronovasrl.com> @ 2020-02-22 23:48 ` Romain Naour 3 siblings, 0 replies; 37+ messages in thread From: Romain Naour @ 2020-02-22 23:48 UTC (permalink / raw) To: buildroot Hello, Le 20/02/2020 ? 03:43, Thomas Petazzoni a ?crit?: > Hello, > > On Wed, 19 Feb 2020 07:48:39 -0000 > Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > >> master | 92 | 67 | 0 | 159 | > > These results are not really good, so we need to put some effort into > reducing the number of build failures in the autobuilders. See below > for an analysis of the different build failures. Your help is > appreciated to fix those issues. > > >> arm | efl-1.22.3 | NOK | http://autobuild.buildroot.net/results/4d7861fd5908c59546de19f6af3c27d061fed60b | > > /data/buildroot/buildroot-test/instance-0/output/host/bin/../arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/poppler/cpp/poppler-page.h:39:22: error: expected ',' or '...' before '&&' token > > Some C++ mess it seems. Romain, any idea ? This is an issue related to poppler dependency that is built with C++11 standard: sysroot/usr/include/poppler/cpp/poppler-page.h:70:10: "error: 'unique_ptr' in namespace 'std' does not name a template type" But with this toolchain based on gcc-5, the default C++ standard is gnu++98 [2]. The efl libraries should be built with -std=c++11 in CFLAGS (see [1] for similar issue). Or maybe we should bump the poppler's package gcc dependency (gcc 5 to gcc 6) [3]. Doing so, the C++ standard for poppler and efl are the same (C++14). Otherwise, I don't see how the efl package can know the C++ standard to use. [1] https://git.buildroot.net/buildroot/commit/?id=995fb9a4ebca3acb5dc6eb22edee039b67bf5303 [2] https://gcc.gnu.org/gcc-6/changes.html [3] https://git.buildroot.net/buildroot/tree/package/poppler/Config.in?h=2020.02-rc1#n7 Best regards, Romain > Thomas > ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Daily results for 2020-02-26
@ 2020-02-27 9:31 Thomas Petazzoni
2020-02-27 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni
0 siblings, 1 reply; 37+ messages in thread
From: Thomas Petazzoni @ 2020-02-27 9:31 UTC (permalink / raw)
To: buildroot
Hello,
Autobuild statistics for 2020-02-26
===============================
branch | OK | NOK | TIM | TOT |
2019.02.x | 20 | 1 | 0 | 21 |
2019.11.x | 16 | 0 | 0 | 16 |
master | 126 | 48 | 0 | 174 |
next | 34 | 22 | 0 | 56 |
Results for branch 'master'
===========================
Classification of failures by reason
------------------------------------
brltty-6.0 | 7
unknown | 6
protobuf-3.11.0 | 4
vlc-3.0.8 | 3
bitcoin-0.19.0.1 | 2
host-nodejs-12.16.0 | 2
mimic-1.1.0 | 2
mongodb-r4.0.12 | 2
qpdf-9.1.1 | 2
rocksdb-6.6.4 | 2
bash-5.0 | 1
domoticz-0f411f781ae4fb4a82... | 1
dvdauthor-0.7.2 | 1
fail2ban-0.11.1 | 1
gerbera-1.3.4 | 1
gst1-plugins-base-1.16.2 | 1
host-go-1.13.8 | 1
host-grpc-1.25.0 | 1
libgdiplus-5.6 | 1
libopenssl-1.1.1d | 1
lxc-3.2.1 | 1
mesa3d-19.3.4 | 1
minicom-52b626b15a883b03006... | 1
opencv3-3.4.9 | 1
pango-1.44.6 | 1
qt5svg-5.12.7 | 1
Detail of failures
------------------
arch | reason | OK? | url | orph?
-------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
microblazeel | bash-5.0 | NOK | http://autobuild.buildroot.net/results/c4bc6cc208e94ffb84caaea03c4898a3001c7f9a | ORPH
arc | bitcoin-0.19.0.1 | NOK | http://autobuild.buildroot.net/results/f4821f44ceb2811e9ab160dd2cb886243215df52 |
arc | bitcoin-0.19.0.1 | NOK | http://autobuild.buildroot.net/results/f3ac50c32c7e4fd3a5e9e3dd4170b0799a26270b |
mips64el | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/4569cbbe97ab9057e5e3909a03540544d588a479 |
sparc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/71fdd490873809acd89d7b3e3ea27e88c5b62c24 |
xtensa | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/caa1041217f8b2bc835dd6a06c13d59f70f72caa |
arc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/a05dee0491871bdd7d0a8f53d96e7971f7c71d1a |
arc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/a8edb5621ecc2d250f572240b0607762735b0ffb |
sparc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/1c6d8e80974547c48f6a4c9d2ff43b9ba268a2aa |
arm | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/7d8ccf9cc8559db9aed19bf32e6cb342141bd360 |
xtensa | domoticz-0f411f781ae4fb4a82... | NOK | http://autobuild.buildroot.net/results/7885705f1b1c0f31cf21b464150f5509929c1906 |
m68k | dvdauthor-0.7.2 | NOK | http://autobuild.buildroot.net/results/9c7f4f22386d4ffd211ed62da323f9861f1b1716 |
arm | fail2ban-0.11.1 | NOK | http://autobuild.buildroot.net/results/4b16c925a0aa0aba073324e2c3a4297c456b55bd |
riscv64 | gerbera-1.3.4 | NOK | http://autobuild.buildroot.net/results/b499442a920dd3969e2beb2099504d33641b4980 |
xtensa | gst1-plugins-base-1.16.2 | NOK | http://autobuild.buildroot.net/results/42cbc33ded6cf04f5cb2edb105f2e561d06886ff |
mips64el | host-go-1.13.8 | NOK | http://autobuild.buildroot.net/results/fa13a054995d6060d2dc15c36007e41a50ed7fc4 |
mips64el | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/4f853af32b5c09e63896e2125b5d018d279c0951 |
aarch64 | host-nodejs-12.16.0 | NOK | http://autobuild.buildroot.net/results/a83acd958d177a47ea2b1ca94b8a163da3e4a2c5 |
arm | host-nodejs-12.16.0 | NOK | http://autobuild.buildroot.net/results/c7934318c29b9dce9062d93158906409c5229a6d |
arc | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/46c5cf068cf9ea50e53491870d9dbf3f134c8c22 |
m68k | libopenssl-1.1.1d | NOK | http://autobuild.buildroot.net/results/686b92af36ec691dd06078c18df21f59209bea06 |
sparc64 | lxc-3.2.1 | NOK | http://autobuild.buildroot.net/results/94d021c513569cf4062619127ec2262d30b3201f |
arm | mesa3d-19.3.4 | NOK | http://autobuild.buildroot.net/results/6387b0a99e1a0922811919623d9a10b0943988df |
powerpc | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/ddb1c83ede34c125296563227f6b8f4b76729480 |
m68k | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/1a0caff18be6d55395c40f4d9f04076b03122757 |
arm | minicom-52b626b15a883b03006... | NOK | http://autobuild.buildroot.net/results/d3edbab1f2cd0f7b790e2559dc8d489497ae02f3 |
x86_64 | mongodb-r4.0.12 | NOK | http://autobuild.buildroot.net/results/80a0d9dc59567c28b891c50c63280cea3aad613f |
arm | mongodb-r4.0.12 | NOK | http://autobuild.buildroot.net/results/5765e33f444a22701b055015ed41436d3526e9eb |
aarch64_be | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/3938ecd3a0aae2e87d3876e7bf0d8244dcffb457 |
microblazeel | pango-1.44.6 | NOK | http://autobuild.buildroot.net/results/e5cfb968bc867d14f4ef4dd8da63b51360bc6808 | ORPH
or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/25a594a74795bbccf5a218a6cd3b6804beac6e4d |
or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/f0086358fd7bca5f2e77855c926641329e2e6ac8 |
or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/079fd66a15dba75ed1ba70aec8708f35fb7e93fe |
or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/f800a5f24cb4b23231165ad60c03bf177bad4a9f |
powerpc | qpdf-9.1.1 | NOK | http://autobuild.buildroot.net/results/c57fccab2e644b4b97971e9961682fac96f00a5c |
m68k | qpdf-9.1.1 | NOK | http://autobuild.buildroot.net/results/1e2299df96a2ddea22907870b6571553c5e7f7ef |
arm | qt5svg-5.12.7 | NOK | http://autobuild.buildroot.net/results/1c957888ba8f6124f093f96653035c8db2fc37ca |
arm | rocksdb-6.6.4 | NOK | http://autobuild.buildroot.net/results/832e1c85ee5ff79c74e84536ce09a66befe14c39 |
arm | rocksdb-6.6.4 | NOK | http://autobuild.buildroot.net/results/cdf9f3435e9526eee12bbf036d333c82323d24ba |
microblazeel | unknown | NOK | http://autobuild.buildroot.net/results/b92c1c09de74886c9039b3b76f35275f4e7a7b6c |
i686 | unknown | NOK | http://autobuild.buildroot.net/results/cdee1d3a823238be39f1d0bc6eb3498633b25865 |
arm | unknown | NOK | http://autobuild.buildroot.net/results/4e60fa31b1cd08bc7fdf9c5dd3a3f4941e029ba3 |
microblazeel | unknown | NOK | http://autobuild.buildroot.net/results/8466f1798cad365040ba6a5359fac30aafc82a60 |
x86_64 | unknown | NOK | http://autobuild.buildroot.net/results/deb862bed384296c2a6f119f63d4174cacb823d9 |
arm | unknown | NOK | http://autobuild.buildroot.net/results/4ce1704d3fc60fd3dec1d06b9031fb674b2236e3 |
riscv64 | vlc-3.0.8 | NOK | http://autobuild.buildroot.net/results/e8fd34f3b9b7166772e04d3e15c478990d07d894 |
riscv32 | vlc-3.0.8 | NOK | http://autobuild.buildroot.net/results/a61819381ff8dc59b1cf20338df6b6a49f63e0c0 |
i586 | vlc-3.0.8 | NOK | http://autobuild.buildroot.net/results/f11e2f24b998ac68891ab58a2bcf7b8677801767 |
Results for branch 'next'
=========================
Classification of failures by reason
------------------------------------
linphone-3.6.1 | 7
gensio-1.5.2 | 2
libglib2-2.62.4 | 2
bash-5.0 | 1
brltty-6.0 | 1
host-grpc-1.25.0 | 1
host-sdbusplus-4212292bcf13... | 1
libiio-0.19 | 1
libopenssl-1.1.1d | 1
mpd-0.21.20 | 1
opencv3-3.4.9 | 1
qpdf-9.1.1 | 1
qt5script-5.12.7 | 1
unknown | 1
Detail of failures
------------------
arch | reason | OK? | url | orph?
-------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
arm | bash-5.0 | NOK | http://autobuild.buildroot.net/results/76c75d1ea30c44debd87228eee0102fc7fe3bf89 | ORPH
powerpc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/d70f338a538dea322ce91cd3d57a6392c2ab55f4 |
arm | gensio-1.5.2 | NOK | http://autobuild.buildroot.net/results/62d1c2d6d55191d10af45d3cc95066308756644e |
riscv64 | gensio-1.5.2 | NOK | http://autobuild.buildroot.net/results/14157f596e48fee26e81e5f6ce3c9f6e5f9eea1f |
m68k | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/29e32d21d05f5acab5a460aa7c20339ab85f2a40 |
nios2 | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/1477fc1f40e6743bc2a2f39c7c88e8263a6324bf |
i586 | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/1b10f65c636acf87e6bcf5341f6884b3cbb8bebb |
powerpc | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/32afc3051d02aae5473da56f916ceaa8d8e2e409 |
arm | libiio-0.19 | NOK | http://autobuild.buildroot.net/results/42ffbd07d0e998c75d1afde6a5db7d6418c10f45 |
m68k | libopenssl-1.1.1d | NOK | http://autobuild.buildroot.net/results/14c0a553d4dcc82b08f4aef1fb95565879e4247f |
microblazeel | linphone-3.6.1 | NOK | http://autobuild.buildroot.net/results/838b1fba23d4a5ac7f4036ff5b124970df8bf8f9 | ORPH
sh4 | linphone-3.6.1 | NOK | http://autobuild.buildroot.net/results/eaa94ebb57d69998b596fc75d4f62bde4fe015f3 | ORPH
arc | linphone-3.6.1 | NOK | http://autobuild.buildroot.net/results/d24a504c570655a0ff4b7077f3864a27b7b92e38 | ORPH
arm | linphone-3.6.1 | NOK | http://autobuild.buildroot.net/results/6265a0b889beb67b3c8aaa7ee789ab5127413b62 | ORPH
xtensa | linphone-3.6.1 | NOK | http://autobuild.buildroot.net/results/38598433f53c79a64a9010cee05428af2b575ae9 | ORPH
aarch64 | linphone-3.6.1 | NOK | http://autobuild.buildroot.net/results/ebbd7951d8e7cb51c5e25686d092f4d71dd2e717 | ORPH
microblazeel | linphone-3.6.1 | NOK | http://autobuild.buildroot.net/results/5f5473d911886c31586e18ba3646d62cbd2f0d78 | ORPH
arm | mpd-0.21.20 | NOK | http://autobuild.buildroot.net/results/b97b261bc974f2d2b5480645cef9bf6a37eaceb0 |
arc | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/e8124d2f7d4c0122d632b6d78820f478d7151213 |
powerpc | qpdf-9.1.1 | NOK | http://autobuild.buildroot.net/results/6ae73d8965ec702207fa3edf5c82698b0fb936cd |
x86_64 | qt5script-5.12.7 | NOK | http://autobuild.buildroot.net/results/2e08b8b1605e601eb57a3597b15169fb4b64cb3b |
i586 | unknown | NOK | http://autobuild.buildroot.net/results/a5bd651e5c2bea2c571ed2412644028ba3d4c28b |
Results for branch '2019.02.x'
==============================
Classification of failures by reason
------------------------------------
host-grpc-v1.16.1 | 1
Detail of failures
------------------
arch | reason | OK? | url | orph?
-------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
powerpc | host-grpc-v1.16.1 | NOK | http://autobuild.buildroot.net/results/2530b053e0b78c2dcdac2ab87b6939ba99a10196 |
--
http://autobuild.buildroot.net
^ permalink raw reply [flat|nested] 37+ messages in thread* [Buildroot] Analysis of build results 2020-02-27 9:31 [Buildroot] [autobuild.buildroot.net] Daily results for 2020-02-26 Thomas Petazzoni @ 2020-02-27 22:49 ` Thomas Petazzoni 2020-02-27 23:06 ` Max Filippov ` (3 more replies) 0 siblings, 4 replies; 37+ messages in thread From: Thomas Petazzoni @ 2020-02-27 22:49 UTC (permalink / raw) To: buildroot Hello, Here is an analysis of yesterday's build failures. Please have a look and help! On Thu, 27 Feb 2020 09:31:33 -0000 Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > arch | reason | OK? | url | orph? > -------------+--------------------------------+-----+---------------------------------------------------------------------------------+------- > microblazeel | bash-5.0 | NOK | http://autobuild.buildroot.net/results/c4bc6cc208e94ffb84caaea03c4898a3001c7f9a | ORPH Would be fixed by http://patchwork.ozlabs.org/patch/1242647/, but I'm personally not entirely sure about this patch. > arc | bitcoin-0.19.0.1 | NOK | http://autobuild.buildroot.net/results/f4821f44ceb2811e9ab160dd2cb886243215df52 | > arc | bitcoin-0.19.0.1 | NOK | http://autobuild.buildroot.net/results/f3ac50c32c7e4fd3a5e9e3dd4170b0799a26270b | undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)' According to http://autobuild.buildroot.net/?reason=bitcoin%, this only happens on the ARC architecture. ARC maintainers, any idea ? > mips64el | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/4569cbbe97ab9057e5e3909a03540544d588a479 | > sparc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/71fdd490873809acd89d7b3e3ea27e88c5b62c24 | > xtensa | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/caa1041217f8b2bc835dd6a06c13d59f70f72caa | > arc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/a05dee0491871bdd7d0a8f53d96e7971f7c71d1a | > arc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/a8edb5621ecc2d250f572240b0607762735b0ffb | > sparc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/1c6d8e80974547c48f6a4c9d2ff43b9ba268a2aa | > arm | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/7d8ccf9cc8559db9aed19bf32e6cb342141bd360 | Fixed by https://git.buildroot.org/buildroot/commit/?id=7bed3ee409661107b6ce2a05c48adcc7f79258fa. > xtensa | domoticz-0f411f781ae4fb4a82... | NOK | http://autobuild.buildroot.net/results/7885705f1b1c0f31cf21b464150f5509929c1906 | Toolchain issue: BFD (GNU Binutils) 2.31.1 internal error, aborting at elf32-xtensa.c:3283 in elf_xtensa_finish_dynamic_sections Max, any idea ? > m68k | dvdauthor-0.7.2 | NOK | http://autobuild.buildroot.net/results/9c7f4f22386d4ffd211ed62da323f9861f1b1716 | elf2flt issue, Romain has posted a series to avoid it. > arm | fail2ban-0.11.1 | NOK | http://autobuild.buildroot.net/results/4b16c925a0aa0aba073324e2c3a4297c456b55bd | I would assume fixed by https://git.buildroot.org/buildroot/commit/?id=bdc9364ffae64623158830698a4f84fb2a179910. > riscv64 | gerbera-1.3.4 | NOK | http://autobuild.buildroot.net/results/b499442a920dd3969e2beb2099504d33641b4980 | /home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: cannot find /lib64/libc.so.6 /home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: cannot find /usr/lib/libc_nonshared.a /home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: cannot find /lib/ld-linux-riscv64-lp64d.so.1 This is a per-package directory build issue I believe. > xtensa | gst1-plugins-base-1.16.2 | NOK | http://autobuild.buildroot.net/results/42cbc33ded6cf04f5cb2edb105f2e561d06886ff | /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/xtensa-buildroot-linux-uclibc/8.3.0/../../../../xtensa-buildroot-linux-uclibc/bin/ld: gstplugin.c:(.text+0xb58): undefined reference to `g_module_open' /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/xtensa-buildroot-linux-uclibc/8.3.0/../../../../xtensa-buildroot-linux-uclibc/bin/ld: gstplugin.c:(.text+0xb5c): undefined reference to `g_module_error' static linking issue. Any brave meson/gstreamer person in the house ? Adam ? :-) > mips64el | host-go-1.13.8 | NOK | http://autobuild.buildroot.net/results/fa13a054995d6060d2dc15c36007e41a50ed7fc4 | Some funky toolchain issue: /data/buildroot/buildroot-test/instance-0/output/build/host-go-1.13.8/pkg/tool/linux_amd64/link: running /data/buildroot/buildroot-test/instance-0/output/host/bin/mips64el-linux-gcc failed: exit status 1 collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped compilation terminated. /data/buildroot/buildroot-test/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64el-buildroot-linux-uclibc/5.5.0/../../../../mips64el-buildroot-linux-uclibc/bin/ld: /tmp/go-link-130627779/go.o: relocation R_MIPS_26 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /data/buildroot/buildroot-test/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64el-buildroot-linux-uclibc/5.5.0/../../../../mips64el-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elfxx-mips.c:6550 > mips64el | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/4f853af32b5c09e63896e2125b5d018d279c0951 | Yann's machine still exhibiting this weird issue. > aarch64 | host-nodejs-12.16.0 | NOK | http://autobuild.buildroot.net/results/a83acd958d177a47ea2b1ca94b8a163da3e4a2c5 | > arm | host-nodejs-12.16.0 | NOK | http://autobuild.buildroot.net/results/c7934318c29b9dce9062d93158906409c5229a6d | Would be fixed by http://patchwork.ozlabs.org/patch/1239736/, but I don't like the fact that package A refers to package B build directory. > arc | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/46c5cf068cf9ea50e53491870d9dbf3f134c8c22 | /home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/9.2.1/../../../../arc-buildroot-linux-uclibc/bin/ld: ../src/.libs/libgdiplus.so: undefined reference to `GifQuantizeBuffer' This is *not* a static linking issue. > m68k | libopenssl-1.1.1d | NOK | http://autobuild.buildroot.net/results/686b92af36ec691dd06078c18df21f59209bea06 | elf2flt mess. > sparc64 | lxc-3.2.1 | NOK | http://autobuild.buildroot.net/results/94d021c513569cf4062619127ec2262d30b3201f | error: ^[[m^[[Kinvalid 'asm': invalid operand output code J?r?me, you are listed as the lxc package developer, could you have a look ? > arm | mesa3d-19.3.4 | NOK | http://autobuild.buildroot.net/results/6387b0a99e1a0922811919623d9a10b0943988df | {standard input}: Assembler messages: {standard input}:334: Error: selected processor does not support `vldm r4,{q0,q1,q2,q3}' in ARM mode {standard input}:335: Error: selected processor does not support `vst1.8 d0,[r3],r2' in ARM mode {standard input}:336: Error: selected processor does not support `vst1.8 d1,[r3],r2' in ARM mode {standard input}:337: Error: selected processor does not support `vst1.8 d2,[r3],r2' in ARM mode Bad stuff happens when building the vc4 driver. It probably needs some minimal ARM architecture variant. > powerpc | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/ddb1c83ede34c125296563227f6b8f4b76729480 | /home/giuliobenetti/autobuild/run/instance-0/output-1/host/lib/gcc/powerpc-buildroot-linux-uclibc/8.3.0/crtbeginS.o: in function `__do_global_dtors_aux': crtstuff.c:(.text+0x13c): relocation truncated to fit: R_PPC_PLTREL24 against symbol `__cxa_finalize' defined in .text section in /home/giuliobenetti/autobuild/run/instance-0/output-1/host/powerpc-buildroot-linux-uclibc/sysroot/lib/libc.so.1 collect2: error: ld returned 1 exit status > m68k | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/1a0caff18be6d55395c40f4d9f04076b03122757 | elf2flt mess. > arm | minicom-52b626b15a883b03006... | NOK | http://autobuild.buildroot.net/results/d3edbab1f2cd0f7b790e2559dc8d489497ae02f3 | Fixed by https://git.buildroot.org/buildroot/commit/?id=acbae76d6977b1f2d3847ea379c7dd8f1761f565. > x86_64 | mongodb-r4.0.12 | NOK | http://autobuild.buildroot.net/results/80a0d9dc59567c28b891c50c63280cea3aad613f | src/mongo/util/heap_profiler.cpp:484:33: error: 'abi' has not been declared > arm | mongodb-r4.0.12 | NOK | http://autobuild.buildroot.net/results/5765e33f444a22701b055015ed41436d3526e9eb | /home/test/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-linux-gnueabihf/7.3.1/../../../../arm-linux-gnueabihf/bin/ld.gold: error: /home/test/autobuild/run/instance-1/output-1/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libyaml-cpp.a(null.cpp.o): requires unsupported dynamic reloc R_ARM_MOVW_ABS_NC; recompile with -fPIC > aarch64_be | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/3938ecd3a0aae2e87d3876e7bf0d8244dcffb457 | /home/test/autobuild/run/instance-2/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:17:2: error: #error This file was generated by an older version of protoc which is #error This file was generated by an older version of protoc which is Sigh. > microblazeel | pango-1.44.6 | NOK | http://autobuild.buildroot.net/results/e5cfb968bc867d14f4ef4dd8da63b51360bc6808 | ORPH Static linking issue. > or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/25a594a74795bbccf5a218a6cd3b6804beac6e4d | > or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/f0086358fd7bca5f2e77855c926641329e2e6ac8 | > or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/079fd66a15dba75ed1ba70aec8708f35fb7e93fe | > or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/f800a5f24cb4b23231165ad60c03bf177bad4a9f | /home/giuliobenetti/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752 /home/giuliobenetti/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752 Giulio, I think you like toolchain issues! :-) > powerpc | qpdf-9.1.1 | NOK | http://autobuild.buildroot.net/results/c57fccab2e644b4b97971e9961682fac96f00a5c | libtool: error: 'libqpdf/build/QUtil.lo' is not a valid libtool object Not sure. Parallel build issue ? > m68k | qpdf-9.1.1 | NOK | http://autobuild.buildroot.net/results/1e2299df96a2ddea22907870b6571553c5e7f7ef | elf2flt mess. > arm | qt5svg-5.12.7 | NOK | http://autobuild.buildroot.net/results/1c957888ba8f6124f093f96653035c8db2fc37ca | per-package directory issue known, due to qt5 > arm | rocksdb-6.6.4 | NOK | http://autobuild.buildroot.net/results/832e1c85ee5ff79c74e84536ce09a66befe14c39 | > arm | rocksdb-6.6.4 | NOK | http://autobuild.buildroot.net/results/cdf9f3435e9526eee12bbf036d333c82323d24ba | Would be fixed by http://patchwork.ozlabs.org/patch/1243001/. > microblazeel | unknown | NOK | http://autobuild.buildroot.net/results/b92c1c09de74886c9039b3b76f35275f4e7a7b6c | Another funky toolchain issue: /home/giuliobenetti/autobuild/run/instance-3/output-1/per-package/x264/host/bin/../lib/gcc/microblazeel-buildroot-linux-uclibc/8.3.0/../../../../microblazeel-buildroot-linux-uclibc/bin/ld: FDE encoding in /home/giuliobenetti/autobuild/run/instance-3/output-1/per-package/x264/host/bin/../lib/gcc/microblazeel-buildroot-linux-uclibc/8.3.0/libgcc.a(_divdi3.o)(.eh_frame) prevents .eh_frame_hdr table being created > i686 | unknown | NOK | http://autobuild.buildroot.net/results/cdee1d3a823238be39f1d0bc6eb3498633b25865 | Probably a top-level parallel build issue. > arm | unknown | NOK | http://autobuild.buildroot.net/results/4e60fa31b1cd08bc7fdf9c5dd3a3f4941e029ba3 | Top-level parallel build issue that is fixed by my rework of the installed file list collection logic: mv: cannot stat '/home/giuliobenetti/autobuild/run/instance-0/output-1/build/.files-list-staging.new': No such file or directory > microblazeel | unknown | NOK | http://autobuild.buildroot.net/results/8466f1798cad365040ba6a5359fac30aafc82a60 | Reproducible build issue in: - getconf - rpm > x86_64 | unknown | NOK | http://autobuild.buildroot.net/results/deb862bed384296c2a6f119f63d4174cacb823d9 | Probably another top-level parallel build issue. > arm | unknown | NOK | http://autobuild.buildroot.net/results/4ce1704d3fc60fd3dec1d06b9031fb674b2236e3 | Fixed by my rework of the installed file collection logic: comm: /home/naourr/work/instance-1/output-1/build/.files-list-staging.new: No such file or directory > riscv64 | vlc-3.0.8 | NOK | http://autobuild.buildroot.net/results/e8fd34f3b9b7166772e04d3e15c478990d07d894 | > riscv32 | vlc-3.0.8 | NOK | http://autobuild.buildroot.net/results/a61819381ff8dc59b1cf20338df6b6a49f63e0c0 | > i586 | vlc-3.0.8 | NOK | http://autobuild.buildroot.net/results/f11e2f24b998ac68891ab58a2bcf7b8677801767 | video_filter/opencv_example.cpp:200:46: error: could not convert 'cv::Scalar_<double>((double)0, (double)0, (double)0, (double)0)' from 'cv::Scalar' {aka 'cv::Scalar_<double>'} to 'CvScalar' cvRectangle( p_img[0], pt1, pt2, CV_RGB(0,0,0), 3, 8, 0 ); Bernd, you are in charge of vlc, could you have a look ? Thanks! Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2020-02-27 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni @ 2020-02-27 23:06 ` Max Filippov 2020-02-27 23:18 ` Giulio Benetti ` (2 subsequent siblings) 3 siblings, 0 replies; 37+ messages in thread From: Max Filippov @ 2020-02-27 23:06 UTC (permalink / raw) To: buildroot On Thu, Feb 27, 2020 at 2:49 PM Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > xtensa | domoticz-0f411f781ae4fb4a82... | NOK | http://autobuild.buildroot.net/results/7885705f1b1c0f31cf21b464150f5509929c1906 | > > Toolchain issue: > > BFD (GNU Binutils) 2.31.1 internal error, aborting at elf32-xtensa.c:3283 in elf_xtensa_finish_dynamic_sections > > Max, any idea ? Looking at it, thanks for the heads up! -- Thanks. -- Max ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2020-02-27 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni 2020-02-27 23:06 ` Max Filippov @ 2020-02-27 23:18 ` Giulio Benetti 2020-02-28 8:03 ` Thomas Petazzoni 2020-02-28 18:06 ` Giulio Benetti 2020-02-28 6:21 ` Heiko Thiery 2020-02-28 7:32 ` Romain Naour 3 siblings, 2 replies; 37+ messages in thread From: Giulio Benetti @ 2020-02-27 23:18 UTC (permalink / raw) To: buildroot Hello, Inviato da iPhone > Il giorno 27 feb 2020, alle ore 23:49, Thomas Petazzoni <thomas.petazzoni@bootlin.com> ha scritto: > > ?Hello, > > Here is an analysis of yesterday's build failures. Please have a look > and help! > >> On Thu, 27 Feb 2020 09:31:33 -0000 >> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: >> >> arch | reason | OK? | url | orph? >> -------------+--------------------------------+-----+---------------------------------------------------------------------------------+------- >> microblazeel | bash-5.0 | NOK | http://autobuild.buildroot.net/results/c4bc6cc208e94ffb84caaea03c4898a3001c7f9a | ORPH > > Would be fixed by http://patchwork.ozlabs.org/patch/1242647/, but I'm > personally not entirely sure about this patch. > >> arc | bitcoin-0.19.0.1 | NOK | http://autobuild.buildroot.net/results/f4821f44ceb2811e9ab160dd2cb886243215df52 | >> arc | bitcoin-0.19.0.1 | NOK | http://autobuild.buildroot.net/results/f3ac50c32c7e4fd3a5e9e3dd4170b0799a26270b | > > undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)' > > According to http://autobuild.buildroot.net/?reason=bitcoin%, this only > happens on the ARC architecture. > > ARC maintainers, any idea ? > >> mips64el | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/4569cbbe97ab9057e5e3909a03540544d588a479 | >> sparc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/71fdd490873809acd89d7b3e3ea27e88c5b62c24 | >> xtensa | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/caa1041217f8b2bc835dd6a06c13d59f70f72caa | >> arc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/a05dee0491871bdd7d0a8f53d96e7971f7c71d1a | >> arc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/a8edb5621ecc2d250f572240b0607762735b0ffb | >> sparc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/1c6d8e80974547c48f6a4c9d2ff43b9ba268a2aa | >> arm | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/7d8ccf9cc8559db9aed19bf32e6cb342141bd360 | > > Fixed by https://git.buildroot.org/buildroot/commit/?id=7bed3ee409661107b6ce2a05c48adcc7f79258fa. > >> xtensa | domoticz-0f411f781ae4fb4a82... | NOK | http://autobuild.buildroot.net/results/7885705f1b1c0f31cf21b464150f5509929c1906 | > > Toolchain issue: > > BFD (GNU Binutils) 2.31.1 internal error, aborting at elf32-xtensa.c:3283 in elf_xtensa_finish_dynamic_sections > > Max, any idea ? > >> m68k | dvdauthor-0.7.2 | NOK | http://autobuild.buildroot.net/results/9c7f4f22386d4ffd211ed62da323f9861f1b1716 | > > elf2flt issue, Romain has posted a series to avoid it. > >> arm | fail2ban-0.11.1 | NOK | http://autobuild.buildroot.net/results/4b16c925a0aa0aba073324e2c3a4297c456b55bd | > > I would assume fixed by > https://git.buildroot.org/buildroot/commit/?id=bdc9364ffae64623158830698a4f84fb2a179910. > >> riscv64 | gerbera-1.3.4 | NOK | http://autobuild.buildroot.net/results/b499442a920dd3969e2beb2099504d33641b4980 | > > /home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: cannot find /lib64/libc.so.6 > /home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: cannot find /usr/lib/libc_nonshared.a > /home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: cannot find /lib/ld-linux-riscv64-lp64d.so.1 > > This is a per-package directory build issue I believe. > >> xtensa | gst1-plugins-base-1.16.2 | NOK | http://autobuild.buildroot.net/results/42cbc33ded6cf04f5cb2edb105f2e561d06886ff | > > /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/xtensa-buildroot-linux-uclibc/8.3.0/../../../../xtensa-buildroot-linux-uclibc/bin/ld: gstplugin.c:(.text+0xb58): undefined reference to `g_module_open' > /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/xtensa-buildroot-linux-uclibc/8.3.0/../../../../xtensa-buildroot-linux-uclibc/bin/ld: gstplugin.c:(.text+0xb5c): undefined reference to `g_module_error' > > static linking issue. Any brave meson/gstreamer person in the house ? > Adam ? :-) > >> mips64el | host-go-1.13.8 | NOK | http://autobuild.buildroot.net/results/fa13a054995d6060d2dc15c36007e41a50ed7fc4 | > > Some funky toolchain issue: > > /data/buildroot/buildroot-test/instance-0/output/build/host-go-1.13.8/pkg/tool/linux_amd64/link: running /data/buildroot/buildroot-test/instance-0/output/host/bin/mips64el-linux-gcc failed: exit status 1 > collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped > compilation terminated. > /data/buildroot/buildroot-test/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64el-buildroot-linux-uclibc/5.5.0/../../../../mips64el-buildroot-linux-uclibc/bin/ld: /tmp/go-link-130627779/go.o: relocation R_MIPS_26 against `a local symbol' can not be used when making a shared object; recompile with -fPIC > /data/buildroot/buildroot-test/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64el-buildroot-linux-uclibc/5.5.0/../../../../mips64el-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elfxx-mips.c:6550 > >> mips64el | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/4f853af32b5c09e63896e2125b5d018d279c0951 | > > Yann's machine still exhibiting this weird issue. > >> aarch64 | host-nodejs-12.16.0 | NOK | http://autobuild.buildroot.net/results/a83acd958d177a47ea2b1ca94b8a163da3e4a2c5 | >> arm | host-nodejs-12.16.0 | NOK | http://autobuild.buildroot.net/results/c7934318c29b9dce9062d93158906409c5229a6d | > > Would be fixed by http://patchwork.ozlabs.org/patch/1239736/, but I > don't like the fact that package A refers to package B build directory. > >> arc | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/46c5cf068cf9ea50e53491870d9dbf3f134c8c22 | > > /home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/9.2.1/../../../../arc-buildroot-linux-uclibc/bin/ld: ../src/.libs/libgdiplus.so: undefined reference to `GifQuantizeBuffer' > > This is *not* a static linking issue. > >> m68k | libopenssl-1.1.1d | NOK | http://autobuild.buildroot.net/results/686b92af36ec691dd06078c18df21f59209bea06 | > > elf2flt mess. > >> sparc64 | lxc-3.2.1 | NOK | http://autobuild.buildroot.net/results/94d021c513569cf4062619127ec2262d30b3201f | > > error: ^[[m^[[Kinvalid 'asm': invalid operand output code > > J?r?me, you are listed as the lxc package developer, could you have a > look ? > > >> arm | mesa3d-19.3.4 | NOK | http://autobuild.buildroot.net/results/6387b0a99e1a0922811919623d9a10b0943988df | > > {standard input}: Assembler messages: > {standard input}:334: Error: selected processor does not support `vldm r4,{q0,q1,q2,q3}' in ARM mode > {standard input}:335: Error: selected processor does not support `vst1.8 d0,[r3],r2' in ARM mode > {standard input}:336: Error: selected processor does not support `vst1.8 d1,[r3],r2' in ARM mode > {standard input}:337: Error: selected processor does not support `vst1.8 d2,[r3],r2' in ARM mode > > Bad stuff happens when building the vc4 driver. It probably needs some > minimal ARM architecture variant. > >> powerpc | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/ddb1c83ede34c125296563227f6b8f4b76729480 | > > /home/giuliobenetti/autobuild/run/instance-0/output-1/host/lib/gcc/powerpc-buildroot-linux-uclibc/8.3.0/crtbeginS.o: in function `__do_global_dtors_aux': > crtstuff.c:(.text+0x13c): relocation truncated to fit: R_PPC_PLTREL24 against symbol `__cxa_finalize' defined in .text section in /home/giuliobenetti/autobuild/run/instance-0/output-1/host/powerpc-buildroot-linux-uclibc/sysroot/lib/libc.so.1 > collect2: error: ld returned 1 exit status > >> m68k | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/1a0caff18be6d55395c40f4d9f04076b03122757 | > > elf2flt mess. > >> arm | minicom-52b626b15a883b03006... | NOK | http://autobuild.buildroot.net/results/d3edbab1f2cd0f7b790e2559dc8d489497ae02f3 | > > Fixed by https://git.buildroot.org/buildroot/commit/?id=acbae76d6977b1f2d3847ea379c7dd8f1761f565. > >> x86_64 | mongodb-r4.0.12 | NOK | http://autobuild.buildroot.net/results/80a0d9dc59567c28b891c50c63280cea3aad613f | > > src/mongo/util/heap_profiler.cpp:484:33: error: 'abi' has not been declared > >> arm | mongodb-r4.0.12 | NOK | http://autobuild.buildroot.net/results/5765e33f444a22701b055015ed41436d3526e9eb | > > /home/test/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-linux-gnueabihf/7.3.1/../../../../arm-linux-gnueabihf/bin/ld.gold: error: /home/test/autobuild/run/instance-1/output-1/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libyaml-cpp.a(null.cpp.o): requires unsupported dynamic reloc R_ARM_MOVW_ABS_NC; recompile with -fPIC > >> aarch64_be | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/3938ecd3a0aae2e87d3876e7bf0d8244dcffb457 | > > /home/test/autobuild/run/instance-2/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:17:2: error: #error This file was generated by an older version of protoc which is > #error This file was generated by an older version of protoc which is > > Sigh. > >> microblazeel | pango-1.44.6 | NOK | http://autobuild.buildroot.net/results/e5cfb968bc867d14f4ef4dd8da63b51360bc6808 | ORPH > > Static linking issue. > >> or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/25a594a74795bbccf5a218a6cd3b6804beac6e4d | >> or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/f0086358fd7bca5f2e77855c926641329e2e6ac8 | >> or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/079fd66a15dba75ed1ba70aec8708f35fb7e93fe | >> or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/f800a5f24cb4b23231165ad60c03bf177bad4a9f | > > /home/giuliobenetti/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752 > /home/giuliobenetti/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752 > > Giulio, I think you like toolchain issues! :-) Everyone has its particular tastes... :-) I take care about this and... > >> powerpc | qpdf-9.1.1 | NOK | http://autobuild.buildroot.net/results/c57fccab2e644b4b97971e9961682fac96f00a5c | > > libtool: error: 'libqpdf/build/QUtil.lo' is not a valid libtool object > > Not sure. Parallel build issue ? > >> m68k | qpdf-9.1.1 | NOK | http://autobuild.buildroot.net/results/1e2299df96a2ddea22907870b6571553c5e7f7ef | > > elf2flt mess. > >> arm | qt5svg-5.12.7 | NOK | http://autobuild.buildroot.net/results/1c957888ba8f6124f093f96653035c8db2fc37ca | > > per-package directory issue known, due to qt5 > >> arm | rocksdb-6.6.4 | NOK | http://autobuild.buildroot.net/results/832e1c85ee5ff79c74e84536ce09a66befe14c39 | >> arm | rocksdb-6.6.4 | NOK | http://autobuild.buildroot.net/results/cdf9f3435e9526eee12bbf036d333c82323d24ba | > > Would be fixed by http://patchwork.ozlabs.org/patch/1243001/. > >> microblazeel | unknown | NOK | http://autobuild.buildroot.net/results/b92c1c09de74886c9039b3b76f35275f4e7a7b6c | > > Another funky toolchain issue: > > /home/giuliobenetti/autobuild/run/instance-3/output-1/per-package/x264/host/bin/../lib/gcc/microblazeel-buildroot-linux-uclibc/8.3.0/../../../../microblazeel-buildroot-linux-uclibc/bin/ld: FDE encoding in /home/giuliobenetti/autobuild/run/instance-3/output-1/per-package/x264/host/bin/../lib/gcc/microblazeel-buildroot-linux-uclibc/8.3.0/libgcc.a(_divdi3.o)(.eh_frame) prevents .eh_frame_hdr table being created ... this too in 1-2 days at most. And as I?ve pointed libnss is waiting to be applied. Upstream almost applied it to, but we had a deal for PowerPC sys/auxv.h build failure. Btw did you all noticed an increase of NOK after adding the 2 Micronova Autobuilders? They build fast but I don?t know in the complex how much they contribute. Best regards! Giulio Benetti > >> i686 | unknown | NOK | http://autobuild.buildroot.net/results/cdee1d3a823238be39f1d0bc6eb3498633b25865 | > > Probably a top-level parallel build issue. > >> arm | unknown | NOK | http://autobuild.buildroot.net/results/4e60fa31b1cd08bc7fdf9c5dd3a3f4941e029ba3 | > > Top-level parallel build issue that is fixed by my rework of the > installed file list collection logic: > > mv: cannot stat '/home/giuliobenetti/autobuild/run/instance-0/output-1/build/.files-list-staging.new': No such file or directory > > >> microblazeel | unknown | NOK | http://autobuild.buildroot.net/results/8466f1798cad365040ba6a5359fac30aafc82a60 | > > Reproducible build issue in: > > - getconf > - rpm > >> x86_64 | unknown | NOK | http://autobuild.buildroot.net/results/deb862bed384296c2a6f119f63d4174cacb823d9 | > > Probably another top-level parallel build issue. > >> arm | unknown | NOK | http://autobuild.buildroot.net/results/4ce1704d3fc60fd3dec1d06b9031fb674b2236e3 | > > Fixed by my rework of the installed file collection logic: > > comm: /home/naourr/work/instance-1/output-1/build/.files-list-staging.new: No such file or directory > > >> riscv64 | vlc-3.0.8 | NOK | http://autobuild.buildroot.net/results/e8fd34f3b9b7166772e04d3e15c478990d07d894 | >> riscv32 | vlc-3.0.8 | NOK | http://autobuild.buildroot.net/results/a61819381ff8dc59b1cf20338df6b6a49f63e0c0 | >> i586 | vlc-3.0.8 | NOK | http://autobuild.buildroot.net/results/f11e2f24b998ac68891ab58a2bcf7b8677801767 | > > video_filter/opencv_example.cpp:200:46: error: could not convert 'cv::Scalar_<double>((double)0, (double)0, (double)0, (double)0)' from 'cv::Scalar' {aka 'cv::Scalar_<double>'} to 'CvScalar' > cvRectangle( p_img[0], pt1, pt2, CV_RGB(0,0,0), 3, 8, 0 ); > > Bernd, you are in charge of vlc, could you have a look ? > > Thanks! > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com > _______________________________________________ > buildroot mailing list > buildroot at busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2020-02-27 23:18 ` Giulio Benetti @ 2020-02-28 8:03 ` Thomas Petazzoni 2020-02-28 18:06 ` Giulio Benetti 1 sibling, 0 replies; 37+ messages in thread From: Thomas Petazzoni @ 2020-02-28 8:03 UTC (permalink / raw) To: buildroot On Fri, 28 Feb 2020 00:18:29 +0100 Giulio Benetti <giulio.benetti@benettiengineering.com> wrote: > ... this too in 1-2 days at most. Thanks! > And as I?ve pointed libnss is waiting to be applied. Upstream almost applied it to, but we had a deal for PowerPC sys/auxv.h build failure. Yes, I've seen you posted a new version of the patch. > Btw did you all noticed an increase of NOK after adding the 2 > Micronova Autobuilders? They build fast but I don?t know in the > complex how much they contribute. You can see statistics over time at http://autobuild.buildroot.net/stats.php. Bringing new builders doesn't really increase the number of failed builds, but rather the overall number of builds. In the mean time, we have fixed a number of build failures, which statistically reduces the number of build failures overall. I have also restarted builders on the Bootlin build server, gcc159 and gcc160, so overall, we are getting quite a bit more of build results compared to a few days ago. Best regards, Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2020-02-27 23:18 ` Giulio Benetti 2020-02-28 8:03 ` Thomas Petazzoni @ 2020-02-28 18:06 ` Giulio Benetti 1 sibling, 0 replies; 37+ messages in thread From: Giulio Benetti @ 2020-02-28 18:06 UTC (permalink / raw) To: buildroot Hello, On 2/28/20 12:18 AM, Giulio Benetti wrote: > Hello, > > Inviato da iPhone > >> Il giorno 27 feb 2020, alle ore 23:49, Thomas Petazzoni <thomas.petazzoni@bootlin.com> ha scritto: >> >> ?Hello, >> >> Here is an analysis of yesterday's build failures. Please have a look >> and help! >> >>> On Thu, 27 Feb 2020 09:31:33 -0000 >>> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: >>> >>> arch | reason | OK? | url | orph? >>> -------------+--------------------------------+-----+---------------------------------------------------------------------------------+------- >>> microblazeel | bash-5.0 | NOK | http://autobuild.buildroot.net/results/c4bc6cc208e94ffb84caaea03c4898a3001c7f9a | ORPH >> >> Would be fixed by http://patchwork.ozlabs.org/patch/1242647/, but I'm >> personally not entirely sure about this patch. >> >>> arc | bitcoin-0.19.0.1 | NOK | http://autobuild.buildroot.net/results/f4821f44ceb2811e9ab160dd2cb886243215df52 | >>> arc | bitcoin-0.19.0.1 | NOK | http://autobuild.buildroot.net/results/f3ac50c32c7e4fd3a5e9e3dd4170b0799a26270b | >> >> undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)' >> >> According to http://autobuild.buildroot.net/?reason=bitcoin%, this only >> happens on the ARC architecture. >> >> ARC maintainers, any idea ? >> >>> mips64el | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/4569cbbe97ab9057e5e3909a03540544d588a479 | >>> sparc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/71fdd490873809acd89d7b3e3ea27e88c5b62c24 | >>> xtensa | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/caa1041217f8b2bc835dd6a06c13d59f70f72caa | >>> arc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/a05dee0491871bdd7d0a8f53d96e7971f7c71d1a | >>> arc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/a8edb5621ecc2d250f572240b0607762735b0ffb | >>> sparc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/1c6d8e80974547c48f6a4c9d2ff43b9ba268a2aa | >>> arm | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/7d8ccf9cc8559db9aed19bf32e6cb342141bd360 | >> >> Fixed by https://git.buildroot.org/buildroot/commit/?id=7bed3ee409661107b6ce2a05c48adcc7f79258fa. >> >>> xtensa | domoticz-0f411f781ae4fb4a82... | NOK | http://autobuild.buildroot.net/results/7885705f1b1c0f31cf21b464150f5509929c1906 | >> >> Toolchain issue: >> >> BFD (GNU Binutils) 2.31.1 internal error, aborting at elf32-xtensa.c:3283 in elf_xtensa_finish_dynamic_sections >> >> Max, any idea ? >> >>> m68k | dvdauthor-0.7.2 | NOK | http://autobuild.buildroot.net/results/9c7f4f22386d4ffd211ed62da323f9861f1b1716 | >> >> elf2flt issue, Romain has posted a series to avoid it. >> >>> arm | fail2ban-0.11.1 | NOK | http://autobuild.buildroot.net/results/4b16c925a0aa0aba073324e2c3a4297c456b55bd | >> >> I would assume fixed by >> https://git.buildroot.org/buildroot/commit/?id=bdc9364ffae64623158830698a4f84fb2a179910. >> >>> riscv64 | gerbera-1.3.4 | NOK | http://autobuild.buildroot.net/results/b499442a920dd3969e2beb2099504d33641b4980 | >> >> /home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: cannot find /lib64/libc.so.6 >> /home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: cannot find /usr/lib/libc_nonshared.a >> /home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: cannot find /lib/ld-linux-riscv64-lp64d.so.1 >> >> This is a per-package directory build issue I believe. >> >>> xtensa | gst1-plugins-base-1.16.2 | NOK | http://autobuild.buildroot.net/results/42cbc33ded6cf04f5cb2edb105f2e561d06886ff | >> >> /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/xtensa-buildroot-linux-uclibc/8.3.0/../../../../xtensa-buildroot-linux-uclibc/bin/ld: gstplugin.c:(.text+0xb58): undefined reference to `g_module_open' >> /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/xtensa-buildroot-linux-uclibc/8.3.0/../../../../xtensa-buildroot-linux-uclibc/bin/ld: gstplugin.c:(.text+0xb5c): undefined reference to `g_module_error' >> >> static linking issue. Any brave meson/gstreamer person in the house ? >> Adam ? :-) >> >>> mips64el | host-go-1.13.8 | NOK | http://autobuild.buildroot.net/results/fa13a054995d6060d2dc15c36007e41a50ed7fc4 | >> >> Some funky toolchain issue: >> >> /data/buildroot/buildroot-test/instance-0/output/build/host-go-1.13.8/pkg/tool/linux_amd64/link: running /data/buildroot/buildroot-test/instance-0/output/host/bin/mips64el-linux-gcc failed: exit status 1 >> collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped >> compilation terminated. >> /data/buildroot/buildroot-test/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64el-buildroot-linux-uclibc/5.5.0/../../../../mips64el-buildroot-linux-uclibc/bin/ld: /tmp/go-link-130627779/go.o: relocation R_MIPS_26 against `a local symbol' can not be used when making a shared object; recompile with -fPIC >> /data/buildroot/buildroot-test/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64el-buildroot-linux-uclibc/5.5.0/../../../../mips64el-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elfxx-mips.c:6550 >> >>> mips64el | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/4f853af32b5c09e63896e2125b5d018d279c0951 | >> >> Yann's machine still exhibiting this weird issue. >> >>> aarch64 | host-nodejs-12.16.0 | NOK | http://autobuild.buildroot.net/results/a83acd958d177a47ea2b1ca94b8a163da3e4a2c5 | >>> arm | host-nodejs-12.16.0 | NOK | http://autobuild.buildroot.net/results/c7934318c29b9dce9062d93158906409c5229a6d | >> >> Would be fixed by http://patchwork.ozlabs.org/patch/1239736/, but I >> don't like the fact that package A refers to package B build directory. >> >>> arc | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/46c5cf068cf9ea50e53491870d9dbf3f134c8c22 | >> >> /home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/9.2.1/../../../../arc-buildroot-linux-uclibc/bin/ld: ../src/.libs/libgdiplus.so: undefined reference to `GifQuantizeBuffer' >> >> This is *not* a static linking issue. >> >>> m68k | libopenssl-1.1.1d | NOK | http://autobuild.buildroot.net/results/686b92af36ec691dd06078c18df21f59209bea06 | >> >> elf2flt mess. >> >>> sparc64 | lxc-3.2.1 | NOK | http://autobuild.buildroot.net/results/94d021c513569cf4062619127ec2262d30b3201f | >> >> error: ^[[m^[[Kinvalid 'asm': invalid operand output code >> >> J?r?me, you are listed as the lxc package developer, could you have a >> look ? >> >> >>> arm | mesa3d-19.3.4 | NOK | http://autobuild.buildroot.net/results/6387b0a99e1a0922811919623d9a10b0943988df | >> >> {standard input}: Assembler messages: >> {standard input}:334: Error: selected processor does not support `vldm r4,{q0,q1,q2,q3}' in ARM mode >> {standard input}:335: Error: selected processor does not support `vst1.8 d0,[r3],r2' in ARM mode >> {standard input}:336: Error: selected processor does not support `vst1.8 d1,[r3],r2' in ARM mode >> {standard input}:337: Error: selected processor does not support `vst1.8 d2,[r3],r2' in ARM mode >> >> Bad stuff happens when building the vc4 driver. It probably needs some >> minimal ARM architecture variant. >> >>> powerpc | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/ddb1c83ede34c125296563227f6b8f4b76729480 | >> >> /home/giuliobenetti/autobuild/run/instance-0/output-1/host/lib/gcc/powerpc-buildroot-linux-uclibc/8.3.0/crtbeginS.o: in function `__do_global_dtors_aux': >> crtstuff.c:(.text+0x13c): relocation truncated to fit: R_PPC_PLTREL24 against symbol `__cxa_finalize' defined in .text section in /home/giuliobenetti/autobuild/run/instance-0/output-1/host/powerpc-buildroot-linux-uclibc/sysroot/lib/libc.so.1 >> collect2: error: ld returned 1 exit status >> >>> m68k | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/1a0caff18be6d55395c40f4d9f04076b03122757 | >> >> elf2flt mess. >> >>> arm | minicom-52b626b15a883b03006... | NOK | http://autobuild.buildroot.net/results/d3edbab1f2cd0f7b790e2559dc8d489497ae02f3 | >> >> Fixed by https://git.buildroot.org/buildroot/commit/?id=acbae76d6977b1f2d3847ea379c7dd8f1761f565. >> >>> x86_64 | mongodb-r4.0.12 | NOK | http://autobuild.buildroot.net/results/80a0d9dc59567c28b891c50c63280cea3aad613f | >> >> src/mongo/util/heap_profiler.cpp:484:33: error: 'abi' has not been declared >> >>> arm | mongodb-r4.0.12 | NOK | http://autobuild.buildroot.net/results/5765e33f444a22701b055015ed41436d3526e9eb | >> >> /home/test/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-linux-gnueabihf/7.3.1/../../../../arm-linux-gnueabihf/bin/ld.gold: error: /home/test/autobuild/run/instance-1/output-1/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libyaml-cpp.a(null.cpp.o): requires unsupported dynamic reloc R_ARM_MOVW_ABS_NC; recompile with -fPIC >> >>> aarch64_be | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/3938ecd3a0aae2e87d3876e7bf0d8244dcffb457 | >> >> /home/test/autobuild/run/instance-2/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:17:2: error: #error This file was generated by an older version of protoc which is >> #error This file was generated by an older version of protoc which is >> >> Sigh. >> >>> microblazeel | pango-1.44.6 | NOK | http://autobuild.buildroot.net/results/e5cfb968bc867d14f4ef4dd8da63b51360bc6808 | ORPH >> >> Static linking issue. >> >>> or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/25a594a74795bbccf5a218a6cd3b6804beac6e4d | >>> or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/f0086358fd7bca5f2e77855c926641329e2e6ac8 | >>> or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/079fd66a15dba75ed1ba70aec8708f35fb7e93fe | >>> or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/f800a5f24cb4b23231165ad60c03bf177bad4a9f | >> >> /home/giuliobenetti/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752 >> /home/giuliobenetti/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752 >> >> Giulio, I think you like toolchain issues! :-) > > Everyone has its particular tastes... :-) > I take care about this and... This is fixed by these: https://patchwork.ozlabs.org/project/buildroot/list/?series=161548 >>> microblazeel | unknown | NOK | http://autobuild.buildroot.net/results/b92c1c09de74886c9039b3b76f35275f4e7a7b6c | >> >> Another funky toolchain issue: >> >> /home/giuliobenetti/autobuild/run/instance-3/output-1/per-package/x264/host/bin/../lib/gcc/microblazeel-buildroot-linux-uclibc/8.3.0/../../../../microblazeel-buildroot-linux-uclibc/bin/ld: FDE encoding in /home/giuliobenetti/autobuild/run/instance-3/output-1/per-package/x264/host/bin/../lib/gcc/microblazeel-buildroot-linux-uclibc/8.3.0/libgcc.a(_divdi3.o)(.eh_frame) prevents .eh_frame_hdr table being created I can't reproduce this, any suggestions to make it trigger? Thank you Best regards -- Giulio Benetti Benetti Engineering sas ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2020-02-27 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni 2020-02-27 23:06 ` Max Filippov 2020-02-27 23:18 ` Giulio Benetti @ 2020-02-28 6:21 ` Heiko Thiery 2020-02-28 7:56 ` Sergio Prado 2020-02-28 8:01 ` Thomas Petazzoni 2020-02-28 7:32 ` Romain Naour 3 siblings, 2 replies; 37+ messages in thread From: Heiko Thiery @ 2020-02-28 6:21 UTC (permalink / raw) To: buildroot Hi Thomas ,Sergio and all, > > arc | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/46c5cf068cf9ea50e53491870d9dbf3f134c8c22 | > > /home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/9.2.1/../../../../arc-buildroot-linux-uclibc/bin/ld: ../src/.libs/libgdiplus.so: undefined reference to `GifQuantizeBuffer' > > This is *not* a static linking issue. This is an issue coming with a newer giflib version (https://github.com/mono/libgdiplus/pull/575). Gitlib has remove the code used by libgdiplus version in buildroot. But in version 6.x of libgdiplus the commit https://github.com/mono/libgdiplus/commit/1c028b7087b27e62fff6dcf8e3240ce2b1a4ce7a included the missing fucntion from giflib. There are 2 options: 1) update libgdiplus to 6.x in buildroot (I dont know if it is possible with little effort) 2) backport the fix commit (unfortunatly the commit does not apply to the version used by buildroot) What do you think? -- Heiko ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2020-02-28 6:21 ` Heiko Thiery @ 2020-02-28 7:56 ` Sergio Prado 2020-02-28 8:01 ` Thomas Petazzoni 1 sibling, 0 replies; 37+ messages in thread From: Sergio Prado @ 2020-02-28 7:56 UTC (permalink / raw) To: buildroot Hi Heiko, Thomas, and all: Em sex., 28 de fev. de 2020 ?s 03:22, Heiko Thiery <heiko.thiery@gmail.com> escreveu: > > Hi Thomas ,Sergio and all, > > > > arc | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/46c5cf068cf9ea50e53491870d9dbf3f134c8c22 | > > > > /home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/9.2.1/../../../../arc-buildroot-linux-uclibc/bin/ld: ../src/.libs/libgdiplus.so: undefined reference to `GifQuantizeBuffer' > > > > This is *not* a static linking issue. > > This is an issue coming with a newer giflib version > (https://github.com/mono/libgdiplus/pull/575). > Gitlib has remove the code used by libgdiplus version in buildroot. > But in version 6.x of libgdiplus the commit > https://github.com/mono/libgdiplus/commit/1c028b7087b27e62fff6dcf8e3240ce2b1a4ce7a > included the missing fucntion from giflib. > > > There are 2 options: > 1) update libgdiplus to 6.x in buildroot (I dont know if it is > possible with little effort) > 2) backport the fix commit (unfortunatly the commit does not apply to > the version used by buildroot) > > What do you think? I will bump to version 6.0.4, test it and send a patch. Best regards, Sergio Prado -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200228/e5860a63/attachment.html> ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2020-02-28 6:21 ` Heiko Thiery 2020-02-28 7:56 ` Sergio Prado @ 2020-02-28 8:01 ` Thomas Petazzoni 1 sibling, 0 replies; 37+ messages in thread From: Thomas Petazzoni @ 2020-02-28 8:01 UTC (permalink / raw) To: buildroot Hello Heiko, Thanks for looking into this! On Fri, 28 Feb 2020 07:21:55 +0100 Heiko Thiery <heiko.thiery@gmail.com> wrote: > > > arc | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/46c5cf068cf9ea50e53491870d9dbf3f134c8c22 | > > > > /home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/9.2.1/../../../../arc-buildroot-linux-uclibc/bin/ld: ../src/.libs/libgdiplus.so: undefined reference to `GifQuantizeBuffer' > > > > This is *not* a static linking issue. > > This is an issue coming with a newer giflib version > (https://github.com/mono/libgdiplus/pull/575). > Gitlib has remove the code used by libgdiplus version in buildroot. > But in version 6.x of libgdiplus the commit > https://github.com/mono/libgdiplus/commit/1c028b7087b27e62fff6dcf8e3240ce2b1a4ce7a > included the missing fucntion from giflib. > > > There are 2 options: > 1) update libgdiplus to 6.x in buildroot (I dont know if it is > possible with little effort) > 2) backport the fix commit (unfortunatly the commit does not apply to > the version used by buildroot) > > What do you think? For master, a small backport is much more reasonable, if said backport can easily be achieved. Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2020-02-27 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni ` (2 preceding siblings ...) 2020-02-28 6:21 ` Heiko Thiery @ 2020-02-28 7:32 ` Romain Naour 2020-02-28 15:02 ` Peter Seiderer 3 siblings, 1 reply; 37+ messages in thread From: Romain Naour @ 2020-02-28 7:32 UTC (permalink / raw) To: buildroot Hi Thomas, Le jeu. 27 f?vr. 2020 ? 23:49, Thomas Petazzoni < thomas.petazzoni@bootlin.com> a ?crit : > Hello, > > Here is an analysis of yesterday's build failures. Please have a look > and help! > > On Thu, 27 Feb 2020 09:31:33 -0000 > Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > > arch | reason | OK? | > url | orph? > > > -------------+--------------------------------+-----+---------------------------------------------------------------------------------+------- > > microblazeel | bash-5.0 | NOK | > http://autobuild.buildroot.net/results/c4bc6cc208e94ffb84caaea03c4898a3001c7f9a > | ORPH > > Would be fixed by http://patchwork.ozlabs.org/patch/1242647/, but I'm > personally not entirely sure about this patch. > > > arc | bitcoin-0.19.0.1 | NOK | > http://autobuild.buildroot.net/results/f4821f44ceb2811e9ab160dd2cb886243215df52 > | > > arc | bitcoin-0.19.0.1 | NOK | > http://autobuild.buildroot.net/results/f3ac50c32c7e4fd3a5e9e3dd4170b0799a26270b > | > > undefined reference to > `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)' > > According to http://autobuild.buildroot.net/?reason=bitcoin%, this only > happens on the ARC architecture. > > ARC maintainers, any idea ? > > > mips64el | brltty-6.0 | NOK | > http://autobuild.buildroot.net/results/4569cbbe97ab9057e5e3909a03540544d588a479 > | > > sparc | brltty-6.0 | NOK | > http://autobuild.buildroot.net/results/71fdd490873809acd89d7b3e3ea27e88c5b62c24 > | > > xtensa | brltty-6.0 | NOK | > http://autobuild.buildroot.net/results/caa1041217f8b2bc835dd6a06c13d59f70f72caa > | > > arc | brltty-6.0 | NOK | > http://autobuild.buildroot.net/results/a05dee0491871bdd7d0a8f53d96e7971f7c71d1a > | > > arc | brltty-6.0 | NOK | > http://autobuild.buildroot.net/results/a8edb5621ecc2d250f572240b0607762735b0ffb > | > > sparc | brltty-6.0 | NOK | > http://autobuild.buildroot.net/results/1c6d8e80974547c48f6a4c9d2ff43b9ba268a2aa > | > > arm | brltty-6.0 | NOK | > http://autobuild.buildroot.net/results/7d8ccf9cc8559db9aed19bf32e6cb342141bd360 > | > > Fixed by > https://git.buildroot.org/buildroot/commit/?id=7bed3ee409661107b6ce2a05c48adcc7f79258fa > . > > > xtensa | domoticz-0f411f781ae4fb4a82... | NOK | > http://autobuild.buildroot.net/results/7885705f1b1c0f31cf21b464150f5509929c1906 > | > > Toolchain issue: > > BFD (GNU Binutils) 2.31.1 internal error, aborting at elf32-xtensa.c:3283 > in elf_xtensa_finish_dynamic_sections > > Max, any idea ? > > > m68k | dvdauthor-0.7.2 | NOK | > http://autobuild.buildroot.net/results/9c7f4f22386d4ffd211ed62da323f9861f1b1716 > | > > elf2flt issue, Romain has posted a series to avoid it. > > > arm | fail2ban-0.11.1 | NOK | > http://autobuild.buildroot.net/results/4b16c925a0aa0aba073324e2c3a4297c456b55bd > | > > I would assume fixed by > > https://git.buildroot.org/buildroot/commit/?id=bdc9364ffae64623158830698a4f84fb2a179910 > . > > > riscv64 | gerbera-1.3.4 | NOK | > http://autobuild.buildroot.net/results/b499442a920dd3969e2beb2099504d33641b4980 > | > > /home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: > cannot find /lib64/libc.so.6 > /home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: > cannot find /usr/lib/libc_nonshared.a > /home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: > cannot find /lib/ld-linux-riscv64-lp64d.so.1 > > This is a per-package directory build issue I believe. > > > xtensa | gst1-plugins-base-1.16.2 | NOK | > http://autobuild.buildroot.net/results/42cbc33ded6cf04f5cb2edb105f2e561d06886ff > | > > /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/xtensa-buildroot-linux-uclibc/8.3.0/../../../../xtensa-buildroot-linux-uclibc/bin/ld: > gstplugin.c:(.text+0xb58): undefined reference to `g_module_open' > /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/xtensa-buildroot-linux-uclibc/8.3.0/../../../../xtensa-buildroot-linux-uclibc/bin/ld: > gstplugin.c:(.text+0xb5c): undefined reference to `g_module_error' > > static linking issue. Any brave meson/gstreamer person in the house ? > Adam ? :-) > > > mips64el | host-go-1.13.8 | NOK | > http://autobuild.buildroot.net/results/fa13a054995d6060d2dc15c36007e41a50ed7fc4 > | > > Some funky toolchain issue: > > /data/buildroot/buildroot-test/instance-0/output/build/host-go-1.13.8/pkg/tool/linux_amd64/link: > running > /data/buildroot/buildroot-test/instance-0/output/host/bin/mips64el-linux-gcc > failed: exit status 1 > collect2: fatal error: ld terminated with signal 11 [Segmentation fault], > core dumped > compilation terminated. > /data/buildroot/buildroot-test/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64el-buildroot-linux-uclibc/5.5.0/../../../../mips64el-buildroot-linux-uclibc/bin/ld: > /tmp/go-link-130627779/go.o: relocation R_MIPS_26 against `a local symbol' > can not be used when making a shared object; recompile with -fPIC > /data/buildroot/buildroot-test/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64el-buildroot-linux-uclibc/5.5.0/../../../../mips64el-buildroot-linux-uclibc/bin/ld: > BFD (GNU Binutils) 2.31.1 assertion fail elfxx-mips.c:6550 > > > mips64el | host-grpc-1.25.0 | NOK | > http://autobuild.buildroot.net/results/4f853af32b5c09e63896e2125b5d018d279c0951 > | > > Yann's machine still exhibiting this weird issue. > > > aarch64 | host-nodejs-12.16.0 | NOK | > http://autobuild.buildroot.net/results/a83acd958d177a47ea2b1ca94b8a163da3e4a2c5 > | > > arm | host-nodejs-12.16.0 | NOK | > http://autobuild.buildroot.net/results/c7934318c29b9dce9062d93158906409c5229a6d > | > > Would be fixed by http://patchwork.ozlabs.org/patch/1239736/, but I > don't like the fact that package A refers to package B build directory. > > > arc | libgdiplus-5.6 | NOK | > http://autobuild.buildroot.net/results/46c5cf068cf9ea50e53491870d9dbf3f134c8c22 > | > > /home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/9.2.1/../../../../arc-buildroot-linux-uclibc/bin/ld: > ../src/.libs/libgdiplus.so: undefined reference to `GifQuantizeBuffer' > > This is *not* a static linking issue. > > > m68k | libopenssl-1.1.1d | NOK | > http://autobuild.buildroot.net/results/686b92af36ec691dd06078c18df21f59209bea06 > | > > elf2flt mess. > > > sparc64 | lxc-3.2.1 | NOK | > http://autobuild.buildroot.net/results/94d021c513569cf4062619127ec2262d30b3201f > | > > error: [m [Kinvalid 'asm': invalid operand output code > > J?r?me, you are listed as the lxc package developer, could you have a > look ? > > > > arm | mesa3d-19.3.4 | NOK | > http://autobuild.buildroot.net/results/6387b0a99e1a0922811919623d9a10b0943988df > | > > {standard input}: Assembler messages: > {standard input}:334: Error: selected processor does not support `vldm > r4,{q0,q1,q2,q3}' in ARM mode > {standard input}:335: Error: selected processor does not support `vst1.8 > d0,[r3],r2' in ARM mode > {standard input}:336: Error: selected processor does not support `vst1.8 > d1,[r3],r2' in ARM mode > {standard input}:337: Error: selected processor does not support `vst1.8 > d2,[r3],r2' in ARM mode > > Bad stuff happens when building the vc4 driver. It probably needs some > minimal ARM architecture variant. > I believe we should re-add the dependency on neon for vc4 driver. There is -mfpu=neon added by the build system. Romain > > powerpc | mimic-1.1.0 | NOK | > http://autobuild.buildroot.net/results/ddb1c83ede34c125296563227f6b8f4b76729480 > | > > /home/giuliobenetti/autobuild/run/instance-0/output-1/host/lib/gcc/powerpc-buildroot-linux-uclibc/8.3.0/crtbeginS.o: > in function `__do_global_dtors_aux': > crtstuff.c:(.text+0x13c): relocation truncated to fit: R_PPC_PLTREL24 > against symbol `__cxa_finalize' defined in .text section in > /home/giuliobenetti/autobuild/run/instance-0/output-1/host/powerpc-buildroot-linux-uclibc/sysroot/lib/libc.so.1 > collect2: error: ld returned 1 exit status > > > m68k | mimic-1.1.0 | NOK | > http://autobuild.buildroot.net/results/1a0caff18be6d55395c40f4d9f04076b03122757 > | > > elf2flt mess. > > > arm | minicom-52b626b15a883b03006... | NOK | > http://autobuild.buildroot.net/results/d3edbab1f2cd0f7b790e2559dc8d489497ae02f3 > | > > Fixed by > https://git.buildroot.org/buildroot/commit/?id=acbae76d6977b1f2d3847ea379c7dd8f1761f565 > . > > > x86_64 | mongodb-r4.0.12 | NOK | > http://autobuild.buildroot.net/results/80a0d9dc59567c28b891c50c63280cea3aad613f > | > > src/mongo/util/heap_profiler.cpp:484:33: error: 'abi' has not been declared > > > arm | mongodb-r4.0.12 | NOK | > http://autobuild.buildroot.net/results/5765e33f444a22701b055015ed41436d3526e9eb > | > > /home/test/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-linux-gnueabihf/7.3.1/../../../../arm-linux-gnueabihf/bin/ld.gold: > error: > /home/test/autobuild/run/instance-1/output-1/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libyaml-cpp.a(null.cpp.o): > requires unsupported dynamic reloc R_ARM_MOVW_ABS_NC; recompile with -fPIC > > > aarch64_be | opencv3-3.4.9 | NOK | > http://autobuild.buildroot.net/results/3938ecd3a0aae2e87d3876e7bf0d8244dcffb457 > | > > /home/test/autobuild/run/instance-2/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:17:2: > error: #error This file was generated by an older version of protoc which is > #error This file was generated by an older version of protoc which is > > Sigh. > > > microblazeel | pango-1.44.6 | NOK | > http://autobuild.buildroot.net/results/e5cfb968bc867d14f4ef4dd8da63b51360bc6808 > | ORPH > > Static linking issue. > > > or1k | protobuf-3.11.0 | NOK | > http://autobuild.buildroot.net/results/25a594a74795bbccf5a218a6cd3b6804beac6e4d > | > > or1k | protobuf-3.11.0 | NOK | > http://autobuild.buildroot.net/results/f0086358fd7bca5f2e77855c926641329e2e6ac8 > | > > or1k | protobuf-3.11.0 | NOK | > http://autobuild.buildroot.net/results/079fd66a15dba75ed1ba70aec8708f35fb7e93fe > | > > or1k | protobuf-3.11.0 | NOK | > http://autobuild.buildroot.net/results/f800a5f24cb4b23231165ad60c03bf177bad4a9f > | > > /home/giuliobenetti/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: > BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752 > /home/giuliobenetti/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: > BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752 > > Giulio, I think you like toolchain issues! :-) > > > powerpc | qpdf-9.1.1 | NOK | > http://autobuild.buildroot.net/results/c57fccab2e644b4b97971e9961682fac96f00a5c > | > > libtool: error: 'libqpdf/build/QUtil.lo' is not a valid libtool object > > Not sure. Parallel build issue ? > > > m68k | qpdf-9.1.1 | NOK | > http://autobuild.buildroot.net/results/1e2299df96a2ddea22907870b6571553c5e7f7ef > | > > elf2flt mess. > > > arm | qt5svg-5.12.7 | NOK | > http://autobuild.buildroot.net/results/1c957888ba8f6124f093f96653035c8db2fc37ca > | > > per-package directory issue known, due to qt5 > > > arm | rocksdb-6.6.4 | NOK | > http://autobuild.buildroot.net/results/832e1c85ee5ff79c74e84536ce09a66befe14c39 > | > > arm | rocksdb-6.6.4 | NOK | > http://autobuild.buildroot.net/results/cdf9f3435e9526eee12bbf036d333c82323d24ba > | > > Would be fixed by http://patchwork.ozlabs.org/patch/1243001/. > > > microblazeel | unknown | NOK | > http://autobuild.buildroot.net/results/b92c1c09de74886c9039b3b76f35275f4e7a7b6c > | > > Another funky toolchain issue: > > /home/giuliobenetti/autobuild/run/instance-3/output-1/per-package/x264/host/bin/../lib/gcc/microblazeel-buildroot-linux-uclibc/8.3.0/../../../../microblazeel-buildroot-linux-uclibc/bin/ld: > FDE encoding in > /home/giuliobenetti/autobuild/run/instance-3/output-1/per-package/x264/host/bin/../lib/gcc/microblazeel-buildroot-linux-uclibc/8.3.0/libgcc.a(_divdi3.o)(.eh_frame) > prevents .eh_frame_hdr table being created > > > i686 | unknown | NOK | > http://autobuild.buildroot.net/results/cdee1d3a823238be39f1d0bc6eb3498633b25865 > | > > Probably a top-level parallel build issue. > > > arm | unknown | NOK | > http://autobuild.buildroot.net/results/4e60fa31b1cd08bc7fdf9c5dd3a3f4941e029ba3 > | > > Top-level parallel build issue that is fixed by my rework of the > installed file list collection logic: > > mv: cannot stat > '/home/giuliobenetti/autobuild/run/instance-0/output-1/build/.files-list-staging.new': > No such file or directory > > > > microblazeel | unknown | NOK | > http://autobuild.buildroot.net/results/8466f1798cad365040ba6a5359fac30aafc82a60 > | > > Reproducible build issue in: > > - getconf > - rpm > > > x86_64 | unknown | NOK | > http://autobuild.buildroot.net/results/deb862bed384296c2a6f119f63d4174cacb823d9 > | > > Probably another top-level parallel build issue. > > > arm | unknown | NOK | > http://autobuild.buildroot.net/results/4ce1704d3fc60fd3dec1d06b9031fb674b2236e3 > | > > Fixed by my rework of the installed file collection logic: > > comm: /home/naourr/work/instance-1/output-1/build/.files-list-staging.new: > No such file or directory > > > > riscv64 | vlc-3.0.8 | NOK | > http://autobuild.buildroot.net/results/e8fd34f3b9b7166772e04d3e15c478990d07d894 > | > > riscv32 | vlc-3.0.8 | NOK | > http://autobuild.buildroot.net/results/a61819381ff8dc59b1cf20338df6b6a49f63e0c0 > | > > i586 | vlc-3.0.8 | NOK | > http://autobuild.buildroot.net/results/f11e2f24b998ac68891ab58a2bcf7b8677801767 > | > > video_filter/opencv_example.cpp:200:46: error: could not convert > 'cv::Scalar_<double>((double)0, (double)0, (double)0, (double)0)' from > 'cv::Scalar' {aka 'cv::Scalar_<double>'} to 'CvScalar' > cvRectangle( p_img[0], pt1, pt2, CV_RGB(0,0,0), 3, 8, 0 ); > > Bernd, you are in charge of vlc, could you have a look ? > > Thanks! > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com > _______________________________________________ > buildroot mailing list > buildroot at busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200228/9e0f3691/attachment.html> ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2020-02-28 7:32 ` Romain Naour @ 2020-02-28 15:02 ` Peter Seiderer 2020-02-29 21:15 ` Romain Naour 0 siblings, 1 reply; 37+ messages in thread From: Peter Seiderer @ 2020-02-28 15:02 UTC (permalink / raw) To: buildroot Hello Romain, On Fri, 28 Feb 2020 08:32:18 +0100, Romain Naour <romain.naour@gmail.com> wrote: > > > > > arm | mesa3d-19.3.4 | NOK | > > http://autobuild.buildroot.net/results/6387b0a99e1a0922811919623d9a10b0943988df > > | > > > > {standard input}: Assembler messages: > > {standard input}:334: Error: selected processor does not support `vldm > > r4,{q0,q1,q2,q3}' in ARM mode > > {standard input}:335: Error: selected processor does not support `vst1.8 > > d0,[r3],r2' in ARM mode > > {standard input}:336: Error: selected processor does not support `vst1.8 > > d1,[r3],r2' in ARM mode > > {standard input}:337: Error: selected processor does not support `vst1.8 > > d2,[r3],r2' in ARM mode > > > > Bad stuff happens when building the vc4 driver. It probably needs some > > minimal ARM architecture variant. > > > > I believe we should re-add the dependency on neon for vc4 driver. There is > -mfpu=neon added by the build system. The BR2_ARM_CPU_HAS_NEON dependency was dropped with commit [1] because mesa3d commit [2] added a compile time detected neon support, in the meantime this was changed to a runtime detection [3] and finally enabled for the meson cross compile build with commit [4] (assuming toolchain support for the neon assembler instructions)... Maybe the compile error could be fixed by re-adding partly the compile time check for the neon support (tested): --- mesa3d-19.3.4/src/broadcom/common/v3d_cpu_tiling.h_orig 2020-02-28 14:47:44.232634657 +0100 +++ mesa3d-19.3.4/src/broadcom/common/v3d_cpu_tiling.h 2020-02-28 14:49:21.518425222 +0100 @@ -31,7 +31,7 @@ v3d_load_utile(void *cpu, uint32_t cpu_stride, void *gpu, uint32_t gpu_stride) { -#if defined(V3D_BUILD_NEON) && defined(PIPE_ARCH_ARM) +#if defined(V3D_BUILD_NEON) && defined(__ARM_ARCH) && __ARM_ARCH >= 7 if (gpu_stride == 8) { __asm__ volatile ( /* Load from the GPU in one shot, no interleave, to @@ -141,7 +141,7 @@ v3d_store_utile(void *gpu, uint32_t gpu_stride, void *cpu, uint32_t cpu_stride) { -#if defined(V3D_BUILD_NEON) && defined(PIPE_ARCH_ARM) +#if defined(V3D_BUILD_NEON) && defined(__ARM_ARCH) && __ARM_ARCH >= 7 if (gpu_stride == 8) { __asm__ volatile ( /* Load each 8-byte line from cpu-side source, Regards, Peter [1] https://git.buildroot.net/buildroot/commit/package/mesa3d?id=350cb0d32ece533b9723a5f3ca6fbf7e6f071c90 [2] https://cgit.freedesktop.org/mesa/mesa/commit/?h=17.1&id=4d30024238efa829cabc72c1601beeee18c3dbf2 [3] https://cgit.freedesktop.org/mesa/mesa/commit/?h=staging/19.3&id=ece06defe77a77d2db40abeddee5a2e0e45654ce [4] https://cgit.freedesktop.org/mesa/mesa/commit/?id=932ed9c00b99e6ec92146ec9e820f546cf3e6551 > > Romain ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2020-02-28 15:02 ` Peter Seiderer @ 2020-02-29 21:15 ` Romain Naour 2020-02-29 23:17 ` Peter Seiderer 0 siblings, 1 reply; 37+ messages in thread From: Romain Naour @ 2020-02-29 21:15 UTC (permalink / raw) To: buildroot Hi Peter, Le 28/02/2020 ? 16:02, Peter Seiderer a ?crit?: > Hello Romain, > > On Fri, 28 Feb 2020 08:32:18 +0100, Romain Naour <romain.naour@gmail.com> wrote: > >>> >>>> arm | mesa3d-19.3.4 | NOK | >>> http://autobuild.buildroot.net/results/6387b0a99e1a0922811919623d9a10b0943988df >>> | >>> >>> {standard input}: Assembler messages: >>> {standard input}:334: Error: selected processor does not support `vldm >>> r4,{q0,q1,q2,q3}' in ARM mode >>> {standard input}:335: Error: selected processor does not support `vst1.8 >>> d0,[r3],r2' in ARM mode >>> {standard input}:336: Error: selected processor does not support `vst1.8 >>> d1,[r3],r2' in ARM mode >>> {standard input}:337: Error: selected processor does not support `vst1.8 >>> d2,[r3],r2' in ARM mode >>> >>> Bad stuff happens when building the vc4 driver. It probably needs some >>> minimal ARM architecture variant. >>> >> >> I believe we should re-add the dependency on neon for vc4 driver. There is >> -mfpu=neon added by the build system. > > The BR2_ARM_CPU_HAS_NEON dependency was dropped with commit [1] because mesa3d > commit [2] added a compile time detected neon support, in the meantime this > was changed to a runtime detection [3] and finally enabled for the meson > cross compile build with commit [4] (assuming toolchain support for the > neon assembler instructions)... Thank you for the detailed explanation. I saw the commit [4] and conclude that upstream mesa3d now require neon support when vc4 driver is enabled. > > Maybe the compile error could be fixed by re-adding partly the compile time > check for the neon support (tested): > > --- mesa3d-19.3.4/src/broadcom/common/v3d_cpu_tiling.h_orig 2020-02-28 14:47:44.232634657 +0100 > +++ mesa3d-19.3.4/src/broadcom/common/v3d_cpu_tiling.h 2020-02-28 14:49:21.518425222 +0100 > @@ -31,7 +31,7 @@ > v3d_load_utile(void *cpu, uint32_t cpu_stride, > void *gpu, uint32_t gpu_stride) > { > -#if defined(V3D_BUILD_NEON) && defined(PIPE_ARCH_ARM) > +#if defined(V3D_BUILD_NEON) && defined(__ARM_ARCH) && __ARM_ARCH >= 7 > if (gpu_stride == 8) { > __asm__ volatile ( > /* Load from the GPU in one shot, no interleave, to > @@ -141,7 +141,7 @@ > v3d_store_utile(void *gpu, uint32_t gpu_stride, > void *cpu, uint32_t cpu_stride) > { > -#if defined(V3D_BUILD_NEON) && defined(PIPE_ARCH_ARM) > +#if defined(V3D_BUILD_NEON) && defined(__ARM_ARCH) && __ARM_ARCH >= 7 > if (gpu_stride == 8) { > __asm__ volatile ( > /* Load each 8-byte line from cpu-side source, > But -mfpu=neon is still present on the command line. Do you think if the neon support can be handled/forced by a new meson option? Best regards, Romain > Regards, > Peter > > [1] https://git.buildroot.net/buildroot/commit/package/mesa3d?id=350cb0d32ece533b9723a5f3ca6fbf7e6f071c90 > [2] https://cgit.freedesktop.org/mesa/mesa/commit/?h=17.1&id=4d30024238efa829cabc72c1601beeee18c3dbf2 > [3] https://cgit.freedesktop.org/mesa/mesa/commit/?h=staging/19.3&id=ece06defe77a77d2db40abeddee5a2e0e45654ce > [4] https://cgit.freedesktop.org/mesa/mesa/commit/?id=932ed9c00b99e6ec92146ec9e820f546cf3e6551 > >> >> Romain > ^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis of build results 2020-02-29 21:15 ` Romain Naour @ 2020-02-29 23:17 ` Peter Seiderer 0 siblings, 0 replies; 37+ messages in thread From: Peter Seiderer @ 2020-02-29 23:17 UTC (permalink / raw) To: buildroot Hello Romain, On Sat, 29 Feb 2020 22:15:10 +0100, Romain Naour <romain.naour@gmail.com> wrote: > Hi Peter, > > Le 28/02/2020 ? 16:02, Peter Seiderer a ?crit?: > > Hello Romain, > > > > On Fri, 28 Feb 2020 08:32:18 +0100, Romain Naour <romain.naour@gmail.com> wrote: > > > >>> > >>>> arm | mesa3d-19.3.4 | NOK | > >>> http://autobuild.buildroot.net/results/6387b0a99e1a0922811919623d9a10b0943988df > >>> | > >>> > >>> {standard input}: Assembler messages: > >>> {standard input}:334: Error: selected processor does not support `vldm > >>> r4,{q0,q1,q2,q3}' in ARM mode > >>> {standard input}:335: Error: selected processor does not support `vst1.8 > >>> d0,[r3],r2' in ARM mode > >>> {standard input}:336: Error: selected processor does not support `vst1.8 > >>> d1,[r3],r2' in ARM mode > >>> {standard input}:337: Error: selected processor does not support `vst1.8 > >>> d2,[r3],r2' in ARM mode > >>> > >>> Bad stuff happens when building the vc4 driver. It probably needs some > >>> minimal ARM architecture variant. > >>> > >> > >> I believe we should re-add the dependency on neon for vc4 driver. There is > >> -mfpu=neon added by the build system. > > > > The BR2_ARM_CPU_HAS_NEON dependency was dropped with commit [1] because mesa3d > > commit [2] added a compile time detected neon support, in the meantime this > > was changed to a runtime detection [3] and finally enabled for the meson > > cross compile build with commit [4] (assuming toolchain support for the > > neon assembler instructions)... > > Thank you for the detailed explanation. > > I saw the commit [4] and conclude that upstream mesa3d now require neon support > when vc4 driver is enabled. > > > > > Maybe the compile error could be fixed by re-adding partly the compile time > > check for the neon support (tested): > > > > --- mesa3d-19.3.4/src/broadcom/common/v3d_cpu_tiling.h_orig 2020-02-28 14:47:44.232634657 +0100 > > +++ mesa3d-19.3.4/src/broadcom/common/v3d_cpu_tiling.h 2020-02-28 14:49:21.518425222 +0100 > > @@ -31,7 +31,7 @@ > > v3d_load_utile(void *cpu, uint32_t cpu_stride, > > void *gpu, uint32_t gpu_stride) > > { > > -#if defined(V3D_BUILD_NEON) && defined(PIPE_ARCH_ARM) > > +#if defined(V3D_BUILD_NEON) && defined(__ARM_ARCH) && __ARM_ARCH >= 7 > > if (gpu_stride == 8) { > > __asm__ volatile ( > > /* Load from the GPU in one shot, no interleave, to > > @@ -141,7 +141,7 @@ > > v3d_store_utile(void *gpu, uint32_t gpu_stride, > > void *cpu, uint32_t cpu_stride) > > { > > -#if defined(V3D_BUILD_NEON) && defined(PIPE_ARCH_ARM) > > +#if defined(V3D_BUILD_NEON) && defined(__ARM_ARCH) && __ARM_ARCH >= 7 > > if (gpu_stride == 8) { > > __asm__ volatile ( > > /* Load each 8-byte line from cpu-side source, > > > > But -mfpu=neon is still present on the command line. But without problems, as all the neon stuff in handcrafted via inline assambler ;-) > > Do you think if the neon support can be handled/forced by a new meson option? The following patch fixes the problem for the vc4 driver (but not for the v3d one which needs neon unconditionally - or fixed by the previous patch): diff --git a/meson.build b/meson.build index 7e2295b..a3134b1 100644 --- a/meson.build +++ b/meson.build @@ -1112,8 +1112,10 @@ elif host_machine.cpu_family() == 'x86_64' endif elif host_machine.cpu_family() == 'arm' if system_has_kms_drm - with_asm_arch = 'arm' - pre_args += ['-DUSE_ARM_ASM'] + if not (host_machine.cpu().contains('4') or host_machine.cpu().contains('5') or host_machine.cpu().contains('6')) + with_asm_arch = 'arm' + pre_args += ['-DUSE_ARM_ASM'] + endif endif elif host_machine.cpu_family() == 'aarch64' if system_has_kms_drm diff --git a/src/gallium/drivers/vc4/meson.build b/src/gallium/drivers/vc4/meson.build index 5ce5af5..2bb5d06 100644 --- a/src/gallium/drivers/vc4/meson.build +++ b/src/gallium/drivers/vc4/meson.build @@ -84,7 +84,7 @@ files_libvc4 = files( vc4_c_args = [] libvc4_neon = [] -if host_machine.cpu_family() == 'arm' +if host_machine.cpu_family() == 'arm' and not (host_machine.cpu().contains('4') or host_machine.cpu().contains('5') or host_machine.cpu().contains('6')) libvc4_neon = static_library( 'vc4_neon', 'vc4_tiling_lt_neon.c', An alternative to the check on ARMvX >=7 a new meson option should be possible... Regards, Peter > > Best regards, > Romain > > > Regards, > > Peter > > > > [1] https://git.buildroot.net/buildroot/commit/package/mesa3d?id=350cb0d32ece533b9723a5f3ca6fbf7e6f071c90 > > [2] https://cgit.freedesktop.org/mesa/mesa/commit/?h=17.1&id=4d30024238efa829cabc72c1601beeee18c3dbf2 > > [3] https://cgit.freedesktop.org/mesa/mesa/commit/?h=staging/19.3&id=ece06defe77a77d2db40abeddee5a2e0e45654ce > > [4] https://cgit.freedesktop.org/mesa/mesa/commit/?id=932ed9c00b99e6ec92146ec9e820f546cf3e6551 > > > >> > >> Romain > > > ^ permalink raw reply related [flat|nested] 37+ messages in thread
end of thread, other threads:[~2020-02-29 23:17 UTC | newest]
Thread overview: 37+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-08-25 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-24 Thomas Petazzoni
2014-08-25 16:16 ` [Buildroot] Analysis of build results Thomas Petazzoni
2014-08-25 16:26 ` Phil Eichinger
2014-08-25 17:47 ` Thomas Petazzoni
2014-08-25 21:07 ` Peter Korsgaard
2014-08-25 21:13 ` Jörg Krause
2014-08-26 6:17 ` Alexander Lukichev
2014-08-28 12:52 ` Ezequiel Garcia
2014-08-31 16:58 ` Frank Bergmann
2014-08-31 21:13 ` Ezequiel Garcia
-- strict thread matches above, loose matches on Subject: below --
2014-08-30 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-29 Thomas Petazzoni
2014-08-30 9:07 ` [Buildroot] Analysis of build results Thomas Petazzoni
2014-11-11 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-11-10 Thomas Petazzoni
2014-11-11 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni
2014-11-11 23:41 ` Gustavo Zacarias
2014-11-12 2:30 ` Nathaniel Roach
2014-11-12 14:09 ` Jörg Krause
2014-11-16 10:07 ` Yann E. MORIN
2014-11-22 11:10 ` Bernd Kuhls
2020-02-19 7:48 [Buildroot] [autobuild.buildroot.net] Daily results for 2020-02-18 Thomas Petazzoni
[not found] ` <20200220034343.2370e4e4@windsurf>
2020-02-20 13:36 ` [Buildroot] Analysis of build results Giulio Benetti
2020-02-21 8:23 ` Romain Naour
[not found] ` <94c8edad-773d-2b36-5daf-b6ee60dd747f@micronovasrl.com>
[not found] ` <3e7b016b-eca6-b768-3fca-8fd7e44d0299@micronovasrl.com>
[not found] ` <20200220190807.505b4fb2@windsurf>
[not found] ` <00751b5d-ca05-fe42-0e9b-6a1005a09e6d@micronovasrl.com>
[not found] ` <20200220192344.03785f04@windsurf>
[not found] ` <bcc10a0e-c54e-5b75-9b77-8922b85a925a@micronovasrl.com>
[not found] ` <fe7d07df-71a0-e317-6b91-ade479545ec4@smile.fr>
[not found] ` <28258465-4f79-3f47-189d-bb066b0aa9f7@micronovasrl.com>
2020-02-22 19:10 ` Romain Naour
2020-02-22 19:44 ` Giulio Benetti
2020-02-22 21:11 ` Fabrice Fontaine
2020-02-22 21:48 ` Giulio Benetti
2020-02-22 22:00 ` Fabrice Fontaine
2020-02-22 23:48 ` Romain Naour
2020-02-27 9:31 [Buildroot] [autobuild.buildroot.net] Daily results for 2020-02-26 Thomas Petazzoni
2020-02-27 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni
2020-02-27 23:06 ` Max Filippov
2020-02-27 23:18 ` Giulio Benetti
2020-02-28 8:03 ` Thomas Petazzoni
2020-02-28 18:06 ` Giulio Benetti
2020-02-28 6:21 ` Heiko Thiery
2020-02-28 7:56 ` Sergio Prado
2020-02-28 8:01 ` Thomas Petazzoni
2020-02-28 7:32 ` Romain Naour
2020-02-28 15:02 ` Peter Seiderer
2020-02-29 21:15 ` Romain Naour
2020-02-29 23:17 ` Peter Seiderer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox