* [Buildroot] [autobuild.buildroot.net] Build results for 2015-05-04
@ 2015-05-05 6:30 Thomas Petazzoni
2015-05-05 7:59 ` [Buildroot] Analysis of build failures Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-05 6:30 UTC (permalink / raw)
To: buildroot
Build statistics for 2015-05-04
===============================
success : 166
failures : 38
timeouts : 8
TOTAL : 212
Classification of failures by reason
====================================
python-pyqt-4.11.3 | 8
qt-4.8.6 | 3
php-5.6.8 | 2
lua-periphery-1.0.4-1 | 2
host-gdb-arc-2014.12-gdb | 2
host-gdb-7.8.2 | 2
host-mono-4.0.1 | 2
tinyxml2-2.2.0 | 2
google-breakpad-1373 | 2
guile-2.0.11 | 2
sane-backends-1.0.24 | 2
libtirpc-0.2.4 | 1
snmppp-3.3.4 | 1
openldap-2.4.40 | 1
xapp_xwud-1.0.4 | 1
xerces-3.1.2 | 1
valgrind-3.10.1 | 1
cc-tool-0.26 | 1
unknown | 1
ipmiutil-2.9.5 | 1
znc-b396cafdb249544164ed029... | 1
poppler-0.32.0 | 1
at-3.1.13 | 1
filemq-482797b8aa30fcc9ea13... | 1
neard-0.14 | 1
libcap-ng-0.7.4 | 1
xproto_presentproto-1.0 | 1
vlc-2.2.1 | 1
Detail of failures
===================
arm | at-3.1.13 | NOK | http://autobuild.buildroot.net/results/6f25e80e8aedec91323ef9b67576b550d7abee60/
arm | cc-tool-0.26 | NOK | http://autobuild.buildroot.net/results/69aff0b9d0ac8fe08e1d2f7ffb691f6a8fc8693b/
xtensa | filemq-482797b8aa30fcc9ea13... | NOK | http://autobuild.buildroot.net/results/f685d73952a2562e0f3e1c378ddd7885d6433272/
aarch64 | google-breakpad-1373 | NOK | http://autobuild.buildroot.net/results/e063085f7d34f8d7940614b26313b28f5eb2396e/
aarch64 | google-breakpad-1373 | NOK | http://autobuild.buildroot.net/results/24baf2a135a1bdb6db7bd022e3899482f7f02c10/
aarch64 | guile-2.0.11 | NOK | http://autobuild.buildroot.net/results/85bd849e17c6e5ed6b5b56a4d4ad1a73f7de99c2/
aarch64 | guile-2.0.11 | NOK | http://autobuild.buildroot.net/results/38ce95ef3bf3b8270c48ca8fe839c5313ac51621/
arm | host-gdb-7.8.2 | NOK | http://autobuild.buildroot.net/results/f8037de36e9a0d3b22bea1e52f563b8abeb50500/
xtensa | host-gdb-7.8.2 | NOK | http://autobuild.buildroot.net/results/37238ee36af62a668e132a09490a02cf774b8889/
arc | host-gdb-arc-2014.12-gdb | NOK | http://autobuild.buildroot.net/results/f23333bcff3e8d317013faca00351023bf92de88/
arc | host-gdb-arc-2014.12-gdb | NOK | http://autobuild.buildroot.net/results/58f0276eea85f35edf7a247a958b1f42340b0a66/
powerpc | host-mono-4.0.1 | NOK | http://autobuild.buildroot.net/results/7980bbd50ab63ea2bf482b8f58493ac39790a213/
arm | host-mono-4.0.1 | NOK | http://autobuild.buildroot.net/results/1eeb6b7f4c055968f1683a37cec2b2142923cd28/
x86_64 | ipmiutil-2.9.5 | NOK | http://autobuild.buildroot.net/results/cd2e617f8e2b00581ab5936029f85e62ed3259ba/
nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/c8f19279cd49d13b14ec0d9dc116f527325d9c5b/
arm | libtirpc-0.2.4 | NOK | http://autobuild.buildroot.net/results/09a7de29e21501a094f22e9afe470524f5de8c92/
mips64el | lua-periphery-1.0.4-1 | NOK | http://autobuild.buildroot.net/results/48efae954e6b030fa8743a5728fb3f30a892f142/
mips | lua-periphery-1.0.4-1 | NOK | http://autobuild.buildroot.net/results/ed2150dd5be56056de299d2011cad340dc1e3e56/
arc | neard-0.14 | NOK | http://autobuild.buildroot.net/results/0a466cde55c5e128a2e201924f80f0ec6b8b5c2a/
arm | openldap-2.4.40 | NOK | http://autobuild.buildroot.net/results/b41c043fb3b2fad1d9cea0a95b512fb4942b5b19/
bfin | php-5.6.8 | NOK | http://autobuild.buildroot.net/results/633581d8f95efd3fc92ce9875e0608fe40d054bf/
bfin | php-5.6.8 | NOK | http://autobuild.buildroot.net/results/bf12eb189ab35ce00a2212695d2dbf8b8a126529/
arm | poppler-0.32.0 | NOK | http://autobuild.buildroot.net/results/3a70305be4a78af9404b0bd027dbcdd011ca01b3/
arm | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/bd8796a3001458de5326f96a9110a95bac247225/
arm | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/156e4afe32f7928880859a69999abcc3c9b304d0/
sh4a | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/04e209c1b54ec4ccfc0da67a3f077151b65171a7/
arm | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/2dcc2b044a1235cf9df24e5d55423c5e4ca7196a/
arm | python-pyqt-4.11.3 | TIM | http://autobuild.buildroot.net/results/d2f426d839bebebef3d8a41d1d010a0c6ac285a9/
sh4 | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/de975f29185aa95826b416ee5a60d2f190a979a6/
arm | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/891dc6ad46039740867a0b436281fc489cfb2772/
powerpc | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/65fe75b6aa965641f447c41b82d8511bd6be1a86/
mips64el | qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/e0df30e8068cd784bed8e47f5cd13f1f70284027/
mips64el | qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/ccd0534d1dfcb1628f808da91850ec62091f2178/
powerpc | qt-4.8.6 | TIM | http://autobuild.buildroot.net/results/349922ebab920c82cf087080f96c12310d6e66bb/
arm | sane-backends-1.0.24 | NOK | http://autobuild.buildroot.net/results/f2a43b62aa2a720c538fc60c80c78c8ed5b04dea/
xtensa | sane-backends-1.0.24 | NOK | http://autobuild.buildroot.net/results/31115fe8d88f52d77ed0f2da769eb8896a1b34a2/
aarch64 | snmppp-3.3.4 | NOK | http://autobuild.buildroot.net/results/23d696e3ecbd192669e0de5eae6d339730c1aea2/
bfin | tinyxml2-2.2.0 | NOK | http://autobuild.buildroot.net/results/86a4da3f9f4c9025f2f2393800c797b2af050808/
bfin | tinyxml2-2.2.0 | NOK | http://autobuild.buildroot.net/results/438ef12933aaac24029e352fdadeedb76bbd1cbb/
arm | unknown | TIM | http://autobuild.buildroot.net/results/c2f41853747d32f253ba251f8919e02d47f69719/
arm | valgrind-3.10.1 | TIM | http://autobuild.buildroot.net/results/f5aa99efe31e5b417ba27a0de0408eed10926375/
arm | vlc-2.2.1 | NOK | http://autobuild.buildroot.net/results/3612b54b0bbc2a55ba6f0febb7be32595b523d96/
mips64el | xapp_xwud-1.0.4 | TIM | http://autobuild.buildroot.net/results/5c02fe80e6072ee8d1794c20a31850af71eb10eb/
mips64el | xerces-3.1.2 | TIM | http://autobuild.buildroot.net/results/9c5cc4182b561804476bdcbda5b7dbb763110aa2/
arc | xproto_presentproto-1.0 | TIM | http://autobuild.buildroot.net/results/b6abf41c886ade1e88d2cce7c0250f58a966aa7c/
arm | znc-b396cafdb249544164ed029... | TIM | http://autobuild.buildroot.net/results/990172b1d3b2e028adba947efad9544a5a705f78/
--
http://autobuild.buildroot.net
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-05 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2015-05-04 Thomas Petazzoni
@ 2015-05-05 7:59 ` Thomas Petazzoni
2015-05-05 13:44 ` Gustavo Zacarias
` (4 more replies)
0 siblings, 5 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-05 7:59 UTC (permalink / raw)
To: buildroot
Hello,
Simon, Pascal, Gustavo, Vicente, Max, Samuel, Bernd, look below, there
are some questions/tasks for you! :-)
On Tue, 5 May 2015 08:30:15 +0200 (CEST), Thomas Petazzoni wrote:
> arm | at-3.1.13 | NOK | http://autobuild.buildroot.net/results/6f25e80e8aedec91323ef9b67576b550d7abee60/
musl build problem. Yann has sent a patch to disable at on musl, but I
would actually prefer to fix at.
> arm | cc-tool-0.26 | NOK | http://autobuild.buildroot.net/results/69aff0b9d0ac8fe08e1d2f7ffb691f6a8fc8693b/
There a -L/lib64 hardcoded somewhere.
> xtensa | filemq-482797b8aa30fcc9ea13... | NOK | http://autobuild.buildroot.net/results/f685d73952a2562e0f3e1c378ddd7885d6433272/
Two issues:
* Linking C++ code with gcc
* Missing -lpthread since we're linking statically
Simon, can you have a look?
> aarch64 | google-breakpad-1373 | NOK | http://autobuild.buildroot.net/results/e063085f7d34f8d7940614b26313b28f5eb2396e/
> aarch64 | google-breakpad-1373 | NOK | http://autobuild.buildroot.net/results/24baf2a135a1bdb6db7bd022e3899482f7f02c10/
./src/client/linux/minidump_writer/linux_dumper.h:93:23: error: field 'regs' has incomplete type 'google_breakpad::user_pt_regs'
struct user_pt_regs regs;
Does google-breakpad really works on AArch64 ?
Pascal, you're the original submitter of the google breakpad support,
can you have a look ?
> aarch64 | guile-2.0.11 | NOK | http://autobuild.buildroot.net/results/85bd849e17c6e5ed6b5b56a4d4ad1a73f7de99c2/
> aarch64 | guile-2.0.11 | NOK | http://autobuild.buildroot.net/results/38ce95ef3bf3b8270c48ca8fe839c5313ac51621/
Should be fixed by http://patchwork.ozlabs.org/patch/467829/.
> arm | host-gdb-7.8.2 | NOK | http://autobuild.buildroot.net/results/f8037de36e9a0d3b22bea1e52f563b8abeb50500/
> xtensa | host-gdb-7.8.2 | NOK | http://autobuild.buildroot.net/results/37238ee36af62a668e132a09490a02cf774b8889/
> arc | host-gdb-arc-2014.12-gdb | NOK | http://autobuild.buildroot.net/results/f23333bcff3e8d317013faca00351023bf92de88/
> arc | host-gdb-arc-2014.12-gdb | NOK | http://autobuild.buildroot.net/results/58f0276eea85f35edf7a247a958b1f42340b0a66/
These should be fixed by http://patchwork.ozlabs.org/patch/460494/ or
http://patchwork.ozlabs.org/patch/449686/. Not sure which one is the
most appropriate solution.
> powerpc | host-mono-4.0.1 | NOK | http://autobuild.buildroot.net/results/7980bbd50ab63ea2bf482b8f58493ac39790a213/
> arm | host-mono-4.0.1 | NOK | http://autobuild.buildroot.net/results/1eeb6b7f4c055968f1683a37cec2b2142923cd28/
Smells like parallel installation issue, but not sure. Angelo tried to
investigate, but was not able to reach a conclusion. Anyone to look at
this?
> x86_64 | ipmiutil-2.9.5 | NOK | http://autobuild.buildroot.net/results/cd2e617f8e2b00581ab5936029f85e62ed3259ba/
md2.o: In function `md2_sum':
md2.c:(.text+0x18): undefined reference to `EVP_md2'
Gustavo, maybe? Has OpenSSL removed md2 support by default or something
like that?
> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/c8f19279cd49d13b14ec0d9dc116f527325d9c5b/
Compiler issue, let's disable libcap-ng on nios.
> arm | libtirpc-0.2.4 | NOK | http://autobuild.buildroot.net/results/09a7de29e21501a094f22e9afe470524f5de8c92/
musl build problem. Will not re-appear for now since I disabled the
musl toolchain.
> mips64el | lua-periphery-1.0.4-1 | NOK | http://autobuild.buildroot.net/results/48efae954e6b030fa8743a5728fb3f30a892f142/
> mips | lua-periphery-1.0.4-1 | NOK | http://autobuild.buildroot.net/results/ed2150dd5be56056de299d2011cad340dc1e3e56/
Directly accessing the struct termios fields is bad, because depending
on the architecture, the structure is a bit different. There are some
accessors to do this, they should be used. Vincente, can you have a
look, since you fixed a similar problem in a different package some
time ago?
> arc | neard-0.14 | NOK | http://autobuild.buildroot.net/results/0a466cde55c5e128a2e201924f80f0ec6b8b5c2a/
Should be fixed by applying http://patchwork.ozlabs.org/patch/467858/.
> arm | openldap-2.4.40 | NOK | http://autobuild.buildroot.net/results/b41c043fb3b2fad1d9cea0a95b512fb4942b5b19/
Should be fixed by applying http://patchwork.ozlabs.org/patch/467444/.
> bfin | php-5.6.8 | NOK | http://autobuild.buildroot.net/results/633581d8f95efd3fc92ce9875e0608fe40d054bf/
> bfin | php-5.6.8 | NOK | http://autobuild.buildroot.net/results/bf12eb189ab35ce00a2212695d2dbf8b8a126529/
Missing -lpthread when linking statically.
> arm | poppler-0.32.0 | NOK | http://autobuild.buildroot.net/results/3a70305be4a78af9404b0bd027dbcdd011ca01b3/
> arm | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/bd8796a3001458de5326f96a9110a95bac247225/
> arm | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/156e4afe32f7928880859a69999abcc3c9b304d0/
> sh4a | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/04e209c1b54ec4ccfc0da67a3f077151b65171a7/
> arm | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/2dcc2b044a1235cf9df24e5d55423c5e4ca7196a/
> arm | python-pyqt-4.11.3 | TIM | http://autobuild.buildroot.net/results/d2f426d839bebebef3d8a41d1d010a0c6ac285a9/
> sh4 | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/de975f29185aa95826b416ee5a60d2f190a979a6/
> arm | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/891dc6ad46039740867a0b436281fc489cfb2772/
> powerpc | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/65fe75b6aa965641f447c41b82d8511bd6be1a86/
> mips64el | qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/e0df30e8068cd784bed8e47f5cd13f1f70284027/
> mips64el | qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/ccd0534d1dfcb1628f808da91850ec62091f2178/
> powerpc | qt-4.8.6 | TIM | http://autobuild.buildroot.net/results/349922ebab920c82cf087080f96c12310d6e66bb/
All these issues are caused by
http://git.buildroot.net/buildroot/commit/?id=7619aba496208102e098e24454371b9513ec2f90.
I suggest to revert this patch.
> arm | sane-backends-1.0.24 | NOK | http://autobuild.buildroot.net/results/f2a43b62aa2a720c538fc60c80c78c8ed5b04dea/
Missing pthread, already fixed by
http://git.buildroot.net/buildroot/commit/?id=0045808c1b271eef75e08fe02b4032f3f0e3dfc7.
> xtensa | sane-backends-1.0.24 | NOK | http://autobuild.buildroot.net/results/31115fe8d88f52d77ed0f2da769eb8896a1b34a2/
kvs40xx.h:265:2: error: #error __BYTE_ORDER not defined
#error __BYTE_ORDER not defined
Max, can you have a look?
> aarch64 | snmppp-3.3.4 | NOK | http://autobuild.buildroot.net/results/23d696e3ecbd192669e0de5eae6d339730c1aea2/
Try 'libtool --help' for more information.
libtool: error: unrecognised option: '-DHAVE_CONFIG_H'
Weird.
> bfin | tinyxml2-2.2.0 | NOK | http://autobuild.buildroot.net/results/86a4da3f9f4c9025f2f2393800c797b2af050808/
> bfin | tinyxml2-2.2.0 | NOK | http://autobuild.buildroot.net/results/438ef12933aaac24029e352fdadeedb76bbd1cbb/
tinyxml is trying to build a shared library in all cases. Samuel, you
are our CMake guy, can you have a look to fix this?
> arm | unknown | TIM | http://autobuild.buildroot.net/results/c2f41853747d32f253ba251f8919e02d47f69719/
> arm | valgrind-3.10.1 | TIM | http://autobuild.buildroot.net/results/f5aa99efe31e5b417ba27a0de0408eed10926375/
Ignore.
> arm | vlc-2.2.1 | NOK | http://autobuild.buildroot.net/results/3612b54b0bbc2a55ba6f0febb7be32595b523d96/
CC libgles2_plugin_la-gl.lo
arm-none-linux-gnueabi-gcc: ERROR: unsafe header/library path used in cross-compilation: '/usr/include/directfb'
make[6]: *** [libdirectfb_plugin_la-directfb.lo] Error 1
Bernd, can you have a look?
> mips64el | xapp_xwud-1.0.4 | TIM | http://autobuild.buildroot.net/results/5c02fe80e6072ee8d1794c20a31850af71eb10eb/
> mips64el | xerces-3.1.2 | TIM | http://autobuild.buildroot.net/results/9c5cc4182b561804476bdcbda5b7dbb763110aa2/
> arc | xproto_presentproto-1.0 | TIM | http://autobuild.buildroot.net/results/b6abf41c886ade1e88d2cce7c0250f58a966aa7c/
> arm | znc-b396cafdb249544164ed029... | TIM | http://autobuild.buildroot.net/results/990172b1d3b2e028adba947efad9544a5a705f78/
Ignore, all these are timeouts.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-05 7:59 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2015-05-05 13:44 ` Gustavo Zacarias
2015-05-05 13:47 ` Thomas Petazzoni
[not found] ` <5548C487.90604@gmail.com>
` (3 subsequent siblings)
4 siblings, 1 reply; 416+ messages in thread
From: Gustavo Zacarias @ 2015-05-05 13:44 UTC (permalink / raw)
To: buildroot
On 05/05/2015 04:59 AM, Thomas Petazzoni wrote:
>> x86_64 | ipmiutil-2.9.5 | NOK | http://autobuild.buildroot.net/results/cd2e617f8e2b00581ab5936029f85e62ed3259ba/
>
> md2.o: In function `md2_sum':
> md2.c:(.text+0x18): undefined reference to `EVP_md2'
>
> Gustavo, maybe? Has OpenSSL removed md2 support by default or something
> like that?
Yes, md2 has been disabled for some time, the problem is that ipmiutil's
configure uses LIB_DIR to check for md2 availability in libcrypto.
But we can't override that otherwise libipmiutil doesn't get installed
in the correct place :-/
Quick solution is to force it off, ideally a well-done tests would be
better.
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-05 13:44 ` Gustavo Zacarias
@ 2015-05-05 13:47 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-05 13:47 UTC (permalink / raw)
To: buildroot
Gustavo,
On Tue, 05 May 2015 10:44:18 -0300, Gustavo Zacarias wrote:
> Yes, md2 has been disabled for some time, the problem is that ipmiutil's
> configure uses LIB_DIR to check for md2 availability in libcrypto.
> But we can't override that otherwise libipmiutil doesn't get installed
> in the correct place :-/
> Quick solution is to force it off, ideally a well-done tests would be
> better.
Ok, thanks. Can you send a patch to force it off?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
[not found] ` <5548C487.90604@gmail.com>
@ 2015-05-05 13:48 ` Thomas Petazzoni
2015-05-06 9:16 ` Pascal Huerst
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-05 13:48 UTC (permalink / raw)
To: buildroot
Hello,
On Tue, 05 May 2015 15:24:23 +0200, Pascal Huerst wrote:
> According to:
>
> https://breakpad.appspot.com/2824002/
>
> support has been added for release r1407. I tried to build that
> revision, but I got the same error as reported above. I'm not really
> familiar with the internals of breakpad, but I asked on the breakpad
> mailing list. Maybe someone there already knows that issue... I'll keep
> you updated.
Thanks. We'll wait a bit for them to give some feedback, and if it
doesn't come soon enough, we'll disable breakpad on aarch64 for now.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-05 7:59 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2015-05-05 13:44 ` Gustavo Zacarias
[not found] ` <5548C487.90604@gmail.com>
@ 2015-05-05 14:52 ` Max Filippov
2015-05-05 15:06 ` Thomas Petazzoni
2015-05-05 15:22 ` Peter Korsgaard
2015-05-06 7:34 ` Angelo Compagnucci
4 siblings, 1 reply; 416+ messages in thread
From: Max Filippov @ 2015-05-05 14:52 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Tue, May 5, 2015 at 10:59 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
>> xtensa | sane-backends-1.0.24 | NOK | http://autobuild.buildroot.net/results/31115fe8d88f52d77ed0f2da769eb8896a1b34a2/
>
> kvs40xx.h:265:2: error: #error __BYTE_ORDER not defined
> #error __BYTE_ORDER not defined
>
> Max, can you have a look?
Apparently sane-backends configure script cannot correctly detect target system
endianness without hints. It gets a hint in form of
ac_cv_c_bigendian=yes/no, that
is set in accordance to BR2_ENDIAN.
But for xtensa we don't have BR2_ENDIAN and endianness comes from the
configuration overlay. Do you think we need to provide BR2_ENDIAN setting
for xtensa?
--
Thanks.
-- Max
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-05 14:52 ` Max Filippov
@ 2015-05-05 15:06 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-05 15:06 UTC (permalink / raw)
To: buildroot
Dear Max Filippov,
On Tue, 5 May 2015 17:52:23 +0300, Max Filippov wrote:
> Apparently sane-backends configure script cannot correctly detect target system
> endianness without hints. It gets a hint in form of
> ac_cv_c_bigendian=yes/no, that
> is set in accordance to BR2_ENDIAN.
> But for xtensa we don't have BR2_ENDIAN and endianness comes from the
> configuration overlay. Do you think we need to provide BR2_ENDIAN setting
> for xtensa?
Yes, we should have BR2_ENDIAN defined for Xtensa. Precisely to avoid
such issues :)
Thanks for the investigation!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-05 7:59 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (2 preceding siblings ...)
2015-05-05 14:52 ` Max Filippov
@ 2015-05-05 15:22 ` Peter Korsgaard
2015-05-05 15:26 ` Thomas Petazzoni
2015-05-06 7:34 ` Angelo Compagnucci
4 siblings, 1 reply; 416+ messages in thread
From: Peter Korsgaard @ 2015-05-05 15:22 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> Hello,
> Simon, Pascal, Gustavo, Vicente, Max, Samuel, Bernd, look below, there
> are some questions/tasks for you! :-)
It would probably have been good to add them in To: then ;)
>> arm | at-3.1.13 | NOK |
>> http://autobuild.buildroot.net/results/6f25e80e8aedec91323ef9b67576b550d7abee60/
> musl build problem. Yann has sent a patch to disable at on musl, but I
> would actually prefer to fix at.
J?rg mentioned that OE has a patch:
http://patchwork.openembedded.org/patch/91893/
>> x86_64 | ipmiutil-2.9.5 | NOK |
>> http://autobuild.buildroot.net/results/cd2e617f8e2b00581ab5936029f85e62ed3259ba/
> md2.o: In function `md2_sum':
> md2.c:(.text+0x18): undefined reference to `EVP_md2'
> Gustavo, maybe? Has OpenSSL removed md2 support by default or something
> like that?
I believe it simply gets confused about something on the build host.
>> powerpc | qt-4.8.6 | TIM | http://autobuild.buildroot.net/results/349922ebab920c82cf087080f96c12310d6e66bb/
> All these issues are caused by
> http://git.buildroot.net/buildroot/commit/?id=7619aba496208102e098e24454371b9513ec2f90.
> I suggest to revert this patch.
I've reverted it now.
>> arm | vlc-2.2.1 | NOK |
>> http://autobuild.buildroot.net/results/3612b54b0bbc2a55ba6f0febb7be32595b523d96/
> CC libgles2_plugin_la-gl.lo
> arm-none-linux-gnueabi-gcc: ERROR: unsafe header/library path used in
> cross-compilation: '/usr/include/directfb'
> make[6]: *** [libdirectfb_plugin_la-directfb.lo] Error 1
> Bernd, can you have a look?
I believe it is fixed by:
http://git.buildroot.net/buildroot/commit/?id=ac95a7a27bf319a69db41
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-05 15:22 ` Peter Korsgaard
@ 2015-05-05 15:26 ` Thomas Petazzoni
2015-05-05 15:50 ` Peter Korsgaard
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-05 15:26 UTC (permalink / raw)
To: buildroot
Dear Peter Korsgaard,
On Tue, 05 May 2015 17:22:32 +0200, Peter Korsgaard wrote:
> > Hello,
> > Simon, Pascal, Gustavo, Vicente, Max, Samuel, Bernd, look below, there
> > are some questions/tasks for you! :-)
>
> It would probably have been good to add them in To: then ;)
They were in Cc, but this stupid mailing list removes people from the
Cc: list when they are subscribed. My initial e-mail headers were:
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot at uclibc.org
Cc: Simon Dawson <spdawson@gmail.com>, Pascal Huerst <pascal.huerst@gmail.com>, Gustavo Zacarias <gustavo@zacarias.com.ar>, Vicente Olivert Riera <Vincent.Riera@imgtec.com>, Max Filippov <jcmvbkbc@gmail.com>, Samuel Martin <s.martin49@gmail.com>, Bernd Kuhls <berndkuhls@hotmail.com>
If the mailing list configuration could be changed to not do this
stupid trimming of the Cc addresses, it would be great.
> >> arm | at-3.1.13 | NOK |
> >> http://autobuild.buildroot.net/results/6f25e80e8aedec91323ef9b67576b550d7abee60/
>
> > musl build problem. Yann has sent a patch to disable at on musl, but I
> > would actually prefer to fix at.
>
> J?rg mentioned that OE has a patch:
>
> http://patchwork.openembedded.org/patch/91893/
So let's use it :-)
> >> x86_64 | ipmiutil-2.9.5 | NOK |
> >> http://autobuild.buildroot.net/results/cd2e617f8e2b00581ab5936029f85e62ed3259ba/
>
> > md2.o: In function `md2_sum':
> > md2.c:(.text+0x18): undefined reference to `EVP_md2'
>
> > Gustavo, maybe? Has OpenSSL removed md2 support by default or something
> > like that?
>
> I believe it simply gets confused about something on the build host.
Yes, Gustavo has already submitted a patch.
> >> powerpc | qt-4.8.6 | TIM | http://autobuild.buildroot.net/results/349922ebab920c82cf087080f96c12310d6e66bb/
>
> > All these issues are caused by
> > http://git.buildroot.net/buildroot/commit/?id=7619aba496208102e098e24454371b9513ec2f90.
> > I suggest to revert this patch.
>
> I've reverted it now.
Great. We'll see which Qt related failures remain after that.
> >> arm | vlc-2.2.1 | NOK |
> >> http://autobuild.buildroot.net/results/3612b54b0bbc2a55ba6f0febb7be32595b523d96/
>
> > CC libgles2_plugin_la-gl.lo
> > arm-none-linux-gnueabi-gcc: ERROR: unsafe header/library path used in
> > cross-compilation: '/usr/include/directfb'
> > make[6]: *** [libdirectfb_plugin_la-directfb.lo] Error 1
>
> > Bernd, can you have a look?
>
> I believe it is fixed by:
>
> http://git.buildroot.net/buildroot/commit/?id=ac95a7a27bf319a69db41
Excellent, thanks.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-05 15:26 ` Thomas Petazzoni
@ 2015-05-05 15:50 ` Peter Korsgaard
2015-05-05 15:54 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Peter Korsgaard @ 2015-05-05 15:50 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> Dear Peter Korsgaard,
> On Tue, 05 May 2015 17:22:32 +0200, Peter Korsgaard wrote:
>> > Hello,
>> > Simon, Pascal, Gustavo, Vicente, Max, Samuel, Bernd, look below, there
>> > are some questions/tasks for you! :-)
>>
>> It would probably have been good to add them in To: then ;)
> They were in Cc, but this stupid mailing list removes people from the
> Cc: list when they are subscribed. My initial e-mail headers were:
Ahh, ok.
> From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> To: buildroot at uclibc.org
> Cc: Simon Dawson <spdawson@gmail.com>, Pascal Huerst
> <pascal.huerst@gmail.com>, Gustavo Zacarias <gustavo@zacarias.com.ar>,
> Vicente Olivert Riera <Vincent.Riera@imgtec.com>, Max Filippov
> <jcmvbkbc@gmail.com>, Samuel Martin <s.martin49@gmail.com>, Bernd
> Kuhls <berndkuhls@hotmail.com>
> If the mailing list configuration could be changed to not do this
> stupid trimming of the Cc addresses, it would be great.
I had a look around, and according to this, it is because these users
have the nodupes option enabled:
https://bugs.launchpad.net/mailman/+bug/1216960
As described below, I have changed the default for new subscribers to
NOT enable this option, but I don't know how to do it in any bulk way
for the current subscribers (and if people want that):
https://www.ietf.org/mail-archive/web/ietf/current/msg37128.html
>> >> arm | at-3.1.13 | NOK |
>> >> http://autobuild.buildroot.net/results/6f25e80e8aedec91323ef9b67576b550d7abee60/
>>
>> > musl build problem. Yann has sent a patch to disable at on musl, but I
>> > would actually prefer to fix at.
>>
>> J?rg mentioned that OE has a patch:
>>
>> http://patchwork.openembedded.org/patch/91893/
> So let's use it :-)
Yeah, will you send a patch? ;)
>> > Gustavo, maybe? Has OpenSSL removed md2 support by default or something
>> > like that?
>>
>> I believe it simply gets confused about something on the build host.
> Yes, Gustavo has already submitted a patch.
Yes, applied already.
--
Venlig hilsen,
Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-05 15:50 ` Peter Korsgaard
@ 2015-05-05 15:54 ` Thomas Petazzoni
2015-05-05 18:46 ` Peter Korsgaard
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-05 15:54 UTC (permalink / raw)
To: buildroot
Peter,
On Tue, 05 May 2015 17:50:06 +0200, Peter Korsgaard wrote:
> > From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > To: buildroot at uclibc.org
> > Cc: Simon Dawson <spdawson@gmail.com>, Pascal Huerst
> > <pascal.huerst@gmail.com>, Gustavo Zacarias <gustavo@zacarias.com.ar>,
> > Vicente Olivert Riera <Vincent.Riera@imgtec.com>, Max Filippov
> > <jcmvbkbc@gmail.com>, Samuel Martin <s.martin49@gmail.com>, Bernd
> > Kuhls <berndkuhls@hotmail.com>
>
> > If the mailing list configuration could be changed to not do this
> > stupid trimming of the Cc addresses, it would be great.
>
> I had a look around, and according to this, it is because these users
> have the nodupes option enabled:
>
> https://bugs.launchpad.net/mailman/+bug/1216960
>
> As described below, I have changed the default for new subscribers to
> NOT enable this option, but I don't know how to do it in any bulk way
> for the current subscribers (and if people want that):
>
> https://www.ietf.org/mail-archive/web/ietf/current/msg37128.html
I suppose it cannot be changed from the Mailman admin interface?
> >> J?rg mentioned that OE has a patch:
> >>
> >> http://patchwork.openembedded.org/patch/91893/
>
> > So let's use it :-)
>
> Yeah, will you send a patch? ;)
If nobody beats me at it, I'll try.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-05 15:54 ` Thomas Petazzoni
@ 2015-05-05 18:46 ` Peter Korsgaard
0 siblings, 0 replies; 416+ messages in thread
From: Peter Korsgaard @ 2015-05-05 18:46 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> As described below, I have changed the default for new subscribers to
>> NOT enable this option, but I don't know how to do it in any bulk way
>> for the current subscribers (and if people want that):
>>
>> https://www.ietf.org/mail-archive/web/ietf/current/msg37128.html
> I suppose it cannot be changed from the Mailman admin interface?
It can be done by clicking seperately for each subscriber, but I'm not
going to do that ~1300 times, and somebody might not like to get
doubles.
--
Venlig hilsen,
Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-05 7:59 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (3 preceding siblings ...)
2015-05-05 15:22 ` Peter Korsgaard
@ 2015-05-06 7:34 ` Angelo Compagnucci
2015-05-06 7:44 ` Thomas Petazzoni
4 siblings, 1 reply; 416+ messages in thread
From: Angelo Compagnucci @ 2015-05-06 7:34 UTC (permalink / raw)
To: buildroot
Dear Thomas Petazzoni,
>> powerpc | host-mono-4.0.1 | NOK | http://autobuild.buildroot.net/results/7980bbd50ab63ea2bf482b8f58493ac39790a213/
>> arm | host-mono-4.0.1 | NOK | http://autobuild.buildroot.net/results/1eeb6b7f4c055968f1683a37cec2b2142923cd28/
>
> Smells like parallel installation issue, but not sure. Angelo tried to
> investigate, but was not able to reach a conclusion. Anyone to look at
> this?
Stating at today (2015-05-06) report, the error is gone. Honestly I
think there is something in autobuild that makes parallel installation
screws, cause I repeated at least a dozen of tests with different
configurations and I'm using it in a side project (several more
compilations) and never encountered this bug on my quad core machine.
Sincerely, Angelo
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-06 7:34 ` Angelo Compagnucci
@ 2015-05-06 7:44 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-06 7:44 UTC (permalink / raw)
To: buildroot
Dear Angelo Compagnucci,
On Wed, 6 May 2015 09:34:32 +0200, Angelo Compagnucci wrote:
> Stating at today (2015-05-06) report, the error is gone. Honestly I
> think there is something in autobuild that makes parallel installation
> screws, cause I repeated at least a dozen of tests with different
> configurations and I'm using it in a side project (several more
> compilations) and never encountered this bug on my quad core machine.
No it isn't gone: it occurred again two times during this night,
http://autobuild.buildroot.org/?reason=host-mono-4.0.1.
(The 2015-05-06 autobuild e-mail reports failures that took place
between 2015-05-05 00:00 and 2015-05-06 00:00, European time).
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-05 13:48 ` Thomas Petazzoni
@ 2015-05-06 9:16 ` Pascal Huerst
0 siblings, 0 replies; 416+ messages in thread
From: Pascal Huerst @ 2015-05-06 9:16 UTC (permalink / raw)
To: buildroot
Hey Thomas,
On 05.05.2015 15:48, Thomas Petazzoni wrote:
> Hello,
>
> On Tue, 05 May 2015 15:24:23 +0200, Pascal Huerst wrote:
>
>> According to:
>>
>> https://breakpad.appspot.com/2824002/
>>
>> support has been added for release r1407. I tried to build that
>> revision, but I got the same error as reported above. I'm not really
>> familiar with the internals of breakpad, but I asked on the breakpad
>> mailing list. Maybe someone there already knows that issue... I'll keep
>> you updated.
>
> Thanks. We'll wait a bit for them to give some feedback, and if it
> doesn't come soon enough, we'll disable breakpad on aarch64 for now.
Looks like there is a patch in pipeline, but not applied, yet. I would
suggest to disable breakpad for AArch64 for now and re-enable it on a
next version bump.
pending patch:
https://breakpad.appspot.com/10734002/
and Mike's reply:
https://groups.google.com/forum/#!topic/google-breakpad-discuss/PpWkw79SVIs
regards
Pascal
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-02-12 11:54 ` Martin Bark
@ 2016-02-15 13:15 ` Martin Bark
0 siblings, 0 replies; 416+ messages in thread
From: Martin Bark @ 2016-02-15 13:15 UTC (permalink / raw)
To: buildroot
Thomas,
On 12 February 2016 at 11:54, Martin Bark <martin@barkynet.com> wrote:
> Thomas,
>
> On 12 February 2016 at 09:45, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Hello,
>>
>> Rodrigo, Martin, Romain, Vicente, J?rg, Bernd, Gustavo, please see
>> below. Others, please see below as well :-)
>>
>> On Fri, 12 Feb 2016 08:30:18 +0100 (CET), Thomas Petazzoni wrote:
>>
>>> mipsel | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/2b7c82ef6c43c33ffaecb0b148c4404576c37d1d/
>>> powerpc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/19aefa63291de818b99fb0b084d083f60549aa55/
>>> powerpc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/020dc8c77e44c9620bd3fd007c738c88b0d654c2/
>>> i686 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/e2a4a00d2a590a39a00106c1519dd6c81e0cf236/
>>> sh4 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/b50009a1d7ba67894b42dd407042db406d4b0517/
>>> powerpc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/0011b24cddc1af971dc1ee158430293dadba4cb6/
>>> arm | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/827e571070bd340e23ee3971c0e6ddad80db20fb/
>>
>> There are all caused by the fenv problem I believe. Would apply
>> http://patchwork.ozlabs.org/patch/579807/ to fix this. I'm not super
>> happy with the solution, but the Boost build system is complicated, and
>> it's hard to find the proper solution. The issue was reported upstream,
>> so hopefully it should be fixed at some point in the future.
>>
>> So maybe we should just go ahead, and merge this patch, at least so
>> that we can see which other build failures are hidden behind all those
>> failures.
>>
>>> x86_64 | chocolate-doom-2.2.1 | NOK | http://autobuild.buildroot.net/results/0ba92b05c03f1f67009aae456b5136f43f9052d4/
>>
>> Static linking problem. Rodrigo, you added this package, can you have a
>> look ?
>>
>>> x86_64 | connman-1.31 | NOK | http://autobuild.buildroot.net/results/7efaee147d85c211f733cd65bd9c99088be5662b/
>>> x86_64 | connman-1.31 | NOK | http://autobuild.buildroot.net/results/c5b3ff9da989d5110402caaeab7dda89e1cb1f52/
>>
>> Musl build issue:
>>
>> redefinition of 'struct ethhdr'
>>
>> Probably some things to be taken from
>> http://git.alpinelinux.org/cgit/aports/plain/testing/connman/musl-fixes.patch,
>> and submit upstream. Anyone ?
>>
>>> x86_64 | ffmpeg-2.8.6 | NOK | http://autobuild.buildroot.net/results/c53f7768be220fcd0f574ac16a7b4b0e26e7b0a9/
>>
>> LD ffplay_g
>> /usr/lib/libglib-2.0.so.0: undefined reference to
>> `clock_gettime at GLIBC_2.17' collect2: error: ld returned 1 exit status
>>
>> Looks like it links with host libraries: not good.
>>
>> Bernd, could you have a look ?
>>
>>> microblazeel | fio-fio-2.6 | NOK | http://autobuild.buildroot.net/results/44dd45e0f693ea84fc072ab28f038bf04a9226ec/
>>
>> oslib/libmtd.h:288:8: error: unknown type name 'uint8_t'
>>
>> Anyone ?
>>
>>> powerpc | fio-fio-2.6 | NOK | http://autobuild.buildroot.net/results/dc75b1f5ca4db5fb4658f19fde56b18cb7170fe9/
>>
>> Same.
>>
>>> sh4 | gst-ffmpeg-0.10.13 | NOK | http://autobuild.buildroot.net/results/598bc7f81fe89188308226f453339d53bf7ed262/
>>
>> internal compiler error: in elimination_costs_in_insn, at reload1.c:3638
>>
>> Seems to be https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65151. So we
>> need to 1/ check if the problem has been fixed in gcc 5.x, and 2/ add
>> the necessary exclusions.
>>
>>> arc | host-efl-1.15.3 | NOK | http://autobuild.buildroot.net/results/7dcaeb8fbb5739c36aa0615e3d8a13e9c32993b0/
>>
>> I guess would be fixed by http://patchwork.ozlabs.org/patch/572201/.
>>
>>> microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/d63e346ba4d00a68602b1bcec0acb09e266a53c9/
>>
>> The infamous documentation problem, would be fixed by
>> http://patchwork.ozlabs.org/patch/576556/.
>>
>>> arm | host-nodejs-5.5.0 | NOK | http://autobuild.buildroot.net/results/9406af4b20a0b7450169f7bd63e6a2ebb85c81af/
>>
>> TypeError: object of type 'filter' has no len()
>>
>> Martin, can you have a look ?
>>
>>> arm | iputils-c8ff6feaf0442f8efd9... | NOK | http://autobuild.buildroot.net/results/08f7386f75c881bc582b338824f8ccd509b2921e/
>>> powerpc | iputils-c8ff6feaf0442f8efd9... | NOK | http://autobuild.buildroot.net/results/5aeef61fbd399dd78dc72b9e7cce978e6f1f58b4/
>>
>> undefined reference to `__finite'
>>
>> Missing -lm ?
>
> Yes I'm happy to have a look into this. I'm able to reproduce the
> error so it should not be too hard to fix.
>
> Thanks
>
> Martin
I have submitted a patch to fix the iputils build error. See
http://patchwork.ozlabs.org/patch/582930/
Thanks
Martin
>
>>
>>> sparc64 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/0e7ff249524dab1ca434295263e9768253c1cf49/
>>> mips64el | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/b1234d705b4d98951c4b500c28758ccab3f86e18/
>>> powerpc | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/5550868f70f37942429fcc318d7b19cfe561bdf3/
>>> powerpc | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/f9b7ea22fc41f6f4c2d4f41659236e2ba7ed73cd/
>>> nios2 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/4997da79f0b40215e7401f29aeab34d78b4903e9/
>>> mips64el | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/29c448af79d3711fafde551ab838bf75fadfb666/
>>> x86_64 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/9d2ee117f9537550f53d0ef18006e4890950928c/
>>> mips64el | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/e5a0ee705b706eabbb934ae65c2c7ce76a88dd90/
>>> powerpc | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/97f581feac60cc0cfe9c69d994cbd24491d8e5d9/
>>> x86_64 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/b440a18905f5c676c986d9a9f4ea54dfac749898/
>>> microblazeel | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/0fb4030cd5b8c1a05e70175ec5cfe4434ce89e1a/
>>> x86_64 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/9479cf09232d844c2c42a1a3642c270ddc164dd3/
>>> arm | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/b9aa4cf1f000421d052f9f9547cc43275c08ef59/
>>> arm | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/57e4386e43d8bd65a571e20ebc8f69c8a424f38c/
>>> aarch64 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/a50c44861cbe72fb285f07be4303c60f4f17dd98/
>>> mips64el | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/e1c641b18d82cd3900e47d245fb1b3bcfbe5a968/
>>> arm | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/d04cc8e09c8b9fcb705f340ef6defd28f8b38168/
>>> arm | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/23e42afc2e33649486d0052a9525ad3b2bd4bf4f/
>>> arm | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/9f7524f4a4883c6135e829635b587fa2c3dbd68d/
>>> aarch64 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/0edd44eb4bea6640699a13af11ba98eac1bd6884/
>>> x86_64 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/8408c6ede9aba029a1aecd7bfd617e6e058c75e3/
>>> arm | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/f6baa37428aef3a410854c0138e71a3ae085910f/
>>
>> These should all be fixed by now, thanks to
>> https://git.busybox.net/buildroot/commit/?id=9f81bad770304871177c16147fc150a1998ee4cc.
>>
>>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/00a5ef3a4e10700c79b83bc1ab026808ce930030/
>>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/c98add9541defd5f12415b69521a1b32ddfa270d/
>>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/527d982ab6616eb7bef9419a9e793f7a46c32830/
>>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/d4e18789c1da2d8518db873d7833af186daf9859/
>>
>> Romain, didn't we say we should add some exclusion for this issue ? If
>> so, can you submit a patch ?
>>
>>> sparc | libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/2d8379580c37b8835dcb4dc32ca0df3aa6283e0f/
>>
>> /tmp/ccgqVshp.s: Assembler messages:
>> /tmp/ccgqVshp.s:87: Error: Architecture mismatch on "membar".
>> /tmp/ccgqVshp.s:87: (Requires v9|v9a|v9b; requested architecture is v8.)
>>
>> I guess http://patchwork.ozlabs.org/patch/569818/ would fix it. Not
>> sure if the patch is the most correct solution, though (I haven't
>> investigated at all).
>>
>>> mipsel | libpam-tacplus-1.3.9 | NOK | http://autobuild.buildroot.net/results/89f9ef5a3ed9743269f82eab11323840b409ce70/
>>
>> /home/test/autobuild/instance-2/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp_nonshared
>> /home/test/autobuild/instance-2/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp
>>
>> Vicente, what is the status of this issue ?
>>
>>> bfin | libraw-0.17.1 | NOK | http://autobuild.buildroot.net/results/56fa1435cf5dc68f95bbba29dd557c4975f73818/
>>> bfin | libraw-0.17.1 | NOK | http://autobuild.buildroot.net/results/f7ddd14023ea54127cd8dd44b76171a2247d8f97/
>>> bfin | libraw-0.17.1 | NOK | http://autobuild.buildroot.net/results/143c4c2a1d8527c97362ce11507e8b5a79dd0d6b/
>>
>> Would be fixed by http://patchwork.ozlabs.org/patch/582121/.
>>
>>> bfin | libraw1394-2.1.1 | NOK | http://autobuild.buildroot.net/results/198149e80be3e62eaf9f4731442031a1aa93409c/
>>> bfin | libraw1394-2.1.1 | NOK | http://autobuild.buildroot.net/results/774204390942faa43296c5abf193bcbf1260687c/
>>> bfin | libraw1394-2.1.1 | NOK | http://autobuild.buildroot.net/results/d4e50cb00ec66498a2989ed406eaa2165ef5684f/
>>> bfin | libraw1394-2.1.1 | NOK | http://autobuild.buildroot.net/results/2444ba3224fb08ab5677cecdf6a9eb31b9435459/
>>
>> Would be fixed by http://patchwork.ozlabs.org/patch/582122/.
>>
>>> powerpc | libupnpp-0.13.1 | NOK | http://autobuild.buildroot.net/results/653421502099e4a9220bdb5ed13d92e78c3cf674/
>>
>> checking for curl_easy_init in -lcurl... no
>> configure: error: libcurl not found
>>
>> Static linking problem. J?rg, can you have a look ?
>>
>>> arm | lvm2-2.02.138 | NOK | http://autobuild.buildroot.net/results/c16fb939a9f1b7d786cf2f7d7f6ffad9ac6cd841/
>>
>> commands/toolcontext.c: In function 'create_toolcontext':
>> commands/toolcontext.c:1796:10: error: assignment of read-only variable 'stdin'
>> stdin = new_stream;
>>
>> Would be fixed by http://patchwork.ozlabs.org/patch/573519/, though it
>> would be good to get the patch merged upstream to get some proper
>> review of it.
>>
>> Bernd ?
>>
>>> sparc | mesa3d-11.1.1 | NOK | http://autobuild.buildroot.net/results/d8925a4968306d67749c9fe165230cdad066d988/
>>
>> Use of atomic operations. Waldemar ?
>>
>>> arm | minidlna-1.1.5 | NOK | http://autobuild.buildroot.net/results/8ebea55163a36735a3d987a787efd7eeb42d1e66/
>>
>> /home/peko/autobuild/instance-2/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libwavpack.a(libwavpack_la-pack_utils.o): In function `free_metadata':
>> pack_utils.c:(.text+0x9a8): multiple definition of `free_metadata'
>> metadata.o:metadata.c:(.text+0x474): first defined here
>> collect2: error: ld returned 1 exit status
>>
>> Consequence of static linking.
>>
>> Anyone to have a look ?
>>
>>> aarch64 | mplayer-1.2 | NOK | http://autobuild.buildroot.net/results/48f96ef26f895639f3376e94eccdea9765710877/
>>> aarch64 | mplayer-1.2 | NOK | http://autobuild.buildroot.net/results/97c435c39345b22e1e7e2feb7d5badba9b74791b/
>>> aarch64 | mplayer-1.2 | NOK | http://autobuild.buildroot.net/results/009287d4dd1511ab2127328815fed0365549a5ed/
>>
>> Still the same problem building mplayer on AArch64. I will send a patch
>> to disable it.
>>
>>> powerpc | nfs-utils-1.3.3 | NOK | http://autobuild.buildroot.net/results/7a102b5f3f9794be8c02db6f9bfbccec4f4acd8a/
>>
>> Would be fixed by http://patchwork.ozlabs.org/patch/577178/.
>>
>>> powerpc | numactl-2.0.11 | NOK | http://autobuild.buildroot.net/results/ef89fb8982438842a45794462b37f10ed121f33a/
>>> x86_64 | numactl-2.0.11 | NOK | http://autobuild.buildroot.net/results/077c6b213738e6914b1836bacc1e6bb8613bea50/
>>> powerpc | numactl-2.0.11 | NOK | http://autobuild.buildroot.net/results/ac611dc851e7a5638f0c8fc0a9b246c3c79cd7d7/
>>> mipsel | numactl-2.0.11 | NOK | http://autobuild.buildroot.net/results/48a94050e26ad829277c46300b90439502e8a3e6/
>>> powerpc | numactl-2.0.11 | NOK | http://autobuild.buildroot.net/results/2b62e30bcb36c3877686b1471642273e21756c91/
>>
>> This seems to be a regression following the merge of patch
>> https://git.busybox.net/buildroot/commit/?id=21ed7a92fe5a771911ef06f97522e504d0eebbc2
>> from Bernd.
>>
>> Bernd, can you have a look ?
>>
>>> powerpc | pax-utils-1.1.4 | NOK | http://autobuild.buildroot.net/results/ba9d058da46fcb569120a6dc826e2c51dc676569/
>>
>> security.c: In function 'security_init':
>> security.c:245:8: error: 'PR_SET_NO_NEW_PRIVS' undeclared (first use in this function)
>> security.c:245:8: note: each undeclared identifier is reported only once for each function it appears in
>>
>> Probably we need some more recent kernel headers.
>>
>>> mips64el | psmisc-22.21 | NOK | http://autobuild.buildroot.net/results/410327935adcc1cded02243c051f8e92c56237af/
>>> mips64el | psmisc-22.21 | NOK | http://autobuild.buildroot.net/results/b98e244b8ae1b06047fcb05b7d34ce483c736ecc/
>>
>> /home/buildroot/autobuild/run/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp_nonshared
>> /home/buildroot/autobuild/run/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp
>>
>> Vicente ?
>>
>>> mipsel | pulseaudio-8.0 | NOK | http://autobuild.buildroot.net/results/d2b953bb074e7f0e0de86c11771624b399d43859/
>>> powerpc | pulseaudio-8.0 | NOK | http://autobuild.buildroot.net/results/46d702f32b23b50c12237e04e50b2d304d944f40/
>>> mipsel | pulseaudio-8.0 | NOK | http://autobuild.buildroot.net/results/8c022016235bef7850fc933c7f1f5ab5ac7cf0fb/
>>> sparc64 | pulseaudio-8.0 | NOK | http://autobuild.buildroot.net/results/474e237f6ec11cec590f32aa55372917abcbf396/
>>> sparc64 | pulseaudio-8.0 | NOK | http://autobuild.buildroot.net/results/ac5395c8b2c1d634c341b0c7d7913c9528f6117f/
>>> mips | pulseaudio-8.0 | NOK | http://autobuild.buildroot.net/results/f2fdc25c6d3c85a24c7a13b8448a7463b4049a48/
>>> x86_64 | pulseaudio-8.0 | NOK | http://autobuild.buildroot.net/results/5a82b31f6065a0aad123d78d0b6b0f8025ba360b/
>>
>> These seem to be regressions following the merge of https://git.busybox.net/buildroot/commit/package/pulseaudio?id=1cffb454320aeba80a56985ecfc44c3c1d293802 from Bernd.
>>
>> Bernd, can you have a look ?
>>
>>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/ee562524c5b12191e584ceae89006c5a5103e700/
>>
>> Romain, is the patch for this pending somewhere ?
>>
>>> i686 | samba4-4.3.4 | NOK | http://autobuild.buildroot.net/results/2cdfedf5407bbb6f5c383aba930ee79794d45df6/
>>> sh4a | samba4-4.3.4 | NOK | http://autobuild.buildroot.net/results/16a9f69f0cef6e02c7249be6cae61dd36a9ef6df/
>>> x86_64 | samba4-4.3.4 | NOK | http://autobuild.buildroot.net/results/a5b837d6d02ec96ac53c5b1c531a0c8e7eafeb9a/
>>
>> default/lib/crypto/hmacmd5_1.o: In function `hmac_md5_init_rfc2104':
>> hmacmd5.c:(.text+0x2e): undefined reference to `MD5Init'
>> hmacmd5.c:(.text+0x3e): undefined reference to `MD5Update'
>> hmacmd5.c:(.text+0x4b): undefined reference to `MD5Final'
>> hmacmd5.c:(.text+0xab): undefined reference to `MD5Init'
>> hmacmd5.c:(.text+0xbb): undefined reference to `MD5Update'
>>
>> Gustavo, can you have a look ?
>>
>>> mips64el | sox-14.4.2 | NOK | http://autobuild.buildroot.net/results/0273acd342bf1cf470c0b944c10ca23acf0e1a39/
>>
>> Vicente:
>>
>> /home/buildroot/build/instance-1/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp_nonshared
>> /home/buildroot/build/instance-1/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp
>>
>> Maybe those Codescape toolchains are not ready, and we should change
>> the autobuilder configurations to not use them?
>>
>>> arm | sqlite-3100200 | NOK | http://autobuild.buildroot.net/results/a25932ef64c6a0fb64bb7d053aac18527ce1ccf5/
>>> arm | sqlite-3100200 | NOK | http://autobuild.buildroot.net/results/c9a8589782b387e99f4c840eb722bcced86cf74d/
>>
>> sqlite3.o: file not recognized: File truncated
>> collect2: error: ld returned 1 exit status
>>
>> Parallel build problem ? Gustavo ?
>>
>>> mips64el | strongswan-5.3.5 | NOK | http://autobuild.buildroot.net/results/3153eed33aaed1e4605a927ca8f78de56d3697a1/
>>
>> utils/utils.c: In function 'closefrom':
>> utils/utils.c:173:25: error: '__NR_getdents64' undeclared (first use in this function)
>> while ((len = syscall(__NR_getdents64, dir_fd, buffer,
>>
>> Vicente ?
>>
>>> aarch64 | tor-0.2.7.6 | NOK | http://autobuild.buildroot.net/results/fff98784c3f8c67d6db54e10459d287bc3a490e2/
>>> aarch64 | tor-0.2.7.6 | NOK | http://autobuild.buildroot.net/results/fc51b05556433368bc242b50b0b68c97eadfd2c6/
>>
>> crypto_format.c:(.text+0x1c): relocation truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against symbol `smartlist_new' defined in .text
>>
>> Seems like a toolchain problem :/
>>
>>> arm | trinity-v1.6 | NOK | http://autobuild.buildroot.net/results/2a91b8d585c34ee97d97fe9618cf82242ae5f3d0/
>>
>> error: redefinition of 'struct in6_pktinfo'
>>
>> Musl related issue.
>>
>>> i686 | trinity-v1.6 | NOK | http://autobuild.buildroot.net/results/b5a199d24c625e083f8238a500de113c888021a3/
>>
>> But maybe not, because this is the same issue, but on glibc.
>>
>>> mips | valgrind-3.11.0 | NOK | http://autobuild.buildroot.net/results/1929133f50400e148044f9a1d4984aee10b80468/
>>
>> Vicente, this one is for you :-)
>>
>> If there is no support yet for mips32r2, then can you submit a patch
>> that disables the build of valgrind on this architecture variant ?
>>
>> Thanks!
>>
>> Thomas
>> --
>> Thomas Petazzoni, CTO, Free Electrons
>> Embedded Linux, Kernel and Android engineering
>> http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
[not found] <mailman.19.1455278403.3863.buildroot@busybox.net>
@ 2016-02-13 1:04 ` Ricardo Martincoski
0 siblings, 0 replies; 416+ messages in thread
From: Ricardo Martincoski @ 2016-02-13 1:04 UTC (permalink / raw)
To: buildroot
Hi Thomas, all,
On Fri, 12 Feb 2016 10:45:41 +0100, Thomas Petazzoni wrote:
>> microblazeel | fio-fio-2.6 | NOK | http://autobuild.buildroot.net/results/44dd45e0f693ea84fc072ab28f038bf04a9226ec/
>
> oslib/libmtd.h:288:8: error: unknown type name 'uint8_t'
>
> Anyone ?
>
>> powerpc | fio-fio-2.6 | NOK | http://autobuild.buildroot.net/results/dc75b1f5ca4db5fb4658f19fde56b18cb7170fe9/
>
> Same.
There is a patch upstream for this.
http://git.kernel.dk/?p=fio.git;a=patch;h=d7bb6180f831091c468e5aa749b142efd5eddda4
http://patchwork.ozlabs.org/patch/582346/
*Really sorry* the spam sending the patch.
Regards,
Ricardo
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-02-12 20:35 ` Thomas Petazzoni
@ 2016-02-12 20:52 ` Romain Naour
0 siblings, 0 replies; 416+ messages in thread
From: Romain Naour @ 2016-02-12 20:52 UTC (permalink / raw)
To: buildroot
Hi Thomas, All,
Le 12/02/2016 21:35, Thomas Petazzoni a ?crit :
> Romain,
>
> On Fri, 12 Feb 2016 20:26:41 +0100, Romain Naour wrote:
>
>>>> arc | host-efl-1.15.3 | NOK | http://autobuild.buildroot.net/results/7dcaeb8fbb5739c36aa0615e3d8a13e9c32993b0/
>>>
>>> I guess would be fixed by http://patchwork.ozlabs.org/patch/572201/.
>>
>> I reopened a bug about this issue the upstream fix is not enough. See
>> https://phab.enlightenment.org/T2718
>
> I don't see this bug as being reopened. Am I missing something ?
Wrong link sorry.
>
>> So, for the moment we can build efl 1.15 only with Lua 5.1 (Lua 5.1 was the
>> default version used at the time I tested the efl bump series).
>
> Right, so http://patchwork.ozlabs.org/patch/572201/ would fix the
> problem for now, correct ?
>
> BTW, your patch references https://phab.enlightenment.org/T2728, but
> this URL cannot be accessed without creating an account on this
> Phabricator instance, which is somewhat annoying.
Yes this one, I just changed the visibility. can you retry now ?
>
>> I have a local branch that bump the efl to the latest version (1.17.0) and the
>> support for lua-old doesn't build with (5.1, 5.2 and 5.3) due to this issue.
>
> Due to which issue ?
The issue I reported while I reopened T2728.
host-efl-1.16.1/src/lib/evas/.libs/libevas.so: undefined reference to `luaL_openlib'
collect2: error: ld returned 1 exit status
>
>> The problem for 2016.02 is it's too late to enable lua-jit support in efl. So
>> people using efl with 2016.02 will have to switch to lua-jit when efl will be
>> updated to a newer version :-/
>>
>> Do you want me to send a small series (3 patches) adding lua-jit support for
>> 2016.02 ?
>
> No, it's too late for such a change. I prefer a minimal solution, so if
> forcing the use of Lua 5.1 fixes the problem for now (as your patch
> http://patchwork.ozlabs.org/patch/572201/) suggests, I'd prefer this
> option.
Ok, so you can apply this patch.
>
>>>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/00a5ef3a4e10700c79b83bc1ab026808ce930030/
>>>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/c98add9541defd5f12415b69521a1b32ddfa270d/
>>>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/527d982ab6616eb7bef9419a9e793f7a46c32830/
>>>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/d4e18789c1da2d8518db873d7833af186daf9859/
>>>
>>> Romain, didn't we say we should add some exclusion for this issue ? If
>>> so, can you submit a patch ?
>>
>> Technically, it's a toolchain issue with gcc 4.9. So if we rebuild a new nios2
>> toolchain with gcc 5.3 this error is gone. Otherwise we can add an autobuilder
>> exception for br-nios2-full-2015.11-rc1-71-g90d1299.tar.bz2.
>>
>> Even we can remove BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_NIOSII since the new
>> codesourcery toolchain use gcc 5.2.
>
> For the time being, can we simply do:
>
> - depends on !BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_NIOSII # triggers compiler bug
> + depends on BR2_TOOLCHAIN_GCC_AT_LEAST_5 || !BR2_nios2
>
> Or simply as you suggest, we add an exclusion in the autobuilders.
> Probably the easiest. Can you send a patch doing this ?
Yes, I prefer to add an exclusion in the autobuilders. I'll send a patch.
Also, I need to check if each 'depends on
!BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_NIOSII' are still valid for the new CS
nios2 toolchain.
>
>>>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/ee562524c5b12191e584ceae89006c5a5103e700/
>>>
>>> Romain, is the patch for this pending somewhere ?
>>
>> We need to rebuild a nios2 toolchain with the upstream patch applied [1] and
>> disable for BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_NIOSII:
>>
>> [1]
>> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=83da6e748c8f105f07e17f53aa6b99ed7867ff5f
>>
>> Otherwise we can apply this one: http://patchwork.ozlabs.org/patch/561414/
>
> We need to do three things here I believe:
>
> 1/ Add a BR2_TOOLCHAIN_BINUTILS_HAS_BUG_xyz option, which the CodeSourcery
> option would select and Qt GUI would depends
> on !BR2_TOOLCHAIN_BINUTILS_HAS_BUG_xyz
>
> 2/ Add the patch to the binutils package.
I tested the patch with binutils 2.26 [1], I'm testing it with 2.25.1.
[1] http://patchwork.ozlabs.org/patch/580038/
>
> 3/ Add an exclusion to the autobuilder script, until the toolchains
> are rebuilt with the upstream patch.
>
> Do you think you can work on this ?
I'm on it.
Best regards,
Romain
>
> Thanks!
>
> Thomas
>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-02-12 19:26 ` Romain Naour
@ 2016-02-12 20:35 ` Thomas Petazzoni
2016-02-12 20:52 ` Romain Naour
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2016-02-12 20:35 UTC (permalink / raw)
To: buildroot
Romain,
On Fri, 12 Feb 2016 20:26:41 +0100, Romain Naour wrote:
> >> arc | host-efl-1.15.3 | NOK | http://autobuild.buildroot.net/results/7dcaeb8fbb5739c36aa0615e3d8a13e9c32993b0/
> >
> > I guess would be fixed by http://patchwork.ozlabs.org/patch/572201/.
>
> I reopened a bug about this issue the upstream fix is not enough. See
> https://phab.enlightenment.org/T2718
I don't see this bug as being reopened. Am I missing something ?
> So, for the moment we can build efl 1.15 only with Lua 5.1 (Lua 5.1 was the
> default version used at the time I tested the efl bump series).
Right, so http://patchwork.ozlabs.org/patch/572201/ would fix the
problem for now, correct ?
BTW, your patch references https://phab.enlightenment.org/T2728, but
this URL cannot be accessed without creating an account on this
Phabricator instance, which is somewhat annoying.
> I have a local branch that bump the efl to the latest version (1.17.0) and the
> support for lua-old doesn't build with (5.1, 5.2 and 5.3) due to this issue.
Due to which issue ?
> The problem for 2016.02 is it's too late to enable lua-jit support in efl. So
> people using efl with 2016.02 will have to switch to lua-jit when efl will be
> updated to a newer version :-/
>
> Do you want me to send a small series (3 patches) adding lua-jit support for
> 2016.02 ?
No, it's too late for such a change. I prefer a minimal solution, so if
forcing the use of Lua 5.1 fixes the problem for now (as your patch
http://patchwork.ozlabs.org/patch/572201/) suggests, I'd prefer this
option.
> >> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/00a5ef3a4e10700c79b83bc1ab026808ce930030/
> >> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/c98add9541defd5f12415b69521a1b32ddfa270d/
> >> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/527d982ab6616eb7bef9419a9e793f7a46c32830/
> >> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/d4e18789c1da2d8518db873d7833af186daf9859/
> >
> > Romain, didn't we say we should add some exclusion for this issue ? If
> > so, can you submit a patch ?
>
> Technically, it's a toolchain issue with gcc 4.9. So if we rebuild a new nios2
> toolchain with gcc 5.3 this error is gone. Otherwise we can add an autobuilder
> exception for br-nios2-full-2015.11-rc1-71-g90d1299.tar.bz2.
>
> Even we can remove BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_NIOSII since the new
> codesourcery toolchain use gcc 5.2.
For the time being, can we simply do:
- depends on !BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_NIOSII # triggers compiler bug
+ depends on BR2_TOOLCHAIN_GCC_AT_LEAST_5 || !BR2_nios2
Or simply as you suggest, we add an exclusion in the autobuilders.
Probably the easiest. Can you send a patch doing this ?
> >> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/ee562524c5b12191e584ceae89006c5a5103e700/
> >
> > Romain, is the patch for this pending somewhere ?
>
> We need to rebuild a nios2 toolchain with the upstream patch applied [1] and
> disable for BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_NIOSII:
>
> [1]
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=83da6e748c8f105f07e17f53aa6b99ed7867ff5f
>
> Otherwise we can apply this one: http://patchwork.ozlabs.org/patch/561414/
We need to do three things here I believe:
1/ Add a BR2_TOOLCHAIN_BINUTILS_HAS_BUG_xyz option, which the CodeSourcery
option would select and Qt GUI would depends
on !BR2_TOOLCHAIN_BINUTILS_HAS_BUG_xyz
2/ Add the patch to the binutils package.
3/ Add an exclusion to the autobuilder script, until the toolchains
are rebuilt with the upstream patch.
Do you think you can work on this ?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-02-12 9:45 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (2 preceding siblings ...)
2016-02-12 18:29 ` Bernd Kuhls
@ 2016-02-12 19:26 ` Romain Naour
2016-02-12 20:35 ` Thomas Petazzoni
3 siblings, 1 reply; 416+ messages in thread
From: Romain Naour @ 2016-02-12 19:26 UTC (permalink / raw)
To: buildroot
Hi Thomas, All,
Le 12/02/2016 10:45, Thomas Petazzoni a ?crit :
> Hello,
>
> Rodrigo, Martin, Romain, Vicente, J?rg, Bernd, Gustavo, please see
> below. Others, please see below as well :-)
>
> On Fri, 12 Feb 2016 08:30:18 +0100 (CET), Thomas Petazzoni wrote:
>
>> arc | host-efl-1.15.3 | NOK | http://autobuild.buildroot.net/results/7dcaeb8fbb5739c36aa0615e3d8a13e9c32993b0/
>
> I guess would be fixed by http://patchwork.ozlabs.org/patch/572201/.
I reopened a bug about this issue the upstream fix is not enough. See
https://phab.enlightenment.org/T2718
So, for the moment we can build efl 1.15 only with Lua 5.1 (Lua 5.1 was the
default version used at the time I tested the efl bump series).
I have a local branch that bump the efl to the latest version (1.17.0) and the
support for lua-old doesn't build with (5.1, 5.2 and 5.3) due to this issue. The
only solution is to add lua-jit support which build and work correctly (tested
with Qemu).
The problem for 2016.02 is it's too late to enable lua-jit support in efl. So
people using efl with 2016.02 will have to switch to lua-jit when efl will be
updated to a newer version :-/
Do you want me to send a small series (3 patches) adding lua-jit support for
2016.02 ?
>
>> microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/d63e346ba4d00a68602b1bcec0acb09e266a53c9/
>
> The infamous documentation problem, would be fixed by
> http://patchwork.ozlabs.org/patch/576556/.
Or this one http://patchwork.ozlabs.org/patch/572150/ even if I don't like to
use sed all over the gdb tree :-/
>
>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/00a5ef3a4e10700c79b83bc1ab026808ce930030/
>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/c98add9541defd5f12415b69521a1b32ddfa270d/
>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/527d982ab6616eb7bef9419a9e793f7a46c32830/
>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/d4e18789c1da2d8518db873d7833af186daf9859/
>
> Romain, didn't we say we should add some exclusion for this issue ? If
> so, can you submit a patch ?
Technically, it's a toolchain issue with gcc 4.9. So if we rebuild a new nios2
toolchain with gcc 5.3 this error is gone. Otherwise we can add an autobuilder
exception for br-nios2-full-2015.11-rc1-71-g90d1299.tar.bz2.
Even we can remove BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_NIOSII since the new
codesourcery toolchain use gcc 5.2.
>
>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/ee562524c5b12191e584ceae89006c5a5103e700/
>
> Romain, is the patch for this pending somewhere ?
We need to rebuild a nios2 toolchain with the upstream patch applied [1] and
disable for BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_NIOSII:
[1]
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=83da6e748c8f105f07e17f53aa6b99ed7867ff5f
Otherwise we can apply this one: http://patchwork.ozlabs.org/patch/561414/
Best regards,
Romain
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-02-12 9:45 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2016-02-12 11:54 ` Martin Bark
2016-02-12 18:01 ` Bernd Kuhls
@ 2016-02-12 18:29 ` Bernd Kuhls
2016-02-12 19:26 ` Romain Naour
3 siblings, 0 replies; 416+ messages in thread
From: Bernd Kuhls @ 2016-02-12 18:29 UTC (permalink / raw)
To: buildroot
Am Fri, 12 Feb 2016 10:45:41 +0100 schrieb Thomas Petazzoni:
>> powerpc | numactl-2.0.11 | NOK |
>> http://autobuild.buildroot.net/
results/2b62e30bcb36c3877686b1471642273e21756c91/
>
> This seems to be a regression following the merge of patch
> https://git.busybox.net/buildroot/commit/?
id=21ed7a92fe5a771911ef06f97522e504d0eebbc2
> from Bernd.
>
> Bernd, can you have a look ?
Hi Thomas,
should be fixed by: http://patchwork.ozlabs.org/patch/582268/
Regards, Bernd
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-02-12 9:45 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2016-02-12 11:54 ` Martin Bark
@ 2016-02-12 18:01 ` Bernd Kuhls
2016-02-12 18:29 ` Bernd Kuhls
2016-02-12 19:26 ` Romain Naour
3 siblings, 0 replies; 416+ messages in thread
From: Bernd Kuhls @ 2016-02-12 18:01 UTC (permalink / raw)
To: buildroot
Am Fri, 12 Feb 2016 10:45:41 +0100 schrieb Thomas Petazzoni:
>> x86_64 | ffmpeg-2.8.6 | NOK |
>> http://autobuild.buildroot.net/results/
c53f7768be220fcd0f574ac16a7b4b0e26e7b0a9/
>
> LD ffplay_g /usr/lib/libglib-2.0.so.0: undefined reference to
> `clock_gettime at GLIBC_2.17' collect2: error: ld returned 1 exit status
>
> Looks like it links with host libraries: not good.
>
> Bernd, could you have a look ?
Hi Thomas,
weird, on my machine I can not reproduce the bug.
Regards, Bernd
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-02-12 9:45 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2016-02-12 11:54 ` Martin Bark
2016-02-15 13:15 ` Martin Bark
2016-02-12 18:01 ` Bernd Kuhls
` (2 subsequent siblings)
3 siblings, 1 reply; 416+ messages in thread
From: Martin Bark @ 2016-02-12 11:54 UTC (permalink / raw)
To: buildroot
Thomas,
On 12 February 2016 at 09:45, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> Rodrigo, Martin, Romain, Vicente, J?rg, Bernd, Gustavo, please see
> below. Others, please see below as well :-)
>
> On Fri, 12 Feb 2016 08:30:18 +0100 (CET), Thomas Petazzoni wrote:
>
>> mipsel | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/2b7c82ef6c43c33ffaecb0b148c4404576c37d1d/
>> powerpc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/19aefa63291de818b99fb0b084d083f60549aa55/
>> powerpc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/020dc8c77e44c9620bd3fd007c738c88b0d654c2/
>> i686 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/e2a4a00d2a590a39a00106c1519dd6c81e0cf236/
>> sh4 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/b50009a1d7ba67894b42dd407042db406d4b0517/
>> powerpc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/0011b24cddc1af971dc1ee158430293dadba4cb6/
>> arm | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/827e571070bd340e23ee3971c0e6ddad80db20fb/
>
> There are all caused by the fenv problem I believe. Would apply
> http://patchwork.ozlabs.org/patch/579807/ to fix this. I'm not super
> happy with the solution, but the Boost build system is complicated, and
> it's hard to find the proper solution. The issue was reported upstream,
> so hopefully it should be fixed at some point in the future.
>
> So maybe we should just go ahead, and merge this patch, at least so
> that we can see which other build failures are hidden behind all those
> failures.
>
>> x86_64 | chocolate-doom-2.2.1 | NOK | http://autobuild.buildroot.net/results/0ba92b05c03f1f67009aae456b5136f43f9052d4/
>
> Static linking problem. Rodrigo, you added this package, can you have a
> look ?
>
>> x86_64 | connman-1.31 | NOK | http://autobuild.buildroot.net/results/7efaee147d85c211f733cd65bd9c99088be5662b/
>> x86_64 | connman-1.31 | NOK | http://autobuild.buildroot.net/results/c5b3ff9da989d5110402caaeab7dda89e1cb1f52/
>
> Musl build issue:
>
> redefinition of 'struct ethhdr'
>
> Probably some things to be taken from
> http://git.alpinelinux.org/cgit/aports/plain/testing/connman/musl-fixes.patch,
> and submit upstream. Anyone ?
>
>> x86_64 | ffmpeg-2.8.6 | NOK | http://autobuild.buildroot.net/results/c53f7768be220fcd0f574ac16a7b4b0e26e7b0a9/
>
> LD ffplay_g
> /usr/lib/libglib-2.0.so.0: undefined reference to
> `clock_gettime at GLIBC_2.17' collect2: error: ld returned 1 exit status
>
> Looks like it links with host libraries: not good.
>
> Bernd, could you have a look ?
>
>> microblazeel | fio-fio-2.6 | NOK | http://autobuild.buildroot.net/results/44dd45e0f693ea84fc072ab28f038bf04a9226ec/
>
> oslib/libmtd.h:288:8: error: unknown type name 'uint8_t'
>
> Anyone ?
>
>> powerpc | fio-fio-2.6 | NOK | http://autobuild.buildroot.net/results/dc75b1f5ca4db5fb4658f19fde56b18cb7170fe9/
>
> Same.
>
>> sh4 | gst-ffmpeg-0.10.13 | NOK | http://autobuild.buildroot.net/results/598bc7f81fe89188308226f453339d53bf7ed262/
>
> internal compiler error: in elimination_costs_in_insn, at reload1.c:3638
>
> Seems to be https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65151. So we
> need to 1/ check if the problem has been fixed in gcc 5.x, and 2/ add
> the necessary exclusions.
>
>> arc | host-efl-1.15.3 | NOK | http://autobuild.buildroot.net/results/7dcaeb8fbb5739c36aa0615e3d8a13e9c32993b0/
>
> I guess would be fixed by http://patchwork.ozlabs.org/patch/572201/.
>
>> microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/d63e346ba4d00a68602b1bcec0acb09e266a53c9/
>
> The infamous documentation problem, would be fixed by
> http://patchwork.ozlabs.org/patch/576556/.
>
>> arm | host-nodejs-5.5.0 | NOK | http://autobuild.buildroot.net/results/9406af4b20a0b7450169f7bd63e6a2ebb85c81af/
>
> TypeError: object of type 'filter' has no len()
>
> Martin, can you have a look ?
>
>> arm | iputils-c8ff6feaf0442f8efd9... | NOK | http://autobuild.buildroot.net/results/08f7386f75c881bc582b338824f8ccd509b2921e/
>> powerpc | iputils-c8ff6feaf0442f8efd9... | NOK | http://autobuild.buildroot.net/results/5aeef61fbd399dd78dc72b9e7cce978e6f1f58b4/
>
> undefined reference to `__finite'
>
> Missing -lm ?
Yes I'm happy to have a look into this. I'm able to reproduce the
error so it should not be too hard to fix.
Thanks
Martin
>
>> sparc64 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/0e7ff249524dab1ca434295263e9768253c1cf49/
>> mips64el | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/b1234d705b4d98951c4b500c28758ccab3f86e18/
>> powerpc | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/5550868f70f37942429fcc318d7b19cfe561bdf3/
>> powerpc | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/f9b7ea22fc41f6f4c2d4f41659236e2ba7ed73cd/
>> nios2 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/4997da79f0b40215e7401f29aeab34d78b4903e9/
>> mips64el | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/29c448af79d3711fafde551ab838bf75fadfb666/
>> x86_64 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/9d2ee117f9537550f53d0ef18006e4890950928c/
>> mips64el | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/e5a0ee705b706eabbb934ae65c2c7ce76a88dd90/
>> powerpc | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/97f581feac60cc0cfe9c69d994cbd24491d8e5d9/
>> x86_64 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/b440a18905f5c676c986d9a9f4ea54dfac749898/
>> microblazeel | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/0fb4030cd5b8c1a05e70175ec5cfe4434ce89e1a/
>> x86_64 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/9479cf09232d844c2c42a1a3642c270ddc164dd3/
>> arm | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/b9aa4cf1f000421d052f9f9547cc43275c08ef59/
>> arm | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/57e4386e43d8bd65a571e20ebc8f69c8a424f38c/
>> aarch64 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/a50c44861cbe72fb285f07be4303c60f4f17dd98/
>> mips64el | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/e1c641b18d82cd3900e47d245fb1b3bcfbe5a968/
>> arm | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/d04cc8e09c8b9fcb705f340ef6defd28f8b38168/
>> arm | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/23e42afc2e33649486d0052a9525ad3b2bd4bf4f/
>> arm | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/9f7524f4a4883c6135e829635b587fa2c3dbd68d/
>> aarch64 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/0edd44eb4bea6640699a13af11ba98eac1bd6884/
>> x86_64 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/8408c6ede9aba029a1aecd7bfd617e6e058c75e3/
>> arm | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/f6baa37428aef3a410854c0138e71a3ae085910f/
>
> These should all be fixed by now, thanks to
> https://git.busybox.net/buildroot/commit/?id=9f81bad770304871177c16147fc150a1998ee4cc.
>
>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/00a5ef3a4e10700c79b83bc1ab026808ce930030/
>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/c98add9541defd5f12415b69521a1b32ddfa270d/
>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/527d982ab6616eb7bef9419a9e793f7a46c32830/
>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/d4e18789c1da2d8518db873d7833af186daf9859/
>
> Romain, didn't we say we should add some exclusion for this issue ? If
> so, can you submit a patch ?
>
>> sparc | libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/2d8379580c37b8835dcb4dc32ca0df3aa6283e0f/
>
> /tmp/ccgqVshp.s: Assembler messages:
> /tmp/ccgqVshp.s:87: Error: Architecture mismatch on "membar".
> /tmp/ccgqVshp.s:87: (Requires v9|v9a|v9b; requested architecture is v8.)
>
> I guess http://patchwork.ozlabs.org/patch/569818/ would fix it. Not
> sure if the patch is the most correct solution, though (I haven't
> investigated at all).
>
>> mipsel | libpam-tacplus-1.3.9 | NOK | http://autobuild.buildroot.net/results/89f9ef5a3ed9743269f82eab11323840b409ce70/
>
> /home/test/autobuild/instance-2/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp_nonshared
> /home/test/autobuild/instance-2/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp
>
> Vicente, what is the status of this issue ?
>
>> bfin | libraw-0.17.1 | NOK | http://autobuild.buildroot.net/results/56fa1435cf5dc68f95bbba29dd557c4975f73818/
>> bfin | libraw-0.17.1 | NOK | http://autobuild.buildroot.net/results/f7ddd14023ea54127cd8dd44b76171a2247d8f97/
>> bfin | libraw-0.17.1 | NOK | http://autobuild.buildroot.net/results/143c4c2a1d8527c97362ce11507e8b5a79dd0d6b/
>
> Would be fixed by http://patchwork.ozlabs.org/patch/582121/.
>
>> bfin | libraw1394-2.1.1 | NOK | http://autobuild.buildroot.net/results/198149e80be3e62eaf9f4731442031a1aa93409c/
>> bfin | libraw1394-2.1.1 | NOK | http://autobuild.buildroot.net/results/774204390942faa43296c5abf193bcbf1260687c/
>> bfin | libraw1394-2.1.1 | NOK | http://autobuild.buildroot.net/results/d4e50cb00ec66498a2989ed406eaa2165ef5684f/
>> bfin | libraw1394-2.1.1 | NOK | http://autobuild.buildroot.net/results/2444ba3224fb08ab5677cecdf6a9eb31b9435459/
>
> Would be fixed by http://patchwork.ozlabs.org/patch/582122/.
>
>> powerpc | libupnpp-0.13.1 | NOK | http://autobuild.buildroot.net/results/653421502099e4a9220bdb5ed13d92e78c3cf674/
>
> checking for curl_easy_init in -lcurl... no
> configure: error: libcurl not found
>
> Static linking problem. J?rg, can you have a look ?
>
>> arm | lvm2-2.02.138 | NOK | http://autobuild.buildroot.net/results/c16fb939a9f1b7d786cf2f7d7f6ffad9ac6cd841/
>
> commands/toolcontext.c: In function 'create_toolcontext':
> commands/toolcontext.c:1796:10: error: assignment of read-only variable 'stdin'
> stdin = new_stream;
>
> Would be fixed by http://patchwork.ozlabs.org/patch/573519/, though it
> would be good to get the patch merged upstream to get some proper
> review of it.
>
> Bernd ?
>
>> sparc | mesa3d-11.1.1 | NOK | http://autobuild.buildroot.net/results/d8925a4968306d67749c9fe165230cdad066d988/
>
> Use of atomic operations. Waldemar ?
>
>> arm | minidlna-1.1.5 | NOK | http://autobuild.buildroot.net/results/8ebea55163a36735a3d987a787efd7eeb42d1e66/
>
> /home/peko/autobuild/instance-2/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libwavpack.a(libwavpack_la-pack_utils.o): In function `free_metadata':
> pack_utils.c:(.text+0x9a8): multiple definition of `free_metadata'
> metadata.o:metadata.c:(.text+0x474): first defined here
> collect2: error: ld returned 1 exit status
>
> Consequence of static linking.
>
> Anyone to have a look ?
>
>> aarch64 | mplayer-1.2 | NOK | http://autobuild.buildroot.net/results/48f96ef26f895639f3376e94eccdea9765710877/
>> aarch64 | mplayer-1.2 | NOK | http://autobuild.buildroot.net/results/97c435c39345b22e1e7e2feb7d5badba9b74791b/
>> aarch64 | mplayer-1.2 | NOK | http://autobuild.buildroot.net/results/009287d4dd1511ab2127328815fed0365549a5ed/
>
> Still the same problem building mplayer on AArch64. I will send a patch
> to disable it.
>
>> powerpc | nfs-utils-1.3.3 | NOK | http://autobuild.buildroot.net/results/7a102b5f3f9794be8c02db6f9bfbccec4f4acd8a/
>
> Would be fixed by http://patchwork.ozlabs.org/patch/577178/.
>
>> powerpc | numactl-2.0.11 | NOK | http://autobuild.buildroot.net/results/ef89fb8982438842a45794462b37f10ed121f33a/
>> x86_64 | numactl-2.0.11 | NOK | http://autobuild.buildroot.net/results/077c6b213738e6914b1836bacc1e6bb8613bea50/
>> powerpc | numactl-2.0.11 | NOK | http://autobuild.buildroot.net/results/ac611dc851e7a5638f0c8fc0a9b246c3c79cd7d7/
>> mipsel | numactl-2.0.11 | NOK | http://autobuild.buildroot.net/results/48a94050e26ad829277c46300b90439502e8a3e6/
>> powerpc | numactl-2.0.11 | NOK | http://autobuild.buildroot.net/results/2b62e30bcb36c3877686b1471642273e21756c91/
>
> This seems to be a regression following the merge of patch
> https://git.busybox.net/buildroot/commit/?id=21ed7a92fe5a771911ef06f97522e504d0eebbc2
> from Bernd.
>
> Bernd, can you have a look ?
>
>> powerpc | pax-utils-1.1.4 | NOK | http://autobuild.buildroot.net/results/ba9d058da46fcb569120a6dc826e2c51dc676569/
>
> security.c: In function 'security_init':
> security.c:245:8: error: 'PR_SET_NO_NEW_PRIVS' undeclared (first use in this function)
> security.c:245:8: note: each undeclared identifier is reported only once for each function it appears in
>
> Probably we need some more recent kernel headers.
>
>> mips64el | psmisc-22.21 | NOK | http://autobuild.buildroot.net/results/410327935adcc1cded02243c051f8e92c56237af/
>> mips64el | psmisc-22.21 | NOK | http://autobuild.buildroot.net/results/b98e244b8ae1b06047fcb05b7d34ce483c736ecc/
>
> /home/buildroot/autobuild/run/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp_nonshared
> /home/buildroot/autobuild/run/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp
>
> Vicente ?
>
>> mipsel | pulseaudio-8.0 | NOK | http://autobuild.buildroot.net/results/d2b953bb074e7f0e0de86c11771624b399d43859/
>> powerpc | pulseaudio-8.0 | NOK | http://autobuild.buildroot.net/results/46d702f32b23b50c12237e04e50b2d304d944f40/
>> mipsel | pulseaudio-8.0 | NOK | http://autobuild.buildroot.net/results/8c022016235bef7850fc933c7f1f5ab5ac7cf0fb/
>> sparc64 | pulseaudio-8.0 | NOK | http://autobuild.buildroot.net/results/474e237f6ec11cec590f32aa55372917abcbf396/
>> sparc64 | pulseaudio-8.0 | NOK | http://autobuild.buildroot.net/results/ac5395c8b2c1d634c341b0c7d7913c9528f6117f/
>> mips | pulseaudio-8.0 | NOK | http://autobuild.buildroot.net/results/f2fdc25c6d3c85a24c7a13b8448a7463b4049a48/
>> x86_64 | pulseaudio-8.0 | NOK | http://autobuild.buildroot.net/results/5a82b31f6065a0aad123d78d0b6b0f8025ba360b/
>
> These seem to be regressions following the merge of https://git.busybox.net/buildroot/commit/package/pulseaudio?id=1cffb454320aeba80a56985ecfc44c3c1d293802 from Bernd.
>
> Bernd, can you have a look ?
>
>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/ee562524c5b12191e584ceae89006c5a5103e700/
>
> Romain, is the patch for this pending somewhere ?
>
>> i686 | samba4-4.3.4 | NOK | http://autobuild.buildroot.net/results/2cdfedf5407bbb6f5c383aba930ee79794d45df6/
>> sh4a | samba4-4.3.4 | NOK | http://autobuild.buildroot.net/results/16a9f69f0cef6e02c7249be6cae61dd36a9ef6df/
>> x86_64 | samba4-4.3.4 | NOK | http://autobuild.buildroot.net/results/a5b837d6d02ec96ac53c5b1c531a0c8e7eafeb9a/
>
> default/lib/crypto/hmacmd5_1.o: In function `hmac_md5_init_rfc2104':
> hmacmd5.c:(.text+0x2e): undefined reference to `MD5Init'
> hmacmd5.c:(.text+0x3e): undefined reference to `MD5Update'
> hmacmd5.c:(.text+0x4b): undefined reference to `MD5Final'
> hmacmd5.c:(.text+0xab): undefined reference to `MD5Init'
> hmacmd5.c:(.text+0xbb): undefined reference to `MD5Update'
>
> Gustavo, can you have a look ?
>
>> mips64el | sox-14.4.2 | NOK | http://autobuild.buildroot.net/results/0273acd342bf1cf470c0b944c10ca23acf0e1a39/
>
> Vicente:
>
> /home/buildroot/build/instance-1/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp_nonshared
> /home/buildroot/build/instance-1/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp
>
> Maybe those Codescape toolchains are not ready, and we should change
> the autobuilder configurations to not use them?
>
>> arm | sqlite-3100200 | NOK | http://autobuild.buildroot.net/results/a25932ef64c6a0fb64bb7d053aac18527ce1ccf5/
>> arm | sqlite-3100200 | NOK | http://autobuild.buildroot.net/results/c9a8589782b387e99f4c840eb722bcced86cf74d/
>
> sqlite3.o: file not recognized: File truncated
> collect2: error: ld returned 1 exit status
>
> Parallel build problem ? Gustavo ?
>
>> mips64el | strongswan-5.3.5 | NOK | http://autobuild.buildroot.net/results/3153eed33aaed1e4605a927ca8f78de56d3697a1/
>
> utils/utils.c: In function 'closefrom':
> utils/utils.c:173:25: error: '__NR_getdents64' undeclared (first use in this function)
> while ((len = syscall(__NR_getdents64, dir_fd, buffer,
>
> Vicente ?
>
>> aarch64 | tor-0.2.7.6 | NOK | http://autobuild.buildroot.net/results/fff98784c3f8c67d6db54e10459d287bc3a490e2/
>> aarch64 | tor-0.2.7.6 | NOK | http://autobuild.buildroot.net/results/fc51b05556433368bc242b50b0b68c97eadfd2c6/
>
> crypto_format.c:(.text+0x1c): relocation truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against symbol `smartlist_new' defined in .text
>
> Seems like a toolchain problem :/
>
>> arm | trinity-v1.6 | NOK | http://autobuild.buildroot.net/results/2a91b8d585c34ee97d97fe9618cf82242ae5f3d0/
>
> error: redefinition of 'struct in6_pktinfo'
>
> Musl related issue.
>
>> i686 | trinity-v1.6 | NOK | http://autobuild.buildroot.net/results/b5a199d24c625e083f8238a500de113c888021a3/
>
> But maybe not, because this is the same issue, but on glibc.
>
>> mips | valgrind-3.11.0 | NOK | http://autobuild.buildroot.net/results/1929133f50400e148044f9a1d4984aee10b80468/
>
> Vicente, this one is for you :-)
>
> If there is no support yet for mips32r2, then can you submit a patch
> that disables the build of valgrind on this architecture variant ?
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-02-12 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2016-02-11 Thomas Petazzoni
@ 2016-02-12 9:45 ` Thomas Petazzoni
2016-02-12 11:54 ` Martin Bark
` (3 more replies)
0 siblings, 4 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2016-02-12 9:45 UTC (permalink / raw)
To: buildroot
Hello,
Rodrigo, Martin, Romain, Vicente, J?rg, Bernd, Gustavo, please see
below. Others, please see below as well :-)
On Fri, 12 Feb 2016 08:30:18 +0100 (CET), Thomas Petazzoni wrote:
> mipsel | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/2b7c82ef6c43c33ffaecb0b148c4404576c37d1d/
> powerpc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/19aefa63291de818b99fb0b084d083f60549aa55/
> powerpc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/020dc8c77e44c9620bd3fd007c738c88b0d654c2/
> i686 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/e2a4a00d2a590a39a00106c1519dd6c81e0cf236/
> sh4 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/b50009a1d7ba67894b42dd407042db406d4b0517/
> powerpc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/0011b24cddc1af971dc1ee158430293dadba4cb6/
> arm | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/827e571070bd340e23ee3971c0e6ddad80db20fb/
There are all caused by the fenv problem I believe. Would apply
http://patchwork.ozlabs.org/patch/579807/ to fix this. I'm not super
happy with the solution, but the Boost build system is complicated, and
it's hard to find the proper solution. The issue was reported upstream,
so hopefully it should be fixed at some point in the future.
So maybe we should just go ahead, and merge this patch, at least so
that we can see which other build failures are hidden behind all those
failures.
> x86_64 | chocolate-doom-2.2.1 | NOK | http://autobuild.buildroot.net/results/0ba92b05c03f1f67009aae456b5136f43f9052d4/
Static linking problem. Rodrigo, you added this package, can you have a
look ?
> x86_64 | connman-1.31 | NOK | http://autobuild.buildroot.net/results/7efaee147d85c211f733cd65bd9c99088be5662b/
> x86_64 | connman-1.31 | NOK | http://autobuild.buildroot.net/results/c5b3ff9da989d5110402caaeab7dda89e1cb1f52/
Musl build issue:
redefinition of 'struct ethhdr'
Probably some things to be taken from
http://git.alpinelinux.org/cgit/aports/plain/testing/connman/musl-fixes.patch,
and submit upstream. Anyone ?
> x86_64 | ffmpeg-2.8.6 | NOK | http://autobuild.buildroot.net/results/c53f7768be220fcd0f574ac16a7b4b0e26e7b0a9/
LD ffplay_g
/usr/lib/libglib-2.0.so.0: undefined reference to
`clock_gettime at GLIBC_2.17' collect2: error: ld returned 1 exit status
Looks like it links with host libraries: not good.
Bernd, could you have a look ?
> microblazeel | fio-fio-2.6 | NOK | http://autobuild.buildroot.net/results/44dd45e0f693ea84fc072ab28f038bf04a9226ec/
oslib/libmtd.h:288:8: error: unknown type name 'uint8_t'
Anyone ?
> powerpc | fio-fio-2.6 | NOK | http://autobuild.buildroot.net/results/dc75b1f5ca4db5fb4658f19fde56b18cb7170fe9/
Same.
> sh4 | gst-ffmpeg-0.10.13 | NOK | http://autobuild.buildroot.net/results/598bc7f81fe89188308226f453339d53bf7ed262/
internal compiler error: in elimination_costs_in_insn, at reload1.c:3638
Seems to be https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65151. So we
need to 1/ check if the problem has been fixed in gcc 5.x, and 2/ add
the necessary exclusions.
> arc | host-efl-1.15.3 | NOK | http://autobuild.buildroot.net/results/7dcaeb8fbb5739c36aa0615e3d8a13e9c32993b0/
I guess would be fixed by http://patchwork.ozlabs.org/patch/572201/.
> microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/d63e346ba4d00a68602b1bcec0acb09e266a53c9/
The infamous documentation problem, would be fixed by
http://patchwork.ozlabs.org/patch/576556/.
> arm | host-nodejs-5.5.0 | NOK | http://autobuild.buildroot.net/results/9406af4b20a0b7450169f7bd63e6a2ebb85c81af/
TypeError: object of type 'filter' has no len()
Martin, can you have a look ?
> arm | iputils-c8ff6feaf0442f8efd9... | NOK | http://autobuild.buildroot.net/results/08f7386f75c881bc582b338824f8ccd509b2921e/
> powerpc | iputils-c8ff6feaf0442f8efd9... | NOK | http://autobuild.buildroot.net/results/5aeef61fbd399dd78dc72b9e7cce978e6f1f58b4/
undefined reference to `__finite'
Missing -lm ?
> sparc64 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/0e7ff249524dab1ca434295263e9768253c1cf49/
> mips64el | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/b1234d705b4d98951c4b500c28758ccab3f86e18/
> powerpc | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/5550868f70f37942429fcc318d7b19cfe561bdf3/
> powerpc | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/f9b7ea22fc41f6f4c2d4f41659236e2ba7ed73cd/
> nios2 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/4997da79f0b40215e7401f29aeab34d78b4903e9/
> mips64el | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/29c448af79d3711fafde551ab838bf75fadfb666/
> x86_64 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/9d2ee117f9537550f53d0ef18006e4890950928c/
> mips64el | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/e5a0ee705b706eabbb934ae65c2c7ce76a88dd90/
> powerpc | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/97f581feac60cc0cfe9c69d994cbd24491d8e5d9/
> x86_64 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/b440a18905f5c676c986d9a9f4ea54dfac749898/
> microblazeel | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/0fb4030cd5b8c1a05e70175ec5cfe4434ce89e1a/
> x86_64 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/9479cf09232d844c2c42a1a3642c270ddc164dd3/
> arm | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/b9aa4cf1f000421d052f9f9547cc43275c08ef59/
> arm | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/57e4386e43d8bd65a571e20ebc8f69c8a424f38c/
> aarch64 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/a50c44861cbe72fb285f07be4303c60f4f17dd98/
> mips64el | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/e1c641b18d82cd3900e47d245fb1b3bcfbe5a968/
> arm | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/d04cc8e09c8b9fcb705f340ef6defd28f8b38168/
> arm | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/23e42afc2e33649486d0052a9525ad3b2bd4bf4f/
> arm | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/9f7524f4a4883c6135e829635b587fa2c3dbd68d/
> aarch64 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/0edd44eb4bea6640699a13af11ba98eac1bd6884/
> x86_64 | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/8408c6ede9aba029a1aecd7bfd617e6e058c75e3/
> arm | kbd-2.0.3 | NOK | http://autobuild.buildroot.net/results/f6baa37428aef3a410854c0138e71a3ae085910f/
These should all be fixed by now, thanks to
https://git.busybox.net/buildroot/commit/?id=9f81bad770304871177c16147fc150a1998ee4cc.
> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/00a5ef3a4e10700c79b83bc1ab026808ce930030/
> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/c98add9541defd5f12415b69521a1b32ddfa270d/
> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/527d982ab6616eb7bef9419a9e793f7a46c32830/
> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/d4e18789c1da2d8518db873d7833af186daf9859/
Romain, didn't we say we should add some exclusion for this issue ? If
so, can you submit a patch ?
> sparc | libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/2d8379580c37b8835dcb4dc32ca0df3aa6283e0f/
/tmp/ccgqVshp.s: Assembler messages:
/tmp/ccgqVshp.s:87: Error: Architecture mismatch on "membar".
/tmp/ccgqVshp.s:87: (Requires v9|v9a|v9b; requested architecture is v8.)
I guess http://patchwork.ozlabs.org/patch/569818/ would fix it. Not
sure if the patch is the most correct solution, though (I haven't
investigated at all).
> mipsel | libpam-tacplus-1.3.9 | NOK | http://autobuild.buildroot.net/results/89f9ef5a3ed9743269f82eab11323840b409ce70/
/home/test/autobuild/instance-2/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp_nonshared
/home/test/autobuild/instance-2/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp
Vicente, what is the status of this issue ?
> bfin | libraw-0.17.1 | NOK | http://autobuild.buildroot.net/results/56fa1435cf5dc68f95bbba29dd557c4975f73818/
> bfin | libraw-0.17.1 | NOK | http://autobuild.buildroot.net/results/f7ddd14023ea54127cd8dd44b76171a2247d8f97/
> bfin | libraw-0.17.1 | NOK | http://autobuild.buildroot.net/results/143c4c2a1d8527c97362ce11507e8b5a79dd0d6b/
Would be fixed by http://patchwork.ozlabs.org/patch/582121/.
> bfin | libraw1394-2.1.1 | NOK | http://autobuild.buildroot.net/results/198149e80be3e62eaf9f4731442031a1aa93409c/
> bfin | libraw1394-2.1.1 | NOK | http://autobuild.buildroot.net/results/774204390942faa43296c5abf193bcbf1260687c/
> bfin | libraw1394-2.1.1 | NOK | http://autobuild.buildroot.net/results/d4e50cb00ec66498a2989ed406eaa2165ef5684f/
> bfin | libraw1394-2.1.1 | NOK | http://autobuild.buildroot.net/results/2444ba3224fb08ab5677cecdf6a9eb31b9435459/
Would be fixed by http://patchwork.ozlabs.org/patch/582122/.
> powerpc | libupnpp-0.13.1 | NOK | http://autobuild.buildroot.net/results/653421502099e4a9220bdb5ed13d92e78c3cf674/
checking for curl_easy_init in -lcurl... no
configure: error: libcurl not found
Static linking problem. J?rg, can you have a look ?
> arm | lvm2-2.02.138 | NOK | http://autobuild.buildroot.net/results/c16fb939a9f1b7d786cf2f7d7f6ffad9ac6cd841/
commands/toolcontext.c: In function 'create_toolcontext':
commands/toolcontext.c:1796:10: error: assignment of read-only variable 'stdin'
stdin = new_stream;
Would be fixed by http://patchwork.ozlabs.org/patch/573519/, though it
would be good to get the patch merged upstream to get some proper
review of it.
Bernd ?
> sparc | mesa3d-11.1.1 | NOK | http://autobuild.buildroot.net/results/d8925a4968306d67749c9fe165230cdad066d988/
Use of atomic operations. Waldemar ?
> arm | minidlna-1.1.5 | NOK | http://autobuild.buildroot.net/results/8ebea55163a36735a3d987a787efd7eeb42d1e66/
/home/peko/autobuild/instance-2/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libwavpack.a(libwavpack_la-pack_utils.o): In function `free_metadata':
pack_utils.c:(.text+0x9a8): multiple definition of `free_metadata'
metadata.o:metadata.c:(.text+0x474): first defined here
collect2: error: ld returned 1 exit status
Consequence of static linking.
Anyone to have a look ?
> aarch64 | mplayer-1.2 | NOK | http://autobuild.buildroot.net/results/48f96ef26f895639f3376e94eccdea9765710877/
> aarch64 | mplayer-1.2 | NOK | http://autobuild.buildroot.net/results/97c435c39345b22e1e7e2feb7d5badba9b74791b/
> aarch64 | mplayer-1.2 | NOK | http://autobuild.buildroot.net/results/009287d4dd1511ab2127328815fed0365549a5ed/
Still the same problem building mplayer on AArch64. I will send a patch
to disable it.
> powerpc | nfs-utils-1.3.3 | NOK | http://autobuild.buildroot.net/results/7a102b5f3f9794be8c02db6f9bfbccec4f4acd8a/
Would be fixed by http://patchwork.ozlabs.org/patch/577178/.
> powerpc | numactl-2.0.11 | NOK | http://autobuild.buildroot.net/results/ef89fb8982438842a45794462b37f10ed121f33a/
> x86_64 | numactl-2.0.11 | NOK | http://autobuild.buildroot.net/results/077c6b213738e6914b1836bacc1e6bb8613bea50/
> powerpc | numactl-2.0.11 | NOK | http://autobuild.buildroot.net/results/ac611dc851e7a5638f0c8fc0a9b246c3c79cd7d7/
> mipsel | numactl-2.0.11 | NOK | http://autobuild.buildroot.net/results/48a94050e26ad829277c46300b90439502e8a3e6/
> powerpc | numactl-2.0.11 | NOK | http://autobuild.buildroot.net/results/2b62e30bcb36c3877686b1471642273e21756c91/
This seems to be a regression following the merge of patch
https://git.busybox.net/buildroot/commit/?id=21ed7a92fe5a771911ef06f97522e504d0eebbc2
from Bernd.
Bernd, can you have a look ?
> powerpc | pax-utils-1.1.4 | NOK | http://autobuild.buildroot.net/results/ba9d058da46fcb569120a6dc826e2c51dc676569/
security.c: In function 'security_init':
security.c:245:8: error: 'PR_SET_NO_NEW_PRIVS' undeclared (first use in this function)
security.c:245:8: note: each undeclared identifier is reported only once for each function it appears in
Probably we need some more recent kernel headers.
> mips64el | psmisc-22.21 | NOK | http://autobuild.buildroot.net/results/410327935adcc1cded02243c051f8e92c56237af/
> mips64el | psmisc-22.21 | NOK | http://autobuild.buildroot.net/results/b98e244b8ae1b06047fcb05b7d34ce483c736ecc/
/home/buildroot/autobuild/run/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp_nonshared
/home/buildroot/autobuild/run/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp
Vicente ?
> mipsel | pulseaudio-8.0 | NOK | http://autobuild.buildroot.net/results/d2b953bb074e7f0e0de86c11771624b399d43859/
> powerpc | pulseaudio-8.0 | NOK | http://autobuild.buildroot.net/results/46d702f32b23b50c12237e04e50b2d304d944f40/
> mipsel | pulseaudio-8.0 | NOK | http://autobuild.buildroot.net/results/8c022016235bef7850fc933c7f1f5ab5ac7cf0fb/
> sparc64 | pulseaudio-8.0 | NOK | http://autobuild.buildroot.net/results/474e237f6ec11cec590f32aa55372917abcbf396/
> sparc64 | pulseaudio-8.0 | NOK | http://autobuild.buildroot.net/results/ac5395c8b2c1d634c341b0c7d7913c9528f6117f/
> mips | pulseaudio-8.0 | NOK | http://autobuild.buildroot.net/results/f2fdc25c6d3c85a24c7a13b8448a7463b4049a48/
> x86_64 | pulseaudio-8.0 | NOK | http://autobuild.buildroot.net/results/5a82b31f6065a0aad123d78d0b6b0f8025ba360b/
These seem to be regressions following the merge of https://git.busybox.net/buildroot/commit/package/pulseaudio?id=1cffb454320aeba80a56985ecfc44c3c1d293802 from Bernd.
Bernd, can you have a look ?
> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/ee562524c5b12191e584ceae89006c5a5103e700/
Romain, is the patch for this pending somewhere ?
> i686 | samba4-4.3.4 | NOK | http://autobuild.buildroot.net/results/2cdfedf5407bbb6f5c383aba930ee79794d45df6/
> sh4a | samba4-4.3.4 | NOK | http://autobuild.buildroot.net/results/16a9f69f0cef6e02c7249be6cae61dd36a9ef6df/
> x86_64 | samba4-4.3.4 | NOK | http://autobuild.buildroot.net/results/a5b837d6d02ec96ac53c5b1c531a0c8e7eafeb9a/
default/lib/crypto/hmacmd5_1.o: In function `hmac_md5_init_rfc2104':
hmacmd5.c:(.text+0x2e): undefined reference to `MD5Init'
hmacmd5.c:(.text+0x3e): undefined reference to `MD5Update'
hmacmd5.c:(.text+0x4b): undefined reference to `MD5Final'
hmacmd5.c:(.text+0xab): undefined reference to `MD5Init'
hmacmd5.c:(.text+0xbb): undefined reference to `MD5Update'
Gustavo, can you have a look ?
> mips64el | sox-14.4.2 | NOK | http://autobuild.buildroot.net/results/0273acd342bf1cf470c0b944c10ca23acf0e1a39/
Vicente:
/home/buildroot/build/instance-1/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp_nonshared
/home/buildroot/build/instance-1/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp
Maybe those Codescape toolchains are not ready, and we should change
the autobuilder configurations to not use them?
> arm | sqlite-3100200 | NOK | http://autobuild.buildroot.net/results/a25932ef64c6a0fb64bb7d053aac18527ce1ccf5/
> arm | sqlite-3100200 | NOK | http://autobuild.buildroot.net/results/c9a8589782b387e99f4c840eb722bcced86cf74d/
sqlite3.o: file not recognized: File truncated
collect2: error: ld returned 1 exit status
Parallel build problem ? Gustavo ?
> mips64el | strongswan-5.3.5 | NOK | http://autobuild.buildroot.net/results/3153eed33aaed1e4605a927ca8f78de56d3697a1/
utils/utils.c: In function 'closefrom':
utils/utils.c:173:25: error: '__NR_getdents64' undeclared (first use in this function)
while ((len = syscall(__NR_getdents64, dir_fd, buffer,
Vicente ?
> aarch64 | tor-0.2.7.6 | NOK | http://autobuild.buildroot.net/results/fff98784c3f8c67d6db54e10459d287bc3a490e2/
> aarch64 | tor-0.2.7.6 | NOK | http://autobuild.buildroot.net/results/fc51b05556433368bc242b50b0b68c97eadfd2c6/
crypto_format.c:(.text+0x1c): relocation truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against symbol `smartlist_new' defined in .text
Seems like a toolchain problem :/
> arm | trinity-v1.6 | NOK | http://autobuild.buildroot.net/results/2a91b8d585c34ee97d97fe9618cf82242ae5f3d0/
error: redefinition of 'struct in6_pktinfo'
Musl related issue.
> i686 | trinity-v1.6 | NOK | http://autobuild.buildroot.net/results/b5a199d24c625e083f8238a500de113c888021a3/
But maybe not, because this is the same issue, but on glibc.
> mips | valgrind-3.11.0 | NOK | http://autobuild.buildroot.net/results/1929133f50400e148044f9a1d4984aee10b80468/
Vicente, this one is for you :-)
If there is no support yet for mips32r2, then can you submit a patch
that disables the build of valgrind on this architecture variant ?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-22 9:29 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (8 preceding siblings ...)
2016-01-27 17:18 ` Peter Korsgaard
@ 2016-02-03 9:37 ` Max Filippov
9 siblings, 0 replies; 416+ messages in thread
From: Max Filippov @ 2016-02-03 9:37 UTC (permalink / raw)
To: buildroot
On Fri, Jan 22, 2016 at 12:29 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>> xtensa | mp4v2-2.0.0 | NOK | http://autobuild.buildroot.net/results/bff7436a800eeea92c0c92bd2846b0f2b31947fd/
>
> /tmp/cchH5TCg.s:23436: Error: value of 38619 too large for field of 2 bytes at 2889
>
> Toolchain problem. Max can you have a look ?
Fixed by https://patchwork.ozlabs.org/patch/577797/
--
Thanks.
-- Max
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-22 9:29 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (7 preceding siblings ...)
2016-01-26 21:06 ` Bernd Kuhls
@ 2016-01-27 17:18 ` Peter Korsgaard
2016-02-03 9:37 ` Max Filippov
9 siblings, 0 replies; 416+ messages in thread
From: Peter Korsgaard @ 2016-01-27 17:18 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> x86_64 | madplay-0.15.2b | NOK | http://autobuild.buildroot.net/results/2561190b274d71666c4bdf3c569b02063cefdb30/
> ./relocatable.c: In function 'libintl_relocate':
> ./relocatable.c:402:40: error: 'INSTALLPREFIX' undeclared (first use in this function)
> const char *orig_installprefix = INSTALLPREFIX;
> Musl related ? Not sure. Peter, you added the madplay package back in
> 2007, so can you have a look ? :-)
Heh, I don't recall any details from 2007 - But I've taken a look and
pushed a fix. It was indeed musl related.
--
Venlig hilsen,
Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-27 15:09 ` Thomas Petazzoni
@ 2016-01-27 15:13 ` Joao Pinto
0 siblings, 0 replies; 416+ messages in thread
From: Joao Pinto @ 2016-01-27 15:13 UTC (permalink / raw)
To: buildroot
Thomas,
According to the MPlayer team, version 1.2.x already supports AARCH64, so there
is no sense on applying the patch for this new version.
On 1/27/2016 3:09 PM, Thomas Petazzoni wrote:
> Joao,
>
> On Wed, 27 Jan 2016 14:25:29 +0000, Joao Pinto wrote:
>
>> Wrong commit, sorry.
>> Please consider this one:
>> https://git.busybox.net/buildroot/commit/?id=1fc839e436a2a745bc7996545b1f60df5670df63
>
> I still don't understand. The previous version of MPlayer was building
> fine for AArch64, so you enabled support for AArch64, which was good.
>
> But now, because there is a regression on the new version of MPlayer
> which makes it fail to build on AArch64, you want to completely disable
> the MPlayer package for AArch64 ? It seems like a very strange
> solution. Instead, what about investigating the regression and fixing
> it ?
>
> Thanks,
>
> Thomas
>
Joao
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-27 14:25 ` Joao Pinto
@ 2016-01-27 15:09 ` Thomas Petazzoni
2016-01-27 15:13 ` Joao Pinto
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2016-01-27 15:09 UTC (permalink / raw)
To: buildroot
Joao,
On Wed, 27 Jan 2016 14:25:29 +0000, Joao Pinto wrote:
> Wrong commit, sorry.
> Please consider this one:
> https://git.busybox.net/buildroot/commit/?id=1fc839e436a2a745bc7996545b1f60df5670df63
I still don't understand. The previous version of MPlayer was building
fine for AArch64, so you enabled support for AArch64, which was good.
But now, because there is a regression on the new version of MPlayer
which makes it fail to build on AArch64, you want to completely disable
the MPlayer package for AArch64 ? It seems like a very strange
solution. Instead, what about investigating the regression and fixing
it ?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-27 12:16 ` Thomas Petazzoni
@ 2016-01-27 14:25 ` Joao Pinto
2016-01-27 15:09 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Joao Pinto @ 2016-01-27 14:25 UTC (permalink / raw)
To: buildroot
Dear Thomas,
Wrong commit, sorry.
Please consider this one:
https://git.busybox.net/buildroot/commit/?id=1fc839e436a2a745bc7996545b1f60df5670df63
Joao
On 1/27/2016 12:16 PM, Thomas Petazzoni wrote:
> Dear Joao Pinto,
>
> On Wed, 27 Jan 2016 11:37:31 +0000, Joao Pinto wrote:
>
>> Just checked and apparently MPlayer 1.2.x already supports AARCH64 so I think
>> the patch
>> https://git.busybox.net/buildroot/commit/?id=c93805207e24df082495f4d050bc2f29f3d19dd6
>> is no longer necessary.
>
> Sorry, I don't understand. You're talking about MPlayer, which clearly
> doesn't build for AArch64, and you point to a commit about sysvinit.
>
> Could you explain ?
>
> Thanks,
>
> Thomas
>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-27 11:37 ` Joao Pinto
@ 2016-01-27 12:16 ` Thomas Petazzoni
2016-01-27 14:25 ` Joao Pinto
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2016-01-27 12:16 UTC (permalink / raw)
To: buildroot
Dear Joao Pinto,
On Wed, 27 Jan 2016 11:37:31 +0000, Joao Pinto wrote:
> Just checked and apparently MPlayer 1.2.x already supports AARCH64 so I think
> the patch
> https://git.busybox.net/buildroot/commit/?id=c93805207e24df082495f4d050bc2f29f3d19dd6
> is no longer necessary.
Sorry, I don't understand. You're talking about MPlayer, which clearly
doesn't build for AArch64, and you point to a commit about sysvinit.
Could you explain ?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-26 13:26 ` Thomas Petazzoni
@ 2016-01-27 11:37 ` Joao Pinto
2016-01-27 12:16 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Joao Pinto @ 2016-01-27 11:37 UTC (permalink / raw)
To: buildroot
Hi,
Just checked and apparently MPlayer 1.2.x already supports AARCH64 so I think
the patch
https://git.busybox.net/buildroot/commit/?id=c93805207e24df082495f4d050bc2f29f3d19dd6
is no longer necessary.
On 1/26/2016 1:26 PM, Thomas Petazzoni wrote:
> Joao,
>
> On Tue, 26 Jan 2016 12:02:46 +0000, Joao Pinto wrote:
>
>> Could you tell me what changed in the Buildroot ecosystem to generate such "new"
>> errors?
>
> So you're talking about the mplayer failure on AArch64. I believe the
> main change that took place is that after you enabled it on AArch64,
> mplayer was bumped to version 1.2. Maybe the AArch64 build problem
> appeared with the bump to version 1.2.
>
> Could you investigate if that's the case, if mplayer upstream already
> has a fix for the issue, and if not, see if the issue can be fixed
> easily ?
>
> Thanks,
>
> Thomas
>
Thanks,
Joao
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-22 9:29 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (6 preceding siblings ...)
2016-01-26 12:02 ` Joao Pinto
@ 2016-01-26 21:06 ` Bernd Kuhls
2016-01-27 17:18 ` Peter Korsgaard
2016-02-03 9:37 ` Max Filippov
9 siblings, 0 replies; 416+ messages in thread
From: Bernd Kuhls @ 2016-01-26 21:06 UTC (permalink / raw)
To: buildroot
Am Fri, 22 Jan 2016 10:29:57 +0100 schrieb Thomas Petazzoni:
>> arm | aumix-2.8 | NOK |
>> http://autobuild.buildroot.net/results/
c8c7f9a799d1af507a6edd5e02b0bbc8b7b5d068/
>
> gettext/libintl handling issue.
Hi Thomas,
fixed by http://patchwork.ozlabs.org/patch/573473/
Regards, Bernd
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-26 12:02 ` Joao Pinto
@ 2016-01-26 13:26 ` Thomas Petazzoni
2016-01-27 11:37 ` Joao Pinto
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2016-01-26 13:26 UTC (permalink / raw)
To: buildroot
Joao,
On Tue, 26 Jan 2016 12:02:46 +0000, Joao Pinto wrote:
> Could you tell me what changed in the Buildroot ecosystem to generate such "new"
> errors?
So you're talking about the mplayer failure on AArch64. I believe the
main change that took place is that after you enabled it on AArch64,
mplayer was bumped to version 1.2. Maybe the AArch64 build problem
appeared with the bump to version 1.2.
Could you investigate if that's the case, if mplayer upstream already
has a fix for the issue, and if not, see if the issue can be fixed
easily ?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-22 9:29 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (5 preceding siblings ...)
2016-01-23 10:55 ` Samuel Martin
@ 2016-01-26 12:02 ` Joao Pinto
2016-01-26 13:26 ` Thomas Petazzoni
2016-01-26 21:06 ` Bernd Kuhls
` (2 subsequent siblings)
9 siblings, 1 reply; 416+ messages in thread
From: Joao Pinto @ 2016-01-26 12:02 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Could you tell me what changed in the Buildroot ecosystem to generate such "new"
errors?
Joao
On 1/22/2016 9:29 AM, Thomas Petazzoni wrote:
> Hello,
>
> Gustavo, Carsten, Frank, Vicente, Alan, Romain, Bernd, Thomas, Peter,
> Max, Joao, Maxime, Sonic, Simon, Waldemar, please see below, there are
> some questions for you. Thanks!
>
> On Fri, 22 Jan 2016 08:30:21 +0100 (CET), Thomas Petazzoni wrote:
>
>> arm | aumix-2.8 | NOK | http://autobuild.buildroot.net/results/c8c7f9a799d1af507a6edd5e02b0bbc8b7b5d068/
>
> gettext/libintl handling issue.
>
>> mipsel | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/62f386829193c747176ace05e4b26826fcabbf59/
>> mips64el | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/a92fa5dc5d9d6742d61d4d293f7eac97c5355dfe/
>
> rbt.c:116:15: error: two or more data types in declaration specifiers
> isc_uint32_t ptrsize;
> ^
> rbt.c:116:22: error: expected identifier or '(' before ';' token
> isc_uint32_t ptrsize;
>
> Gustavo, can you have a look ? I think this error already popped up in the past, no?
>
>> arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/c7d987a51f2b2b731fb60e0e741361bbfb4ff230/
>> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/b2c860fc8fbc7a025bcd3c04e9b43b04f029ead3/
>> arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/5a33d69d2c11e3013b73b3f6c1d8ab3a31facf62/
>> arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/a7c7eb7c2f477f8a19c1b364f746dfd31bf18a3d/
>> arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/fb2f5cbe28a41161df7e3c5b2f6a36242daf5374/
>> xtensa | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/179345a92e0c1db1b8d5bccb27c6b93e484f9b6d/
>> i686 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/8612864811bbb04d655a6040869ccb81396d7737/
>> arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/51c54c85010c61245a4ef51d4e602974809d077f/
>> arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/e474243b83233c008fc2351c77eba35269e95439/
>> xtensa | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/30898a3c7a5fceb1bd14a287064b96e04fba7921/
>> microblazeel | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/d5d159dc004e28fed537b84fae76afb0734b2ec0/
>> microblazeel | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/71e9dbb63b91980723554651071fdc3d7a2250f2/
>> mips64el | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/3ee30fe28f709c63c9a0e2d0d91440d855ff73a9/
>> xtensa | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/c48523b0bc50c61a9dd1bb691cd3fe3b05fdc1a7/
>> sh4 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/04553f5d6b73b0a97901995674b0876c33d062f5/
>
> The FE_* issue. I tried to have a look at the other day. It seems like
> the Boost code does check for FE_*, but it does by running tests with
> the host compiler... So it concludes that fenv.h support is OK, but
> then it really builds with the target compiler and fails. But the boost
> build system is so... that I'm not even sure.
>
>> arm | dvbsnoop-1.4.50 | NOK | http://autobuild.buildroot.net/results/be64a45ac158b9057fb3e7ef9b515250acc77187/
>
> Still the u_long problem. Carsten ?
>
>> sparc | erlang-17.5 | NOK | http://autobuild.buildroot.net/results/20cd87c6a05c91ee223b813040d9d10fa923b174/
>
> libatomic_ops not usable. Probably need to disable erlang on Sparc and
> be done with it?
>
>> x86_64 | erlang-17.5 | NOK | http://autobuild.buildroot.net/results/e4ab3fa4a121f7d7edb0263f02aac2ee836905a7/
>
> sys/common/erl_poll.c: In function 'update_pollset':
> sys/common/erl_poll.h:132:5: error: '__uint32_t' undeclared (first use in this function)
> ((__uint32_t) (EV))
> ^
> sys/common/erl_poll.c:1150:24: note: in expansion of macro 'ERTS_POLL_EV_E2N'
> epe_templ.events = ERTS_POLL_EV_E2N(ps->fds_status[fd].events);
> ^
> sys/common/erl_poll.h:132:5: note: each undeclared identifier is reported only once for each function it appears in
> ((__uint32_t) (EV))
> ^
> sys/common/erl_poll.c:1150:24: note: in expansion of macro 'ERTS_POLL_EV_E2N'
> epe_templ.events = ERTS_POLL_EV_E2N(ps->fds_status[fd].events);
> ^
>
> Musl build issue. Frank, can you have a look at this one ?
>
>> arm | gdk-pixbuf-2.32.3 | NOK | http://autobuild.buildroot.net/results/f271386d3cefad4a4971bc8698848b4563498e6b/
>
> ./.libs/libgdk_pixbuf-2.0.so: undefined reference to `libintl_bind_textdomain_codeset'
> ./.libs/libgdk_pixbuf-2.0.so: undefined reference to `libintl_bindtextdomain'
> ./.libs/libgdk_pixbuf-2.0.so: undefined reference to `libintl_gettext'
>
> Gustavo, can you have a look ?
>
>> mips64el | gst1-libav-1.6.3 | NOK | http://autobuild.buildroot.net/results/1a0eb189ad91a7f2fb7285f4225555a0a0febda2/
>
> libavformat/aacdec.c:1:0: error: '-mips64r2' conflicts with the other architecture options, which specify a mips64 processor
>
> Vicente, this one is for you :-)
>
>> xtensa | hidapi-d17db57b9d4354752e0a... | NOK | http://autobuild.buildroot.net/results/a5b0d3816953b5477d7938cf001fb048fee7462b/
>
> Weird:
>
> make[3]: *** No rule to make target `hidtest.o', needed by `hidtest-libusb'. Stop.
>
> Alan, hidapi is your thing, would you mind having a look ?
>
>> arm | host-efl-1.15.3 | NOK | http://autobuild.buildroot.net/results/e178371c2c3bf42d59c6fc26409e098081239ccb/
>
> lib/evas/filters/evas_filter_parser.c: In function '_lua_backtrace':
> lib/evas/filters/evas_filter_parser.c:2434:20: error: 'LUA_GLOBALSINDEX' undeclared (first use in this function)
> lua_getfield(L, LUA_GLOBALSINDEX, "debug");
>
> Romain ? This is host-efl, maybe we need to disable Lua support or
> something ?
>
>> microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/d35f6ee7643a695af7db3739ff480d25b99ee051/
>> microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/09f4a89e463b6ccbca01cce1d38eb849c17ed6e1/
>
> The documentation issue. Romain, you looked into this a while ago, why
> does it pop up again on Microblaze specifically ?
>
> Maybe we can switch to the mainline gdb for Microblaze ?
>
>> nios2 | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/0e8d5ab5127b5e40c58912fe16504e3fcb941e69/
>> arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/10f61d4cc5f6fdac231185d577493e0e82c5d091/
>> microblazeel | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/bdcb9bbd7a07f0bde1b575bbf7ae88d006a1e823/
>> arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/a25de6a6e8d68fd86ebf2c5805c6fe31d5860656/
>> arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/f00e14e2360544ffe7501247dddfcb701631646d/
>> mips64el | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/95491e089e6e18bfddbf6d7d19450026e9a349f5/
>> mips64el | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/936d66543e2db55309af115ead64ded24f31661c/
>> arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/25409dfeb7ce5806115092eb341e201d680ab974/
>> bfin | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/1a45412939a3f9d6fa59d086d834a3b4a4bffef7/
>
> Would be fixed by http://patchwork.ozlabs.org/patch/571347/.
>
>> nios2 | imagemagick-6.9.2-10 | NOK | http://autobuild.buildroot.net/results/0bf3a2a284b7d4712ab1530562d3b8164fc75e88/
>
> The usual:
>
> assertion fail elf32-nios2.c:1038
>
> This is being fixed at
> https://sourceware.org/bugzilla/show_bug.cgi?id=19405. In the mean
> time, we could disable on NIOS II maybe ?
>
>> arm | iperf3-3.1 | NOK | http://autobuild.buildroot.net/results/50e34db9e273ebb7b8a9198dec254f6b22e26eff/
>
> iperf.h:71:21: error: field 'tcpInfo' has incomplete type
> struct tcp_info tcpInfo; /* getsockopt(TCP_INFO) for Linux, {Free,Net}BSD */
>
> musl build issue.
>
> Gustavo, you added the iperf3 package, can you have a look ?
>
>> x86_64 | iproute2-4.4.0 | NOK | http://autobuild.buildroot.net/results/d3d79b55cb19987d5d5c0da9c0f0d25697697c05/
>
> Already fixed by
> https://git.busybox.net/buildroot/commit/?id=11d7b8b64aa171823bc4c97e3cce43884d078ecf.
>
>> x86_64 | iucode-tool-1cbd73013cd4c6b... | NOK | http://autobuild.buildroot.net/results/7f8626db69500a84a393053a485f04180c565673/
>
> Fixed by https://git.busybox.net/buildroot/commit/?id=6a774f400b20612cb77836a47aaf62ea72422fb8.
>
>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/183df75a853c3b0e2617c9219a356c5531aa523d/
>
> Will be fixed once we bump to binutils 2.26. Romain, maybe we should
> disable libcap-ng in the mean time ?
>
>> x86_64 | libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/7d444611f8efa40e0eb81ac88365416ef553fcd5/
>> x86_64 | libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/6287fa5a754610f04f0df93bf611676d982f5cff/
>
> Musl build issue. Bernd, can you have a look ?
>
>> powerpc | libnss-3.21 | NOK | http://autobuild.buildroot.net/results/cdae10070b9a97066dbfd0fb2c2004d9bd1fdd43/
>> powerpc | libnss-3.21 | NOK | http://autobuild.buildroot.net/results/0df8b1f78b671ff05b2ecbf9c4cf08b8898e2d43/
>
> Fixed by https://git.busybox.net/buildroot/commit/?id=b8fb4903fb858bc81eab6ac5bd37c801853594cb.
>
>> i686 | libsoil-20080707 | NOK | http://autobuild.buildroot.net/results/8ff91ab8e52000eb34dd8f662520cf1b31490cf5/
>> x86_64 | libsoil-20080707 | NOK | http://autobuild.buildroot.net/results/ea77d6b23aca0cb1cf527e6c16ddf5eba957a69c/
>
> These are really weird. The patch doesn't apply when the build takes
> place on my build server, but it does apply when I test things locally
> on my machine. A difference in the version of patch ?
>
>> sparc | libubox-e88d816d6e462180f03... | NOK | http://autobuild.buildroot.net/results/4feaa9089ee9a183c5086b791bea35c0156945af/
>
> Atomic issue strikes again.
>
>> mips64el | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/4d63874fe2efda8ac7aa3a8c82affa99f0ce5af0/
>
> [.... many more of this issue ....]
>
> Fixed by
> https://git.busybox.net/buildroot/commit/?id=343ec915e3f7cb6f83ef114cd6c5e5f3502d8f4a.
>
>> mips64el | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/3a2b141d90b28a2954fa0ad3104cba81d648d2a3/
>> mipsel | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/70aa227c8a289631c2973474cfaef5973756dd5c/
>> mips64el | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/2b8c777c76b7e5d5a426045f5a3872d6b71faa56/
>> mipsel | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/3f19dd459400ac7fca39e69dd280def6a547f8b6/
>
> tirpc/tests_pack/rpc_suite/tirpc/tirpc_auth_authdes_create/tirpc_authdes_create.c:50: undefined reference to `authdes_create'
> collect2: error: ld returned 1 exit status
>
> Thomas, you touched the ltp-testsuite/tirpc handling recently IIRC.
> Interestingly, this problem only occurs on MIPS apparently. Thomas,
> Vicente, can you have a look ?
>
>
>> arm | lttng-tools-2.7.1 | NOK | http://autobuild.buildroot.net/results/b48bc7ad4bede4d16c079da0ae1121e6796a0e8d/
>> arm | lttng-tools-2.7.1 | NOK | http://autobuild.buildroot.net/results/25dcb19c3dd32e50990f9b45053d71ea18746a80/
>> arm | lttng-tools-2.7.1 | NOK | http://autobuild.buildroot.net/results/a3f93498811491d37ba13d024e33e68a8bc7ba18/
>
> checking for dlopen in -lc... no
> configure: error: Cannot find dlopen in libdl nor libc. Use LDFLAGS=-Ldir to specify their location.
>
> In a static linking only situation.
>
> Samuel, can you have a look ? Most likely we should simply disable
> lttng-tools for static only scenarios.
>
>> x86_64 | madplay-0.15.2b | NOK | http://autobuild.buildroot.net/results/2561190b274d71666c4bdf3c569b02063cefdb30/
>
> ./relocatable.c: In function 'libintl_relocate':
> ./relocatable.c:402:40: error: 'INSTALLPREFIX' undeclared (first use in this function)
> const char *orig_installprefix = INSTALLPREFIX;
>
> Musl related ? Not sure. Peter, you added the madplay package back in
> 2007, so can you have a look ? :-)
>
>> microblazeel | mesa3d-11.1.1 | NOK | http://autobuild.buildroot.net/results/0d71cd6edccd390106636cc0c4acfe5a8dca112a/
>> microblazeel | mesa3d-11.1.1 | NOK | http://autobuild.buildroot.net/results/6567477b87c081db97a9c2bf84af182a9a281193/
>
> Another atomic issue: __sync_val_compare_and_swap_1.
>
>> mipsel | mosh-1.2.5 | NOK | http://autobuild.buildroot.net/results/3f9443a76d2f8811720748b487e045eec23ec338/
>> mipsel | mosh-1.2.5 | NOK | http://autobuild.buildroot.net/results/104b8fae4ff5918353e0e6a7ac050e2f04d701c1/
>
> Vicente, this is with your new mips toolchains, SSP library problem.
> Can you have a look ?
>
>> xtensa | mp4v2-2.0.0 | NOK | http://autobuild.buildroot.net/results/bff7436a800eeea92c0c92bd2846b0f2b31947fd/
>
> /tmp/cchH5TCg.s:23436: Error: value of 38619 too large for field of 2 bytes at 2889
>
> Toolchain problem. Max can you have a look ?
>
>> aarch64 | mplayer-1.2 | NOK | http://autobuild.buildroot.net/results/aadce770cf86ded813a78f936f0a6d4441845907/
>
> libavutil/aarch64/cpu.c:25:32: error: 'HAVE_ARMV8' undeclared (first use in this function)
> return AV_CPU_FLAG_ARMV8 * HAVE_ARMV8 |
> ^
> libavutil/aarch64/cpu.c:25:32: note: each undeclared identifier is reported only once for each function it appears in
>
> Joao, you enabled mplayer on AArch64, can you have a look please ?
>
>> powerpc | nfs-utils-1.3.3 | NOK | http://autobuild.buildroot.net/results/fe3be93988e585a84ae3116a0c327e1e2c95ad08/
>
> Still the same build issue:
>
> cache.c: In function 'same_path':
> cache.c:429:22: error: field 'fh' has incomplete type
> cache.c:436:2: warning: implicit declaration of function 'name_to_handle_at' [-Wimplicit-function-declaration]
> Makefile:613: recipe for target 'mountd-cache.o' failed
>
> Maxime ? I gave you some hints about this one, can you cook a patch ?
>
>> arm | php-5.6.17 | NOK | http://autobuild.buildroot.net/results/0bbae90d05f14ac1fdbac7d8d69d4e6fd922e301/
>
> Forgets to link with pthread in a static linking scenario.
>
> Gustavo ?
>
>> arm | pinentry-0.9.4 | NOK | http://autobuild.buildroot.net/results/bd886cd10a8f52647296de2ff50270f25532756e/
>
> Weird C++ error:
>
> error: member 'QChar std::__cxx11::basic_string<QChar, std::char_traits<QChar>, secmem::alloc<QChar> >::<anonymous union>::_M_local_buf [8]' with constructor not allowed in union
>
> Vicente, you added this package, so can you have a look ?
>
>> arm | pptp-linux-1.8.0 | NOK | http://autobuild.buildroot.net/results/56dd530d53489220d0080480310b8dc150cf1b2e/
>
> Musl build issue. Gustavo ?
>
>> arc | qextserialport-ada321a9ee46... | NOK | http://autobuild.buildroot.net/results/d6565367f83cc845495e5e5f60935b71d04ef2da/
>
> Toolchain issue it seems:
>
> /home/test/autobuild/instance-1/output/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/4.8.4/../../../../arc-buildroot-linux-uclibc/bin/ld: /home/test/autobuild/instance-1/output/host/usr/arc-buildroot-linux-uclibc/sysroot/usr/lib/libglib-2.0.a(libglib_2_0_la-gmain.o): relocation R_ARC_32_ME against `.rodata.str1.4' can not be used when making a shared object; recompile with -fPIC
>
> Alexey ?
>
>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/aa1492777c5f60ab45921618f64910ca4d048e5f/
>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/a74810f0fce398c41fef11b8e2b8e1a52ffdb46a/
>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/cb70d195cf9b9b5ae09b83a40ef767cc8f699a9c/
>
> Toolchain issues. Being fixed in upstream gcc, but we should disable
> with external NIOS2 toolchain anyway.
>
> Romain ?
>
>> arm | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/53e7e122e96b4b96c0f5feb4f26055b3f5ad8096/
>
> Full static configuration fails with:
>
> /home/test/autobuild/instance-1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.9.3/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: cannot find -ldl
>
> See if we can, get rid of the libdl dependency or make qt (or one of
> its sub-option) depend on dynamic library.
>
>
>> arm | rt-tests-v0.89 | NOK | http://autobuild.buildroot.net/results/a6f6502e55fd68803f3ff8b4b76cce6601e101db/
>
> In file included from src/lib/rt-get_cpu.c:4:0:
> src/include/rt-get_cpu.h:9:19: fatal error: dlfcn.h: No such file or directory
> #include <dlfcn.h>
>
> Should depend on dynamic library.
>
>> bfin | ruby-2.3.0 | NOK | http://autobuild.buildroot.net/results/268d29bd910c17b1fccad5d13ce281238080efd2/
>> bfin | ruby-2.3.0 | NOK | http://autobuild.buildroot.net/results/1eb3d1ca20ce81fa2b10593d9393fb130558a706/
>
> process.c: In function 'rb_spawn_process':
> process.c:3921: warning: passing argument 2 of 'rb_ary_new_from_values' from incompatible pointer type
> process.c:3923: error: 'status' undeclared (first use in this function)
> process.c:3923: error: (Each undeclared identifier is reported only once
> process.c:3923: error: for each function it appears in.)
>
> Sonic, this is a Blackfin problem, can you have a look ?
>
>
>> arm | sconeserver-3b886c3dda6eda3... | NOK | http://autobuild.buildroot.net/results/178bdfb062949fb10b9d6b9830975aa57702b3ae/
>
> Static configuration, fails with:
>
> checking for mpfr_init in -lmpfr... no
> configure: error: libraries 'mpfr' and 'gmp' are required for the maths module
>
> Simon, can you have a look ?
>
>> sparc64 | setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/328192a8c561f3517bb0f9ebafb59d09e4f4b3ae/
>
> policy_scan.o: In function `yyget_out':
> policy_scan.c:(.text+0x504): relocation truncated to fit: R_SPARC_GOT13 against symbol `yyout' defined in .bss section in policy_scan.o
> policy_scan.o: In function `yyget_leng':
> policy_scan.c:(.text+0x520): relocation truncated to fit: R_SPARC_GOT13 against symbol `yyleng' defined in COMMON section in policy_scan.o
>
> Waldemar, this is a toolchain problem, can you have a look ?
>
>> mips64el | slang-2.3.0 | NOK | http://autobuild.buildroot.net/results/3c1fef2163b8a194ede70040da87af95bf5dc331/
>
> /home/buildroot/autobuild/run/instance-2/output/host/usr/mips64el-buildroot-linux-uclibc/sysroot/usr/lib/../lib64/libreadline.a(display.o): In function `cr':
> display.c:(.text+0x208): undefined reference to `tputs'
> display.c:(.text+0x210): undefined reference to `tputs'
>
> Static linking problem.
>
> Vicente, in commit 41d6f177d226b9014f5a14d0d05ca843f482d94f, you added
> some patches to fix static linking. Seems like there are more
> problems :-)
>
>> arm | strongswan-5.3.5 | NOK | http://autobuild.buildroot.net/results/601d8dc1654d8733db49b195139e12437663034c/
>
> plugins/plugin_loader.c: In function 'load_plugin':
> plugins/plugin_loader.c:359:13: error: 'RTLD_LAZY' undeclared (first use in this function)
> int flag = RTLD_LAZY;
>
> Needs dynamic library ?
>
>> mipsel | stunnel-5.28 | NOK | http://autobuild.buildroot.net/results/3448dc253a4a86450f15fb225374bd1e643dacd1/
>
> Vicente, this is with your new MIPS toolchain, SSP problem:
>
> /home/peko/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp_nonshared
> /home/peko/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp
>
>> arc | tar-1.28 | NOK | http://autobuild.buildroot.net/results/e9c5df490264a2d9ff5160187bda75431493d666/
>
> ../gnu/libgnu.a(quotearg.o): In function `quote':
> quotearg.c:(.text+0xdac): multiple definition of `quote'
> /home/buildroot/buildroot-test/instance-1/output/host/usr/arc-buildroot-linux-uclibc/sysroot/usr/lib/libacl.a(quote.o):/home/buildroot/buildroot-test/instance-1/output/build/acl-2.2.52/libmisc/quote.c:27: first defined here
>
> I don't think it's specific to ARC. Anyone to have a look ?
>
>> arc | trousers-0.3.13 | NOK | http://autobuild.buildroot.net/results/7009e334e51adce37353c5d4f618fb28678f6114/
>
> PIE problem, patch pending.
>
>> arm | webkitgtk24-2.4.9 | NOK | http://autobuild.buildroot.net/results/c660d29b0184daf7d16045b595e48d3c73ab521a/
>
> checking for GLES2/gl2.h... yes
> checking whether to use OpenGL ES 2 support... configure: error: Cannot enable OpenGL ES 2 support without EGL enabled.
>
> Gustavo ?
>
> Thomas
>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-25 9:10 ` Joris Lijssens
@ 2016-01-25 9:30 ` Joris Lijssens
0 siblings, 0 replies; 416+ messages in thread
From: Joris Lijssens @ 2016-01-25 9:30 UTC (permalink / raw)
To: buildroot
hey thomas,
used the wrong config file, sorry for that.
regards,
Joris
On 25 January 2016 at 10:10, Joris Lijssens <joris.lijssens@gmail.com>
wrote:
>
> http://autobuild.buildroot.net/results/2ef/2ef1ed958db8012224f9174334e9c58edace604a/
>
>
> On 25 January 2016 at 10:09, Thomas Petazzoni <
> thomas.petazzoni at free-electrons.com> wrote:
>
>> Joris,
>>
>> On Mon, 25 Jan 2016 10:06:25 +0100, Joris Lijssens wrote:
>>
>> > I had another look at the rabbitmq-c build issue this morning, but with
>> the
>> > latest buildroot version of this morning it builds just fine. Any idea
>> what
>> > has changed?
>>
>> Can you remind me which rabbitmq-c failure you are investigating ?
>>
>> Thanks,
>>
>> Thomas
>> --
>> Thomas Petazzoni, CTO, Free Electrons
>> Embedded Linux, Kernel and Android engineering
>> http://free-electrons.com
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160125/9b23afe1/attachment.html>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-25 9:09 ` Thomas Petazzoni
@ 2016-01-25 9:10 ` Joris Lijssens
2016-01-25 9:30 ` Joris Lijssens
0 siblings, 1 reply; 416+ messages in thread
From: Joris Lijssens @ 2016-01-25 9:10 UTC (permalink / raw)
To: buildroot
http://autobuild.buildroot.net/results/2ef/2ef1ed958db8012224f9174334e9c58edace604a/
On 25 January 2016 at 10:09, Thomas Petazzoni <
thomas.petazzoni@free-electrons.com> wrote:
> Joris,
>
> On Mon, 25 Jan 2016 10:06:25 +0100, Joris Lijssens wrote:
>
> > I had another look at the rabbitmq-c build issue this morning, but with
> the
> > latest buildroot version of this morning it builds just fine. Any idea
> what
> > has changed?
>
> Can you remind me which rabbitmq-c failure you are investigating ?
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160125/1e31e53f/attachment.html>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-25 9:06 ` Joris Lijssens
@ 2016-01-25 9:09 ` Thomas Petazzoni
2016-01-25 9:10 ` Joris Lijssens
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2016-01-25 9:09 UTC (permalink / raw)
To: buildroot
Joris,
On Mon, 25 Jan 2016 10:06:25 +0100, Joris Lijssens wrote:
> I had another look at the rabbitmq-c build issue this morning, but with the
> latest buildroot version of this morning it builds just fine. Any idea what
> has changed?
Can you remind me which rabbitmq-c failure you are investigating ?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-23 8:01 ` Thomas Petazzoni
@ 2016-01-25 9:06 ` Joris Lijssens
2016-01-25 9:09 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Joris Lijssens @ 2016-01-25 9:06 UTC (permalink / raw)
To: buildroot
Hello thomas,
I had another look at the rabbitmq-c build issue this morning, but with the
latest buildroot version of this morning it builds just fine. Any idea what
has changed?
regards,
Joris
On 23 January 2016 at 09:01, Thomas Petazzoni <
thomas.petazzoni@free-electrons.com> wrote:
> Frank,
>
> On Fri, 22 Jan 2016 20:05:01 -0500, Frank Hunleth wrote:
>
> > I received further advice from the Erlang mailing list. The summary is:
> >
> > 1. Upgrade to Erlang 18 (BR is currently using 17.5)
> > 2. Prefer the use of Erlang 18's native atomics implementation over
> > libatomic_ops.
> >
> > I verified that upgrading to Erlang 18 and not using libatomic_ops
> > works for all qemu_*_defconfigs (with Erlang enabled), the aarch64
> > autobuilder failure, and a couple other configs. It does not work with
> > sparc_v8 as recently found with Erlang 17.5. I also tested whether
> > Erlang 18's configure scripts would choose libatomic_ops if it were
> > present, and they do not. This was tedious, so I am quite open to
> > others repeating the tests (or telling me to do so) if this does not
> > sound right. As a result of this testing, I disabled the use of
> > libatomic_ops for Erlang as you will see in a subsequent patch set.
> >
> > Unfortunately, the upgrade to Erlang 18 was nontrivial due to a couple
> > major changes to the language and APIs. I had to bump the versions of
> > ejabberd and nearly all Erlang packages to fix this. While Erlang is
> > very important to me, I have never used the rebar infrastructure or
> > ejabberd. I verified that the new version of ejabberd compiles across
> > all qemu_*_defconfigs except the sparc_v8 one. I do not know if it
> > runs correctly, though. Johan - I cc'd you since I saw that you are
> > using ejabberd. Hopefully you can review too.
> >
> > The patch set will follow shortly.
>
> Thanks a lot for working on this. Upgrading to Erlang 18 definitely
> looks like a good thing.
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.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/20160125/baa12787/attachment.html>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-23 17:14 ` Ricardo Martincoski
@ 2016-01-23 20:48 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2016-01-23 20:48 UTC (permalink / raw)
To: buildroot
Ricardo,
On Sat, 23 Jan 2016 15:14:22 -0200, Ricardo Martincoski wrote:
> Maybe there is a solution that does not limit the version of patch, following
> the idea of symlinks or hardlinks.
> It still needs more tests, but it seems to work with patch 2.5.4.
> I created 2 hooks, one before patching to rename the file, and other after to
> rename it back.
>
> See example below. I used POST_EXTRACT instead of PRE_PATCH because some
> developer could use 'make package-extract', create a copy of the extracted
> directory, edit the needed files and then use diff to create the patch.
> This way hand-editing the patch would not be needed.
>
> Please let me know if you agree with this approach.
I think you can remove the post patch hook, i.e keep the file named
with the _, and simply adjust:
LIBSOIL_MAKEFILE = "../projects/makefile/alternate Makefile.txt"
to:
LIBSOIL_MAKEFILE = ../projects/makefile/alternate_Makefile.txt
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-23 16:07 ` Thomas De Schampheleire
@ 2016-01-23 17:14 ` Ricardo Martincoski
2016-01-23 20:48 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Ricardo Martincoski @ 2016-01-23 17:14 UTC (permalink / raw)
To: buildroot
Hello,
On Sat, Jan 23, 2016 at 02:07 PM, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote:
> On Jan 23, 2016 4:58 PM, "Thomas Petazzoni" <
> thomas.petazzoni at free-electrons.com> wrote:
>>
>> Hello,
>>
>> On Sat, 23 Jan 2016 13:16:00 -0200, Ricardo Martincoski wrote:
>>
>> > Just to be clear, removing the double quotes makes it work with
>> > patch 2.5.9 or later.
>> > Patch 2.5.4 can't handle spaces in filenames.
>> > (I tested using only the versions with tarballs available, that's the
> cause of
>> > the gap 2.5.9 -> 2.5.4, see http://ftp.gnu.org/gnu/patch/)
>>
>> RHEL4 uses patch 2.5.4
>> (http://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/).
>> RHEL4 was released January 2005
>>
>> RHEL5 also seems to be using patch 2.5.4
>> (http://ftp.redhat.com/pub/redhat/linux/enterprise/5Client/en/os/SRPMS/).
>> RHEL5 was released March 2007.
>>
>> It's only starting at RHEL6 that patch 2.6 starts to be used
>> (http://ftp.redhat.com/pub/redhat/linux/enterprise/6Client/en/os/SRPMS/).
>> RHEL6 was released November 2010.
>>
>> Thomas DS, you are one of our users relying on very old enterprise
>> distros. Are you still on RHEL 4/5 ?
>
> There are some of our users still on RHEL4 (hopefully not too much anymore)
> and RHEL5 (not negligible yet).
>
> That said, libsoil is not something we use, so if the problem is limited to
> that we're fine.
>
> /Thomas
Maybe there is a solution that does not limit the version of patch, following
the idea of symlinks or hardlinks.
It still needs more tests, but it seems to work with patch 2.5.4.
I created 2 hooks, one before patching to rename the file, and other after to
rename it back.
See example below. I used POST_EXTRACT instead of PRE_PATCH because some
developer could use 'make package-extract', create a copy of the extracted
directory, edit the needed files and then use diff to create the patch.
This way hand-editing the patch would not be needed.
Please let me know if you agree with this approach.
Regards,
Ricardo
diff --git package/libsoil/0001-fix-makefile.patch package/libsoil/0001-fix-makefile.patch
index 3b80048..310d264 100644
--- package/libsoil/0001-fix-makefile.patch
+++ package/libsoil/0001-fix-makefile.patch
@@ -5,9 +5,9 @@ http://anonscm.debian.org/cgit/pkg-games/libsoil.git/tree/debian/patches/linking
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
-diff -uNr "soil.org/projects/makefile/alternate Makefile.txt" "soil/projects/makefile/alternate Makefile.txt"
---- "soil.org/projects/makefile/alternate Makefile.txt" 2008-07-07 18:13:28.000000000 +0200
-+++ "soil/projects/makefile/alternate Makefile.txt" 2015-11-07 11:15:04.140106336 +0100
+diff -uNr soil.org/projects/makefile/alternate_Makefile.txt soil/projects/makefile/alternate_Makefile.txt
+--- soil.org/projects/makefile/alternate_Makefile.txt 2008-07-07 18:13:28.000000000 +0200
++++ soil/projects/makefile/alternate_Makefile.txt 2015-11-07 11:15:04.140106336 +0100
@@ -1,8 +1,8 @@
MAKE = make
-CC = gcc
diff --git package/libsoil/libsoil.mk package/libsoil/libsoil.mk
index eb8c2ce..1aca345 100644
--- package/libsoil/libsoil.mk
+++ package/libsoil/libsoil.mk
@@ -18,6 +18,18 @@ define LIBSOIL_EXTRACT_CMDS
mv $(@D)/Simple\ OpenGL\ Image\ Library/* $(@D)
endef
+define REMOVE_SPACE_FROM_FILENAME
+ cd $(@D)/projects/makefile/ && \
+ mv alternate\ Makefile.txt alternate_Makefile.txt
+endef
+LIBSOIL_POST_EXTRACT_HOOKS += REMOVE_SPACE_FROM_FILENAME
+
+define ADD_SPACE_BACK_TO_FILENAME
+ cd $(@D)/projects/makefile/ && \
+ mv alternate_Makefile.txt alternate\ Makefile.txt
+endef
+LIBSOIL_POST_PATCH_HOOKS += ADD_SPACE_BACK_TO_FILENAME
+
define LIBSOIL_BUILD_CMDS
$(MAKE) $(TARGET_CONFIGURE_OPTS) -f $(LIBSOIL_MAKEFILE) \
-C $(@D)/src
^ permalink raw reply related [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-23 15:58 ` Thomas Petazzoni
@ 2016-01-23 16:07 ` Thomas De Schampheleire
2016-01-23 17:14 ` Ricardo Martincoski
0 siblings, 1 reply; 416+ messages in thread
From: Thomas De Schampheleire @ 2016-01-23 16:07 UTC (permalink / raw)
To: buildroot
On Jan 23, 2016 4:58 PM, "Thomas Petazzoni" <
thomas.petazzoni@free-electrons.com> wrote:
>
> Hello,
>
> On Sat, 23 Jan 2016 13:16:00 -0200, Ricardo Martincoski wrote:
>
> > Just to be clear, removing the double quotes makes it work with
> > patch 2.5.9 or later.
> > Patch 2.5.4 can't handle spaces in filenames.
> > (I tested using only the versions with tarballs available, that's the
cause of
> > the gap 2.5.9 -> 2.5.4, see http://ftp.gnu.org/gnu/patch/)
>
> RHEL4 uses patch 2.5.4
> (http://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/).
> RHEL4 was released January 2005
>
> RHEL5 also seems to be using patch 2.5.4
> (http://ftp.redhat.com/pub/redhat/linux/enterprise/5Client/en/os/SRPMS/).
> RHEL5 was released March 2007.
>
> It's only starting at RHEL6 that patch 2.6 starts to be used
> (http://ftp.redhat.com/pub/redhat/linux/enterprise/6Client/en/os/SRPMS/).
> RHEL6 was released November 2010.
>
> Thomas DS, you are one of our users relying on very old enterprise
> distros. Are you still on RHEL 4/5 ?
There are some of our users still on RHEL4 (hopefully not too much anymore)
and RHEL5 (not negligible yet).
That said, libsoil is not something we use, so if the problem is limited to
that we're fine.
/Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160123/0bcc064b/attachment.html>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-23 15:16 ` Ricardo Martincoski
@ 2016-01-23 15:58 ` Thomas Petazzoni
2016-01-23 16:07 ` Thomas De Schampheleire
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2016-01-23 15:58 UTC (permalink / raw)
To: buildroot
Hello,
On Sat, 23 Jan 2016 13:16:00 -0200, Ricardo Martincoski wrote:
> Just to be clear, removing the double quotes makes it work with
> patch 2.5.9 or later.
> Patch 2.5.4 can't handle spaces in filenames.
> (I tested using only the versions with tarballs available, that's the cause of
> the gap 2.5.9 -> 2.5.4, see http://ftp.gnu.org/gnu/patch/)
RHEL4 uses patch 2.5.4
(http://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/).
RHEL4 was released January 2005
RHEL5 also seems to be using patch 2.5.4
(http://ftp.redhat.com/pub/redhat/linux/enterprise/5Client/en/os/SRPMS/).
RHEL5 was released March 2007.
It's only starting at RHEL6 that patch 2.6 starts to be used
(http://ftp.redhat.com/pub/redhat/linux/enterprise/6Client/en/os/SRPMS/).
RHEL6 was released November 2010.
Thomas DS, you are one of our users relying on very old enterprise
distros. Are you still on RHEL 4/5 ?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-23 14:42 ` Thomas Petazzoni
@ 2016-01-23 15:16 ` Ricardo Martincoski
2016-01-23 15:58 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Ricardo Martincoski @ 2016-01-23 15:16 UTC (permalink / raw)
To: buildroot
On Sat, Jan 23, 2016 at 12:42 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> On Sat, 23 Jan 2016 15:26:13 +0100, Thomas De Schampheleire wrote:
>
>> I guess a hard link would work here, then. Care to try?
Between the 2 e-mails I tested using hard link.
Using patch v2.6, the hardlinks get unlinked too.
patch v2.7.1 has --follow-symlinks but its use is discouraged in the man page.
>
> But why would we do that? If I understood Ricardo's e-mail, a simple
> change to the patch (remove the double quotes) would make it just work.
>
> So why are we looking for a complicated solution here ?
Just to be clear, removing the double quotes makes it work with
patch 2.5.9 or later.
Patch 2.5.4 can't handle spaces in filenames.
(I tested using only the versions with tarballs available, that's the cause of
the gap 2.5.9 -> 2.5.4, see http://ftp.gnu.org/gnu/patch/)
I am sending the first version of the patch series.
Probably it will need some rewording, since it's my first patch to the manual.
Regards,
Ricardo
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-23 14:26 ` Thomas De Schampheleire
@ 2016-01-23 14:42 ` Thomas Petazzoni
2016-01-23 15:16 ` Ricardo Martincoski
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2016-01-23 14:42 UTC (permalink / raw)
To: buildroot
Thomas,
On Sat, 23 Jan 2016 15:26:13 +0100, Thomas De Schampheleire wrote:
> I guess a hard link would work here, then. Care to try?
But why would we do that? If I understood Ricardo's e-mail, a simple
change to the patch (remove the double quotes) would make it just work.
So why are we looking for a complicated solution here ?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-23 13:56 ` Ricardo Martincoski
@ 2016-01-23 14:26 ` Thomas De Schampheleire
2016-01-23 14:42 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Thomas De Schampheleire @ 2016-01-23 14:26 UTC (permalink / raw)
To: buildroot
On Jan 23, 2016 2:56 PM, "Ricardo Martincoski" <
ricardo.martincoski@gmail.com> wrote:
>
> On Sat, Jan 23, 2016 at 11:03 AM, Thomas De Schampheleire <
patrickdepinguin@gmail.com> wrote:
>
> > from: Thomas De Schampheleire <patrickdepinguin@gmail.com>
> > date: Sat, Jan 23 02:03 PM +01:00 2016
> > to: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > cc: buildroot at busybox.net, berndkuhls at hotmail.com, Ricardo Martincoski <
ricardo.martincoski@gmail.com>
> > subject: Re: [Buildroot] Analysis of build failures
> >
> > On Jan 23, 2016 1:56 PM, "Thomas Petazzoni" <
> > thomas.petazzoni at free-electrons.com> wrote:
> >>
> >> Ricardo,
> >>
> >> First of all, thanks a lot for this great investigation! Definitely
> >> very useful!
> >>
> >> On Sat, 23 Jan 2016 10:33:20 -0200, Ricardo Martincoski wrote:
> >>
> >> > This error occurs when applying a patch that changes a file with
spaces
> >> > in the name.
> >> > When applying a patch generated by diff v3.3 (the newest version
[2]),
> >> > the tool patch needs to be version 2.7 or any later to ensure any
patch
> >> > will be applied.
> >> > libsoil is the only package today that patches a file with space in
the
> >> > name.
> >>
> >> Aah, this explains the problem. My build server has patch version 2.6.
> >>
> >> > Solution 1: Add patch >= 2.7 as prerequisite to the manual (patch
v2.7
> >> > is from 2012 [2]).
> >> > http://patchwork.ozlabs.org/patch/572097/
> >>
> >> Not really acceptable, as we want to support old distros. Especially
> >> when this is really needed only for one package.
>
> Ok. I changed the state of this patch to Rejected.
> >>
> >> > Solution 2: Add patch >= 2.5.9 as prerequisite to the manual (patch
> >> > v2.5.9 is from 2004 [2]), address on the manual
> >> > 'Format and licensing of the package patches' the workaround needed
when
> >> > a file changed by a patch has spaces in its name, apply the
workaround
> >> > to libsoil (either use diff 3.2 or manually remove the quotes from
the
> >> > filename inside the patch).
> >>
> >> Seems like the best solution. Can you cook such patches (both to the
> >> manual, and the change to libsoil) ?
>
> Yes. No problem.
> >>
> >> BTW, why would we need to require patch >= 2.5.9 ? Just to support file
> >> name with spaces ?
>
> Yes.
> >>
> >> > Solution 3: Create host-patch. Almost every package would depend on
it.
> >> > I don't known if it would be feasible since gcc has patches.
> >>
> >> We only build gcc for the target, so we could certainly build
> >> host-patch. However, this really seems overkill to solve the problem of
> >> just one package, for which there is a separate solution (your solution
> >> 2).
> >>
> >> Thanks again for your investigation. I'm looking forward to seeing your
> >> patches implementing solution (2).
> >
> > What happens if you first make a symlink alternate_makefile ->
'alternate
> > makefile' and apply the patch on the link? Will patch modify the linked
> > file?
>
> I tested using patch 2.6.
> Unfortunately patch breaks the symlink, so I end up with
alternate_makefile
> patched but 'alternate makefile' remains unpatched.
I guess a hard link would work here, then. Care to try?
Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160123/b3b10ee8/attachment.html>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-23 13:03 ` Thomas De Schampheleire
@ 2016-01-23 13:56 ` Ricardo Martincoski
2016-01-23 14:26 ` Thomas De Schampheleire
0 siblings, 1 reply; 416+ messages in thread
From: Ricardo Martincoski @ 2016-01-23 13:56 UTC (permalink / raw)
To: buildroot
On Sat, Jan 23, 2016 at 11:03 AM, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote:
> from: Thomas De Schampheleire <patrickdepinguin@gmail.com>
> date: Sat, Jan 23 02:03 PM +01:00 2016
> to: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> cc: buildroot at busybox.net, berndkuhls at hotmail.com, Ricardo Martincoski <ricardo.martincoski@gmail.com>
> subject: Re: [Buildroot] Analysis of build failures
>
> On Jan 23, 2016 1:56 PM, "Thomas Petazzoni" <
> thomas.petazzoni at free-electrons.com> wrote:
>>
>> Ricardo,
>>
>> First of all, thanks a lot for this great investigation! Definitely
>> very useful!
>>
>> On Sat, 23 Jan 2016 10:33:20 -0200, Ricardo Martincoski wrote:
>>
>> > This error occurs when applying a patch that changes a file with spaces
>> > in the name.
>> > When applying a patch generated by diff v3.3 (the newest version [2]),
>> > the tool patch needs to be version 2.7 or any later to ensure any patch
>> > will be applied.
>> > libsoil is the only package today that patches a file with space in the
>> > name.
>>
>> Aah, this explains the problem. My build server has patch version 2.6.
>>
>> > Solution 1: Add patch >= 2.7 as prerequisite to the manual (patch v2.7
>> > is from 2012 [2]).
>> > http://patchwork.ozlabs.org/patch/572097/
>>
>> Not really acceptable, as we want to support old distros. Especially
>> when this is really needed only for one package.
Ok. I changed the state of this patch to Rejected.
>>
>> > Solution 2: Add patch >= 2.5.9 as prerequisite to the manual (patch
>> > v2.5.9 is from 2004 [2]), address on the manual
>> > 'Format and licensing of the package patches' the workaround needed when
>> > a file changed by a patch has spaces in its name, apply the workaround
>> > to libsoil (either use diff 3.2 or manually remove the quotes from the
>> > filename inside the patch).
>>
>> Seems like the best solution. Can you cook such patches (both to the
>> manual, and the change to libsoil) ?
Yes. No problem.
>>
>> BTW, why would we need to require patch >= 2.5.9 ? Just to support file
>> name with spaces ?
Yes.
>>
>> > Solution 3: Create host-patch. Almost every package would depend on it.
>> > I don't known if it would be feasible since gcc has patches.
>>
>> We only build gcc for the target, so we could certainly build
>> host-patch. However, this really seems overkill to solve the problem of
>> just one package, for which there is a separate solution (your solution
>> 2).
>>
>> Thanks again for your investigation. I'm looking forward to seeing your
>> patches implementing solution (2).
>
> What happens if you first make a symlink alternate_makefile -> 'alternate
> makefile' and apply the patch on the link? Will patch modify the linked
> file?
I tested using patch 2.6.
Unfortunately patch breaks the symlink, so I end up with alternate_makefile
patched but 'alternate makefile' remains unpatched.
>
> If so it could be an alternative solution.
>
> /Thomas
Regards,
Ricardo
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-23 12:55 ` Thomas Petazzoni
@ 2016-01-23 13:03 ` Thomas De Schampheleire
2016-01-23 13:56 ` Ricardo Martincoski
0 siblings, 1 reply; 416+ messages in thread
From: Thomas De Schampheleire @ 2016-01-23 13:03 UTC (permalink / raw)
To: buildroot
On Jan 23, 2016 1:56 PM, "Thomas Petazzoni" <
thomas.petazzoni@free-electrons.com> wrote:
>
> Ricardo,
>
> First of all, thanks a lot for this great investigation! Definitely
> very useful!
>
> On Sat, 23 Jan 2016 10:33:20 -0200, Ricardo Martincoski wrote:
>
> > This error occurs when applying a patch that changes a file with spaces
> > in the name.
> > When applying a patch generated by diff v3.3 (the newest version [2]),
> > the tool patch needs to be version 2.7 or any later to ensure any patch
> > will be applied.
> > libsoil is the only package today that patches a file with space in the
> > name.
>
> Aah, this explains the problem. My build server has patch version 2.6.
>
> > Solution 1: Add patch >= 2.7 as prerequisite to the manual (patch v2.7
> > is from 2012 [2]).
> > http://patchwork.ozlabs.org/patch/572097/
>
> Not really acceptable, as we want to support old distros. Especially
> when this is really needed only for one package.
>
> > Solution 2: Add patch >= 2.5.9 as prerequisite to the manual (patch
> > v2.5.9 is from 2004 [2]), address on the manual
> > 'Format and licensing of the package patches' the workaround needed when
> > a file changed by a patch has spaces in its name, apply the workaround
> > to libsoil (either use diff 3.2 or manually remove the quotes from the
> > filename inside the patch).
>
> Seems like the best solution. Can you cook such patches (both to the
> manual, and the change to libsoil) ?
>
> BTW, why would we need to require patch >= 2.5.9 ? Just to support file
> name with spaces ?
>
> > Solution 3: Create host-patch. Almost every package would depend on it.
> > I don't known if it would be feasible since gcc has patches.
>
> We only build gcc for the target, so we could certainly build
> host-patch. However, this really seems overkill to solve the problem of
> just one package, for which there is a separate solution (your solution
> 2).
>
> Thanks again for your investigation. I'm looking forward to seeing your
> patches implementing solution (2).
What happens if you first make a symlink alternate_makefile -> 'alternate
makefile' and apply the patch on the link? Will patch modify the linked
file?
If so it could be an alternative solution.
/Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160123/8eb476c6/attachment.html>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-23 12:33 Ricardo Martincoski
@ 2016-01-23 12:55 ` Thomas Petazzoni
2016-01-23 13:03 ` Thomas De Schampheleire
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2016-01-23 12:55 UTC (permalink / raw)
To: buildroot
Ricardo,
First of all, thanks a lot for this great investigation! Definitely
very useful!
On Sat, 23 Jan 2016 10:33:20 -0200, Ricardo Martincoski wrote:
> This error occurs when applying a patch that changes a file with spaces
> in the name.
> When applying a patch generated by diff v3.3 (the newest version [2]),
> the tool patch needs to be version 2.7 or any later to ensure any patch
> will be applied.
> libsoil is the only package today that patches a file with space in the
> name.
Aah, this explains the problem. My build server has patch version 2.6.
> Solution 1: Add patch >= 2.7 as prerequisite to the manual (patch v2.7
> is from 2012 [2]).
> http://patchwork.ozlabs.org/patch/572097/
Not really acceptable, as we want to support old distros. Especially
when this is really needed only for one package.
> Solution 2: Add patch >= 2.5.9 as prerequisite to the manual (patch
> v2.5.9 is from 2004 [2]), address on the manual
> 'Format and licensing of the package patches' the workaround needed when
> a file changed by a patch has spaces in its name, apply the workaround
> to libsoil (either use diff 3.2 or manually remove the quotes from the
> filename inside the patch).
Seems like the best solution. Can you cook such patches (both to the
manual, and the change to libsoil) ?
BTW, why would we need to require patch >= 2.5.9 ? Just to support file
name with spaces ?
> Solution 3: Create host-patch. Almost every package would depend on it.
> I don't known if it would be feasible since gcc has patches.
We only build gcc for the target, so we could certainly build
host-patch. However, this really seems overkill to solve the problem of
just one package, for which there is a separate solution (your solution
2).
Thanks again for your investigation. I'm looking forward to seeing your
patches implementing solution (2).
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
@ 2016-01-23 12:33 Ricardo Martincoski
2016-01-23 12:55 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Ricardo Martincoski @ 2016-01-23 12:33 UTC (permalink / raw)
To: buildroot
On Fri, 22 Jan 2016 10:29:57 +0100, Thomas Petazzoni wrote:
>> i686 | libsoil-20080707 | NOK | http://autobuild.buildroot.net/results/8ff91ab8e52000eb34dd8f662520cf1b31490cf5/
>> x86_64 | libsoil-20080707 | NOK | http://autobuild.buildroot.net/results/ea77d6b23aca0cb1cf527e6c16ddf5eba957a69c/
>
> These are really weird. The patch doesn't apply when the build takes
> place on my build server, but it does apply when I test things locally
> on my machine. A difference in the version of patch ?
This error occurs when applying a patch that changes a file with spaces
in the name.
When applying a patch generated by diff v3.3 (the newest version [2]),
the tool patch needs to be version 2.7 or any later to ensure any patch
will be applied.
libsoil is the only package today that patches a file with space in the
name.
Using patch v2.6:
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 23.
2 out of 2 hunks FAILED -- saving rejects to file 'projects/makefile/alternate Makefile.txt".rej'
Patch failed! Please fix 0001-fix-makefile.patch!
Using patch v2.6.1:
can't find file to patch at input line 11
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Various makefile fixes to allow cross compilation
|
|Partly ported from
|http://anonscm.debian.org/cgit/pkg-games/libsoil.git/tree/debian/patches/linking_correctly.patch
|
|Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
|
|diff -uNr "soil.org/projects/makefile/alternate Makefile.txt" "soil/projects/makefile/alternate Makefile.txt"
|--- "soil.org/projects/makefile/alternate Makefile.txt" 2008-07-07 18:13:28.000000000 +0200
|+++ "soil/projects/makefile/alternate Makefile.txt" 2015-11-07 11:15:04.140106336 +0100
--------------------------
No file to patch. Skipping patch.
2 out of 2 hunks ignored
Patch failed! Please fix 0001-fix-makefile.patch!
The output of "diff -purN" when there are spaces in the name of a
changed file depends on the tool version:
diff <= v3.2 does not add double quotes to filenames
diff >= v3.3 adds double quotes to filenames
The tool 'patch' can handle patches with spaces in the name of a
changed file depending on the tool version:
patch >= 2.5.9 can handle unquoted filenames
patch >= 2.7 can handle both quoted and unquoted filenames
Solution 1: Add patch >= 2.7 as prerequisite to the manual (patch v2.7
is from 2012 [2]).
http://patchwork.ozlabs.org/patch/572097/
Solution 2: Add patch >= 2.5.9 as prerequisite to the manual (patch
v2.5.9 is from 2004 [2]), address on the manual
'Format and licensing of the package patches' the workaround needed when
a file changed by a patch has spaces in its name, apply the workaround
to libsoil (either use diff 3.2 or manually remove the quotes from the
filename inside the patch).
Solution 3: Create host-patch. Almost every package would depend on it.
I don't known if it would be feasible since gcc has patches.
[1] http://ftp.gnu.org/gnu/diffutils/
[2] http://ftp.gnu.org/gnu/patch/
I didn't investigate other formats of patch, e.g. git patch.
Regards,
Ricardo
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-22 9:29 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (4 preceding siblings ...)
2016-01-23 1:07 ` Frank Hunleth
@ 2016-01-23 10:55 ` Samuel Martin
2016-01-26 12:02 ` Joao Pinto
` (3 subsequent siblings)
9 siblings, 0 replies; 416+ messages in thread
From: Samuel Martin @ 2016-01-23 10:55 UTC (permalink / raw)
To: buildroot
Hi Thomas, all,
On Fri, Jan 22, 2016 at 10:29 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
[...]
>> arm | lttng-tools-2.7.1 | NOK | http://autobuild.buildroot.net/results/b48bc7ad4bede4d16c079da0ae1121e6796a0e8d/
>> arm | lttng-tools-2.7.1 | NOK | http://autobuild.buildroot.net/results/25dcb19c3dd32e50990f9b45053d71ea18746a80/
>> arm | lttng-tools-2.7.1 | NOK | http://autobuild.buildroot.net/results/a3f93498811491d37ba13d024e33e68a8bc7ba18/
>
> checking for dlopen in -lc... no
> configure: error: Cannot find dlopen in libdl nor libc. Use LDFLAGS=-Ldir to specify their location.
>
> In a static linking only situation.
>
> Samuel, can you have a look ? Most likely we should simply disable
> lttng-tools for static only scenarios.
Indeed.
Patches just sent ;-)
http://patchwork.ozlabs.org/patch/572083/
http://patchwork.ozlabs.org/patch/572084/
Regards,
--
Samuel
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-23 8:32 ` Thomas Petazzoni
@ 2016-01-23 10:47 ` Romain Naour
0 siblings, 0 replies; 416+ messages in thread
From: Romain Naour @ 2016-01-23 10:47 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Le 23/01/2016 09:32, Thomas Petazzoni a ?crit :
> Hello,
>
> On Sat, 23 Jan 2016 00:19:36 +0100, Romain Naour wrote:
>
>>> Romain ? This is host-efl, maybe we need to disable Lua support or
>>> something ?
>>
>> It's a lua 5.1 vs 5.2 and 5.3 issue.
>>
>> It's a complete mess because there is an uptream patch [1] that try to fixes the
>> build issue, but not completely.
>>
>> The build fail with the following error due to compatibility mode in lua
>> (LUA_COMPAT_ALL and LUA_COMPAT_5_1):
>>
>> lib/evas/.libs/libevas.so: undefined reference to `luaL_openlib'
>> collect2: error: ld returned 1 exit status
>>
>> Also the patch break the build for lua 5.1...
>> So, I think it's safe to add a dependency on lua 5.1 and report the problem
>> upstream.
>
> So you would make the *target* EFL package depend on lua 5.1, so that
> the *host* EFL package also gets built against the host Lua 5.1 ?
Yes.
I didn't have the issue during the EFL bump since Lua 5.1 was the default choice
in Buildroot until recently.
> I guess there is no way of disabling Lua support ? :-)
No indeed, we have the choice between old lua and luajit.
>
> So, yes, in the mean time, please add the dependency, and report the
> problem upstream. BTW, did you test the --enable-lua-old option that
> is mentioned in
> https://git.enlightenment.org/core/efl.git/commit/?id=6124d0733657e425001ce51f526aea3bb8dc54e7,
> which you pointed ?
I have a small series (not yet submitted) enabling luajit :)
>
>>>> microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/d35f6ee7643a695af7db3739ff480d25b99ee051/
>>>> microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/09f4a89e463b6ccbca01cce1d38eb849c17ed6e1/
>>>
>>> The documentation issue. Romain, you looked into this a while ago, why
>>> does it pop up again on Microblaze specifically ?
>>
>> I think this build failure is here since we SED into the Makefile to remove the
>> documentation.
>
> I don't understand. Isn't the SED precisely here to prevent the
> documentation from being built ?
I didn't investigate further but it seems we remove something in the Makefile
with the SED command that break the build.
>
>> But I gave up on the patch for upstream...
>
> What was the feedback ?
https://sourceware.org/ml/gdb-patches/2015-09/msg00579.html
I don't remember if I tried with this proposal:
https://sourceware.org/ml/gdb-patches/2015-09/msg00572.html
>
>>> Maybe we can switch to the mainline gdb for Microblaze ?
>>
>> Why not. The latest gdb version was 7.5.1 when gdb for Microblaze was added to
>> Buildroot. Now we have at least 7.7.x.
>
> I think we should try to use the mainline gdb. We have a Microblaze
> Qemu configuration, so we can at least do some basic testing here.
>
>>>
>>>> nios2 | imagemagick-6.9.2-10 | NOK | http://autobuild.buildroot.net/results/0bf3a2a284b7d4712ab1530562d3b8164fc75e88/
>>>
>>> The usual:
>>>
>>> assertion fail elf32-nios2.c:1038
>>>
>>> This is being fixed at
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=19405. In the mean
>>> time, we could disable on NIOS II maybe ?
>>
>> Yes maybe.
>
> Can you submit a patch ?
>
>>>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/183df75a853c3b0e2617c9219a356c5531aa523d/
>>>
>>> Will be fixed once we bump to binutils 2.26. Romain, maybe we should
>>> disable libcap-ng in the mean time ?
>>
>> binutils 2.26 should be released in a few days, hopefully.
>
> Ok, good.
>
>>>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/aa1492777c5f60ab45921618f64910ca4d048e5f/
>>>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/a74810f0fce398c41fef11b8e2b8e1a52ffdb46a/
>>>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/cb70d195cf9b9b5ae09b83a40ef767cc8f699a9c/
>>>
>>> Toolchain issues. Being fixed in upstream gcc, but we should disable
>>> with external NIOS2 toolchain anyway.
>>>
>>> Romain ?
>>
>> This patch should be fine:
>> http://patchwork.ozlabs.org/patch/561414/
>
> Thanks. The only thing that bothers me a bit is that we will likely
> forget to remove all those "depends on BR2_nios2". But I guess we don't
> really have the choice.
Indeed...
Also, we should disable gcc 4.9.x and binutils 2.25.x for niosII for the
internal toolchain.
I'll send a small series doing that.
Best regards,
Romain
>
> Thanks,
>
> Thomas
>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-22 23:19 ` Romain Naour
@ 2016-01-23 8:32 ` Thomas Petazzoni
2016-01-23 10:47 ` Romain Naour
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2016-01-23 8:32 UTC (permalink / raw)
To: buildroot
Hello,
On Sat, 23 Jan 2016 00:19:36 +0100, Romain Naour wrote:
> > Romain ? This is host-efl, maybe we need to disable Lua support or
> > something ?
>
> It's a lua 5.1 vs 5.2 and 5.3 issue.
>
> It's a complete mess because there is an uptream patch [1] that try to fixes the
> build issue, but not completely.
>
> The build fail with the following error due to compatibility mode in lua
> (LUA_COMPAT_ALL and LUA_COMPAT_5_1):
>
> lib/evas/.libs/libevas.so: undefined reference to `luaL_openlib'
> collect2: error: ld returned 1 exit status
>
> Also the patch break the build for lua 5.1...
> So, I think it's safe to add a dependency on lua 5.1 and report the problem
> upstream.
So you would make the *target* EFL package depend on lua 5.1, so that
the *host* EFL package also gets built against the host Lua 5.1 ?
I guess there is no way of disabling Lua support ? :-)
So, yes, in the mean time, please add the dependency, and report the
problem upstream. BTW, did you test the --enable-lua-old option that
is mentioned in
https://git.enlightenment.org/core/efl.git/commit/?id=6124d0733657e425001ce51f526aea3bb8dc54e7,
which you pointed ?
> >> microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/d35f6ee7643a695af7db3739ff480d25b99ee051/
> >> microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/09f4a89e463b6ccbca01cce1d38eb849c17ed6e1/
> >
> > The documentation issue. Romain, you looked into this a while ago, why
> > does it pop up again on Microblaze specifically ?
>
> I think this build failure is here since we SED into the Makefile to remove the
> documentation.
I don't understand. Isn't the SED precisely here to prevent the
documentation from being built ?
> But I gave up on the patch for upstream...
What was the feedback ?
> > Maybe we can switch to the mainline gdb for Microblaze ?
>
> Why not. The latest gdb version was 7.5.1 when gdb for Microblaze was added to
> Buildroot. Now we have at least 7.7.x.
I think we should try to use the mainline gdb. We have a Microblaze
Qemu configuration, so we can at least do some basic testing here.
> >
> >> nios2 | imagemagick-6.9.2-10 | NOK | http://autobuild.buildroot.net/results/0bf3a2a284b7d4712ab1530562d3b8164fc75e88/
> >
> > The usual:
> >
> > assertion fail elf32-nios2.c:1038
> >
> > This is being fixed at
> > https://sourceware.org/bugzilla/show_bug.cgi?id=19405. In the mean
> > time, we could disable on NIOS II maybe ?
>
> Yes maybe.
Can you submit a patch ?
> >> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/183df75a853c3b0e2617c9219a356c5531aa523d/
> >
> > Will be fixed once we bump to binutils 2.26. Romain, maybe we should
> > disable libcap-ng in the mean time ?
>
> binutils 2.26 should be released in a few days, hopefully.
Ok, good.
> >> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/aa1492777c5f60ab45921618f64910ca4d048e5f/
> >> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/a74810f0fce398c41fef11b8e2b8e1a52ffdb46a/
> >> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/cb70d195cf9b9b5ae09b83a40ef767cc8f699a9c/
> >
> > Toolchain issues. Being fixed in upstream gcc, but we should disable
> > with external NIOS2 toolchain anyway.
> >
> > Romain ?
>
> This patch should be fine:
> http://patchwork.ozlabs.org/patch/561414/
Thanks. The only thing that bothers me a bit is that we will likely
forget to remove all those "depends on BR2_nios2". But I guess we don't
really have the choice.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-23 1:05 ` Frank Hunleth
@ 2016-01-23 8:01 ` Thomas Petazzoni
2016-01-25 9:06 ` Joris Lijssens
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2016-01-23 8:01 UTC (permalink / raw)
To: buildroot
Frank,
On Fri, 22 Jan 2016 20:05:01 -0500, Frank Hunleth wrote:
> I received further advice from the Erlang mailing list. The summary is:
>
> 1. Upgrade to Erlang 18 (BR is currently using 17.5)
> 2. Prefer the use of Erlang 18's native atomics implementation over
> libatomic_ops.
>
> I verified that upgrading to Erlang 18 and not using libatomic_ops
> works for all qemu_*_defconfigs (with Erlang enabled), the aarch64
> autobuilder failure, and a couple other configs. It does not work with
> sparc_v8 as recently found with Erlang 17.5. I also tested whether
> Erlang 18's configure scripts would choose libatomic_ops if it were
> present, and they do not. This was tedious, so I am quite open to
> others repeating the tests (or telling me to do so) if this does not
> sound right. As a result of this testing, I disabled the use of
> libatomic_ops for Erlang as you will see in a subsequent patch set.
>
> Unfortunately, the upgrade to Erlang 18 was nontrivial due to a couple
> major changes to the language and APIs. I had to bump the versions of
> ejabberd and nearly all Erlang packages to fix this. While Erlang is
> very important to me, I have never used the rebar infrastructure or
> ejabberd. I verified that the new version of ejabberd compiles across
> all qemu_*_defconfigs except the sparc_v8 one. I do not know if it
> runs correctly, though. Johan - I cc'd you since I saw that you are
> using ejabberd. Hopefully you can review too.
>
> The patch set will follow shortly.
Thanks a lot for working on this. Upgrading to Erlang 18 definitely
looks like a good thing.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-22 9:29 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (3 preceding siblings ...)
2016-01-22 23:19 ` Romain Naour
@ 2016-01-23 1:07 ` Frank Hunleth
2016-01-23 10:55 ` Samuel Martin
` (4 subsequent siblings)
9 siblings, 0 replies; 416+ messages in thread
From: Frank Hunleth @ 2016-01-23 1:07 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Fri, Jan 22, 2016 at 4:29 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>> sparc | erlang-17.5 | NOK | http://autobuild.buildroot.net/results/20cd87c6a05c91ee223b813040d9d10fa923b174/
>
> libatomic_ops not usable. Probably need to disable erlang on Sparc and
> be done with it?
The qemu_sparc64_sun4u_defconfig with Erlang enabled works so I think
that it is just sparc_v8. I saw several comments and Waldemar's patch
concerning atomic_ops support on sparc. I'll hold off sending a patch
for this issue unless directed otherwise.
>
>> x86_64 | erlang-17.5 | NOK | http://autobuild.buildroot.net/results/e4ab3fa4a121f7d7edb0263f02aac2ee836905a7/
>
> sys/common/erl_poll.c: In function 'update_pollset':
> sys/common/erl_poll.h:132:5: error: '__uint32_t' undeclared (first use in this function)
> ((__uint32_t) (EV))
> ^
> sys/common/erl_poll.c:1150:24: note: in expansion of macro 'ERTS_POLL_EV_E2N'
> epe_templ.events = ERTS_POLL_EV_E2N(ps->fds_status[fd].events);
> ^
> sys/common/erl_poll.h:132:5: note: each undeclared identifier is reported only once for each function it appears in
> ((__uint32_t) (EV))
> ^
> sys/common/erl_poll.c:1150:24: note: in expansion of macro 'ERTS_POLL_EV_E2N'
> epe_templ.events = ERTS_POLL_EV_E2N(ps->fds_status[fd].events);
> ^
>
> Musl build issue. Frank, can you have a look at this one ?
Yes. Hopefully there's a patch in Alpine Linux that addresses this.
I'll take a look after I get the other Erlang updates out of the way.
Frank
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-17 16:33 ` Frank Hunleth
@ 2016-01-23 1:05 ` Frank Hunleth
2016-01-23 8:01 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Frank Hunleth @ 2016-01-23 1:05 UTC (permalink / raw)
To: buildroot
Hi Thomas and Johan,
On Sun, Jan 17, 2016 at 11:33 AM, Frank Hunleth
<fhunleth@troodon-software.com> wrote:
> Hi Thomas,
>
> On Sun, Jan 17, 2016 at 6:23 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Hello,
>>
>> On Sat, 16 Jan 2016 20:42:55 -0500, Frank Hunleth wrote:
>>
>>> > Frank, can you investigate why it builds on x86_64 but not on aarch64 ?
>>>
>>> I looked into this a little. My suspicion is that the atomic intrinsic
>>> macros in the Erlang code have not been ported to aarch64, but I'm
>>> having trouble following the code. I've inquired on the Erlang mailing
>>> list and will report back.
>
> It turns out that other people have gotten Erlang to work on aarch64
> without libatomic_ops installed. That doesn't work for Buildroot since
> other programs could depend on libatomic_ops. I've filed a bug against
> Erlang to track this at http://bugs.erlang.org/browse/ERL-78.
> Specifying '--disable-native-ethr-impls' to ./configure seems to
> workaround the issue, but I don't know if it has other consequences.
> Hopefully the Erlang maintainers will get to this sooner rather than
> later, but they're a pretty busy group.
I received further advice from the Erlang mailing list. The summary is:
1. Upgrade to Erlang 18 (BR is currently using 17.5)
2. Prefer the use of Erlang 18's native atomics implementation over
libatomic_ops.
I verified that upgrading to Erlang 18 and not using libatomic_ops
works for all qemu_*_defconfigs (with Erlang enabled), the aarch64
autobuilder failure, and a couple other configs. It does not work with
sparc_v8 as recently found with Erlang 17.5. I also tested whether
Erlang 18's configure scripts would choose libatomic_ops if it were
present, and they do not. This was tedious, so I am quite open to
others repeating the tests (or telling me to do so) if this does not
sound right. As a result of this testing, I disabled the use of
libatomic_ops for Erlang as you will see in a subsequent patch set.
Unfortunately, the upgrade to Erlang 18 was nontrivial due to a couple
major changes to the language and APIs. I had to bump the versions of
ejabberd and nearly all Erlang packages to fix this. While Erlang is
very important to me, I have never used the rebar infrastructure or
ejabberd. I verified that the new version of ejabberd compiles across
all qemu_*_defconfigs except the sparc_v8 one. I do not know if it
runs correctly, though. Johan - I cc'd you since I saw that you are
using ejabberd. Hopefully you can review too.
The patch set will follow shortly.
Frank
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-22 9:29 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (2 preceding siblings ...)
2016-01-22 18:38 ` Waldemar Brodkorb
@ 2016-01-22 23:19 ` Romain Naour
2016-01-23 8:32 ` Thomas Petazzoni
2016-01-23 1:07 ` Frank Hunleth
` (5 subsequent siblings)
9 siblings, 1 reply; 416+ messages in thread
From: Romain Naour @ 2016-01-22 23:19 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Le 22/01/2016 10:29, Thomas Petazzoni a ?crit :
> Hello,
>
> Gustavo, Carsten, Frank, Vicente, Alan, Romain, Bernd, Thomas, Peter,
> Max, Joao, Maxime, Sonic, Simon, Waldemar, please see below, there are
> some questions for you. Thanks!
>
> On Fri, 22 Jan 2016 08:30:21 +0100 (CET), Thomas Petazzoni wrote:
>> arm | host-efl-1.15.3 | NOK | http://autobuild.buildroot.net/results/e178371c2c3bf42d59c6fc26409e098081239ccb/
>
> lib/evas/filters/evas_filter_parser.c: In function '_lua_backtrace':
> lib/evas/filters/evas_filter_parser.c:2434:20: error: 'LUA_GLOBALSINDEX' undeclared (first use in this function)
> lua_getfield(L, LUA_GLOBALSINDEX, "debug");
>
> Romain ? This is host-efl, maybe we need to disable Lua support or
> something ?
It's a lua 5.1 vs 5.2 and 5.3 issue.
It's a complete mess because there is an uptream patch [1] that try to fixes the
build issue, but not completely.
The build fail with the following error due to compatibility mode in lua
(LUA_COMPAT_ALL and LUA_COMPAT_5_1):
lib/evas/.libs/libevas.so: undefined reference to `luaL_openlib'
collect2: error: ld returned 1 exit status
Also the patch break the build for lua 5.1...
So, I think it's safe to add a dependency on lua 5.1 and report the problem
upstream.
[1]
https://git.enlightenment.org/core/efl.git/commit/?id=6124d0733657e425001ce51f526aea3bb8dc54e7
>
>> microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/d35f6ee7643a695af7db3739ff480d25b99ee051/
>> microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/09f4a89e463b6ccbca01cce1d38eb849c17ed6e1/
>
> The documentation issue. Romain, you looked into this a while ago, why
> does it pop up again on Microblaze specifically ?
I think this build failure is here since we SED into the Makefile to remove the
documentation.
But I gave up on the patch for upstream...
>
> Maybe we can switch to the mainline gdb for Microblaze ?
>
Why not. The latest gdb version was 7.5.1 when gdb for Microblaze was added to
Buildroot. Now we have at least 7.7.x.
>
>> nios2 | imagemagick-6.9.2-10 | NOK | http://autobuild.buildroot.net/results/0bf3a2a284b7d4712ab1530562d3b8164fc75e88/
>
> The usual:
>
> assertion fail elf32-nios2.c:1038
>
> This is being fixed at
> https://sourceware.org/bugzilla/show_bug.cgi?id=19405. In the mean
> time, we could disable on NIOS II maybe ?
Yes maybe.
>
>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/183df75a853c3b0e2617c9219a356c5531aa523d/
>
> Will be fixed once we bump to binutils 2.26. Romain, maybe we should
> disable libcap-ng in the mean time ?
binutils 2.26 should be released in a few days, hopefully.
>
>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/aa1492777c5f60ab45921618f64910ca4d048e5f/
>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/a74810f0fce398c41fef11b8e2b8e1a52ffdb46a/
>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/cb70d195cf9b9b5ae09b83a40ef767cc8f699a9c/
>
> Toolchain issues. Being fixed in upstream gcc, but we should disable
> with external NIOS2 toolchain anyway.
>
> Romain ?
This patch should be fine:
http://patchwork.ozlabs.org/patch/561414/
Best regards,
Romain
>
> Thomas
>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-22 9:29 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2016-01-22 9:36 ` Thomas De Schampheleire
2016-01-22 11:26 ` Gustavo Zacarias
@ 2016-01-22 18:38 ` Waldemar Brodkorb
2016-01-22 23:19 ` Romain Naour
` (6 subsequent siblings)
9 siblings, 0 replies; 416+ messages in thread
From: Waldemar Brodkorb @ 2016-01-22 18:38 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Thomas Petazzoni wrote,
> Hello,
>
> Gustavo, Carsten, Frank, Vicente, Alan, Romain, Bernd, Thomas, Peter,
> Max, Joao, Maxime, Sonic, Simon, Waldemar, please see below, there are
> some questions for you. Thanks!
>
> libatomic_ops not usable. Probably need to disable erlang on Sparc and
> be done with it?
You got a patch for it, a while back :=)
http://patchwork.ozlabs.org/patch/553137/
best regards
Waldemar
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-22 9:29 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2016-01-22 9:36 ` Thomas De Schampheleire
@ 2016-01-22 11:26 ` Gustavo Zacarias
2016-01-22 18:38 ` Waldemar Brodkorb
` (7 subsequent siblings)
9 siblings, 0 replies; 416+ messages in thread
From: Gustavo Zacarias @ 2016-01-22 11:26 UTC (permalink / raw)
To: buildroot
On 22/01/16 06:29, Thomas Petazzoni wrote:
>> mipsel | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/62f386829193c747176ace05e4b26826fcabbf59/
>> mips64el | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/a92fa5dc5d9d6742d61d4d293f7eac97c5355dfe/
>
> rbt.c:116:15: error: two or more data types in declaration specifiers
> isc_uint32_t ptrsize;
> ^
> rbt.c:116:22: error: expected identifier or '(' before ';' token
> isc_uint32_t ptrsize;
>
> Gustavo, can you have a look ? I think this error already popped up in the past, no?
Hi.
Finally nailed it down, it's uclibc's fault, basically it #defines
ptrsize in bits/setjmp.h for mips.
Waldemar: you did that in 70a04a287a2875c82e6822c36e071afba5b63a62
(uclibc), unfortunately it will be hard to get rid of, we'll have to
live with this for some time.
I can patch bind to not use ptrsize (say, rename it to pointersize or
something like that) and that fixes it, however it definitely won't be
upstreamable (i don't even want to show my face to explain why it's
necessary).
This could affect other programs in the future i believe.
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-22 9:29 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2016-01-22 9:36 ` Thomas De Schampheleire
2016-01-22 11:26 ` Gustavo Zacarias
` (8 subsequent siblings)
9 siblings, 0 replies; 416+ messages in thread
From: Thomas De Schampheleire @ 2016-01-22 9:36 UTC (permalink / raw)
To: buildroot
On Fri, Jan 22, 2016 at 10:29 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
[..]
>
>> mips64el | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/3a2b141d90b28a2954fa0ad3104cba81d648d2a3/
>> mipsel | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/70aa227c8a289631c2973474cfaef5973756dd5c/
>> mips64el | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/2b8c777c76b7e5d5a426045f5a3872d6b71faa56/
>> mipsel | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/3f19dd459400ac7fca39e69dd280def6a547f8b6/
>
> tirpc/tests_pack/rpc_suite/tirpc/tirpc_auth_authdes_create/tirpc_authdes_create.c:50: undefined reference to `authdes_create'
> collect2: error: ld returned 1 exit status
>
> Thomas, you touched the ltp-testsuite/tirpc handling recently IIRC.
> Interestingly, this problem only occurs on MIPS apparently. Thomas,
> Vicente, can you have a look ?
Yes, I have noticed this same problem very recently here and have a
local patch which I will submit. It seems my original patch did not
disable all required tests.
/Thomas
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-22 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2016-01-21 Thomas Petazzoni
@ 2016-01-22 9:29 ` Thomas Petazzoni
2016-01-22 9:36 ` Thomas De Schampheleire
` (9 more replies)
0 siblings, 10 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2016-01-22 9:29 UTC (permalink / raw)
To: buildroot
Hello,
Gustavo, Carsten, Frank, Vicente, Alan, Romain, Bernd, Thomas, Peter,
Max, Joao, Maxime, Sonic, Simon, Waldemar, please see below, there are
some questions for you. Thanks!
On Fri, 22 Jan 2016 08:30:21 +0100 (CET), Thomas Petazzoni wrote:
> arm | aumix-2.8 | NOK | http://autobuild.buildroot.net/results/c8c7f9a799d1af507a6edd5e02b0bbc8b7b5d068/
gettext/libintl handling issue.
> mipsel | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/62f386829193c747176ace05e4b26826fcabbf59/
> mips64el | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/a92fa5dc5d9d6742d61d4d293f7eac97c5355dfe/
rbt.c:116:15: error: two or more data types in declaration specifiers
isc_uint32_t ptrsize;
^
rbt.c:116:22: error: expected identifier or '(' before ';' token
isc_uint32_t ptrsize;
Gustavo, can you have a look ? I think this error already popped up in the past, no?
> arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/c7d987a51f2b2b731fb60e0e741361bbfb4ff230/
> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/b2c860fc8fbc7a025bcd3c04e9b43b04f029ead3/
> arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/5a33d69d2c11e3013b73b3f6c1d8ab3a31facf62/
> arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/a7c7eb7c2f477f8a19c1b364f746dfd31bf18a3d/
> arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/fb2f5cbe28a41161df7e3c5b2f6a36242daf5374/
> xtensa | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/179345a92e0c1db1b8d5bccb27c6b93e484f9b6d/
> i686 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/8612864811bbb04d655a6040869ccb81396d7737/
> arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/51c54c85010c61245a4ef51d4e602974809d077f/
> arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/e474243b83233c008fc2351c77eba35269e95439/
> xtensa | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/30898a3c7a5fceb1bd14a287064b96e04fba7921/
> microblazeel | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/d5d159dc004e28fed537b84fae76afb0734b2ec0/
> microblazeel | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/71e9dbb63b91980723554651071fdc3d7a2250f2/
> mips64el | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/3ee30fe28f709c63c9a0e2d0d91440d855ff73a9/
> xtensa | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/c48523b0bc50c61a9dd1bb691cd3fe3b05fdc1a7/
> sh4 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/04553f5d6b73b0a97901995674b0876c33d062f5/
The FE_* issue. I tried to have a look at the other day. It seems like
the Boost code does check for FE_*, but it does by running tests with
the host compiler... So it concludes that fenv.h support is OK, but
then it really builds with the target compiler and fails. But the boost
build system is so... that I'm not even sure.
> arm | dvbsnoop-1.4.50 | NOK | http://autobuild.buildroot.net/results/be64a45ac158b9057fb3e7ef9b515250acc77187/
Still the u_long problem. Carsten ?
> sparc | erlang-17.5 | NOK | http://autobuild.buildroot.net/results/20cd87c6a05c91ee223b813040d9d10fa923b174/
libatomic_ops not usable. Probably need to disable erlang on Sparc and
be done with it?
> x86_64 | erlang-17.5 | NOK | http://autobuild.buildroot.net/results/e4ab3fa4a121f7d7edb0263f02aac2ee836905a7/
sys/common/erl_poll.c: In function 'update_pollset':
sys/common/erl_poll.h:132:5: error: '__uint32_t' undeclared (first use in this function)
((__uint32_t) (EV))
^
sys/common/erl_poll.c:1150:24: note: in expansion of macro 'ERTS_POLL_EV_E2N'
epe_templ.events = ERTS_POLL_EV_E2N(ps->fds_status[fd].events);
^
sys/common/erl_poll.h:132:5: note: each undeclared identifier is reported only once for each function it appears in
((__uint32_t) (EV))
^
sys/common/erl_poll.c:1150:24: note: in expansion of macro 'ERTS_POLL_EV_E2N'
epe_templ.events = ERTS_POLL_EV_E2N(ps->fds_status[fd].events);
^
Musl build issue. Frank, can you have a look at this one ?
> arm | gdk-pixbuf-2.32.3 | NOK | http://autobuild.buildroot.net/results/f271386d3cefad4a4971bc8698848b4563498e6b/
./.libs/libgdk_pixbuf-2.0.so: undefined reference to `libintl_bind_textdomain_codeset'
./.libs/libgdk_pixbuf-2.0.so: undefined reference to `libintl_bindtextdomain'
./.libs/libgdk_pixbuf-2.0.so: undefined reference to `libintl_gettext'
Gustavo, can you have a look ?
> mips64el | gst1-libav-1.6.3 | NOK | http://autobuild.buildroot.net/results/1a0eb189ad91a7f2fb7285f4225555a0a0febda2/
libavformat/aacdec.c:1:0: error: '-mips64r2' conflicts with the other architecture options, which specify a mips64 processor
Vicente, this one is for you :-)
> xtensa | hidapi-d17db57b9d4354752e0a... | NOK | http://autobuild.buildroot.net/results/a5b0d3816953b5477d7938cf001fb048fee7462b/
Weird:
make[3]: *** No rule to make target `hidtest.o', needed by `hidtest-libusb'. Stop.
Alan, hidapi is your thing, would you mind having a look ?
> arm | host-efl-1.15.3 | NOK | http://autobuild.buildroot.net/results/e178371c2c3bf42d59c6fc26409e098081239ccb/
lib/evas/filters/evas_filter_parser.c: In function '_lua_backtrace':
lib/evas/filters/evas_filter_parser.c:2434:20: error: 'LUA_GLOBALSINDEX' undeclared (first use in this function)
lua_getfield(L, LUA_GLOBALSINDEX, "debug");
Romain ? This is host-efl, maybe we need to disable Lua support or
something ?
> microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/d35f6ee7643a695af7db3739ff480d25b99ee051/
> microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/09f4a89e463b6ccbca01cce1d38eb849c17ed6e1/
The documentation issue. Romain, you looked into this a while ago, why
does it pop up again on Microblaze specifically ?
Maybe we can switch to the mainline gdb for Microblaze ?
> nios2 | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/0e8d5ab5127b5e40c58912fe16504e3fcb941e69/
> arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/10f61d4cc5f6fdac231185d577493e0e82c5d091/
> microblazeel | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/bdcb9bbd7a07f0bde1b575bbf7ae88d006a1e823/
> arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/a25de6a6e8d68fd86ebf2c5805c6fe31d5860656/
> arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/f00e14e2360544ffe7501247dddfcb701631646d/
> mips64el | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/95491e089e6e18bfddbf6d7d19450026e9a349f5/
> mips64el | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/936d66543e2db55309af115ead64ded24f31661c/
> arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/25409dfeb7ce5806115092eb341e201d680ab974/
> bfin | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/1a45412939a3f9d6fa59d086d834a3b4a4bffef7/
Would be fixed by http://patchwork.ozlabs.org/patch/571347/.
> nios2 | imagemagick-6.9.2-10 | NOK | http://autobuild.buildroot.net/results/0bf3a2a284b7d4712ab1530562d3b8164fc75e88/
The usual:
assertion fail elf32-nios2.c:1038
This is being fixed at
https://sourceware.org/bugzilla/show_bug.cgi?id=19405. In the mean
time, we could disable on NIOS II maybe ?
> arm | iperf3-3.1 | NOK | http://autobuild.buildroot.net/results/50e34db9e273ebb7b8a9198dec254f6b22e26eff/
iperf.h:71:21: error: field 'tcpInfo' has incomplete type
struct tcp_info tcpInfo; /* getsockopt(TCP_INFO) for Linux, {Free,Net}BSD */
musl build issue.
Gustavo, you added the iperf3 package, can you have a look ?
> x86_64 | iproute2-4.4.0 | NOK | http://autobuild.buildroot.net/results/d3d79b55cb19987d5d5c0da9c0f0d25697697c05/
Already fixed by
https://git.busybox.net/buildroot/commit/?id=11d7b8b64aa171823bc4c97e3cce43884d078ecf.
> x86_64 | iucode-tool-1cbd73013cd4c6b... | NOK | http://autobuild.buildroot.net/results/7f8626db69500a84a393053a485f04180c565673/
Fixed by https://git.busybox.net/buildroot/commit/?id=6a774f400b20612cb77836a47aaf62ea72422fb8.
> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/183df75a853c3b0e2617c9219a356c5531aa523d/
Will be fixed once we bump to binutils 2.26. Romain, maybe we should
disable libcap-ng in the mean time ?
> x86_64 | libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/7d444611f8efa40e0eb81ac88365416ef553fcd5/
> x86_64 | libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/6287fa5a754610f04f0df93bf611676d982f5cff/
Musl build issue. Bernd, can you have a look ?
> powerpc | libnss-3.21 | NOK | http://autobuild.buildroot.net/results/cdae10070b9a97066dbfd0fb2c2004d9bd1fdd43/
> powerpc | libnss-3.21 | NOK | http://autobuild.buildroot.net/results/0df8b1f78b671ff05b2ecbf9c4cf08b8898e2d43/
Fixed by https://git.busybox.net/buildroot/commit/?id=b8fb4903fb858bc81eab6ac5bd37c801853594cb.
> i686 | libsoil-20080707 | NOK | http://autobuild.buildroot.net/results/8ff91ab8e52000eb34dd8f662520cf1b31490cf5/
> x86_64 | libsoil-20080707 | NOK | http://autobuild.buildroot.net/results/ea77d6b23aca0cb1cf527e6c16ddf5eba957a69c/
These are really weird. The patch doesn't apply when the build takes
place on my build server, but it does apply when I test things locally
on my machine. A difference in the version of patch ?
> sparc | libubox-e88d816d6e462180f03... | NOK | http://autobuild.buildroot.net/results/4feaa9089ee9a183c5086b791bea35c0156945af/
Atomic issue strikes again.
> mips64el | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/4d63874fe2efda8ac7aa3a8c82affa99f0ce5af0/
[.... many more of this issue ....]
Fixed by
https://git.busybox.net/buildroot/commit/?id=343ec915e3f7cb6f83ef114cd6c5e5f3502d8f4a.
> mips64el | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/3a2b141d90b28a2954fa0ad3104cba81d648d2a3/
> mipsel | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/70aa227c8a289631c2973474cfaef5973756dd5c/
> mips64el | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/2b8c777c76b7e5d5a426045f5a3872d6b71faa56/
> mipsel | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/3f19dd459400ac7fca39e69dd280def6a547f8b6/
tirpc/tests_pack/rpc_suite/tirpc/tirpc_auth_authdes_create/tirpc_authdes_create.c:50: undefined reference to `authdes_create'
collect2: error: ld returned 1 exit status
Thomas, you touched the ltp-testsuite/tirpc handling recently IIRC.
Interestingly, this problem only occurs on MIPS apparently. Thomas,
Vicente, can you have a look ?
> arm | lttng-tools-2.7.1 | NOK | http://autobuild.buildroot.net/results/b48bc7ad4bede4d16c079da0ae1121e6796a0e8d/
> arm | lttng-tools-2.7.1 | NOK | http://autobuild.buildroot.net/results/25dcb19c3dd32e50990f9b45053d71ea18746a80/
> arm | lttng-tools-2.7.1 | NOK | http://autobuild.buildroot.net/results/a3f93498811491d37ba13d024e33e68a8bc7ba18/
checking for dlopen in -lc... no
configure: error: Cannot find dlopen in libdl nor libc. Use LDFLAGS=-Ldir to specify their location.
In a static linking only situation.
Samuel, can you have a look ? Most likely we should simply disable
lttng-tools for static only scenarios.
> x86_64 | madplay-0.15.2b | NOK | http://autobuild.buildroot.net/results/2561190b274d71666c4bdf3c569b02063cefdb30/
./relocatable.c: In function 'libintl_relocate':
./relocatable.c:402:40: error: 'INSTALLPREFIX' undeclared (first use in this function)
const char *orig_installprefix = INSTALLPREFIX;
Musl related ? Not sure. Peter, you added the madplay package back in
2007, so can you have a look ? :-)
> microblazeel | mesa3d-11.1.1 | NOK | http://autobuild.buildroot.net/results/0d71cd6edccd390106636cc0c4acfe5a8dca112a/
> microblazeel | mesa3d-11.1.1 | NOK | http://autobuild.buildroot.net/results/6567477b87c081db97a9c2bf84af182a9a281193/
Another atomic issue: __sync_val_compare_and_swap_1.
> mipsel | mosh-1.2.5 | NOK | http://autobuild.buildroot.net/results/3f9443a76d2f8811720748b487e045eec23ec338/
> mipsel | mosh-1.2.5 | NOK | http://autobuild.buildroot.net/results/104b8fae4ff5918353e0e6a7ac050e2f04d701c1/
Vicente, this is with your new mips toolchains, SSP library problem.
Can you have a look ?
> xtensa | mp4v2-2.0.0 | NOK | http://autobuild.buildroot.net/results/bff7436a800eeea92c0c92bd2846b0f2b31947fd/
/tmp/cchH5TCg.s:23436: Error: value of 38619 too large for field of 2 bytes at 2889
Toolchain problem. Max can you have a look ?
> aarch64 | mplayer-1.2 | NOK | http://autobuild.buildroot.net/results/aadce770cf86ded813a78f936f0a6d4441845907/
libavutil/aarch64/cpu.c:25:32: error: 'HAVE_ARMV8' undeclared (first use in this function)
return AV_CPU_FLAG_ARMV8 * HAVE_ARMV8 |
^
libavutil/aarch64/cpu.c:25:32: note: each undeclared identifier is reported only once for each function it appears in
Joao, you enabled mplayer on AArch64, can you have a look please ?
> powerpc | nfs-utils-1.3.3 | NOK | http://autobuild.buildroot.net/results/fe3be93988e585a84ae3116a0c327e1e2c95ad08/
Still the same build issue:
cache.c: In function 'same_path':
cache.c:429:22: error: field 'fh' has incomplete type
cache.c:436:2: warning: implicit declaration of function 'name_to_handle_at' [-Wimplicit-function-declaration]
Makefile:613: recipe for target 'mountd-cache.o' failed
Maxime ? I gave you some hints about this one, can you cook a patch ?
> arm | php-5.6.17 | NOK | http://autobuild.buildroot.net/results/0bbae90d05f14ac1fdbac7d8d69d4e6fd922e301/
Forgets to link with pthread in a static linking scenario.
Gustavo ?
> arm | pinentry-0.9.4 | NOK | http://autobuild.buildroot.net/results/bd886cd10a8f52647296de2ff50270f25532756e/
Weird C++ error:
error: member 'QChar std::__cxx11::basic_string<QChar, std::char_traits<QChar>, secmem::alloc<QChar> >::<anonymous union>::_M_local_buf [8]' with constructor not allowed in union
Vicente, you added this package, so can you have a look ?
> arm | pptp-linux-1.8.0 | NOK | http://autobuild.buildroot.net/results/56dd530d53489220d0080480310b8dc150cf1b2e/
Musl build issue. Gustavo ?
> arc | qextserialport-ada321a9ee46... | NOK | http://autobuild.buildroot.net/results/d6565367f83cc845495e5e5f60935b71d04ef2da/
Toolchain issue it seems:
/home/test/autobuild/instance-1/output/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/4.8.4/../../../../arc-buildroot-linux-uclibc/bin/ld: /home/test/autobuild/instance-1/output/host/usr/arc-buildroot-linux-uclibc/sysroot/usr/lib/libglib-2.0.a(libglib_2_0_la-gmain.o): relocation R_ARC_32_ME against `.rodata.str1.4' can not be used when making a shared object; recompile with -fPIC
Alexey ?
> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/aa1492777c5f60ab45921618f64910ca4d048e5f/
> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/a74810f0fce398c41fef11b8e2b8e1a52ffdb46a/
> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/cb70d195cf9b9b5ae09b83a40ef767cc8f699a9c/
Toolchain issues. Being fixed in upstream gcc, but we should disable
with external NIOS2 toolchain anyway.
Romain ?
> arm | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/53e7e122e96b4b96c0f5feb4f26055b3f5ad8096/
Full static configuration fails with:
/home/test/autobuild/instance-1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.9.3/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: cannot find -ldl
See if we can, get rid of the libdl dependency or make qt (or one of
its sub-option) depend on dynamic library.
> arm | rt-tests-v0.89 | NOK | http://autobuild.buildroot.net/results/a6f6502e55fd68803f3ff8b4b76cce6601e101db/
In file included from src/lib/rt-get_cpu.c:4:0:
src/include/rt-get_cpu.h:9:19: fatal error: dlfcn.h: No such file or directory
#include <dlfcn.h>
Should depend on dynamic library.
> bfin | ruby-2.3.0 | NOK | http://autobuild.buildroot.net/results/268d29bd910c17b1fccad5d13ce281238080efd2/
> bfin | ruby-2.3.0 | NOK | http://autobuild.buildroot.net/results/1eb3d1ca20ce81fa2b10593d9393fb130558a706/
process.c: In function 'rb_spawn_process':
process.c:3921: warning: passing argument 2 of 'rb_ary_new_from_values' from incompatible pointer type
process.c:3923: error: 'status' undeclared (first use in this function)
process.c:3923: error: (Each undeclared identifier is reported only once
process.c:3923: error: for each function it appears in.)
Sonic, this is a Blackfin problem, can you have a look ?
> arm | sconeserver-3b886c3dda6eda3... | NOK | http://autobuild.buildroot.net/results/178bdfb062949fb10b9d6b9830975aa57702b3ae/
Static configuration, fails with:
checking for mpfr_init in -lmpfr... no
configure: error: libraries 'mpfr' and 'gmp' are required for the maths module
Simon, can you have a look ?
> sparc64 | setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/328192a8c561f3517bb0f9ebafb59d09e4f4b3ae/
policy_scan.o: In function `yyget_out':
policy_scan.c:(.text+0x504): relocation truncated to fit: R_SPARC_GOT13 against symbol `yyout' defined in .bss section in policy_scan.o
policy_scan.o: In function `yyget_leng':
policy_scan.c:(.text+0x520): relocation truncated to fit: R_SPARC_GOT13 against symbol `yyleng' defined in COMMON section in policy_scan.o
Waldemar, this is a toolchain problem, can you have a look ?
> mips64el | slang-2.3.0 | NOK | http://autobuild.buildroot.net/results/3c1fef2163b8a194ede70040da87af95bf5dc331/
/home/buildroot/autobuild/run/instance-2/output/host/usr/mips64el-buildroot-linux-uclibc/sysroot/usr/lib/../lib64/libreadline.a(display.o): In function `cr':
display.c:(.text+0x208): undefined reference to `tputs'
display.c:(.text+0x210): undefined reference to `tputs'
Static linking problem.
Vicente, in commit 41d6f177d226b9014f5a14d0d05ca843f482d94f, you added
some patches to fix static linking. Seems like there are more
problems :-)
> arm | strongswan-5.3.5 | NOK | http://autobuild.buildroot.net/results/601d8dc1654d8733db49b195139e12437663034c/
plugins/plugin_loader.c: In function 'load_plugin':
plugins/plugin_loader.c:359:13: error: 'RTLD_LAZY' undeclared (first use in this function)
int flag = RTLD_LAZY;
Needs dynamic library ?
> mipsel | stunnel-5.28 | NOK | http://autobuild.buildroot.net/results/3448dc253a4a86450f15fb225374bd1e643dacd1/
Vicente, this is with your new MIPS toolchain, SSP problem:
/home/peko/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp_nonshared
/home/peko/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp
> arc | tar-1.28 | NOK | http://autobuild.buildroot.net/results/e9c5df490264a2d9ff5160187bda75431493d666/
../gnu/libgnu.a(quotearg.o): In function `quote':
quotearg.c:(.text+0xdac): multiple definition of `quote'
/home/buildroot/buildroot-test/instance-1/output/host/usr/arc-buildroot-linux-uclibc/sysroot/usr/lib/libacl.a(quote.o):/home/buildroot/buildroot-test/instance-1/output/build/acl-2.2.52/libmisc/quote.c:27: first defined here
I don't think it's specific to ARC. Anyone to have a look ?
> arc | trousers-0.3.13 | NOK | http://autobuild.buildroot.net/results/7009e334e51adce37353c5d4f618fb28678f6114/
PIE problem, patch pending.
> arm | webkitgtk24-2.4.9 | NOK | http://autobuild.buildroot.net/results/c660d29b0184daf7d16045b595e48d3c73ab521a/
checking for GLES2/gl2.h... yes
checking whether to use OpenGL ES 2 support... configure: error: Cannot enable OpenGL ES 2 support without EGL enabled.
Gustavo ?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-17 17:10 ` Maxime Hadjinlian
@ 2016-01-18 22:10 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2016-01-18 22:10 UTC (permalink / raw)
To: buildroot
Maxime,
I know you're using GMail, but please learn to strip long e-mails when
you're just replying to one specific of it :-)
On Sun, 17 Jan 2016 18:10:58 +0100, Maxime Hadjinlian wrote:
> > Not sure:
> >
> > cache.c: In function 'same_path':
> > cache.c:429:22: error: field 'fh' has incomplete type
> > cache.c:436:2: warning: implicit declaration of function 'name_to_handle_at' [-Wimplicit-function-declaration]
> > Makefile:613: recipe for target 'mountd-cache.o' failed
> >
> > Maxime, can you have a look ?
> I will look at it, the errors is a bit puzzling but I only glanced at
> it for now.
I had a look: nfs-utils does have some code to detect if
name_to_handle_at() is implemented. Unfortunately, as can be seen here,
using this function only triggers a warning (because its prototype is
not defined in any headers of the C library), but doesn't fail to link
(because for some reason the function is implemented). However the
"struct file_handle" type is not available.
So, I suggest to add:
AC_CHECK_TYPES([struct file_handle])
to configure.ac, and then change cache.c from
#if HAVE_NAME_TO_HANDLE_AT
to:
#if defined(HAVE_NAME_TO_HANDLE_AT) && defined(HAVE_STRUCT_FILE_HANDLE)
It works with the problematic PowerPC toolchains (i.e it properly
detects that struct file_handle is not available), but it remains to be
tested on another toolchain. Also, this fix should be submitted
upstream, obviously :-)
Care to do it ? :-)
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-18 20:53 ` Peter Seiderer
@ 2016-01-18 21:03 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2016-01-18 21:03 UTC (permalink / raw)
To: buildroot
Peter,
On Mon, 18 Jan 2016 21:53:47 +0100, Peter Seiderer wrote:
> This two enums entered the linux kernel with commit '[media] add DTMB support for DVB API' [1], at least
> since linux-3.10 (did no exact search)...., may be depend GST1_PLUGINS_BAD_PLUGIN_DVB on
> TOOLCHAIN_HEADERS_AT_LEAST_3_10 ?
Thanks for the research. This commit dates back from v3.7:
$ git tag --contains 224b6642f5e82a1b21f6b552c799fa02e527d542 | grep ^v | sort -V | head -1
v3.7
I've committed a patch that fixes this. Many thanks for your
investigation!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-16 23:11 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (8 preceding siblings ...)
2016-01-18 12:22 ` Gustavo Zacarias
@ 2016-01-18 20:53 ` Peter Seiderer
2016-01-18 21:03 ` Thomas Petazzoni
9 siblings, 1 reply; 416+ messages in thread
From: Peter Seiderer @ 2016-01-18 20:53 UTC (permalink / raw)
To: buildroot
Hello Thomas,
On Sun, 17 Jan 2016 00:11:17 +0100, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
>
> > i686 | gst1-plugins-bad-1.6.2 | NOK | http://autobuild.buildroot.net/results/fab7afc3490d77a6b29760394337298f2fd55d51/
> > x86_64 | gst1-plugins-bad-1.6.2 | NOK | http://autobuild.buildroot.net/results/4da1b0454fe7bf028a62058d28dafda104fb75f4/
>
> gstdvbsrc.c: In function 'gst_dvbsrc_code_rate_get_type':
> gstdvbsrc.c:273:6: error: 'FEC_2_5' undeclared (first use in this function)
> gstdvbsrc.c:273:6: note: each undeclared identifier is reported only once for each function it appears in
> gstdvbsrc.c: In function 'gst_dvbsrc_modulation_get_type':
> gstdvbsrc.c:303:6: error: 'QAM_4_NR' undeclared (first use in this function)
> gstdvbsrc.c:303:5: error: initializer element is not constant
> gstdvbsrc.c:303:5: error: (near initialization for 'modulation_types[13].value')
>
> Not sure. Peter, Gustavo ?
>
This two enums entered the linux kernel with commit '[media] add DTMB support for DVB API' [1], at least
since linux-3.10 (did no exact search)...., may be depend GST1_PLUGINS_BAD_PLUGIN_DVB on
TOOLCHAIN_HEADERS_AT_LEAST_3_10 ?
Regards,
Peter
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/include/linux/dvb/frontend.h?id=224b6642f5e82a1b21f6b552c799fa02e527d542
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-16 23:11 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (7 preceding siblings ...)
2016-01-18 7:06 ` Alexey Brodkin
@ 2016-01-18 12:22 ` Gustavo Zacarias
2016-01-18 20:53 ` Peter Seiderer
9 siblings, 0 replies; 416+ messages in thread
From: Gustavo Zacarias @ 2016-01-18 12:22 UTC (permalink / raw)
To: buildroot
On 16/01/16 20:11, Thomas Petazzoni wrote:
>> powerpc | libnss-3.21 | NOK | http://autobuild.buildroot.net/results/cef2fe3d87b742743a54a2fdbc585771e175a9e6/
>
> In file included from secoid.c:1915:0:
> verref.h: In function 'SECOID_Init':
> verref.h:22:9: error: #pragma GCC diagnostic not allowed inside functions
> verref.h:23:9: error: #pragma GCC diagnostic not allowed inside functions
> cc1: warnings being treated as errors
>
> old compiler problem.
This one is fixed via http://patchwork.ozlabs.org/patch/563960/
>> arm | unknown | NOK | http://autobuild.buildroot.net/results/0581889edfb7bf5ca0f23e3111ac6eeffbee3376/
>> mips64el | unknown | NOK | http://autobuild.buildroot.net/results/1abb03babacacf13db33ae9fe89b5d52925b58b1/
>
> 2 different dependency problems.
Fixed via http://patchwork.ozlabs.org/patch/564312/
(more a backport of 2.10.x features than really trying to fix that
particular failure).
I'll look at the others time allowing.
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-16 23:11 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (6 preceding siblings ...)
2016-01-17 19:06 ` Romain Naour
@ 2016-01-18 7:06 ` Alexey Brodkin
2016-01-18 12:22 ` Gustavo Zacarias
2016-01-18 20:53 ` Peter Seiderer
9 siblings, 0 replies; 416+ messages in thread
From: Alexey Brodkin @ 2016-01-18 7:06 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Sun, 2016-01-17 at 00:11 +0100, Thomas Petazzoni wrote:
> Hello,
>
> Gustavo, Vicente, J?rg, Frank, Bernd, Maxime, Carsten, Davide, Jeremy,
> VIcente, Gilles, Gary, Romain, Matt, Waldemar, Fran?ois, Alexey, Joris,
> Volkov: there are some specific build failures for which your help
> would be appreciated. See below. Thanks in advance for your help!
>
> On Sat, 16 Jan 2016 08:30:21 +0100 (CET), Thomas Petazzoni wrote:
> > arc | mesa3d-11.1.0 | NOK |
> > http://autobuild.buildroot.net/results/7b3f5c0e3c59bd49614e8ad4eee3d89e3527a939/
>
> Compiler problem, issue is known by Synopsys.
Indeed that's a known problem for us and it's me to blame for seeing no progress here.
Still we already have newer toolchain in its RC1, let's see it problem still happens.
And anyways I'll send a patch with new tools support today.
> > arc | qt-4.8.7 | NOK |
> > http://autobuild.buildroot.net/results/a85a1839a45fb6102e53131ecc8f6dadf92bcdc2/
>
> Static linking, I'm assuming this *could* be fixed by
> https://git.busybox.net/buildroot/commit/?id=12009bb92931b153823110f811632540044d3b02,
> though I am not sure. Alexey?
Well unfortunately mentioned patch doesn't help here, see it's being applied already:
------------------->8------------------
Applying 0009-Fix-library-inclusion-order-when-building-statically.patch using patch:
patching file config.tests/unix/compile.test
^[[3m>>> qt 4.8.7 Configuring^[[23m
------------------->8------------------
So there's something else. I have 1 idea to try here.
>
> > arc | ruby-2.3.0 | NOK |
> > http://autobuild.buildroot.net/results/8e98934b066d4973d88e7d28b042b99550d68ae8/
>
> Compiler issue:
>
> /tmp/cctdImle.s: Assembler messages:
> /tmp/cctdImle.s:2253: Error: invalid register number `63'
> /tmp/cctdImle.s:2255: Error: invalid register number `63'
>
> Alexey ?
Good catch. Again let us try newer tools and if it doesn't help we'll be
bugging our toolchain developers.
> > arc | trousers-0.3.13 | NOK |
> > http://autobuild.buildroot.net/results/c3d3bedffe0f4ba40f33d18e90a4802f4a7bfffb/
>
> PIE problem, under discussion.
Indeed, Lada is busy with that.
Regards,
Alexey
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-16 23:11 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (5 preceding siblings ...)
2016-01-17 19:02 ` Gary Bisson
@ 2016-01-17 19:06 ` Romain Naour
2016-01-18 7:06 ` Alexey Brodkin
` (2 subsequent siblings)
9 siblings, 0 replies; 416+ messages in thread
From: Romain Naour @ 2016-01-17 19:06 UTC (permalink / raw)
To: buildroot
Hi Thomas, All,
Le 17/01/2016 00:11, Thomas Petazzoni a ?crit :
> Hello,
>
> Gustavo, Vicente, J?rg, Frank, Bernd, Maxime, Carsten, Davide, Jeremy,
> VIcente, Gilles, Gary, Romain, Matt, Waldemar, Fran?ois, Alexey, Joris,
> Volkov: there are some specific build failures for which your help
> would be appreciated. See below. Thanks in advance for your help!
>
> On Sat, 16 Jan 2016 08:30:21 +0100 (CET), Thomas Petazzoni wrote:
>
>> arm | iprutils-2.4.5 | NOK | http://autobuild.buildroot.net/results/61e121c25fc07083bcccedfcb4f938d18f5c5456/
>
> Musl build issue:
>
> iprlib.h:49:27: fatal error: bits/sockaddr.h: No such file or directory
> #include <bits/sockaddr.h>
>
> Romain, you bumped this package recently, can you have a look ?
>
I would suggest to remove bits/sockaddr.h since it's specific to glibc and add
limits.h to define PATH_MAX or disable for musl. At least iprutils build with
these fixes.
Note that iprutils switched to autotools buildsystem recently (since 2.4.6), so
if we bump to the latest version we can remove the two patches :
0002-Allow-CFLAGS-to-be-extended-from-the-enviro.patch
0003-Fix-static-build-by-passing-the-libraries-i.patch
>
>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/ae9eca750d27f80cf8b0743f41cdfcc50ea476f1/
>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/dca1ba4a15cd9326a43e99d78bd13021bc87d9a2/
>
> Romain, I don't remember what was the conclusion about this issue. I
> remember we discussed it at some point.
>
It's an issue with gcc <= 5.2 see:
http://lists.busybox.net/pipermail/buildroot/2015-December/146308.html
I think we should rebuild the prebuild nios2 toolchain with gcc 5.3 and the
upcoming binutils 2.26.
>
>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/199b8ed788e4ca3eca03b95710a3bb644d81d187/
>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/546f94ee09fcff27ea2d7c6cebb0b48aec1881f8/
>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/bb90227b6a18bde0cef45f82620de560d48866e7/
>
> Compiler problem. I don't remember if I reported it.
>
Qt-GUI issue with Binutils 2.25.1 (CS NIOSII 2015.11 and prebuild one).
http://patchwork.ozlabs.org/patch/561414/
>
>> xtensa | unknown | NOK | http://autobuild.buildroot.net/results/f913556517654f833bf17f141597ba41570b02b7/
>> arm | unknown | NOK | http://autobuild.buildroot.net/results/865ce538e3dc3ce8005a39b5400fc3f019d7a411/
>> arm | unknown | NOK | http://autobuild.buildroot.net/results/0581889edfb7bf5ca0f23e3111ac6eeffbee3376/
>> mips64el | unknown | NOK | http://autobuild.buildroot.net/results/1abb03babacacf13db33ae9fe89b5d52925b58b1/
>
> 2 different dependency problems.
>
There is also a similar issue with xlib_libfontenc:
http://patchwork.ozlabs.org/patch/564098/
Best regards,
Romain
>
> Thanks!
>
> Thomas
>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-16 23:11 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (4 preceding siblings ...)
2016-01-17 18:22 ` Rodrigo Rebello
@ 2016-01-17 19:02 ` Gary Bisson
2016-01-17 19:06 ` Romain Naour
` (3 subsequent siblings)
9 siblings, 0 replies; 416+ messages in thread
From: Gary Bisson @ 2016-01-17 19:02 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Sun, Jan 17, 2016 at 12:11 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> <snip>
>> arm | imx-kobs-3.14.28-1.0.0 | NOK | http://autobuild.buildroot.net/results/05a159c7f8382237d4c941b1bb6de7dad72708f3/
>
> Gary, can you have a look ?
This comes from the fact the mtd-user.h header used to include
stdint.h but it's no longer the case since linux 4.4.
http://lxr.free-electrons.com/source/include/uapi/mtd/mtd-user.h?v=4.3
http://lxr.free-electrons.com/source/include/uapi/mtd/mtd-user.h?v=4.4
So I guess I'll offer a patch that adds the stdint inclusion, plus
I'll update the package.
Regards,
Gary
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-16 23:11 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (3 preceding siblings ...)
2016-01-17 17:36 ` Jörg Krause
@ 2016-01-17 18:22 ` Rodrigo Rebello
2016-01-17 19:02 ` Gary Bisson
` (4 subsequent siblings)
9 siblings, 0 replies; 416+ messages in thread
From: Rodrigo Rebello @ 2016-01-17 18:22 UTC (permalink / raw)
To: buildroot
Thomas,
2016-01-16 21:11 GMT-02:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
[snip]
>> arm | chocolate-doom-2.2.1 | NOK | http://autobuild.buildroot.net/results/20019b0daebf1aaf44e0802603108ff712f60513/
>
> In static linking configurations, when SDL_mixer is linked against
> libmad, chocolate-doom doesn't pass -lmad. To fix this, we need to:
>
> * Fix SDL_mixer.pc so that it references libmad in Libs.private (or
> Requires.private ?)
>
> * Either use pkg-config directly in chocolate-doom.mk to pass the
> appropriate flags, or change the chocolate-doom build system itself.
>
> Note that a similar problem might appear when SDL_mixer is linked
> against vorbis.
>
> Rodrigo, since you added the chocolate-doom package, can you look into
> fixing this ?
>
No problem, I'll look into that in the next few days.
Regards,
Rodrigo
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-16 23:11 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (2 preceding siblings ...)
2016-01-17 17:10 ` Maxime Hadjinlian
@ 2016-01-17 17:36 ` Jörg Krause
2016-01-17 18:22 ` Rodrigo Rebello
` (5 subsequent siblings)
9 siblings, 0 replies; 416+ messages in thread
From: Jörg Krause @ 2016-01-17 17:36 UTC (permalink / raw)
To: buildroot
Hi,
On So, 2016-01-17 at 00:11 +0100, Thomas Petazzoni wrote:
> Hello,
>
> Gustavo, Vicente, J?rg, Frank, Bernd, Maxime, Carsten, Davide,
> Jeremy,
> VIcente, Gilles, Gary, Romain, Matt, Waldemar, Fran?ois, Alexey,
> Joris,
> Volkov: there are some specific build failures for which your help
> would be appreciated. See below. Thanks in advance for your help!
>
> On Sat, 16 Jan 2016 08:30:21 +0100 (CET), Thomas Petazzoni wrote:
>
> > ?????powerpc |???????????????????boost-1.60.0 | NOK | http://autobu
> > ild.buildroot.net/results/e92fc7bac808e708e1aadd1b8e6677d003e5bbe4/
> > ?????????arm |???????????????????boost-1.60.0 | NOK | http://autobu
> > ild.buildroot.net/results/46d0907fe06a7b93bb092ad4bf869a2e0030cf32/
> > ??????x86_64 |???????????????????boost-1.60.0 | NOK | http://autobu
> > ild.buildroot.net/results/9ef4d4f5d793f9a854d3a398d00eec6ce9b59178/
> > ??????x86_64 |???????????????????boost-1.60.0 | NOK | http://autobu
> > ild.buildroot.net/results/74e22545f50c9f9e7f12208a1cb9cbb9154a6150/
> > ?????powerpc |???????????????????boost-1.60.0 | NOK | http://autobu
> > ild.buildroot.net/results/5438729ded4bf9887a1dc080366aee9abf27fb19/
> > ??????x86_64 |???????????????????boost-1.60.0 | NOK | http://autobu
> > ild.buildroot.net/results/99ef4325d424569bbd900d6590b8a3a5e445c140/
> > ?????????arc |???????????????????boost-1.60.0 | NOK | http://autobu
> > ild.buildroot.net/results/caded0b9ff89ba69cb3775d5fef18565a85a398a/
> > ??????x86_64 |???????????????????boost-1.60.0 | NOK | http://autobu
> > ild.buildroot.net/results/b81bcc845a091ff1182df7dec306492b67db10ea/
> > ??????xtensa |???????????????????boost-1.60.0 | NOK | http://autobu
> > ild.buildroot.net/results/29241cbf4791947e8bd990253716d8d43e219c23/
> > ????mips64el |???????????????????boost-1.60.0 | NOK | http://autobu
> > ild.buildroot.net/results/648507a680fa0360622ad1fdd47fdf30d3c54091/
> > ??????x86_64 |???????????????????boost-1.60.0 | NOK | http://autobu
> > ild.buildroot.net/results/dea9364e8d8276bbcf42847822ef5da905cd7007/
> > ??????x86_64 |???????????????????boost-1.60.0 | NOK | http://autobu
> > ild.buildroot.net/results/adcea53d916e0825cb5963768304dfe883d5d379/
> > microblazeel |???????????????????boost-1.60.0 | NOK | http://autobu
> > ild.buildroot.net/results/41ee80a733bc676d07d8296b262125b616070835/
> > ??????xtensa |???????????????????boost-1.60.0 | NOK | http://autobu
> > ild.buildroot.net/results/2c555d574540caf3a3b1ed64502274d3ba1f551b/
> > ?????????arc |???????????????????boost-1.60.0 | NOK | http://autobu
> > ild.buildroot.net/results/316dc6221a50537234e4b3e88268363d61b9bf59/
> > ?????????arc |???????????????????boost-1.60.0 | NOK | http://autobu
> > ild.buildroot.net/results/d4eb7cdbfd1152bb5a2a80f832c5edf524852701/
> > ?????????sh4 |???????????????????boost-1.60.0 | NOK | http://autobu
> > ild.buildroot.net/results/3bb3e2b683eabe7a6a9626f083b761b158a418ba/
> > ??????x86_64 |???????????????????boost-1.60.0 | NOK | http://autobu
> > ild.buildroot.net/results/0e2f3f4e4fa9dca521206d52fc061709534be12b/
> > ??????x86_64 |???????????????????boost-1.60.0 | NOK | http://autobu
> > ild.buildroot.net/results/84f5d3417ef5cdb826435b0029ddc8d2e9e4ec44/
> > ??????x86_64 |???????????????????boost-1.60.0 | NOK | http://autobu
> > ild.buildroot.net/results/428cb84d3bde356050b04647a599aea0fae6aeff/
>
> Some of these are the isnan() declaration issue, which is now fixed
> thanks to
> https://git.busybox.net/buildroot/commit/?id=640b75c8d73d713c908d6b28
> 8802c9e6bffe76ed.
>
> However, there is still the FE_* definition problem. J?rg, do you
> have
> something in the works to fix this ?
Not really, someone from OpenWRT reported this issue upstream [1]. I
added a comment to the ticket that it affects Buildroot, too.
My guess is that Boost check for fenv.h implies that FE_* is defined
too, which is wrong for those toolchains.
[1]?https://svn.boost.org/trac/boost/ticket/11756
J?rg
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-17 15:06 ` Matthew Weber
@ 2016-01-17 17:26 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2016-01-17 17:26 UTC (permalink / raw)
To: buildroot
Matt,
On Sun, 17 Jan 2016 09:06:57 -0600, Matthew Weber wrote:
> > Musl build issue. Matt, can you have a look ?
>
> Looks like the development was moved to github and there have been
> updates to support uClibc and musl-libc. I'll work on a patch to
> update the upstream location and hopefully also remove the one patch
> that package has for a ping issue.
Great, thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-16 23:11 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2016-01-17 1:42 ` Frank Hunleth
2016-01-17 15:06 ` Matthew Weber
@ 2016-01-17 17:10 ` Maxime Hadjinlian
2016-01-18 22:10 ` Thomas Petazzoni
2016-01-17 17:36 ` Jörg Krause
` (6 subsequent siblings)
9 siblings, 1 reply; 416+ messages in thread
From: Maxime Hadjinlian @ 2016-01-17 17:10 UTC (permalink / raw)
To: buildroot
Hi Thomas, all
On Sun, Jan 17, 2016 at 12:11 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> Gustavo, Vicente, J?rg, Frank, Bernd, Maxime, Carsten, Davide, Jeremy,
> VIcente, Gilles, Gary, Romain, Matt, Waldemar, Fran?ois, Alexey, Joris,
> Volkov: there are some specific build failures for which your help
> would be appreciated. See below. Thanks in advance for your help!
>
> On Sat, 16 Jan 2016 08:30:21 +0100 (CET), Thomas Petazzoni wrote:
>
>> xtensa | alsa-utils-1.1.0 | NOK | http://autobuild.buildroot.net/results/1bf954501960db802c3e2280b30b70d6813bdb32/
>> arm | alsa-utils-1.1.0 | NOK | http://autobuild.buildroot.net/results/7ba954e03822d758e25356935b0dfc2c91d3712a/
>
> <dlfcn.h> needed by the topology code. Fixed in
> https://git.busybox.net/buildroot/commit/?id=4707383c5d501a9ad7698579e5d0a4e2ab758c7e.
>
>> bfin | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/a5558d054ab19f078d0992f8b691f35f3f1323c0/
>
> Compiler error, in FLAT mode. Not sure what's going on, as I was able
> to build assimp properly in a minimal Blackfin FLAT configuration.
>
>> bfin | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/f0d25c8b08ba32361d47bd6bc344695f168396de/
>> bfin | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/3f143ea946ad98176d8e5eaddecfa0bda11c0439/
>> sparc64 | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/510c59e13f1412ffb831801e6389a32a76b543b6/
>> sparc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/3f6f7a72bec601688991111f21e897306b1d76ca/
>> xtensa | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/5eab445d66a977cdfb73a6b5dede6af692c28b16/
>> xtensa | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/a511687d937c2575d8edffe9235b1507be1c9442/
>> bfin | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/eb659085949c6b62108b8c46c50e8abd01681f23/
>> bfin | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/4f3c001e8fa6781c4a2ca9d82023f959b7897035/
>> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/5a90ba61c5ac863a7779af7783c7b0584a0c79e3/
>> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/a70ec3a94a18db77f094c71d8be055ae0d99862b/
>> xtensa | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/c0a57f9a03c308dcf8129d300d12f4a7d6d999de/
>> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/d37761e95f2f45e92ef641e7117ff6d02f2865d1/
>> xtensa | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/651efb92cd38569a1c53000c642b37a5c4b21115/
>> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/498380d65b3e3d604a36facec894fc60a30a5d74/
>> mips | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/37ce98706477b259da4e9527878aeada2d52366c/
>> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/686755f4f925811fccbdadbe28ba7561af8c51ad/
>> bfin | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/2f46b77f27ca7df9ae80ecaa6fdca6d981eeb8ff/
>> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/7be9e4860ca47f8906c355577d71c0c6e8d597be/
>> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/c0bc9693cfbac282599c73e7f0b6dd19e41bbfa3/
>> xtensa | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/23b6e683aa3db28d2103e47fd263dc9c5afd99b8/
>> xtensa | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/903515ab22c112dacf1583fff77c859c6f68985d/
>> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/23e03277f61490b6f48035075df0fc5e5474168f/
>
> I guess most if not all of these are fixed by
> https://git.busybox.net/buildroot/commit/?id=25ba49518a93265ecb3146e6eb21a2a138989100
> and
> https://git.busybox.net/buildroot/commit/?id=9ebac3bd050ee57cdd8a5ede053aed5522f5e8dc.
>
>> mipsel | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/c4f88c724829e1a2ff152c756ea3dae80fef149c/
>> mips64el | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/870879c3d20dcfb327329fab0d8c13f320fd5788/
>> mipsel | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/1d1889f407adce09f313e8660f8b660f256ea277/
>
> Vicente, Gustavo, can you have a look at those issues? It seems to be
> limited to MIPS, and I don't think it was happening before the recent
> bump of the bind package.
>
>> arm | bluez5_utils-5.37 | NOK | http://autobuild.buildroot.net/results/83112559d84dc156141339a31e3e02f1a2af5155/
>
> Fixed by
> https://git.busybox.net/buildroot/commit/?id=d7c54cb0c0cf8cb013d88ad3c2989ec323323235.
>
>> powerpc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/e92fc7bac808e708e1aadd1b8e6677d003e5bbe4/
>> arm | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/46d0907fe06a7b93bb092ad4bf869a2e0030cf32/
>> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/9ef4d4f5d793f9a854d3a398d00eec6ce9b59178/
>> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/74e22545f50c9f9e7f12208a1cb9cbb9154a6150/
>> powerpc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/5438729ded4bf9887a1dc080366aee9abf27fb19/
>> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/99ef4325d424569bbd900d6590b8a3a5e445c140/
>> arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/caded0b9ff89ba69cb3775d5fef18565a85a398a/
>> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/b81bcc845a091ff1182df7dec306492b67db10ea/
>> xtensa | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/29241cbf4791947e8bd990253716d8d43e219c23/
>> mips64el | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/648507a680fa0360622ad1fdd47fdf30d3c54091/
>> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/dea9364e8d8276bbcf42847822ef5da905cd7007/
>> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/adcea53d916e0825cb5963768304dfe883d5d379/
>> microblazeel | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/41ee80a733bc676d07d8296b262125b616070835/
>> xtensa | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/2c555d574540caf3a3b1ed64502274d3ba1f551b/
>> arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/316dc6221a50537234e4b3e88268363d61b9bf59/
>> arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/d4eb7cdbfd1152bb5a2a80f832c5edf524852701/
>> sh4 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/3bb3e2b683eabe7a6a9626f083b761b158a418ba/
>> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/0e2f3f4e4fa9dca521206d52fc061709534be12b/
>> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/84f5d3417ef5cdb826435b0029ddc8d2e9e4ec44/
>> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/428cb84d3bde356050b04647a599aea0fae6aeff/
>
> Some of these are the isnan() declaration issue, which is now fixed
> thanks to
> https://git.busybox.net/buildroot/commit/?id=640b75c8d73d713c908d6b288802c9e6bffe76ed.
>
> However, there is still the FE_* definition problem. J?rg, do you have
> something in the works to fix this ?
>
>> arm | canfestival-7740ac6fdedc23e... | NOK | http://autobuild.buildroot.net/results/5c5a48b050223d5f4f66a3a5ddde12cb17e310d7/
>
> musl build issue. There was a thread in August between Yann and Brendan
> about this. I pinged the thread.
>
>> arm | chocolate-doom-2.2.1 | NOK | http://autobuild.buildroot.net/results/20019b0daebf1aaf44e0802603108ff712f60513/
>
> In static linking configurations, when SDL_mixer is linked against
> libmad, chocolate-doom doesn't pass -lmad. To fix this, we need to:
>
> * Fix SDL_mixer.pc so that it references libmad in Libs.private (or
> Requires.private ?)
>
> * Either use pkg-config directly in chocolate-doom.mk to pass the
> appropriate flags, or change the chocolate-doom build system itself.
>
> Note that a similar problem might appear when SDL_mixer is linked
> against vorbis.
>
> Rodrigo, since you added the chocolate-doom package, can you look into
> fixing this ?
>
>> microblazeel | code/CMakeFiles/assimp.dir/... | TIM | http://autobuild.buildroot.net/results/50b9c93c0ee080c42362fd6d210745446077d7f5/
>
> Don't care.
>
>> arm | dvbsnoop-1.4.50 | NOK | http://autobuild.buildroot.net/results/2040d919e9d2564cf283ab815bea5ef34840ee61/
>
> musl build issue. Carsten, you added this package back in 2013, can you
> have a look ?
>
>> aarch64 | erlang-17.5 | NOK | http://autobuild.buildroot.net/results/0cd22eb74fa29e5a85bf897762e16ab3daf33962/
>
> Build problem due to atomic intrinsics:
>
> more undefined references to `__atomic_store_16' follow
>
> Frank, can you investigate why it builds on x86_64 but not on aarch64 ?
>
>> x86_64 | faifa-v0.1 | NOK | http://autobuild.buildroot.net/results/617e5635e0c508f82043f21886b6ce9a30549ad2/
>
> Classical musl build issue. Maxime, you added this package, so can you
> fix it ? :-)
Yep, I'll cook up some patch for this.
>
>> mips64el | ffmpeg-2.8.4 | NOK | http://autobuild.buildroot.net/results/12ef8ee60b3c016e8998ff240a6dc51e682f3058/
>> mips64el | ffmpeg-2.8.4 | NOK | http://autobuild.buildroot.net/results/a964ce679fed3eaaebd0ee2f39639d8243e227ef/
>
> ERROR: fontconfig not found using pkg-config
>
> Bernd, Vicente ?
>
>> microblazeel | flann-04b4a56533faf8c8228d0... | NOK | http://autobuild.buildroot.net/results/6126357850f15fb97828cd1b186e71ced83716eb/
>
> internal compiler error: in gen_reg_rtx, at emit-rtl.c:838
>
> To be tested with the latest gcc version, and potentially report a gcc
> bug.
>
> Davide, you added this package back in 2014. Can you have a look ?
>
>> microblazeel | fxload-2008_10_13 | NOK | http://autobuild.buildroot.net/results/4fa96981077c61599cc04b7c0f96b9f430f17f85/
>
> Binutils issue this time:
>
> /tmp/ccQKhnE1.s: Assembler messages:
> /tmp/ccQKhnE1.s: Error: PC relative branch to label logerror which is not in the instruction space
> /tmp/ccQKhnE1.s: Error: PC relative branch to label logerror which is not in the instruction space
>
> Same deal: test with the latest binutils version, and report a bug if
> the problem still exists.
>
> Jeremy, you added the fxload package, can you have a look ?
>
>
>> i686 | gst1-plugins-bad-1.6.2 | NOK | http://autobuild.buildroot.net/results/fab7afc3490d77a6b29760394337298f2fd55d51/
>> x86_64 | gst1-plugins-bad-1.6.2 | NOK | http://autobuild.buildroot.net/results/4da1b0454fe7bf028a62058d28dafda104fb75f4/
>
> gstdvbsrc.c: In function 'gst_dvbsrc_code_rate_get_type':
> gstdvbsrc.c:273:6: error: 'FEC_2_5' undeclared (first use in this function)
> gstdvbsrc.c:273:6: note: each undeclared identifier is reported only once for each function it appears in
> gstdvbsrc.c: In function 'gst_dvbsrc_modulation_get_type':
> gstdvbsrc.c:303:6: error: 'QAM_4_NR' undeclared (first use in this function)
> gstdvbsrc.c:303:5: error: initializer element is not constant
> gstdvbsrc.c:303:5: error: (near initialization for 'modulation_types[13].value')
>
> Not sure. Peter, Gustavo ?
>
>> sparc | harfbuzz-1.1.3 | NOK | http://autobuild.buildroot.net/results/30dec74537539dcbfa97eb9f90f40b2a814830d1/
>
> hb-warning.cc:32:2: error: #error "Could not find any system to define atomic_int macros, library WILL NOT be thread-safe"
> #error "Could not find any system to define atomic_int macros, library WILL NOT be thread-safe"
> ^
> hb-warning.cc:33:2: error: #error "Check hb-atomic-private.hh for possible resolutions."
> #error "Check hb-atomic-private.hh for possible resolutions."
>
> Gustavo, maybe we simply should disable this package on Sparc ? Only
> annoyance is that it is selected by Pango, which means that all reverse
> dependencies of Pango would have to be fixed :-/
>
> Another idea ?
>
>> aarch64 | hidapi-d17db57b9d4354752e0a... | NOK | http://autobuild.buildroot.net/results/7d70b7dac91209d1a63c131e9eb098bd8be3e84c/
>
> make[3]: *** No rule to make target `hidtest.o', needed by `hidtest-libusb'. Stop.
>
> Vicente, you added this package, can you have a look ?
>
>> powerpc | host-python3-3.4.3 | NOK | http://autobuild.buildroot.net/results/49d02998eeb5817d92574f61f6786a4f5c71d131/
>
> Modules/getbuildinfo.o: file not recognized: File truncated
> collect2: error: ld returned 1 exit status
>
> Ooch, smells like a parallel build issue... but building Python with
> make -j1 would really be horrible :-/
>
>> nios2 | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/e8e730f90357fd9818d19ae48b7533c8c5dcbc49/
>> arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/3c673e550535d741d2773e359ed2bebaebad6ad2/
>> bfin | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/5d526c4348a0ab3d802a9ef795096b2bfd1b3515/
>> arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/e64262b0045195892b2c7ed08cfef8f5682b9793/
>> x86_64 | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/844424b9db5ced38f90936fdc96eba480de34459/
>> bfin | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/3ef4945e7c51f354eb4444fc40f50ba0e86929e9/
>> arc | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/cec1c9d0723d72693d526dcfc3e9432b7694911f/
>
> Issue specific to this autobuilder instance, I'll have a look at this
> one.
>
>> arm | httping-2.4 | NOK | http://autobuild.buildroot.net/results/f88f0dd592a52128d250b2c8668a524d6ca35d24/
>
> Improper libintl handling. Gustavo, you bumped this package last year,
> can you have a look ?
>
>> arm | imx-kobs-3.14.28-1.0.0 | NOK | http://autobuild.buildroot.net/results/05a159c7f8382237d4c941b1bb6de7dad72708f3/
>
> Gary, can you have a look ?
>
>> arm | iprutils-2.4.5 | NOK | http://autobuild.buildroot.net/results/61e121c25fc07083bcccedfcb4f938d18f5c5456/
>
> Musl build issue:
>
> iprlib.h:49:27: fatal error: bits/sockaddr.h: No such file or directory
> #include <bits/sockaddr.h>
>
> Romain, you bumped this package recently, can you have a look ?
>
>> arm | ipsec-tools-0.8.2 | NOK | http://autobuild.buildroot.net/results/ce0bb96971147669c1bb253ce259eb5756f1d85e/
>
> Musl build issue. Gustavo, can you have a look ?
>
>> x86_64 | iputils-s20121011 | NOK | http://autobuild.buildroot.net/results/12cb73f3def95efe706bcd957bc2c091e7931d5a/
>
> Musl build issue. Matt, can you have a look ?
>
>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/ae9eca750d27f80cf8b0743f41cdfcc50ea476f1/
>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/dca1ba4a15cd9326a43e99d78bd13021bc87d9a2/
>
> Romain, I don't remember what was the conclusion about this issue. I
> remember we discussed it at some point.
>
>> sparc | libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/fa0ac44d3c7953b2e2afa03cd7570d8a5d49fcc4/
>
> Waldemar, this is a sparc problem, can you look into it ?
>
>> mips | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/cf7fd3dc8a1373c6c963a83e55d093b945f90f1a/
>> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/a7dd03a12c06a1f01826f01f91b39af396dca0d8/
>> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/a39a87c6547c9daa27e8a257c9e573d4c222fca4/
>> mips | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/f09b5d6120203cd5ddc60951828f880905297bcb/
>> mips | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/108cdfac94e88bfdc318e0689295a3799cc23069/
>> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/c14cabcc51f6870a0ab2381b32220d944590669f/
>> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/f05e78f97928c5da48678cdf2e465d413fd5feca/
>> mips | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/0094b3f30f8815fa5ef10afb3b0e506549ee8674/
>> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/4de0087f2bf63612c4354970d8307be7fa8beefd/
>> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/5d9f963a30eea53dd22f0b0d6f0d63592114977a/
>> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/0616fba52db8793ea5ac1383c47a86a72aae682f/
>> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/e2d5f87095f877c9ff7807419014e4af8b43130b/
>> mips | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/4dc9605b801518aa8075972e46e83d4df98cdbb5/
>> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/26dd14f492e4a544400f2d2c6800ee5cde4a0b1f/
>> mips | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/8c668a64b6b9ed4ba7a77c3d3211a41de89c33b6/
>
> Vicente, we really need to solve this problem :)
>
>> arm | libnss-3.21 | NOK | http://autobuild.buildroot.net/results/9ba9e0c148110b69763c12e37a37738deab3f118/
>
> /home/buildroot/autobuild/run/instance-1/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/lib/libnspr4.so: undefined reference to `getprotobyname_r'
> /home/buildroot/autobuild/run/instance-1/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/lib/libnspr4.so: undefined reference to `getprotobynumber_r'
>
> Musl build issue.
>
>> powerpc | libnss-3.21 | NOK | http://autobuild.buildroot.net/results/cef2fe3d87b742743a54a2fdbc585771e175a9e6/
>
> In file included from secoid.c:1915:0:
> verref.h: In function 'SECOID_Init':
> verref.h:22:9: error: #pragma GCC diagnostic not allowed inside functions
> verref.h:23:9: error: #pragma GCC diagnostic not allowed inside functions
> cc1: warnings being treated as errors
>
> old compiler problem.
>
>> i686 | lighttpd-1.4.39 | NOK | http://autobuild.buildroot.net/results/13faa9ebce00359b8943775364a432ce422fe8b8/
>
> mod_magnet.c: In function 'magnet_status_set':
> mod_magnet.c:415:2: warning: implicit declaration of function 'luaL_checkint' [-Wimplicit-function-declaration]
> mod_magnet.c: In function 'magnet_copy_response_header':
> mod_magnet.c:692:2: warning: implicit declaration of function 'lua_getfenv' [-Wimplicit-function-declaration]
> mod_magnet.c: In function 'traceback':
> mod_magnet.c:839:18: error: 'LUA_GLOBALSINDEX' undeclared (first use in this function)
> mod_magnet.c:839:18: note: each undeclared identifier is reported only once for each function it appears in
> mod_magnet.c: In function 'magnet_attract':
> mod_magnet.c:987:19: error: 'LUA_GLOBALSINDEX' undeclared (first use in this function)
> mod_magnet.c:992:2: warning: implicit declaration of function 'lua_setfenv' [-Wimplicit-function-declaration]
>
> Fran?ois, this seems to be Lua related, can you have a look ?
>
>> arm | linux-firmware-bbe4917c054e... | TIM | http://autobuild.buildroot.net/results/fc6001a9fcaeab2a67d03d5809360de00c16392a/
>
> Ignore.
>
>> sparc | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/faa42138e2b5a07b965926e55b831cb6e8eb3c0c/
>
> `undefined__sig_stub 'reference
>
>> sparc64 | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/85e181c2f75037e0d9b9a7bd288d9fdaa828bb34/
>
> undefined toreference `to__rt_sig_stub '`
>
> Waldemar, can you have a look ?
>
>> arm | luabitop-1.0.2-1 | NOK | http://autobuild.buildroot.net/results/80d137d91e6f6173e29074cf12a38f192ce0d7ca/
>> xtensa | luabitop-1.0.2-1 | NOK | http://autobuild.buildroot.net/results/15a0e4c3879eb56604fa88c2e31be641e933afa7/
>> aarch64 | luabitop-1.0.2-1 | NOK | http://autobuild.buildroot.net/results/39d2bae1398bd17891a9d0d2f698340fc7dca591/
>> i686 | luabitop-1.0.2-1 | NOK | http://autobuild.buildroot.net/results/7ac0eb736ad264c59637059ce207989c392f00f7/
>> aarch64 | luabitop-1.0.2-1 | NOK | http://autobuild.buildroot.net/results/a95d9b6eee7b41a0ce4cf6456fde08291cd8b860/
>
> Fixed by https://git.busybox.net/buildroot/commit/?id=be5d265220f36df7e0b633fcc55e3a33b2e74035
>
>> microblazeel | make[3]: *** [code/CMakeFil... | TIM | http://autobuild.buildroot.net/results/8df9f0dd9cbc0446c0458d89cb182d0feb795774/
>
> Ignore.
>
>> arc | mesa3d-11.1.0 | NOK | http://autobuild.buildroot.net/results/7b3f5c0e3c59bd49614e8ad4eee3d89e3527a939/
>
> Compiler problem, issue is known by Synopsys.
>
>> sparc64 | moarvm-2015.10 | NOK | http://autobuild.buildroot.net/results/268e328e2d9ea951c0728ab6031d32e2b460d015/
>> sparc64 | moarvm-2015.10 | NOK | http://autobuild.buildroot.net/results/84847a9201244fce3e05e5e4e201f2e1848238de/
>
> ./libmoar.so: undefined reference to `AO_fetch_compare_and_swap_full'
>
> Waldemar, can you have a look ?
>
>> powerpc | nfs-utils-1.3.3 | NOK | http://autobuild.buildroot.net/results/948f81d7ed2c080a675ee9fec754f6fda1fd905f/
>
> Not sure:
>
> cache.c: In function 'same_path':
> cache.c:429:22: error: field 'fh' has incomplete type
> cache.c:436:2: warning: implicit declaration of function 'name_to_handle_at' [-Wimplicit-function-declaration]
> Makefile:613: recipe for target 'mountd-cache.o' failed
>
> Maxime, can you have a look ?
I will look at it, the errors is a bit puzzling but I only glanced at
it for now.
>
>> arm | nut-2.7.2 | NOK | http://autobuild.buildroot.net/results/8fb9cb823d723903f11d70325b0ea09e103504cf/
>
> checking whether to build SNMP drivers... yes
> configure: error: "neon libraries not found, required for neon based XML/HTTP driver"
>
> Most likely a static linking problem.
>
> Yann, you added the nut package, so ... :-)
>
>> sparc64 | opencv-2.4.10 | NOK | http://autobuild.buildroot.net/results/84cfdfa21205954cb8f0e5541332570ba5206add/
>
> Another atomic related problem. Waldemar ?
>
>> arm | openpgm-release-5-2-122 | NOK | http://autobuild.buildroot.net/results/aa2cf491dfb199a349afd107046f428107a583a0/
>
> Musl build issue:
>
> ./include/pgm/gsi.h:47:75: error: unknown type name 'ssize_t'
> bool pgm_gsi_create_from_string (pgm_gsi_t*restrict, const char*restrict, ssize_t);
>
> Anyone to look into this?
>
>> mipsel | pinentry-0.9.4 | NOK | http://autobuild.buildroot.net/results/d8d6414ae28d9ea84118dfa5c0f73d9334a1c417/
>
> error: member 'QChar std::__cxx11::basic_string<QChar, std::char_traits<QChar>, secmem::alloc<QChar> >::<anonymous union>::_M_local_buf [8]' with constructor not allowed in union
> _CharT _M_local_buf[_S_local_capacity + 1];
>
> Anyone understands this ?
>
>> arc | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/a85a1839a45fb6102e53131ecc8f6dadf92bcdc2/
>
> Static linking, I'm assuming this *could* be fixed by
> https://git.busybox.net/buildroot/commit/?id=12009bb92931b153823110f811632540044d3b02,
> though I am not sure. Alexey ?a
>
>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/199b8ed788e4ca3eca03b95710a3bb644d81d187/
>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/546f94ee09fcff27ea2d7c6cebb0b48aec1881f8/
>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/bb90227b6a18bde0cef45f82620de560d48866e7/
>
> Compiler problem. I don't remember if I reported it.
>
>> arm | rabbitmq-c-0.7.1 | NOK | http://autobuild.buildroot.net/results/2ef1ed958db8012224f9174334e9c58edace604a/
>
> Static linking problem. Joris, can you have a look ?
>
>> sh4 | rpm-5.2.0 | NOK | http://autobuild.buildroot.net/results/499f2a3204a6afab96322c431732541fefd622e8/
>
> Internal compiler error...
>
>> arc | ruby-2.3.0 | NOK | http://autobuild.buildroot.net/results/8e98934b066d4973d88e7d28b042b99550d68ae8/
>
> Compiler issue:
>
> /tmp/cctdImle.s: Assembler messages:
> /tmp/cctdImle.s:2253: Error: invalid register number `63'
> /tmp/cctdImle.s:2255: Error: invalid register number `63'
>
> Alexey ?
>
>> powerpc | ruby-2.3.0 | NOK | http://autobuild.buildroot.net/results/d0a77147cba429bb42f102141810a23e831a8bcb/
>
> Compiler issue:
>
> eval.c: In function 'rb_protect':
> eval.c:881:1: internal compiler error: in move_insn, at haifa-sched.c:3439
>
>> arc | ruby-2.3.0 | NOK | http://autobuild.buildroot.net/results/748771df79b8537d3f4baeb1f7d423dec1f8c519/
>
> Same ARC compiler issue as above.
>
>> arm | sane-backends-1.0.25 | NOK | http://autobuild.buildroot.net/results/9759238db294c0703e8c685f2adc41dba3fdb31f/
>
> ../backend/.libs/libsane.a(libepsonds_la-epsonds.o):(.bss+0x10): multiple definition of `source_list'
> ../backend/.libs/libsane.a(libepson2_la-epson2.o):(.data+0x40): first defined here
> ../backend/.libs/libsane.a(libepsonds_la-epsonds.o):(.data+0x10): multiple definition of `mode_params'
> ../backend/.libs/libsane.a(libepson2_la-epson2.o):(.data+0x0): first defined here
>
> Vicente, you bumped sane-backends recently, can you have a look ?
>
>> mips64el | sconeserver-3b886c3dda6eda3... | NOK | http://autobuild.buildroot.net/results/be8d1ad7c05b39f8ed65b86f938bc2d9530e3c6d/
>
> Static linking issue, most likely:
>
> checking for mysql_init in -lmysqlclient... no
> configure: error: library 'mysqlclient' is required for the mysql module
>
> Anyone interested ?
>
>> arc | trousers-0.3.13 | NOK | http://autobuild.buildroot.net/results/c3d3bedffe0f4ba40f33d18e90a4802f4a7bfffb/
>
> PIE problem, under discussion.
>
>> arm | tstools-08f6be304040e7b8476... | NOK | http://autobuild.buildroot.net/results/357de0b07b2104e0c94cb3d21ca2096df0796071/
>
> Tries to build a shared library, in a static linking scenario. Anyone ?
>
>> xtensa | uboot-tools-2015.10 | NOK | http://autobuild.buildroot.net/results/64ac87a2a4847a45fc96cfaa4ded7f0821f66701/
>> xtensa | uboot-tools-2015.10 | NOK | http://autobuild.buildroot.net/results/9ebc5e3a6f1dd3ceb90d6786a1c5455c965f819e/
>> microblazeel | uboot-tools-2015.10 | NOK | http://autobuild.buildroot.net/results/a197f03c1751a87c7f71e057f2c4619538b4b6c8/
>
> Patch pending to fix this.
>
>> xtensa | unknown | NOK | http://autobuild.buildroot.net/results/f913556517654f833bf17f141597ba41570b02b7/
>> arm | unknown | NOK | http://autobuild.buildroot.net/results/865ce538e3dc3ce8005a39b5400fc3f019d7a411/
>> arm | unknown | NOK | http://autobuild.buildroot.net/results/0581889edfb7bf5ca0f23e3111ac6eeffbee3376/
>> mips64el | unknown | NOK | http://autobuild.buildroot.net/results/1abb03babacacf13db33ae9fe89b5d52925b58b1/
>
> 2 different dependency problems.
>
>> arm | util-linux-2.27.1 | NOK | http://autobuild.buildroot.net/results/2ca06e6bb9b147a44400e26acdd41dcc3ab7d9e4/
>
> checking for prlimit... no
> configure: error: flock selected, but required timer_create function not available
>
> Static linking issue. Anyone ?
>
>> mips | valgrind-3.11.0 | NOK | http://autobuild.buildroot.net/results/a00f4856c4094508334477296d0ec203466fe56e/
>
> Vicente, this one is for you :)
>
>> arm | vpnc-0.5.3 | NOK | http://autobuild.buildroot.net/results/aacb5ae636e2ae2df67a91696b1d2af276777b22/
>
> Yet another static linking issue caused by libintl.
>
>> nios2 | zbar-854a5d97059e395807091a... | NOK | http://autobuild.buildroot.net/results/d4a9e291ad1b36bd268b4b850aa10be3ac00b6d9/
>> arm | zbar-854a5d97059e395807091a... | NOK | http://autobuild.buildroot.net/results/c9cdee9e5cd031e5927b7aa26d92c48dbe35c1e7/
>
> Really bogus code triggers a warning that is now an error. Volkov, you
> added the zbar package, can you have a look ?
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-17 11:23 ` Thomas Petazzoni
@ 2016-01-17 16:33 ` Frank Hunleth
2016-01-23 1:05 ` Frank Hunleth
0 siblings, 1 reply; 416+ messages in thread
From: Frank Hunleth @ 2016-01-17 16:33 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Sun, Jan 17, 2016 at 6:23 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Sat, 16 Jan 2016 20:42:55 -0500, Frank Hunleth wrote:
>
>> > Frank, can you investigate why it builds on x86_64 but not on aarch64 ?
>>
>> I looked into this a little. My suspicion is that the atomic intrinsic
>> macros in the Erlang code have not been ported to aarch64, but I'm
>> having trouble following the code. I've inquired on the Erlang mailing
>> list and will report back.
It turns out that other people have gotten Erlang to work on aarch64
without libatomic_ops installed. That doesn't work for Buildroot since
other programs could depend on libatomic_ops. I've filed a bug against
Erlang to track this at http://bugs.erlang.org/browse/ERL-78.
Specifying '--disable-native-ethr-impls' to ./configure seems to
workaround the issue, but I don't know if it has other consequences.
Hopefully the Erlang maintainers will get to this sooner rather than
later, but they're a pretty busy group.
Regards,
Frank
>
> Excellent, thanks a lot!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-16 23:11 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2016-01-17 1:42 ` Frank Hunleth
@ 2016-01-17 15:06 ` Matthew Weber
2016-01-17 17:26 ` Thomas Petazzoni
2016-01-17 17:10 ` Maxime Hadjinlian
` (7 subsequent siblings)
9 siblings, 1 reply; 416+ messages in thread
From: Matthew Weber @ 2016-01-17 15:06 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Sat, Jan 16, 2016 at 5:11 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> Gustavo, Vicente, J?rg, Frank, Bernd, Maxime, Carsten, Davide, Jeremy,
> VIcente, Gilles, Gary, Romain, Matt, Waldemar, Fran?ois, Alexey, Joris,
> Volkov: there are some specific build failures for which your help
> would be appreciated. See below. Thanks in advance for your help!
>
<snip>
>> x86_64 | iputils-s20121011 | NOK | http://autobuild.buildroot.net/results/12cb73f3def95efe706bcd957bc2c091e7931d5a/
>
> Musl build issue. Matt, can you have a look ?
Looks like the development was moved to github and there have been
updates to support uClibc and musl-libc. I'll work on a patch to
update the upstream location and hopefully also remove the one patch
that package has for a ping issue.
Thanks,
Matt
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-17 1:42 ` Frank Hunleth
@ 2016-01-17 11:23 ` Thomas Petazzoni
2016-01-17 16:33 ` Frank Hunleth
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2016-01-17 11:23 UTC (permalink / raw)
To: buildroot
Hello,
On Sat, 16 Jan 2016 20:42:55 -0500, Frank Hunleth wrote:
> > Frank, can you investigate why it builds on x86_64 but not on aarch64 ?
>
> I looked into this a little. My suspicion is that the atomic intrinsic
> macros in the Erlang code have not been ported to aarch64, but I'm
> having trouble following the code. I've inquired on the Erlang mailing
> list and will report back.
Excellent, thanks a lot!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-16 23:11 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2016-01-17 1:42 ` Frank Hunleth
2016-01-17 11:23 ` Thomas Petazzoni
2016-01-17 15:06 ` Matthew Weber
` (8 subsequent siblings)
9 siblings, 1 reply; 416+ messages in thread
From: Frank Hunleth @ 2016-01-17 1:42 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Sat, Jan 16, 2016 at 6:11 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> Gustavo, Vicente, J?rg, Frank, Bernd, Maxime, Carsten, Davide, Jeremy,
> VIcente, Gilles, Gary, Romain, Matt, Waldemar, Fran?ois, Alexey, Joris,
> Volkov: there are some specific build failures for which your help
> would be appreciated. See below. Thanks in advance for your help!
>
> On Sat, 16 Jan 2016 08:30:21 +0100 (CET), Thomas Petazzoni wrote:
>
>> xtensa | alsa-utils-1.1.0 | NOK | http://autobuild.buildroot.net/results/1bf954501960db802c3e2280b30b70d6813bdb32/
>> arm | alsa-utils-1.1.0 | NOK | http://autobuild.buildroot.net/results/7ba954e03822d758e25356935b0dfc2c91d3712a/
>
> <dlfcn.h> needed by the topology code. Fixed in
> https://git.busybox.net/buildroot/commit/?id=4707383c5d501a9ad7698579e5d0a4e2ab758c7e.
>
>> bfin | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/a5558d054ab19f078d0992f8b691f35f3f1323c0/
>
> Compiler error, in FLAT mode. Not sure what's going on, as I was able
> to build assimp properly in a minimal Blackfin FLAT configuration.
>
>> bfin | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/f0d25c8b08ba32361d47bd6bc344695f168396de/
>> bfin | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/3f143ea946ad98176d8e5eaddecfa0bda11c0439/
>> sparc64 | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/510c59e13f1412ffb831801e6389a32a76b543b6/
>> sparc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/3f6f7a72bec601688991111f21e897306b1d76ca/
>> xtensa | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/5eab445d66a977cdfb73a6b5dede6af692c28b16/
>> xtensa | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/a511687d937c2575d8edffe9235b1507be1c9442/
>> bfin | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/eb659085949c6b62108b8c46c50e8abd01681f23/
>> bfin | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/4f3c001e8fa6781c4a2ca9d82023f959b7897035/
>> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/5a90ba61c5ac863a7779af7783c7b0584a0c79e3/
>> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/a70ec3a94a18db77f094c71d8be055ae0d99862b/
>> xtensa | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/c0a57f9a03c308dcf8129d300d12f4a7d6d999de/
>> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/d37761e95f2f45e92ef641e7117ff6d02f2865d1/
>> xtensa | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/651efb92cd38569a1c53000c642b37a5c4b21115/
>> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/498380d65b3e3d604a36facec894fc60a30a5d74/
>> mips | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/37ce98706477b259da4e9527878aeada2d52366c/
>> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/686755f4f925811fccbdadbe28ba7561af8c51ad/
>> bfin | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/2f46b77f27ca7df9ae80ecaa6fdca6d981eeb8ff/
>> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/7be9e4860ca47f8906c355577d71c0c6e8d597be/
>> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/c0bc9693cfbac282599c73e7f0b6dd19e41bbfa3/
>> xtensa | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/23b6e683aa3db28d2103e47fd263dc9c5afd99b8/
>> xtensa | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/903515ab22c112dacf1583fff77c859c6f68985d/
>> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/23e03277f61490b6f48035075df0fc5e5474168f/
>
> I guess most if not all of these are fixed by
> https://git.busybox.net/buildroot/commit/?id=25ba49518a93265ecb3146e6eb21a2a138989100
> and
> https://git.busybox.net/buildroot/commit/?id=9ebac3bd050ee57cdd8a5ede053aed5522f5e8dc.
>
>> mipsel | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/c4f88c724829e1a2ff152c756ea3dae80fef149c/
>> mips64el | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/870879c3d20dcfb327329fab0d8c13f320fd5788/
>> mipsel | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/1d1889f407adce09f313e8660f8b660f256ea277/
>
> Vicente, Gustavo, can you have a look at those issues? It seems to be
> limited to MIPS, and I don't think it was happening before the recent
> bump of the bind package.
>
>> arm | bluez5_utils-5.37 | NOK | http://autobuild.buildroot.net/results/83112559d84dc156141339a31e3e02f1a2af5155/
>
> Fixed by
> https://git.busybox.net/buildroot/commit/?id=d7c54cb0c0cf8cb013d88ad3c2989ec323323235.
>
>> powerpc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/e92fc7bac808e708e1aadd1b8e6677d003e5bbe4/
>> arm | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/46d0907fe06a7b93bb092ad4bf869a2e0030cf32/
>> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/9ef4d4f5d793f9a854d3a398d00eec6ce9b59178/
>> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/74e22545f50c9f9e7f12208a1cb9cbb9154a6150/
>> powerpc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/5438729ded4bf9887a1dc080366aee9abf27fb19/
>> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/99ef4325d424569bbd900d6590b8a3a5e445c140/
>> arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/caded0b9ff89ba69cb3775d5fef18565a85a398a/
>> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/b81bcc845a091ff1182df7dec306492b67db10ea/
>> xtensa | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/29241cbf4791947e8bd990253716d8d43e219c23/
>> mips64el | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/648507a680fa0360622ad1fdd47fdf30d3c54091/
>> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/dea9364e8d8276bbcf42847822ef5da905cd7007/
>> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/adcea53d916e0825cb5963768304dfe883d5d379/
>> microblazeel | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/41ee80a733bc676d07d8296b262125b616070835/
>> xtensa | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/2c555d574540caf3a3b1ed64502274d3ba1f551b/
>> arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/316dc6221a50537234e4b3e88268363d61b9bf59/
>> arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/d4eb7cdbfd1152bb5a2a80f832c5edf524852701/
>> sh4 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/3bb3e2b683eabe7a6a9626f083b761b158a418ba/
>> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/0e2f3f4e4fa9dca521206d52fc061709534be12b/
>> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/84f5d3417ef5cdb826435b0029ddc8d2e9e4ec44/
>> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/428cb84d3bde356050b04647a599aea0fae6aeff/
>
> Some of these are the isnan() declaration issue, which is now fixed
> thanks to
> https://git.busybox.net/buildroot/commit/?id=640b75c8d73d713c908d6b288802c9e6bffe76ed.
>
> However, there is still the FE_* definition problem. J?rg, do you have
> something in the works to fix this ?
>
>> arm | canfestival-7740ac6fdedc23e... | NOK | http://autobuild.buildroot.net/results/5c5a48b050223d5f4f66a3a5ddde12cb17e310d7/
>
> musl build issue. There was a thread in August between Yann and Brendan
> about this. I pinged the thread.
>
>> arm | chocolate-doom-2.2.1 | NOK | http://autobuild.buildroot.net/results/20019b0daebf1aaf44e0802603108ff712f60513/
>
> In static linking configurations, when SDL_mixer is linked against
> libmad, chocolate-doom doesn't pass -lmad. To fix this, we need to:
>
> * Fix SDL_mixer.pc so that it references libmad in Libs.private (or
> Requires.private ?)
>
> * Either use pkg-config directly in chocolate-doom.mk to pass the
> appropriate flags, or change the chocolate-doom build system itself.
>
> Note that a similar problem might appear when SDL_mixer is linked
> against vorbis.
>
> Rodrigo, since you added the chocolate-doom package, can you look into
> fixing this ?
>
>> microblazeel | code/CMakeFiles/assimp.dir/... | TIM | http://autobuild.buildroot.net/results/50b9c93c0ee080c42362fd6d210745446077d7f5/
>
> Don't care.
>
>> arm | dvbsnoop-1.4.50 | NOK | http://autobuild.buildroot.net/results/2040d919e9d2564cf283ab815bea5ef34840ee61/
>
> musl build issue. Carsten, you added this package back in 2013, can you
> have a look ?
>
>> aarch64 | erlang-17.5 | NOK | http://autobuild.buildroot.net/results/0cd22eb74fa29e5a85bf897762e16ab3daf33962/
>
> Build problem due to atomic intrinsics:
>
> more undefined references to `__atomic_store_16' follow
>
> Frank, can you investigate why it builds on x86_64 but not on aarch64 ?
I looked into this a little. My suspicion is that the atomic intrinsic
macros in the Erlang code have not been ported to aarch64, but I'm
having trouble following the code. I've inquired on the Erlang mailing
list and will report back.
Regards,
Frank
>
>> x86_64 | faifa-v0.1 | NOK | http://autobuild.buildroot.net/results/617e5635e0c508f82043f21886b6ce9a30549ad2/
>
> Classical musl build issue. Maxime, you added this package, so can you
> fix it ? :-)
>
>> mips64el | ffmpeg-2.8.4 | NOK | http://autobuild.buildroot.net/results/12ef8ee60b3c016e8998ff240a6dc51e682f3058/
>> mips64el | ffmpeg-2.8.4 | NOK | http://autobuild.buildroot.net/results/a964ce679fed3eaaebd0ee2f39639d8243e227ef/
>
> ERROR: fontconfig not found using pkg-config
>
> Bernd, Vicente ?
>
>> microblazeel | flann-04b4a56533faf8c8228d0... | NOK | http://autobuild.buildroot.net/results/6126357850f15fb97828cd1b186e71ced83716eb/
>
> internal compiler error: in gen_reg_rtx, at emit-rtl.c:838
>
> To be tested with the latest gcc version, and potentially report a gcc
> bug.
>
> Davide, you added this package back in 2014. Can you have a look ?
>
>> microblazeel | fxload-2008_10_13 | NOK | http://autobuild.buildroot.net/results/4fa96981077c61599cc04b7c0f96b9f430f17f85/
>
> Binutils issue this time:
>
> /tmp/ccQKhnE1.s: Assembler messages:
> /tmp/ccQKhnE1.s: Error: PC relative branch to label logerror which is not in the instruction space
> /tmp/ccQKhnE1.s: Error: PC relative branch to label logerror which is not in the instruction space
>
> Same deal: test with the latest binutils version, and report a bug if
> the problem still exists.
>
> Jeremy, you added the fxload package, can you have a look ?
>
>
>> i686 | gst1-plugins-bad-1.6.2 | NOK | http://autobuild.buildroot.net/results/fab7afc3490d77a6b29760394337298f2fd55d51/
>> x86_64 | gst1-plugins-bad-1.6.2 | NOK | http://autobuild.buildroot.net/results/4da1b0454fe7bf028a62058d28dafda104fb75f4/
>
> gstdvbsrc.c: In function 'gst_dvbsrc_code_rate_get_type':
> gstdvbsrc.c:273:6: error: 'FEC_2_5' undeclared (first use in this function)
> gstdvbsrc.c:273:6: note: each undeclared identifier is reported only once for each function it appears in
> gstdvbsrc.c: In function 'gst_dvbsrc_modulation_get_type':
> gstdvbsrc.c:303:6: error: 'QAM_4_NR' undeclared (first use in this function)
> gstdvbsrc.c:303:5: error: initializer element is not constant
> gstdvbsrc.c:303:5: error: (near initialization for 'modulation_types[13].value')
>
> Not sure. Peter, Gustavo ?
>
>> sparc | harfbuzz-1.1.3 | NOK | http://autobuild.buildroot.net/results/30dec74537539dcbfa97eb9f90f40b2a814830d1/
>
> hb-warning.cc:32:2: error: #error "Could not find any system to define atomic_int macros, library WILL NOT be thread-safe"
> #error "Could not find any system to define atomic_int macros, library WILL NOT be thread-safe"
> ^
> hb-warning.cc:33:2: error: #error "Check hb-atomic-private.hh for possible resolutions."
> #error "Check hb-atomic-private.hh for possible resolutions."
>
> Gustavo, maybe we simply should disable this package on Sparc ? Only
> annoyance is that it is selected by Pango, which means that all reverse
> dependencies of Pango would have to be fixed :-/
>
> Another idea ?
>
>> aarch64 | hidapi-d17db57b9d4354752e0a... | NOK | http://autobuild.buildroot.net/results/7d70b7dac91209d1a63c131e9eb098bd8be3e84c/
>
> make[3]: *** No rule to make target `hidtest.o', needed by `hidtest-libusb'. Stop.
>
> Vicente, you added this package, can you have a look ?
>
>> powerpc | host-python3-3.4.3 | NOK | http://autobuild.buildroot.net/results/49d02998eeb5817d92574f61f6786a4f5c71d131/
>
> Modules/getbuildinfo.o: file not recognized: File truncated
> collect2: error: ld returned 1 exit status
>
> Ooch, smells like a parallel build issue... but building Python with
> make -j1 would really be horrible :-/
>
>> nios2 | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/e8e730f90357fd9818d19ae48b7533c8c5dcbc49/
>> arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/3c673e550535d741d2773e359ed2bebaebad6ad2/
>> bfin | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/5d526c4348a0ab3d802a9ef795096b2bfd1b3515/
>> arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/e64262b0045195892b2c7ed08cfef8f5682b9793/
>> x86_64 | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/844424b9db5ced38f90936fdc96eba480de34459/
>> bfin | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/3ef4945e7c51f354eb4444fc40f50ba0e86929e9/
>> arc | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/cec1c9d0723d72693d526dcfc3e9432b7694911f/
>
> Issue specific to this autobuilder instance, I'll have a look at this
> one.
>
>> arm | httping-2.4 | NOK | http://autobuild.buildroot.net/results/f88f0dd592a52128d250b2c8668a524d6ca35d24/
>
> Improper libintl handling. Gustavo, you bumped this package last year,
> can you have a look ?
>
>> arm | imx-kobs-3.14.28-1.0.0 | NOK | http://autobuild.buildroot.net/results/05a159c7f8382237d4c941b1bb6de7dad72708f3/
>
> Gary, can you have a look ?
>
>> arm | iprutils-2.4.5 | NOK | http://autobuild.buildroot.net/results/61e121c25fc07083bcccedfcb4f938d18f5c5456/
>
> Musl build issue:
>
> iprlib.h:49:27: fatal error: bits/sockaddr.h: No such file or directory
> #include <bits/sockaddr.h>
>
> Romain, you bumped this package recently, can you have a look ?
>
>> arm | ipsec-tools-0.8.2 | NOK | http://autobuild.buildroot.net/results/ce0bb96971147669c1bb253ce259eb5756f1d85e/
>
> Musl build issue. Gustavo, can you have a look ?
>
>> x86_64 | iputils-s20121011 | NOK | http://autobuild.buildroot.net/results/12cb73f3def95efe706bcd957bc2c091e7931d5a/
>
> Musl build issue. Matt, can you have a look ?
>
>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/ae9eca750d27f80cf8b0743f41cdfcc50ea476f1/
>> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/dca1ba4a15cd9326a43e99d78bd13021bc87d9a2/
>
> Romain, I don't remember what was the conclusion about this issue. I
> remember we discussed it at some point.
>
>> sparc | libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/fa0ac44d3c7953b2e2afa03cd7570d8a5d49fcc4/
>
> Waldemar, this is a sparc problem, can you look into it ?
>
>> mips | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/cf7fd3dc8a1373c6c963a83e55d093b945f90f1a/
>> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/a7dd03a12c06a1f01826f01f91b39af396dca0d8/
>> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/a39a87c6547c9daa27e8a257c9e573d4c222fca4/
>> mips | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/f09b5d6120203cd5ddc60951828f880905297bcb/
>> mips | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/108cdfac94e88bfdc318e0689295a3799cc23069/
>> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/c14cabcc51f6870a0ab2381b32220d944590669f/
>> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/f05e78f97928c5da48678cdf2e465d413fd5feca/
>> mips | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/0094b3f30f8815fa5ef10afb3b0e506549ee8674/
>> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/4de0087f2bf63612c4354970d8307be7fa8beefd/
>> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/5d9f963a30eea53dd22f0b0d6f0d63592114977a/
>> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/0616fba52db8793ea5ac1383c47a86a72aae682f/
>> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/e2d5f87095f877c9ff7807419014e4af8b43130b/
>> mips | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/4dc9605b801518aa8075972e46e83d4df98cdbb5/
>> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/26dd14f492e4a544400f2d2c6800ee5cde4a0b1f/
>> mips | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/8c668a64b6b9ed4ba7a77c3d3211a41de89c33b6/
>
> Vicente, we really need to solve this problem :)
>
>> arm | libnss-3.21 | NOK | http://autobuild.buildroot.net/results/9ba9e0c148110b69763c12e37a37738deab3f118/
>
> /home/buildroot/autobuild/run/instance-1/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/lib/libnspr4.so: undefined reference to `getprotobyname_r'
> /home/buildroot/autobuild/run/instance-1/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/lib/libnspr4.so: undefined reference to `getprotobynumber_r'
>
> Musl build issue.
>
>> powerpc | libnss-3.21 | NOK | http://autobuild.buildroot.net/results/cef2fe3d87b742743a54a2fdbc585771e175a9e6/
>
> In file included from secoid.c:1915:0:
> verref.h: In function 'SECOID_Init':
> verref.h:22:9: error: #pragma GCC diagnostic not allowed inside functions
> verref.h:23:9: error: #pragma GCC diagnostic not allowed inside functions
> cc1: warnings being treated as errors
>
> old compiler problem.
>
>> i686 | lighttpd-1.4.39 | NOK | http://autobuild.buildroot.net/results/13faa9ebce00359b8943775364a432ce422fe8b8/
>
> mod_magnet.c: In function 'magnet_status_set':
> mod_magnet.c:415:2: warning: implicit declaration of function 'luaL_checkint' [-Wimplicit-function-declaration]
> mod_magnet.c: In function 'magnet_copy_response_header':
> mod_magnet.c:692:2: warning: implicit declaration of function 'lua_getfenv' [-Wimplicit-function-declaration]
> mod_magnet.c: In function 'traceback':
> mod_magnet.c:839:18: error: 'LUA_GLOBALSINDEX' undeclared (first use in this function)
> mod_magnet.c:839:18: note: each undeclared identifier is reported only once for each function it appears in
> mod_magnet.c: In function 'magnet_attract':
> mod_magnet.c:987:19: error: 'LUA_GLOBALSINDEX' undeclared (first use in this function)
> mod_magnet.c:992:2: warning: implicit declaration of function 'lua_setfenv' [-Wimplicit-function-declaration]
>
> Fran?ois, this seems to be Lua related, can you have a look ?
>
>> arm | linux-firmware-bbe4917c054e... | TIM | http://autobuild.buildroot.net/results/fc6001a9fcaeab2a67d03d5809360de00c16392a/
>
> Ignore.
>
>> sparc | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/faa42138e2b5a07b965926e55b831cb6e8eb3c0c/
>
> `undefined__sig_stub 'reference
>
>> sparc64 | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/85e181c2f75037e0d9b9a7bd288d9fdaa828bb34/
>
> undefined toreference `to__rt_sig_stub '`
>
> Waldemar, can you have a look ?
>
>> arm | luabitop-1.0.2-1 | NOK | http://autobuild.buildroot.net/results/80d137d91e6f6173e29074cf12a38f192ce0d7ca/
>> xtensa | luabitop-1.0.2-1 | NOK | http://autobuild.buildroot.net/results/15a0e4c3879eb56604fa88c2e31be641e933afa7/
>> aarch64 | luabitop-1.0.2-1 | NOK | http://autobuild.buildroot.net/results/39d2bae1398bd17891a9d0d2f698340fc7dca591/
>> i686 | luabitop-1.0.2-1 | NOK | http://autobuild.buildroot.net/results/7ac0eb736ad264c59637059ce207989c392f00f7/
>> aarch64 | luabitop-1.0.2-1 | NOK | http://autobuild.buildroot.net/results/a95d9b6eee7b41a0ce4cf6456fde08291cd8b860/
>
> Fixed by https://git.busybox.net/buildroot/commit/?id=be5d265220f36df7e0b633fcc55e3a33b2e74035
>
>> microblazeel | make[3]: *** [code/CMakeFil... | TIM | http://autobuild.buildroot.net/results/8df9f0dd9cbc0446c0458d89cb182d0feb795774/
>
> Ignore.
>
>> arc | mesa3d-11.1.0 | NOK | http://autobuild.buildroot.net/results/7b3f5c0e3c59bd49614e8ad4eee3d89e3527a939/
>
> Compiler problem, issue is known by Synopsys.
>
>> sparc64 | moarvm-2015.10 | NOK | http://autobuild.buildroot.net/results/268e328e2d9ea951c0728ab6031d32e2b460d015/
>> sparc64 | moarvm-2015.10 | NOK | http://autobuild.buildroot.net/results/84847a9201244fce3e05e5e4e201f2e1848238de/
>
> ./libmoar.so: undefined reference to `AO_fetch_compare_and_swap_full'
>
> Waldemar, can you have a look ?
>
>> powerpc | nfs-utils-1.3.3 | NOK | http://autobuild.buildroot.net/results/948f81d7ed2c080a675ee9fec754f6fda1fd905f/
>
> Not sure:
>
> cache.c: In function 'same_path':
> cache.c:429:22: error: field 'fh' has incomplete type
> cache.c:436:2: warning: implicit declaration of function 'name_to_handle_at' [-Wimplicit-function-declaration]
> Makefile:613: recipe for target 'mountd-cache.o' failed
>
> Maxime, can you have a look ?
>
>> arm | nut-2.7.2 | NOK | http://autobuild.buildroot.net/results/8fb9cb823d723903f11d70325b0ea09e103504cf/
>
> checking whether to build SNMP drivers... yes
> configure: error: "neon libraries not found, required for neon based XML/HTTP driver"
>
> Most likely a static linking problem.
>
> Yann, you added the nut package, so ... :-)
>
>> sparc64 | opencv-2.4.10 | NOK | http://autobuild.buildroot.net/results/84cfdfa21205954cb8f0e5541332570ba5206add/
>
> Another atomic related problem. Waldemar ?
>
>> arm | openpgm-release-5-2-122 | NOK | http://autobuild.buildroot.net/results/aa2cf491dfb199a349afd107046f428107a583a0/
>
> Musl build issue:
>
> ./include/pgm/gsi.h:47:75: error: unknown type name 'ssize_t'
> bool pgm_gsi_create_from_string (pgm_gsi_t*restrict, const char*restrict, ssize_t);
>
> Anyone to look into this?
>
>> mipsel | pinentry-0.9.4 | NOK | http://autobuild.buildroot.net/results/d8d6414ae28d9ea84118dfa5c0f73d9334a1c417/
>
> error: member 'QChar std::__cxx11::basic_string<QChar, std::char_traits<QChar>, secmem::alloc<QChar> >::<anonymous union>::_M_local_buf [8]' with constructor not allowed in union
> _CharT _M_local_buf[_S_local_capacity + 1];
>
> Anyone understands this ?
>
>> arc | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/a85a1839a45fb6102e53131ecc8f6dadf92bcdc2/
>
> Static linking, I'm assuming this *could* be fixed by
> https://git.busybox.net/buildroot/commit/?id=12009bb92931b153823110f811632540044d3b02,
> though I am not sure. Alexey ?a
>
>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/199b8ed788e4ca3eca03b95710a3bb644d81d187/
>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/546f94ee09fcff27ea2d7c6cebb0b48aec1881f8/
>> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/bb90227b6a18bde0cef45f82620de560d48866e7/
>
> Compiler problem. I don't remember if I reported it.
>
>> arm | rabbitmq-c-0.7.1 | NOK | http://autobuild.buildroot.net/results/2ef1ed958db8012224f9174334e9c58edace604a/
>
> Static linking problem. Joris, can you have a look ?
>
>> sh4 | rpm-5.2.0 | NOK | http://autobuild.buildroot.net/results/499f2a3204a6afab96322c431732541fefd622e8/
>
> Internal compiler error...
>
>> arc | ruby-2.3.0 | NOK | http://autobuild.buildroot.net/results/8e98934b066d4973d88e7d28b042b99550d68ae8/
>
> Compiler issue:
>
> /tmp/cctdImle.s: Assembler messages:
> /tmp/cctdImle.s:2253: Error: invalid register number `63'
> /tmp/cctdImle.s:2255: Error: invalid register number `63'
>
> Alexey ?
>
>> powerpc | ruby-2.3.0 | NOK | http://autobuild.buildroot.net/results/d0a77147cba429bb42f102141810a23e831a8bcb/
>
> Compiler issue:
>
> eval.c: In function 'rb_protect':
> eval.c:881:1: internal compiler error: in move_insn, at haifa-sched.c:3439
>
>> arc | ruby-2.3.0 | NOK | http://autobuild.buildroot.net/results/748771df79b8537d3f4baeb1f7d423dec1f8c519/
>
> Same ARC compiler issue as above.
>
>> arm | sane-backends-1.0.25 | NOK | http://autobuild.buildroot.net/results/9759238db294c0703e8c685f2adc41dba3fdb31f/
>
> ../backend/.libs/libsane.a(libepsonds_la-epsonds.o):(.bss+0x10): multiple definition of `source_list'
> ../backend/.libs/libsane.a(libepson2_la-epson2.o):(.data+0x40): first defined here
> ../backend/.libs/libsane.a(libepsonds_la-epsonds.o):(.data+0x10): multiple definition of `mode_params'
> ../backend/.libs/libsane.a(libepson2_la-epson2.o):(.data+0x0): first defined here
>
> Vicente, you bumped sane-backends recently, can you have a look ?
>
>> mips64el | sconeserver-3b886c3dda6eda3... | NOK | http://autobuild.buildroot.net/results/be8d1ad7c05b39f8ed65b86f938bc2d9530e3c6d/
>
> Static linking issue, most likely:
>
> checking for mysql_init in -lmysqlclient... no
> configure: error: library 'mysqlclient' is required for the mysql module
>
> Anyone interested ?
>
>> arc | trousers-0.3.13 | NOK | http://autobuild.buildroot.net/results/c3d3bedffe0f4ba40f33d18e90a4802f4a7bfffb/
>
> PIE problem, under discussion.
>
>> arm | tstools-08f6be304040e7b8476... | NOK | http://autobuild.buildroot.net/results/357de0b07b2104e0c94cb3d21ca2096df0796071/
>
> Tries to build a shared library, in a static linking scenario. Anyone ?
>
>> xtensa | uboot-tools-2015.10 | NOK | http://autobuild.buildroot.net/results/64ac87a2a4847a45fc96cfaa4ded7f0821f66701/
>> xtensa | uboot-tools-2015.10 | NOK | http://autobuild.buildroot.net/results/9ebc5e3a6f1dd3ceb90d6786a1c5455c965f819e/
>> microblazeel | uboot-tools-2015.10 | NOK | http://autobuild.buildroot.net/results/a197f03c1751a87c7f71e057f2c4619538b4b6c8/
>
> Patch pending to fix this.
>
>> xtensa | unknown | NOK | http://autobuild.buildroot.net/results/f913556517654f833bf17f141597ba41570b02b7/
>> arm | unknown | NOK | http://autobuild.buildroot.net/results/865ce538e3dc3ce8005a39b5400fc3f019d7a411/
>> arm | unknown | NOK | http://autobuild.buildroot.net/results/0581889edfb7bf5ca0f23e3111ac6eeffbee3376/
>> mips64el | unknown | NOK | http://autobuild.buildroot.net/results/1abb03babacacf13db33ae9fe89b5d52925b58b1/
>
> 2 different dependency problems.
>
>> arm | util-linux-2.27.1 | NOK | http://autobuild.buildroot.net/results/2ca06e6bb9b147a44400e26acdd41dcc3ab7d9e4/
>
> checking for prlimit... no
> configure: error: flock selected, but required timer_create function not available
>
> Static linking issue. Anyone ?
>
>> mips | valgrind-3.11.0 | NOK | http://autobuild.buildroot.net/results/a00f4856c4094508334477296d0ec203466fe56e/
>
> Vicente, this one is for you :)
>
>> arm | vpnc-0.5.3 | NOK | http://autobuild.buildroot.net/results/aacb5ae636e2ae2df67a91696b1d2af276777b22/
>
> Yet another static linking issue caused by libintl.
>
>> nios2 | zbar-854a5d97059e395807091a... | NOK | http://autobuild.buildroot.net/results/d4a9e291ad1b36bd268b4b850aa10be3ac00b6d9/
>> arm | zbar-854a5d97059e395807091a... | NOK | http://autobuild.buildroot.net/results/c9cdee9e5cd031e5927b7aa26d92c48dbe35c1e7/
>
> Really bogus code triggers a warning that is now an error. Volkov, you
> added the zbar package, can you have a look ?
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2016-01-16 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2016-01-15 Thomas Petazzoni
@ 2016-01-16 23:11 ` Thomas Petazzoni
2016-01-17 1:42 ` Frank Hunleth
` (9 more replies)
0 siblings, 10 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2016-01-16 23:11 UTC (permalink / raw)
To: buildroot
Hello,
Gustavo, Vicente, J?rg, Frank, Bernd, Maxime, Carsten, Davide, Jeremy,
VIcente, Gilles, Gary, Romain, Matt, Waldemar, Fran?ois, Alexey, Joris,
Volkov: there are some specific build failures for which your help
would be appreciated. See below. Thanks in advance for your help!
On Sat, 16 Jan 2016 08:30:21 +0100 (CET), Thomas Petazzoni wrote:
> xtensa | alsa-utils-1.1.0 | NOK | http://autobuild.buildroot.net/results/1bf954501960db802c3e2280b30b70d6813bdb32/
> arm | alsa-utils-1.1.0 | NOK | http://autobuild.buildroot.net/results/7ba954e03822d758e25356935b0dfc2c91d3712a/
<dlfcn.h> needed by the topology code. Fixed in
https://git.busybox.net/buildroot/commit/?id=4707383c5d501a9ad7698579e5d0a4e2ab758c7e.
> bfin | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/a5558d054ab19f078d0992f8b691f35f3f1323c0/
Compiler error, in FLAT mode. Not sure what's going on, as I was able
to build assimp properly in a minimal Blackfin FLAT configuration.
> bfin | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/f0d25c8b08ba32361d47bd6bc344695f168396de/
> bfin | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/3f143ea946ad98176d8e5eaddecfa0bda11c0439/
> sparc64 | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/510c59e13f1412ffb831801e6389a32a76b543b6/
> sparc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/3f6f7a72bec601688991111f21e897306b1d76ca/
> xtensa | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/5eab445d66a977cdfb73a6b5dede6af692c28b16/
> xtensa | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/a511687d937c2575d8edffe9235b1507be1c9442/
> bfin | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/eb659085949c6b62108b8c46c50e8abd01681f23/
> bfin | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/4f3c001e8fa6781c4a2ca9d82023f959b7897035/
> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/5a90ba61c5ac863a7779af7783c7b0584a0c79e3/
> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/a70ec3a94a18db77f094c71d8be055ae0d99862b/
> xtensa | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/c0a57f9a03c308dcf8129d300d12f4a7d6d999de/
> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/d37761e95f2f45e92ef641e7117ff6d02f2865d1/
> xtensa | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/651efb92cd38569a1c53000c642b37a5c4b21115/
> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/498380d65b3e3d604a36facec894fc60a30a5d74/
> mips | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/37ce98706477b259da4e9527878aeada2d52366c/
> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/686755f4f925811fccbdadbe28ba7561af8c51ad/
> bfin | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/2f46b77f27ca7df9ae80ecaa6fdca6d981eeb8ff/
> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/7be9e4860ca47f8906c355577d71c0c6e8d597be/
> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/c0bc9693cfbac282599c73e7f0b6dd19e41bbfa3/
> xtensa | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/23b6e683aa3db28d2103e47fd263dc9c5afd99b8/
> xtensa | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/903515ab22c112dacf1583fff77c859c6f68985d/
> powerpc | assimp-v3.2 | NOK | http://autobuild.buildroot.net/results/23e03277f61490b6f48035075df0fc5e5474168f/
I guess most if not all of these are fixed by
https://git.busybox.net/buildroot/commit/?id=25ba49518a93265ecb3146e6eb21a2a138989100
and
https://git.busybox.net/buildroot/commit/?id=9ebac3bd050ee57cdd8a5ede053aed5522f5e8dc.
> mipsel | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/c4f88c724829e1a2ff152c756ea3dae80fef149c/
> mips64el | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/870879c3d20dcfb327329fab0d8c13f320fd5788/
> mipsel | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/1d1889f407adce09f313e8660f8b660f256ea277/
Vicente, Gustavo, can you have a look at those issues? It seems to be
limited to MIPS, and I don't think it was happening before the recent
bump of the bind package.
> arm | bluez5_utils-5.37 | NOK | http://autobuild.buildroot.net/results/83112559d84dc156141339a31e3e02f1a2af5155/
Fixed by
https://git.busybox.net/buildroot/commit/?id=d7c54cb0c0cf8cb013d88ad3c2989ec323323235.
> powerpc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/e92fc7bac808e708e1aadd1b8e6677d003e5bbe4/
> arm | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/46d0907fe06a7b93bb092ad4bf869a2e0030cf32/
> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/9ef4d4f5d793f9a854d3a398d00eec6ce9b59178/
> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/74e22545f50c9f9e7f12208a1cb9cbb9154a6150/
> powerpc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/5438729ded4bf9887a1dc080366aee9abf27fb19/
> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/99ef4325d424569bbd900d6590b8a3a5e445c140/
> arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/caded0b9ff89ba69cb3775d5fef18565a85a398a/
> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/b81bcc845a091ff1182df7dec306492b67db10ea/
> xtensa | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/29241cbf4791947e8bd990253716d8d43e219c23/
> mips64el | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/648507a680fa0360622ad1fdd47fdf30d3c54091/
> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/dea9364e8d8276bbcf42847822ef5da905cd7007/
> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/adcea53d916e0825cb5963768304dfe883d5d379/
> microblazeel | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/41ee80a733bc676d07d8296b262125b616070835/
> xtensa | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/2c555d574540caf3a3b1ed64502274d3ba1f551b/
> arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/316dc6221a50537234e4b3e88268363d61b9bf59/
> arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/d4eb7cdbfd1152bb5a2a80f832c5edf524852701/
> sh4 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/3bb3e2b683eabe7a6a9626f083b761b158a418ba/
> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/0e2f3f4e4fa9dca521206d52fc061709534be12b/
> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/84f5d3417ef5cdb826435b0029ddc8d2e9e4ec44/
> x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/428cb84d3bde356050b04647a599aea0fae6aeff/
Some of these are the isnan() declaration issue, which is now fixed
thanks to
https://git.busybox.net/buildroot/commit/?id=640b75c8d73d713c908d6b288802c9e6bffe76ed.
However, there is still the FE_* definition problem. J?rg, do you have
something in the works to fix this ?
> arm | canfestival-7740ac6fdedc23e... | NOK | http://autobuild.buildroot.net/results/5c5a48b050223d5f4f66a3a5ddde12cb17e310d7/
musl build issue. There was a thread in August between Yann and Brendan
about this. I pinged the thread.
> arm | chocolate-doom-2.2.1 | NOK | http://autobuild.buildroot.net/results/20019b0daebf1aaf44e0802603108ff712f60513/
In static linking configurations, when SDL_mixer is linked against
libmad, chocolate-doom doesn't pass -lmad. To fix this, we need to:
* Fix SDL_mixer.pc so that it references libmad in Libs.private (or
Requires.private ?)
* Either use pkg-config directly in chocolate-doom.mk to pass the
appropriate flags, or change the chocolate-doom build system itself.
Note that a similar problem might appear when SDL_mixer is linked
against vorbis.
Rodrigo, since you added the chocolate-doom package, can you look into
fixing this ?
> microblazeel | code/CMakeFiles/assimp.dir/... | TIM | http://autobuild.buildroot.net/results/50b9c93c0ee080c42362fd6d210745446077d7f5/
Don't care.
> arm | dvbsnoop-1.4.50 | NOK | http://autobuild.buildroot.net/results/2040d919e9d2564cf283ab815bea5ef34840ee61/
musl build issue. Carsten, you added this package back in 2013, can you
have a look ?
> aarch64 | erlang-17.5 | NOK | http://autobuild.buildroot.net/results/0cd22eb74fa29e5a85bf897762e16ab3daf33962/
Build problem due to atomic intrinsics:
more undefined references to `__atomic_store_16' follow
Frank, can you investigate why it builds on x86_64 but not on aarch64 ?
> x86_64 | faifa-v0.1 | NOK | http://autobuild.buildroot.net/results/617e5635e0c508f82043f21886b6ce9a30549ad2/
Classical musl build issue. Maxime, you added this package, so can you
fix it ? :-)
> mips64el | ffmpeg-2.8.4 | NOK | http://autobuild.buildroot.net/results/12ef8ee60b3c016e8998ff240a6dc51e682f3058/
> mips64el | ffmpeg-2.8.4 | NOK | http://autobuild.buildroot.net/results/a964ce679fed3eaaebd0ee2f39639d8243e227ef/
ERROR: fontconfig not found using pkg-config
Bernd, Vicente ?
> microblazeel | flann-04b4a56533faf8c8228d0... | NOK | http://autobuild.buildroot.net/results/6126357850f15fb97828cd1b186e71ced83716eb/
internal compiler error: in gen_reg_rtx, at emit-rtl.c:838
To be tested with the latest gcc version, and potentially report a gcc
bug.
Davide, you added this package back in 2014. Can you have a look ?
> microblazeel | fxload-2008_10_13 | NOK | http://autobuild.buildroot.net/results/4fa96981077c61599cc04b7c0f96b9f430f17f85/
Binutils issue this time:
/tmp/ccQKhnE1.s: Assembler messages:
/tmp/ccQKhnE1.s: Error: PC relative branch to label logerror which is not in the instruction space
/tmp/ccQKhnE1.s: Error: PC relative branch to label logerror which is not in the instruction space
Same deal: test with the latest binutils version, and report a bug if
the problem still exists.
Jeremy, you added the fxload package, can you have a look ?
> i686 | gst1-plugins-bad-1.6.2 | NOK | http://autobuild.buildroot.net/results/fab7afc3490d77a6b29760394337298f2fd55d51/
> x86_64 | gst1-plugins-bad-1.6.2 | NOK | http://autobuild.buildroot.net/results/4da1b0454fe7bf028a62058d28dafda104fb75f4/
gstdvbsrc.c: In function 'gst_dvbsrc_code_rate_get_type':
gstdvbsrc.c:273:6: error: 'FEC_2_5' undeclared (first use in this function)
gstdvbsrc.c:273:6: note: each undeclared identifier is reported only once for each function it appears in
gstdvbsrc.c: In function 'gst_dvbsrc_modulation_get_type':
gstdvbsrc.c:303:6: error: 'QAM_4_NR' undeclared (first use in this function)
gstdvbsrc.c:303:5: error: initializer element is not constant
gstdvbsrc.c:303:5: error: (near initialization for 'modulation_types[13].value')
Not sure. Peter, Gustavo ?
> sparc | harfbuzz-1.1.3 | NOK | http://autobuild.buildroot.net/results/30dec74537539dcbfa97eb9f90f40b2a814830d1/
hb-warning.cc:32:2: error: #error "Could not find any system to define atomic_int macros, library WILL NOT be thread-safe"
#error "Could not find any system to define atomic_int macros, library WILL NOT be thread-safe"
^
hb-warning.cc:33:2: error: #error "Check hb-atomic-private.hh for possible resolutions."
#error "Check hb-atomic-private.hh for possible resolutions."
Gustavo, maybe we simply should disable this package on Sparc ? Only
annoyance is that it is selected by Pango, which means that all reverse
dependencies of Pango would have to be fixed :-/
Another idea ?
> aarch64 | hidapi-d17db57b9d4354752e0a... | NOK | http://autobuild.buildroot.net/results/7d70b7dac91209d1a63c131e9eb098bd8be3e84c/
make[3]: *** No rule to make target `hidtest.o', needed by `hidtest-libusb'. Stop.
Vicente, you added this package, can you have a look ?
> powerpc | host-python3-3.4.3 | NOK | http://autobuild.buildroot.net/results/49d02998eeb5817d92574f61f6786a4f5c71d131/
Modules/getbuildinfo.o: file not recognized: File truncated
collect2: error: ld returned 1 exit status
Ooch, smells like a parallel build issue... but building Python with
make -j1 would really be horrible :-/
> nios2 | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/e8e730f90357fd9818d19ae48b7533c8c5dcbc49/
> arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/3c673e550535d741d2773e359ed2bebaebad6ad2/
> bfin | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/5d526c4348a0ab3d802a9ef795096b2bfd1b3515/
> arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/e64262b0045195892b2c7ed08cfef8f5682b9793/
> x86_64 | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/844424b9db5ced38f90936fdc96eba480de34459/
> bfin | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/3ef4945e7c51f354eb4444fc40f50ba0e86929e9/
> arc | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/cec1c9d0723d72693d526dcfc3e9432b7694911f/
Issue specific to this autobuilder instance, I'll have a look at this
one.
> arm | httping-2.4 | NOK | http://autobuild.buildroot.net/results/f88f0dd592a52128d250b2c8668a524d6ca35d24/
Improper libintl handling. Gustavo, you bumped this package last year,
can you have a look ?
> arm | imx-kobs-3.14.28-1.0.0 | NOK | http://autobuild.buildroot.net/results/05a159c7f8382237d4c941b1bb6de7dad72708f3/
Gary, can you have a look ?
> arm | iprutils-2.4.5 | NOK | http://autobuild.buildroot.net/results/61e121c25fc07083bcccedfcb4f938d18f5c5456/
Musl build issue:
iprlib.h:49:27: fatal error: bits/sockaddr.h: No such file or directory
#include <bits/sockaddr.h>
Romain, you bumped this package recently, can you have a look ?
> arm | ipsec-tools-0.8.2 | NOK | http://autobuild.buildroot.net/results/ce0bb96971147669c1bb253ce259eb5756f1d85e/
Musl build issue. Gustavo, can you have a look ?
> x86_64 | iputils-s20121011 | NOK | http://autobuild.buildroot.net/results/12cb73f3def95efe706bcd957bc2c091e7931d5a/
Musl build issue. Matt, can you have a look ?
> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/ae9eca750d27f80cf8b0743f41cdfcc50ea476f1/
> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/dca1ba4a15cd9326a43e99d78bd13021bc87d9a2/
Romain, I don't remember what was the conclusion about this issue. I
remember we discussed it at some point.
> sparc | libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/fa0ac44d3c7953b2e2afa03cd7570d8a5d49fcc4/
Waldemar, this is a sparc problem, can you look into it ?
> mips | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/cf7fd3dc8a1373c6c963a83e55d093b945f90f1a/
> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/a7dd03a12c06a1f01826f01f91b39af396dca0d8/
> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/a39a87c6547c9daa27e8a257c9e573d4c222fca4/
> mips | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/f09b5d6120203cd5ddc60951828f880905297bcb/
> mips | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/108cdfac94e88bfdc318e0689295a3799cc23069/
> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/c14cabcc51f6870a0ab2381b32220d944590669f/
> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/f05e78f97928c5da48678cdf2e465d413fd5feca/
> mips | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/0094b3f30f8815fa5ef10afb3b0e506549ee8674/
> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/4de0087f2bf63612c4354970d8307be7fa8beefd/
> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/5d9f963a30eea53dd22f0b0d6f0d63592114977a/
> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/0616fba52db8793ea5ac1383c47a86a72aae682f/
> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/e2d5f87095f877c9ff7807419014e4af8b43130b/
> mips | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/4dc9605b801518aa8075972e46e83d4df98cdbb5/
> mips64el | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/26dd14f492e4a544400f2d2c6800ee5cde4a0b1f/
> mips | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/8c668a64b6b9ed4ba7a77c3d3211a41de89c33b6/
Vicente, we really need to solve this problem :)
> arm | libnss-3.21 | NOK | http://autobuild.buildroot.net/results/9ba9e0c148110b69763c12e37a37738deab3f118/
/home/buildroot/autobuild/run/instance-1/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/lib/libnspr4.so: undefined reference to `getprotobyname_r'
/home/buildroot/autobuild/run/instance-1/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/lib/libnspr4.so: undefined reference to `getprotobynumber_r'
Musl build issue.
> powerpc | libnss-3.21 | NOK | http://autobuild.buildroot.net/results/cef2fe3d87b742743a54a2fdbc585771e175a9e6/
In file included from secoid.c:1915:0:
verref.h: In function 'SECOID_Init':
verref.h:22:9: error: #pragma GCC diagnostic not allowed inside functions
verref.h:23:9: error: #pragma GCC diagnostic not allowed inside functions
cc1: warnings being treated as errors
old compiler problem.
> i686 | lighttpd-1.4.39 | NOK | http://autobuild.buildroot.net/results/13faa9ebce00359b8943775364a432ce422fe8b8/
mod_magnet.c: In function 'magnet_status_set':
mod_magnet.c:415:2: warning: implicit declaration of function 'luaL_checkint' [-Wimplicit-function-declaration]
mod_magnet.c: In function 'magnet_copy_response_header':
mod_magnet.c:692:2: warning: implicit declaration of function 'lua_getfenv' [-Wimplicit-function-declaration]
mod_magnet.c: In function 'traceback':
mod_magnet.c:839:18: error: 'LUA_GLOBALSINDEX' undeclared (first use in this function)
mod_magnet.c:839:18: note: each undeclared identifier is reported only once for each function it appears in
mod_magnet.c: In function 'magnet_attract':
mod_magnet.c:987:19: error: 'LUA_GLOBALSINDEX' undeclared (first use in this function)
mod_magnet.c:992:2: warning: implicit declaration of function 'lua_setfenv' [-Wimplicit-function-declaration]
Fran?ois, this seems to be Lua related, can you have a look ?
> arm | linux-firmware-bbe4917c054e... | TIM | http://autobuild.buildroot.net/results/fc6001a9fcaeab2a67d03d5809360de00c16392a/
Ignore.
> sparc | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/faa42138e2b5a07b965926e55b831cb6e8eb3c0c/
`undefined__sig_stub 'reference
> sparc64 | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/85e181c2f75037e0d9b9a7bd288d9fdaa828bb34/
undefined toreference `to__rt_sig_stub '`
Waldemar, can you have a look ?
> arm | luabitop-1.0.2-1 | NOK | http://autobuild.buildroot.net/results/80d137d91e6f6173e29074cf12a38f192ce0d7ca/
> xtensa | luabitop-1.0.2-1 | NOK | http://autobuild.buildroot.net/results/15a0e4c3879eb56604fa88c2e31be641e933afa7/
> aarch64 | luabitop-1.0.2-1 | NOK | http://autobuild.buildroot.net/results/39d2bae1398bd17891a9d0d2f698340fc7dca591/
> i686 | luabitop-1.0.2-1 | NOK | http://autobuild.buildroot.net/results/7ac0eb736ad264c59637059ce207989c392f00f7/
> aarch64 | luabitop-1.0.2-1 | NOK | http://autobuild.buildroot.net/results/a95d9b6eee7b41a0ce4cf6456fde08291cd8b860/
Fixed by https://git.busybox.net/buildroot/commit/?id=be5d265220f36df7e0b633fcc55e3a33b2e74035
> microblazeel | make[3]: *** [code/CMakeFil... | TIM | http://autobuild.buildroot.net/results/8df9f0dd9cbc0446c0458d89cb182d0feb795774/
Ignore.
> arc | mesa3d-11.1.0 | NOK | http://autobuild.buildroot.net/results/7b3f5c0e3c59bd49614e8ad4eee3d89e3527a939/
Compiler problem, issue is known by Synopsys.
> sparc64 | moarvm-2015.10 | NOK | http://autobuild.buildroot.net/results/268e328e2d9ea951c0728ab6031d32e2b460d015/
> sparc64 | moarvm-2015.10 | NOK | http://autobuild.buildroot.net/results/84847a9201244fce3e05e5e4e201f2e1848238de/
./libmoar.so: undefined reference to `AO_fetch_compare_and_swap_full'
Waldemar, can you have a look ?
> powerpc | nfs-utils-1.3.3 | NOK | http://autobuild.buildroot.net/results/948f81d7ed2c080a675ee9fec754f6fda1fd905f/
Not sure:
cache.c: In function 'same_path':
cache.c:429:22: error: field 'fh' has incomplete type
cache.c:436:2: warning: implicit declaration of function 'name_to_handle_at' [-Wimplicit-function-declaration]
Makefile:613: recipe for target 'mountd-cache.o' failed
Maxime, can you have a look ?
> arm | nut-2.7.2 | NOK | http://autobuild.buildroot.net/results/8fb9cb823d723903f11d70325b0ea09e103504cf/
checking whether to build SNMP drivers... yes
configure: error: "neon libraries not found, required for neon based XML/HTTP driver"
Most likely a static linking problem.
Yann, you added the nut package, so ... :-)
> sparc64 | opencv-2.4.10 | NOK | http://autobuild.buildroot.net/results/84cfdfa21205954cb8f0e5541332570ba5206add/
Another atomic related problem. Waldemar ?
> arm | openpgm-release-5-2-122 | NOK | http://autobuild.buildroot.net/results/aa2cf491dfb199a349afd107046f428107a583a0/
Musl build issue:
./include/pgm/gsi.h:47:75: error: unknown type name 'ssize_t'
bool pgm_gsi_create_from_string (pgm_gsi_t*restrict, const char*restrict, ssize_t);
Anyone to look into this?
> mipsel | pinentry-0.9.4 | NOK | http://autobuild.buildroot.net/results/d8d6414ae28d9ea84118dfa5c0f73d9334a1c417/
error: member 'QChar std::__cxx11::basic_string<QChar, std::char_traits<QChar>, secmem::alloc<QChar> >::<anonymous union>::_M_local_buf [8]' with constructor not allowed in union
_CharT _M_local_buf[_S_local_capacity + 1];
Anyone understands this ?
> arc | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/a85a1839a45fb6102e53131ecc8f6dadf92bcdc2/
Static linking, I'm assuming this *could* be fixed by
https://git.busybox.net/buildroot/commit/?id=12009bb92931b153823110f811632540044d3b02,
though I am not sure. Alexey ?a
> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/199b8ed788e4ca3eca03b95710a3bb644d81d187/
> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/546f94ee09fcff27ea2d7c6cebb0b48aec1881f8/
> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/bb90227b6a18bde0cef45f82620de560d48866e7/
Compiler problem. I don't remember if I reported it.
> arm | rabbitmq-c-0.7.1 | NOK | http://autobuild.buildroot.net/results/2ef1ed958db8012224f9174334e9c58edace604a/
Static linking problem. Joris, can you have a look ?
> sh4 | rpm-5.2.0 | NOK | http://autobuild.buildroot.net/results/499f2a3204a6afab96322c431732541fefd622e8/
Internal compiler error...
> arc | ruby-2.3.0 | NOK | http://autobuild.buildroot.net/results/8e98934b066d4973d88e7d28b042b99550d68ae8/
Compiler issue:
/tmp/cctdImle.s: Assembler messages:
/tmp/cctdImle.s:2253: Error: invalid register number `63'
/tmp/cctdImle.s:2255: Error: invalid register number `63'
Alexey ?
> powerpc | ruby-2.3.0 | NOK | http://autobuild.buildroot.net/results/d0a77147cba429bb42f102141810a23e831a8bcb/
Compiler issue:
eval.c: In function 'rb_protect':
eval.c:881:1: internal compiler error: in move_insn, at haifa-sched.c:3439
> arc | ruby-2.3.0 | NOK | http://autobuild.buildroot.net/results/748771df79b8537d3f4baeb1f7d423dec1f8c519/
Same ARC compiler issue as above.
> arm | sane-backends-1.0.25 | NOK | http://autobuild.buildroot.net/results/9759238db294c0703e8c685f2adc41dba3fdb31f/
../backend/.libs/libsane.a(libepsonds_la-epsonds.o):(.bss+0x10): multiple definition of `source_list'
../backend/.libs/libsane.a(libepson2_la-epson2.o):(.data+0x40): first defined here
../backend/.libs/libsane.a(libepsonds_la-epsonds.o):(.data+0x10): multiple definition of `mode_params'
../backend/.libs/libsane.a(libepson2_la-epson2.o):(.data+0x0): first defined here
Vicente, you bumped sane-backends recently, can you have a look ?
> mips64el | sconeserver-3b886c3dda6eda3... | NOK | http://autobuild.buildroot.net/results/be8d1ad7c05b39f8ed65b86f938bc2d9530e3c6d/
Static linking issue, most likely:
checking for mysql_init in -lmysqlclient... no
configure: error: library 'mysqlclient' is required for the mysql module
Anyone interested ?
> arc | trousers-0.3.13 | NOK | http://autobuild.buildroot.net/results/c3d3bedffe0f4ba40f33d18e90a4802f4a7bfffb/
PIE problem, under discussion.
> arm | tstools-08f6be304040e7b8476... | NOK | http://autobuild.buildroot.net/results/357de0b07b2104e0c94cb3d21ca2096df0796071/
Tries to build a shared library, in a static linking scenario. Anyone ?
> xtensa | uboot-tools-2015.10 | NOK | http://autobuild.buildroot.net/results/64ac87a2a4847a45fc96cfaa4ded7f0821f66701/
> xtensa | uboot-tools-2015.10 | NOK | http://autobuild.buildroot.net/results/9ebc5e3a6f1dd3ceb90d6786a1c5455c965f819e/
> microblazeel | uboot-tools-2015.10 | NOK | http://autobuild.buildroot.net/results/a197f03c1751a87c7f71e057f2c4619538b4b6c8/
Patch pending to fix this.
> xtensa | unknown | NOK | http://autobuild.buildroot.net/results/f913556517654f833bf17f141597ba41570b02b7/
> arm | unknown | NOK | http://autobuild.buildroot.net/results/865ce538e3dc3ce8005a39b5400fc3f019d7a411/
> arm | unknown | NOK | http://autobuild.buildroot.net/results/0581889edfb7bf5ca0f23e3111ac6eeffbee3376/
> mips64el | unknown | NOK | http://autobuild.buildroot.net/results/1abb03babacacf13db33ae9fe89b5d52925b58b1/
2 different dependency problems.
> arm | util-linux-2.27.1 | NOK | http://autobuild.buildroot.net/results/2ca06e6bb9b147a44400e26acdd41dcc3ab7d9e4/
checking for prlimit... no
configure: error: flock selected, but required timer_create function not available
Static linking issue. Anyone ?
> mips | valgrind-3.11.0 | NOK | http://autobuild.buildroot.net/results/a00f4856c4094508334477296d0ec203466fe56e/
Vicente, this one is for you :)
> arm | vpnc-0.5.3 | NOK | http://autobuild.buildroot.net/results/aacb5ae636e2ae2df67a91696b1d2af276777b22/
Yet another static linking issue caused by libintl.
> nios2 | zbar-854a5d97059e395807091a... | NOK | http://autobuild.buildroot.net/results/d4a9e291ad1b36bd268b4b850aa10be3ac00b6d9/
> arm | zbar-854a5d97059e395807091a... | NOK | http://autobuild.buildroot.net/results/c9cdee9e5cd031e5927b7aa26d92c48dbe35c1e7/
Really bogus code triggers a warning that is now an error. Volkov, you
added the zbar package, can you have a look ?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-08-06 18:50 ` Thomas Petazzoni
@ 2015-08-07 12:09 ` Guillaume GARDET - Oliséo
0 siblings, 0 replies; 416+ messages in thread
From: Guillaume GARDET - Oliséo @ 2015-08-07 12:09 UTC (permalink / raw)
To: buildroot
Le 06/08/2015 20:50, Thomas Petazzoni a ?crit :
> Dear Guillaume GARDET - Olis?o,
>
> On Thu, 6 Aug 2015 16:07:10 +0200, Guillaume GARDET - Olis?o wrote:
>
>>>> What would be the best way to fix it? Maybe a "depends on !BR2_STATIC_LIBS" ?
>>> Either fix c-icap, or simpler, make it depends on !BR2_STATIC_LIBS (and
>>> don't forget the corresponding comment).
>> Will send a patch to depends on !BR2_STATIC_LIBS.
>> For the comment, '# dlopen' is enough?
> Yes, but I was actually referring to the Config.in comment to express
> the dynamic library dependency.
>
> Hum, wait. Look at c-icap/Config.in:
>
> config BR2_PACKAGE_C_ICAP
> bool "c-icap"
> depends on !BR2_PREFER_STATIC_LIB
> depends on BR2_TOOLCHAIN_HAS_THREADS
>
> It already has the dependency, it is just wrong: it should be
> BR2_STATIC_LIBS and not BR2_PREFER_STATIC_LIB. I'll fix that up.
Ok. Thanks.
Guillaume
>
> Thanks!
>
> Thomas
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-08-06 14:07 ` Guillaume GARDET - Oliséo
@ 2015-08-06 18:50 ` Thomas Petazzoni
2015-08-07 12:09 ` Guillaume GARDET - Oliséo
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2015-08-06 18:50 UTC (permalink / raw)
To: buildroot
Dear Guillaume GARDET - Olis?o,
On Thu, 6 Aug 2015 16:07:10 +0200, Guillaume GARDET - Olis?o wrote:
> >> What would be the best way to fix it? Maybe a "depends on !BR2_STATIC_LIBS" ?
> > Either fix c-icap, or simpler, make it depends on !BR2_STATIC_LIBS (and
> > don't forget the corresponding comment).
>
> Will send a patch to depends on !BR2_STATIC_LIBS.
> For the comment, '# dlopen' is enough?
Yes, but I was actually referring to the Config.in comment to express
the dynamic library dependency.
Hum, wait. Look at c-icap/Config.in:
config BR2_PACKAGE_C_ICAP
bool "c-icap"
depends on !BR2_PREFER_STATIC_LIB
depends on BR2_TOOLCHAIN_HAS_THREADS
It already has the dependency, it is just wrong: it should be
BR2_STATIC_LIBS and not BR2_PREFER_STATIC_LIB. I'll fix that up.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-08-06 13:58 ` Thomas Petazzoni
@ 2015-08-06 14:07 ` Guillaume GARDET - Oliséo
2015-08-06 18:50 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Guillaume GARDET - Oliséo @ 2015-08-06 14:07 UTC (permalink / raw)
To: buildroot
Le 06/08/2015 15:58, Thomas Petazzoni a ?crit :
> Guillaume,
>
> On Thu, 6 Aug 2015 15:53:44 +0200, Guillaume GARDET - Olis?o wrote:
>
>>>> arm | c-icap-0.3.5 | NOK | http://autobuild.buildroot.net/results/cb623460de30dd7c4ef3275fe13220c1ca0642a5/
>>> c_icap-service.o: In function `load_c_service':
>>> service.c:(.text+0x710): undefined reference to `ci_module_load'
>>> service.c:(.text+0x720): undefined reference to `ci_module_sym'
>>> service.c:(.text+0x774): undefined reference to `ci_module_unload'
>>>
>>> Unknown, already happened yesterday. Guillaume, can you have a look?
>> This is because HAVE_DLFCN_H is not set because dlfcn.h is not provided by the toolchain. But ./os/unix/dlib.c uses dlopen and dlclose functions.
>> Apparently, this is missing on uClibc when it is configured as a static-only C library.
> The c-icap code seems a bit stupid: it encloses the definition of
> ci_module_{load,sym,unload} in #ifdef HAVE_DLFCN_H to not implement
> them when dlopen/dlclose are not available (which is good), but
> ci_module_{load,sym,unload} are still called unconditionally from the
> rest of the c-icap code.
I agree.
>
> Bottom line: the condition on HAVE_DLFCN_H is useless.
>
>> What would be the best way to fix it? Maybe a "depends on !BR2_STATIC_LIBS" ?
> Either fix c-icap, or simpler, make it depends on !BR2_STATIC_LIBS (and
> don't forget the corresponding comment).
Will send a patch to depends on !BR2_STATIC_LIBS.
For the comment, '# dlopen' is enough?
Guillaume
>
> Thanks!
>
> Thomas
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-08-06 13:53 ` Guillaume GARDET - Oliséo
@ 2015-08-06 13:58 ` Thomas Petazzoni
2015-08-06 14:07 ` Guillaume GARDET - Oliséo
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2015-08-06 13:58 UTC (permalink / raw)
To: buildroot
Guillaume,
On Thu, 6 Aug 2015 15:53:44 +0200, Guillaume GARDET - Olis?o wrote:
> >> arm | c-icap-0.3.5 | NOK | http://autobuild.buildroot.net/results/cb623460de30dd7c4ef3275fe13220c1ca0642a5/
> > c_icap-service.o: In function `load_c_service':
> > service.c:(.text+0x710): undefined reference to `ci_module_load'
> > service.c:(.text+0x720): undefined reference to `ci_module_sym'
> > service.c:(.text+0x774): undefined reference to `ci_module_unload'
> >
> > Unknown, already happened yesterday. Guillaume, can you have a look?
>
> This is because HAVE_DLFCN_H is not set because dlfcn.h is not provided by the toolchain. But ./os/unix/dlib.c uses dlopen and dlclose functions.
> Apparently, this is missing on uClibc when it is configured as a static-only C library.
The c-icap code seems a bit stupid: it encloses the definition of
ci_module_{load,sym,unload} in #ifdef HAVE_DLFCN_H to not implement
them when dlopen/dlclose are not available (which is good), but
ci_module_{load,sym,unload} are still called unconditionally from the
rest of the c-icap code.
Bottom line: the condition on HAVE_DLFCN_H is useless.
> What would be the best way to fix it? Maybe a "depends on !BR2_STATIC_LIBS" ?
Either fix c-icap, or simpler, make it depends on !BR2_STATIC_LIBS (and
don't forget the corresponding comment).
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-29 8:03 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (2 preceding siblings ...)
2015-08-04 13:45 ` Angelo Compagnucci
@ 2015-08-06 13:53 ` Guillaume GARDET - Oliséo
2015-08-06 13:58 ` Thomas Petazzoni
3 siblings, 1 reply; 416+ messages in thread
From: Guillaume GARDET - Oliséo @ 2015-08-06 13:53 UTC (permalink / raw)
To: buildroot
Le 29/07/2015 10:03, Thomas Petazzoni a ?crit :
> Hello,
>
> Clayton, Guillaume, Samuel, Gwenhael, Gustavo, Brendan, Paul, Bernd,
> Angelo, Maxime, Simon: see below, there are some questions for you.
> Thanks!
>
> On Wed, 29 Jul 2015 08:30:17 +0200 (CEST), Thomas Petazzoni wrote:
snip...
>> arm | c-icap-0.3.5 | NOK | http://autobuild.buildroot.net/results/cb623460de30dd7c4ef3275fe13220c1ca0642a5/
> c_icap-service.o: In function `load_c_service':
> service.c:(.text+0x710): undefined reference to `ci_module_load'
> service.c:(.text+0x720): undefined reference to `ci_module_sym'
> service.c:(.text+0x774): undefined reference to `ci_module_unload'
>
> Unknown, already happened yesterday. Guillaume, can you have a look?
This is because HAVE_DLFCN_H is not set because dlfcn.h is not provided by the toolchain. But ./os/unix/dlib.c uses dlopen and dlclose functions.
Apparently, this is missing on uClibc when it is configured as a static-only C library.
What would be the best way to fix it? Maybe a "depends on !BR2_STATIC_LIBS" ?
Guillaume
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-29 8:03 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2015-07-29 9:30 ` Jérôme Pouiller
2015-07-29 19:55 ` Bernd Kuhls
@ 2015-08-04 13:45 ` Angelo Compagnucci
2015-08-06 13:53 ` Guillaume GARDET - Oliséo
3 siblings, 0 replies; 416+ messages in thread
From: Angelo Compagnucci @ 2015-08-04 13:45 UTC (permalink / raw)
To: buildroot
Dear Thomas Petazzoni,
>
>> powerpc | mono-4.0.2.5 | NOK | http://autobuild.buildroot.net/results/f7863af051b2b856280a944749b91ba5b552b53d/
>> arm | mono-4.0.2.5 | NOK | http://autobuild.buildroot.net/results/08ec78b88abd16af8e7fc3c5e7d05eb0dbbe9613/
>> powerpc | mono-4.0.2.5 | NOK | http://autobuild.buildroot.net/results/aebfbd4e7fe46edbd3798563df28b4d89903becd/
>
> locale problem. Angelo, can you investigate ?
I investigate the problem and there is a redefinition of function
vasprintf in mono. The configure script should guess if the vasprintf
is missing and compile the internal one only in this case.
Unfortunately, it fails to make a proper detection and compiles the
internal also in case the function is already present.
Actually I brutally delete form Makefile.am the inclusion of
vasprintf.c from compilation and it works, but it's the best patch.
Have you any hint on this matter?
Thank you!
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-08-01 8:25 ` Waldemar Brodkorb
@ 2015-08-01 16:40 ` Romain Naour
0 siblings, 0 replies; 416+ messages in thread
From: Romain Naour @ 2015-08-01 16:40 UTC (permalink / raw)
To: buildroot
Hi Waldemar,
Le 01/08/2015 10:25, Waldemar Brodkorb a ?crit :
> Hi Romain,
> Romain Naour wrote,
>
>> Hi Waldemar,
>>
>> Le 22/07/2015 19:53, Romain Naour a ?crit :
>>> Hi Waldemar,
>>>
>>> Le 22/07/2015 18:27, Waldemar Brodkorb a ?crit :
>>>> Hi Romain,
>>>> Romain Naour wrote,
>>>>
>>>>>>> x86_64 | libedje-1.7.10 | NOK | http://autobuild.buildroot.net/results/6b1e2132a34e0c263bb0f2ea31caf4ce697e9c9c/
>>>>>>
>>>>>> Another uClibc static linking problem. Waldemar?
>>>>>>
>>>>>
>>>>> Waldemar, I think you can skip this issue since I'm working on the efl bump to
>>>>> the latest release and I had to disable the efl package for uClibc-ng.
>>>>>
>>>>> I had a link issue:
>>>>> lib/eina/.libs/libeina.so: undefined reference to `mkstemps'
>>>>> It turn out that mkstemps and mkostemps are not available in uClibc-ng.
>>>>
>>
>> [snip]
>>
>>>
>>>> May be efl developers could be convinced to use something more standard like?
>>>> mkstemps() seems very glibc specific.
>>>
>>> Indeed, man pages says that mkstemps() is unstandardized.
>>
>> I built successfully the efl package with a musl toolchain yesterday.
>>
>> Musl have mkostemp, mkstemps, and mkostemps functions since v0.9.10
>>
>> http://git.musl-libc.org/cgit/musl/commit/?id=2cc63358cdb0309ca996ffe56ccf402c2f2f16d5
>>
>> There is a comment in WHATSNEW that mkostemp is future-POSIX
>> http://git.musl-libc.org/cgit/musl/commit/?id=7bec92e793d4b8a349796848cf43c7329b0f2ed0
>>
>> Rich Felker said about mkostemp():
>> "Technically mkostemp is nonstandard, but it's accepted for inclusion in Issue
>> 8, and so far the policy for such functions is to treat them as if they're
>> already in the standard."
>> http://www.openwall.com/lists/musl/2013/02/03/1
>>
>> So maybe it's time for uClibc-ng to include these functions ?
>>
>> Thoughts ?
>
> Yeah, I think this would be fine. Do you have time to develop a
> patch proposing the changes? I am a bit busy next week not sure if I
> get time to this.
I've sent this patch to the uclibc-ng mailing list:
http://mailman.uclibc-ng.org/pipermail/devel/2015-August/000432.html
What do you think?
I did not test at runtime yet, just build tested...
Also, a test program could be added later.
Best regards,
Romain
>
> best regards
> Waldemar
>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-30 10:46 ` Romain Naour
@ 2015-08-01 8:25 ` Waldemar Brodkorb
2015-08-01 16:40 ` Romain Naour
0 siblings, 1 reply; 416+ messages in thread
From: Waldemar Brodkorb @ 2015-08-01 8:25 UTC (permalink / raw)
To: buildroot
Hi Romain,
Romain Naour wrote,
> Hi Waldemar,
>
> Le 22/07/2015 19:53, Romain Naour a ?crit :
> > Hi Waldemar,
> >
> > Le 22/07/2015 18:27, Waldemar Brodkorb a ?crit :
> >> Hi Romain,
> >> Romain Naour wrote,
> >>
> >>>>> x86_64 | libedje-1.7.10 | NOK | http://autobuild.buildroot.net/results/6b1e2132a34e0c263bb0f2ea31caf4ce697e9c9c/
> >>>>
> >>>> Another uClibc static linking problem. Waldemar?
> >>>>
> >>>
> >>> Waldemar, I think you can skip this issue since I'm working on the efl bump to
> >>> the latest release and I had to disable the efl package for uClibc-ng.
> >>>
> >>> I had a link issue:
> >>> lib/eina/.libs/libeina.so: undefined reference to `mkstemps'
> >>> It turn out that mkstemps and mkostemps are not available in uClibc-ng.
> >>
>
> [snip]
>
> >
> >> May be efl developers could be convinced to use something more standard like?
> >> mkstemps() seems very glibc specific.
> >
> > Indeed, man pages says that mkstemps() is unstandardized.
>
> I built successfully the efl package with a musl toolchain yesterday.
>
> Musl have mkostemp, mkstemps, and mkostemps functions since v0.9.10
>
> http://git.musl-libc.org/cgit/musl/commit/?id=2cc63358cdb0309ca996ffe56ccf402c2f2f16d5
>
> There is a comment in WHATSNEW that mkostemp is future-POSIX
> http://git.musl-libc.org/cgit/musl/commit/?id=7bec92e793d4b8a349796848cf43c7329b0f2ed0
>
> Rich Felker said about mkostemp():
> "Technically mkostemp is nonstandard, but it's accepted for inclusion in Issue
> 8, and so far the policy for such functions is to treat them as if they're
> already in the standard."
> http://www.openwall.com/lists/musl/2013/02/03/1
>
> So maybe it's time for uClibc-ng to include these functions ?
>
> Thoughts ?
Yeah, I think this would be fine. Do you have time to develop a
patch proposing the changes? I am a bit busy next week not sure if I
get time to this.
best regards
Waldemar
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 17:53 ` Romain Naour
@ 2015-07-30 10:46 ` Romain Naour
2015-08-01 8:25 ` Waldemar Brodkorb
0 siblings, 1 reply; 416+ messages in thread
From: Romain Naour @ 2015-07-30 10:46 UTC (permalink / raw)
To: buildroot
Hi Waldemar,
Le 22/07/2015 19:53, Romain Naour a ?crit :
> Hi Waldemar,
>
> Le 22/07/2015 18:27, Waldemar Brodkorb a ?crit :
>> Hi Romain,
>> Romain Naour wrote,
>>
>>>>> x86_64 | libedje-1.7.10 | NOK | http://autobuild.buildroot.net/results/6b1e2132a34e0c263bb0f2ea31caf4ce697e9c9c/
>>>>
>>>> Another uClibc static linking problem. Waldemar?
>>>>
>>>
>>> Waldemar, I think you can skip this issue since I'm working on the efl bump to
>>> the latest release and I had to disable the efl package for uClibc-ng.
>>>
>>> I had a link issue:
>>> lib/eina/.libs/libeina.so: undefined reference to `mkstemps'
>>> It turn out that mkstemps and mkostemps are not available in uClibc-ng.
>>
[snip]
>
>> May be efl developers could be convinced to use something more standard like?
>> mkstemps() seems very glibc specific.
>
> Indeed, man pages says that mkstemps() is unstandardized.
I built successfully the efl package with a musl toolchain yesterday.
Musl have mkostemp, mkstemps, and mkostemps functions since v0.9.10
http://git.musl-libc.org/cgit/musl/commit/?id=2cc63358cdb0309ca996ffe56ccf402c2f2f16d5
There is a comment in WHATSNEW that mkostemp is future-POSIX
http://git.musl-libc.org/cgit/musl/commit/?id=7bec92e793d4b8a349796848cf43c7329b0f2ed0
Rich Felker said about mkostemp():
"Technically mkostemp is nonstandard, but it's accepted for inclusion in Issue
8, and so far the policy for such functions is to treat them as if they're
already in the standard."
http://www.openwall.com/lists/musl/2013/02/03/1
So maybe it's time for uClibc-ng to include these functions ?
Thoughts ?
Best regards,
Romain Naour
>
> Thanks for your help!
>
> Best regards,
> Romain
>
>>
>> best regards
>> Waldemar
>>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-29 8:03 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2015-07-29 9:30 ` Jérôme Pouiller
@ 2015-07-29 19:55 ` Bernd Kuhls
2015-08-04 13:45 ` Angelo Compagnucci
2015-08-06 13:53 ` Guillaume GARDET - Oliséo
3 siblings, 0 replies; 416+ messages in thread
From: Bernd Kuhls @ 2015-07-29 19:55 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Am Wed, 29 Jul 2015 10:03:34 +0200 schrieb Thomas Petazzoni:
>> arm | mesa3d-10.6.2 | NOK |
>> http://autobuild.buildroot.net/
results/6e313e2a4b2ff092d187ac564f25c14aaaceb0dd/
>
> checking for LIBUDEV... no configure: error: Cannot use static libraries
> for DRI drivers make: ***
> [/home/test/autobuild/instance-1/output/build/
mesa3d-10.6.2/.stamp_configured]
> Error 1 make: Leaving directory
> `/home/test/autobuild/instance-1/buildroot'
>
> Bernd, can you have a look?
Fixed by http://patchwork.ozlabs.org/patch/501804/
Regards, Bernd
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-29 8:03 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2015-07-29 9:30 ` Jérôme Pouiller
2015-07-29 19:55 ` Bernd Kuhls
` (2 subsequent siblings)
3 siblings, 0 replies; 416+ messages in thread
From: Jérôme Pouiller @ 2015-07-29 9:30 UTC (permalink / raw)
To: buildroot
Hello,
On Wednesday 29 July 2015 10:03:34 Thomas Petazzoni wrote:
[..]
> > sh4a | quota-4.01 | NOK | http://autobuild.buildroot.net/results/bba8faf210414d956cc07629b8ba99ceed0ebdf6/
> > aarch64 | quota-4.01 | NOK | http://autobuild.buildroot.net/results/f525b48e2982adc4987cb772be92eeda30569c13/
> > aarch64 | quota-4.01 | NOK | http://autobuild.buildroot.net/results/0d2c2cd0bda1dd3c1e137117df535d8e02d67e8b/
> > arm | quota-4.01 | NOK | http://autobuild.buildroot.net/results/a815a4f943e6a07f87f8f6bbf9910459575db311/
> > i686 | quota-4.01 | NOK | http://autobuild.buildroot.net/results/1b72769e65444322de4bfcb02200b7d999f9f5c1/
> > arm | quota-4.01 | NOK | http://autobuild.buildroot.net/results/195f6c34904b8185d44611c3d56084cb7d3e8a14/
> > mips64el | quota-4.01 | NOK | http://autobuild.buildroot.net/results/aac02dd6c5ea04ea70cfa6921a04b5558a9bbe7f/
> > arm | quota-4.01 | NOK | http://autobuild.buildroot.net/results/fbaec431108bec088ff543771c52f2bc20e15b31/
>
> Weird build issues.
It is a quoting problem. I will send a patch.
--
J?r?me Pouiller, Sysmic
Embedded Linux specialist
http://www.sysmic.fr
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-29 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2015-07-28 Thomas Petazzoni
@ 2015-07-29 8:03 ` Thomas Petazzoni
2015-07-29 9:30 ` Jérôme Pouiller
` (3 more replies)
0 siblings, 4 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-07-29 8:03 UTC (permalink / raw)
To: buildroot
Hello,
Clayton, Guillaume, Samuel, Gwenhael, Gustavo, Brendan, Paul, Bernd,
Angelo, Maxime, Simon: see below, there are some questions for you.
Thanks!
On Wed, 29 Jul 2015 08:30:17 +0200 (CEST), Thomas Petazzoni wrote:
> success : 205
> failures : 108
So about 1/3 failures, 2/3 successes. Overall stats:
Issues already fixed: 26
ARC toolchain issues: 19
Misc issues: 16
Musl issues: 10
SourceForge download issues: 9
Quota package issues: 8
Static linking issues: 5
Gcc too old issues: 5
Xtensa toolchain issues: 3
Atomic issues: 3
gcc 5.x issues: 1
> x86_64 | acpid-2.0.22 | NOK | http://autobuild.buildroot.net/results/7f25bb30f536b7528266c164a71d6e0761a53545/
> x86_64 | acpid-2.0.22 | NOK | http://autobuild.buildroot.net/results/e3e2a6af2df4558e20033e88815d3b504d453a10/
Musl build issues, fixed by
http://git.buildroot.net/buildroot/commit/?id=1b53609f993bf52c4b201d412fd88a38b334ab62.
> arm | aircrack-ng-1.2-rc1 | NOK | http://autobuild.buildroot.net/results/9721496871d104b4cfb68ce133b5f48612cb7e50/
> arm | aircrack-ng-1.2-rc1 | NOK | http://autobuild.buildroot.net/results/b90b4f9fdb133443113e515fb0509e3880f86879/
> arm | aircrack-ng-1.2-rc1 | NOK | http://autobuild.buildroot.net/results/efdc5c028ef79c5d04b7197b1c3491cac3a52f28/
Musl build problem:
fatal error: sys/cdefs.h: No such file or directory
> arc | atf-0.21 | NOK | http://autobuild.buildroot.net/results/a0c55e4692fd94a21236479a7c108e7d75ed2068/
> arc | atf-0.21 | NOK | http://autobuild.buildroot.net/results/dd6d2caea475ed488cd6529025125eb8754cffa9/
> arc | audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/c3a3df683357dc476c14e3c26b8361692b7e5767/
> arc | audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/d88244e0a6d28bd6fcff121e0a6babf6a75bdaa7/
> arc | audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/d7a7606ab07515225c7bd69623da9a19498d1f60/
All ARC toolchain problems.
> arm | audit-2.4.3 | NOK | http://autobuild.buildroot.net/results/d5c8e623694728d984bf45a5a0160736b7833d55/
> arm | audit-2.4.3 | NOK | http://autobuild.buildroot.net/results/ede16704d84d7df2fefd29d91dfa261a1cdef0e4/
musl build problems. Clayton, can you have a look?
> arm | bootutils-1.0.0 | NOK | http://autobuild.buildroot.net/results/44b00ad46e685dc2d92ac32a2eddc2083088505f/
raidscan.o: In function `main':
raidscan.c:(.text.startup+0x38): undefined reference to `makedev'
collect2: error: ld returned 1 exit status
Makefile:261: recipe for target 'raidscan' failed
static linking issue, maybe?
> arm | btrfs-progs-4.1.2 | NOK | http://autobuild.buildroot.net/results/b97f1e9cd459da96e3e1680bb7c43d8103ab12c2/
error: 'PATH_MAX' undeclared (first use in this function)
musl build problem.
> arc | bullet-19f999ac087e68ffc255... | NOK | http://autobuild.buildroot.net/results/36a47503f8360149ea22660e39d9a049cb0f7f79/
ARC toolchain issue.
> arm | c-icap-0.3.5 | NOK | http://autobuild.buildroot.net/results/cb623460de30dd7c4ef3275fe13220c1ca0642a5/
c_icap-service.o: In function `load_c_service':
service.c:(.text+0x710): undefined reference to `ci_module_load'
service.c:(.text+0x720): undefined reference to `ci_module_sym'
service.c:(.text+0x774): undefined reference to `ci_module_unload'
Unknown, already happened yesterday. Guillaume, can you have a look?
> arm | cc-tool-0.26 | NOK | http://autobuild.buildroot.net/results/2dc978bded498e6116422f32720e1035d9c29507/
gcc 5 issue, already fixed by
http://git.buildroot.net/buildroot/commit/?id=9c7182f30ccd52b1028b69516803bfcba1ec6812
> x86_64 | clapack-3.2.1 | NOK | http://autobuild.buildroot.net/results/117479b2fe7c8416ea2bcf65b721395ebdb17bd8/
Probably a musl issue. Samuel, can you have a look?
> arc | cppunit-1.13.2 | NOK | http://autobuild.buildroot.net/results/2e5526e794fa62856fcdfdbf33278e41e2bf52a0/
Portability.h:121:21: error: 'CppUnit' does not name a type
Not sure what's going on. Any C++ person to look into this?
> x86_64 | dmraid-1.0.0.rc16-3 | NOK | http://autobuild.buildroot.net/results/e49d781a31f539fc961843ff779ec80fa6fced9a/
error: '_PATH_MOUNTED' undeclared (first use in this function)
musl problem. Any taker?
> xtensa | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/8ac227ff6d8d052ea7d00f249ea11fb3037147f7/
> arm | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/fe8857b6013dbc6342c2a4b06ab90c4229e8077b/
> powerpc | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/aa473c992a506e6218ea0e29eae19c615f1678e3/
> x86_64 | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/bfc6797beed8db9b921d444e856fddf6f6a74ed3/
> i686 | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/f65f36f38397f076050ca2dfbbb7961928906a0b/
> x86_64 | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/0e4b1f1625a6ba790cd9d68059f783f961793eb6/
> aarch64 | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/deabb60ea38d4d6b7f7ac882a5c8c3446bc4dcc5/
> sh4a | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/fb0332a378dd9572494b0d5314189a2b680bc83c/
> sh4a | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/08efeea07be5b565756ddecda4c0c2b87c80dc66/
Download problems.
> arc | fltk-1.3.3 | NOK | http://autobuild.buildroot.net/results/c5a884764ee731fd234856085d83f599b19ef9c5/
ARC toolchain problem.
> arc | gflags-v2.1.2 | NOK | http://autobuild.buildroot.net/results/d0c884379e6d00c30e51755ca23f3cfff3755bf2/
Same.
> x86_64 | gnuradio-3.7.5 | NOK | http://autobuild.buildroot.net/results/f79203ecba17e1195de7b9f533994fc6d671028e/
error: 'mode_t' has not been declared
musl build problem. Gwenhael, you are the author of the gnuradio
package, can you have a look?
> microblazeel | gst-ffmpeg-0.10.13 | TIM | http://autobuild.buildroot.net/results/f284c5c23705f76dea9f502fa581e5383008dee0/
> arm | host-erlang-rebar-2.5.1 | TIM | http://autobuild.buildroot.net/results/9bca274f6f7331f60b9563a449fbf02b37bdf7ad/
> arm | host-erlang-rebar-2.5.1 | TIM | http://autobuild.buildroot.net/results/321c5888ce18aa4d9f428efdf4e1b844c4023345/
> arm | host-erlang-rebar-2.5.1 | TIM | http://autobuild.buildroot.net/results/c7bb82f38b36f499f75bd8e68ade1f6aba1c2219/
Misc timeouts, including the infamous host-erlang-rebar one :/
> powerpc | iproute2-4.1.1 | NOK | http://autobuild.buildroot.net/results/3657c60eaddc3626a89deac3abac8971584f4126/
> powerpc | iproute2-4.1.1 | NOK | http://autobuild.buildroot.net/results/fa810f310c7540e02c0ed84c4a3ce74ab602daa5/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=869af2ad3de46c79677699f007a5ee942aa0bb3d.
> sparc | libatomic_ops-libatomic_ops... | NOK | http://autobuild.buildroot.net/results/03b3122f27916eab19d635df7ce28acb1e330f69/
Atomic operation issue. Gustavo, Brendan maybe?
> powerpc | libebml-1.3.1 | NOK | http://autobuild.buildroot.net/results/f86e7a07863cce31fa188e134e52ed6937338846/
In file included from src/EbmlUnicodeString.cpp:44:0:
./ebml/EbmlUnicodeString.h:60:26: error: expected ')' before 'const'
UTFstring(std::wstring const &);
Don't know. Some random C++ issue.
> arm | libepoxy-v1.2 | NOK | http://autobuild.buildroot.net/results/baa00eabdc736627c88fcb609acedb0383204b12/
The usual EGL failure.
> powerpc | libfreeimage-3.17.0 | NOK | http://autobuild.buildroot.net/results/6e9f2bf02e0a165826e9fab194d6bad7901051a9/
Source/FreeImage.h:817:77: error: unknown type name 'wchar_t'
Seems like we need wchar support for libfreeimage. Any taker for this easy patch?
> sparc | libglib2-2.44.1 | NOK | http://autobuild.buildroot.net/results/3eb14acd65ee606cda9686525b6b1d3094a866cd/
> sparc | libglib2-2.44.1 | NOK | http://autobuild.buildroot.net/results/cd40a2c0d10f8a0cc104ca82c5686d1e7cc9f26f/
Atomic, fixed by
http://git.buildroot.net/buildroot/commit/?id=e4a707e79838680984cd4bb25b5a9959fc44ddc8.
> mips64el | libiscsi-1.15.0 | NOK | http://autobuild.buildroot.net/results/c07f03755d246ed2047fb4d1a8f5f9e91a30831f/
> mips64el | libiscsi-1.15.0 | NOK | http://autobuild.buildroot.net/results/f7e848cf6dd8852365d6a5cff24b0e2dd302a213/
gcc vs. ld issue, fixed by
http://git.buildroot.net/buildroot/commit/?id=84471f1e4b531a262e8f4d2423baf5257ecd29fc.
> powerpc | libpfm4-4.3.0 | NOK | http://autobuild.buildroot.net/results/e1414b1af8bab539221656cdc978d152ce8f66b8/
Tries to generate a shared library in a BR2_STATIC_LIBS configuration.
> aarch64 | libpthsem-2.0.8 | NOK | http://autobuild.buildroot.net/results/547739a745f838e1685cf2aac630ae5ab05712ee/
> mipsel | libpthsem-2.0.8 | NOK | http://autobuild.buildroot.net/results/7d0ad8dceffcd41ba5932bde95c7d51d24751c4b/
> arm | libpthsem-2.0.8 | NOK | http://autobuild.buildroot.net/results/f8074f0a278a07c47834d76cae647f1706a78c33/
pth_mctx.c: In function '__pth_mctx_set':
pth_mctx.c:480:2: error: #error "Unsupported Linux (g)libc version and/or platform"
#error "Unsupported Linux (g)libc version and/or platform"
^
To be investigated.
> arc | libselinux-2.1.13 | NOK | http://autobuild.buildroot.net/results/e60ef93ee9121be10fb2bc1b6860ae9b43f720a3/
> arc | libselinux-2.1.13 | NOK | http://autobuild.buildroot.net/results/d127dbf1c0461a355dcbe59e4c76a59a1efdfae7/
> arc | libselinux-2.1.13 | NOK | http://autobuild.buildroot.net/results/32105cec1594d43a625131bc6b16e12559d2776e/
> arc | libselinux-2.1.13 | NOK | http://autobuild.buildroot.net/results/a732d4c604489fedeb12e970cf1de55b68f2ddc9/
> arc | libselinux-2.1.13 | NOK | http://autobuild.buildroot.net/results/d8b7bc49b5091262677b11b3c1d2aa1d3d48b697/
ARC toolchain issues. Alexey, is this specific problem fixed by the
latest ARC updates?
> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/bbd8f786775c1a77219908210f52346652104b4f/
> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/7a31bd79eececd008549a9bb180f030eedbd32a9/
> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/3941bc90180892d01902687bfd2cab7325ef4fab/
> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/73f852a7302c2609afe8492b0ac69ecf1de0d152/
> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/37f875c435ecd7038ae85158756b8f711477f222/
Too old gcc.
> sh4 | libsigsegv-2.10 | NOK | http://autobuild.buildroot.net/results/629cbae701c3057940a63d7b938cc01e3bad881c/
error: unknown type name 'ucontext_t'
Should probably disable libsigsegv on SuperH.
> arm | lightning-2.0.5 | NOK | http://autobuild.buildroot.net/results/746d20ad19dc1a79bb74ed6aa348050fcca2b18e/
Tries to link with -ldl in a static library build. Paul, you are the
original author of the lightning package. Can you have a look?
> arm | make: *** [_all] Error 2 | NOK | http://autobuild.buildroot.net/results/cca3116a058a5b857776907440d95f0fdd36def8/
PAM issue with musl:
error: '_PATH_LASTLOG' undeclared (first use in this function)
Clayton, can you have a look?
> powerpc | make: *** [_all] Error 2 | NOK | http://autobuild.buildroot.net/results/3640f74037e1f7ebe658edf37fe974f1bb6b7550/
iproute2 kernel header problem, already fixed.
> arm | mesa3d-10.6.2 | NOK | http://autobuild.buildroot.net/results/6e313e2a4b2ff092d187ac564f25c14aaaceb0dd/
checking for LIBUDEV... no
configure: error: Cannot use static libraries for DRI drivers
make: *** [/home/test/autobuild/instance-1/output/build/mesa3d-10.6.2/.stamp_configured] Error 1
make: Leaving directory `/home/test/autobuild/instance-1/buildroot'
Bernd, can you have a look?
> x86_64 | midori-0.4.6 | NOK | http://autobuild.buildroot.net/results/34c31adb95edd07f08257dacf4a7f48e4049fc72/
vala/midori compatibility problem, Gustavo warned about this one. We
need to merge the remaining webkit/midori updates from Gustavo.
> powerpc | mono-4.0.2.5 | NOK | http://autobuild.buildroot.net/results/f7863af051b2b856280a944749b91ba5b552b53d/
> arm | mono-4.0.2.5 | NOK | http://autobuild.buildroot.net/results/08ec78b88abd16af8e7fc3c5e7d05eb0dbbe9613/
> powerpc | mono-4.0.2.5 | NOK | http://autobuild.buildroot.net/results/aebfbd4e7fe46edbd3798563df28b4d89903becd/
locale problem. Angelo, can you investigate ?
> powerpc | mpg123-1.22.2 | NOK | http://autobuild.buildroot.net/results/b4f229b0f7e8c36e19e3cf6e21506d4876f30749/
checking for snd_pcm_open in -lasound... no
checking if you are too dumbing dumb for the dummy... no
configure: error: One/some of your requested audio modules failed the test!
Not sure. Anyone to look into this?
> arc | mysql-5.1.73 | NOK | http://autobuild.buildroot.net/results/17808e50f3c8963875bb950b44c475b5f243c560/
> arc | mysql-5.1.73 | NOK | http://autobuild.buildroot.net/results/78bbcebd249d604890cefd5c95b5474cfec3255e/
> arc | mysql-5.1.73 | NOK | http://autobuild.buildroot.net/results/59c3891ab16b8b1ba731058044633fa6b0769249/
ARC toolchain issues.
> arm | net-tools-3eb367aedf1280f35... | NOK | http://autobuild.buildroot.net/results/e36635ad58dc191db58bc78443bafe8bbb87985a/
Missing -lintl when static linking:
undefined reference to `libintl_gettext'
Anyone to investigate?
> arm | netatalk-3.1.7 | NOK | http://autobuild.buildroot.net/results/edcd3db6ad071e52f5ed5e5265e2f6af76779219/
afpd-uam.o: In function `uam_load':
uam.c:(.text+0x18): undefined reference to `mod_open'
uam.c:(.text+0xd0): undefined reference to `mod_symbol'
uam.c:(.text+0x1b0): undefined reference to `mod_close'
Static linking issue. Maxime, netatalk is your package, can you have a look?
> arm | ola-0.9.6 | NOK | http://autobuild.buildroot.net/results/e14e1700d4fe359c56be57587bdb509e002e5753/
undefined reference to `ola::network::TCPSocket::ReadDescriptor() const'
Simon, can you have a look?
> xtensa | opencv-3.0.0 | NOK | http://autobuild.buildroot.net/results/762327dd24b0f6053c0a2ce712da9604344592e1/
> xtensa | opencv-3.0.0 | NOK | http://autobuild.buildroot.net/results/6fa8d70f8ccf937680c6740a6adbc943d79a5987/
> xtensa | opencv-3.0.0 | NOK | http://autobuild.buildroot.net/results/2e7315c8589f50bb0a002eb39b11ee15211843a8/
Xtensa toolchain problem.
> arm | protobuf-v2.5.0 | NOK | http://autobuild.buildroot.net/results/deeccf52fa62a647cb5b0a3781519b5abd08a2db/
Weird:
make[4]: *** [atomicops_internals_x86_gcc.lo] Error 1
make[4]: *** Waiting for unfinished jobs....
make[4]: *** [stringprintf.lo] Error 1
make[4]: *** [extension_set.lo] Error 1
make[4]: *** [common.lo] Error 1
make[4]: *** [atomicops_internals_x86_msvc.lo] Error 1
it looks like a parallel build problem, but not sure.
Anyone to look into this?
> xtensa | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/96763264226fcd6160c4792005c0e618aa4a82e0/
Static linking broken:
compiling plugin/qlibrary_unix.cpp
plugin/qlibrary_unix.cpp:67:19: fatal error: dlfcn.h: No such file or directory
#include <dlfcn.h>
> x86_64 | qt5base-5.5.0 | NOK | http://autobuild.buildroot.net/results/002f98d33729963ae4c9b31d7bbccc1a9e09c547/
> aarch64 | qt5base-5.5.0 | NOK | http://autobuild.buildroot.net/results/63bfee000256e27fe0ed5796710541387bcfa173/
> mips64el | qt5base-5.5.0 | NOK | http://autobuild.buildroot.net/results/b81a57b09d0aa6a9b117ea2a87f67ff36319d7bf/
> powerpc | qt5base-5.5.0 | NOK | http://autobuild.buildroot.net/results/d9ae6d4b3a73b2db3bd92488d9d0207b69a69f00/
> aarch64 | qt5base-5.5.0 | NOK | http://autobuild.buildroot.net/results/baf104c7613c6f5e4fd9728ece8b9d9548b6714c/
> arm | qt5base-5.5.0 | NOK | http://autobuild.buildroot.net/results/39e47f1d89084b9885d0db1637c30c208cf3fd3d/
> i686 | qt5base-5.5.0 | NOK | http://autobuild.buildroot.net/results/a08bc5f677e684b1298088bc1424706228950376/
> mips | qt5base-5.5.0 | NOK | http://autobuild.buildroot.net/results/adcce9b946fcc9867eb089cf5946786757fad31e/
> arm | qt5base-5.5.0 | NOK | http://autobuild.buildroot.net/results/f924e34bb5f6df83f5761b5bc863137a538756f6/
> xtensa | qt5base-5.5.0 | NOK | http://autobuild.buildroot.net/results/b29db9dbd3b954b8afc5d63e2f3f79ce04d3b630/
These should all be fixed by
http://git.buildroot.net/buildroot/commit/?id=34b4e42a2cfcc829bd5a926703a543ecf5f50b2c.
> sh4a | quota-4.01 | NOK | http://autobuild.buildroot.net/results/bba8faf210414d956cc07629b8ba99ceed0ebdf6/
> aarch64 | quota-4.01 | NOK | http://autobuild.buildroot.net/results/f525b48e2982adc4987cb772be92eeda30569c13/
> aarch64 | quota-4.01 | NOK | http://autobuild.buildroot.net/results/0d2c2cd0bda1dd3c1e137117df535d8e02d67e8b/
> arm | quota-4.01 | NOK | http://autobuild.buildroot.net/results/a815a4f943e6a07f87f8f6bbf9910459575db311/
> i686 | quota-4.01 | NOK | http://autobuild.buildroot.net/results/1b72769e65444322de4bfcb02200b7d999f9f5c1/
> arm | quota-4.01 | NOK | http://autobuild.buildroot.net/results/195f6c34904b8185d44611c3d56084cb7d3e8a14/
> mips64el | quota-4.01 | NOK | http://autobuild.buildroot.net/results/aac02dd6c5ea04ea70cfa6921a04b5558a9bbe7f/
> arm | quota-4.01 | NOK | http://autobuild.buildroot.net/results/fbaec431108bec088ff543771c52f2bc20e15b31/
Weird build issues.
> arm | setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/97b54954816123b938075b5ba4b61b8c1d2d406e/
armv7-ctng-linux-gnueabihf-gcc: error: policy_scan.c: No such file or directory
armv7-ctng-linux-gnueabihf-gcc: fatal error: no input files
This smells like a parallel build problem. Clayton ?
> arc | snmppp-3.3.5 | NOK | http://autobuild.buildroot.net/results/d4bd7f0ea0c32428beeceb3b6d1d4f71030a9950/
> arc | snmppp-3.3.5 | NOK | http://autobuild.buildroot.net/results/9062de0b97772ddb896e8d0698a9f388c9279fff/
> arc | snmppp-3.3.5 | NOK | http://autobuild.buildroot.net/results/b9c79850558a794548ebf6cda342cfa5344581f9/
> arc | snmppp-3.3.5 | NOK | http://autobuild.buildroot.net/results/47ba9ff7c51cbdececeaae3d0c5e27bb80e419d4/
> arc | snmppp-3.3.5 | NOK | http://autobuild.buildroot.net/results/8520963d2a89da6e950c24d09636db29db73cd19/
> arc | snmppp-3.3.5 | NOK | http://autobuild.buildroot.net/results/15fa8333809de37764226ebfa54ef549be56709b/
ARC toolchain issues.
> sparc | systemd-221 | NOK | http://autobuild.buildroot.net/results/2e97f8490a81b5959f6dd5285fa5a10fd9603b51/
/ssd1/thomas/autobuild/instance-0/output/build/systemd-221/src/libsystemd/sd-hwdb/sd-hwdb.c:345: undefined reference to `__sync_sub_and_fetch_4'
collect2: error: ld returned 1 exit status
Atomic issue. Brendan?
> arm | tinyalsa-f2a7b6d3d81bd337a5... | NOK | http://autobuild.buildroot.net/results/5032afa35710496802745a55d04a0d497437b947/
/home/buildroot/build/instance-0/output/host/usr/bin/arm-linux-gcc tinypcminfo.o -L. -ltinyalsa -o tinypcminfo
tinypcminfo.o: In function `main':
tinypcminfo.c:(.text+0x2f0): undefined reference to `pcm_get_format_name'
Probably a gcc 5.x related issue.
> bfin | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/7899a37d2c766716a1deff58e8be94c5c4962240/
> bfin | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/ac41bb4f831911244f739eb90097cd41081d43ba/
> bfin | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/eeb5d9368d15b10d46e8af67cd7772643eeeac0c/
All fixed by
http://git.buildroot.net/buildroot/commit/?id=c2cb0c420526906733d66c3229dce0f08cad437d.
> aarch64 | webp-0.4.3 | NOK | http://autobuild.buildroot.net/results/022ae38a44e9a7ab5e4ae237c652c7240189efb6/
internal compiler error: in simplify_const_unary_operation, at simplify-rtx.c:1539
Anyone to report this to upstream gcc ?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-28 13:56 ` Gustavo Zacarias
@ 2015-07-28 14:02 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-07-28 14:02 UTC (permalink / raw)
To: buildroot
Gustavo,
On Tue, 28 Jul 2015 10:56:12 -0300, Gustavo Zacarias wrote:
> The minimum required headers for iproute2 are 3.0, below that (2.6.39)
> it fails with namespaces. BPF is probably failing before ns because it's
> even older.
> So it's probably time to exclude iproute2 for very old toolchains, but
> unfortunately openswan & ifupdown (not that important) will suffer from it.
> It's possible openswan can work with busybox ip tools, i haven't tested
> that scenario, and unfortuantely (again) it's one of those packages that
> aren't so easy to test.
I am fine with the solution of having those packages use a >= 3.0
kernel headers dependency.
If someone wants openswan with the Busybox IP tools, they can
contribute :-)
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 13:03 ` Thomas Petazzoni
@ 2015-07-28 13:56 ` Gustavo Zacarias
2015-07-28 14:02 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Gustavo Zacarias @ 2015-07-28 13:56 UTC (permalink / raw)
To: buildroot
On 22/07/15 10:03, Thomas Petazzoni wrote:
>>>> powerpc | iproute2-4.1.1 | NOK | http://autobuild.buildroot.net/results/5c15e180973425a742629e9e8d0a56e1913d8c03/
>>>
>>> Smell very much like a too old kernel headers problem. Gustavo?
>>
>> Possible, though you know i generally hate those powerpc toolchains :)
>> I think it's time to kill them.
>
> I know you hate them. But I like them for one thing: they force us to
> keep testing with older kernel headers. Look at Luca Ceresoli, who is
> stuck with a 2.6.30 kernel.
The minimum required headers for iproute2 are 3.0, below that (2.6.39)
it fails with namespaces. BPF is probably failing before ns because it's
even older.
So it's probably time to exclude iproute2 for very old toolchains, but
unfortunately openswan & ifupdown (not that important) will suffer from it.
It's possible openswan can work with busybox ip tools, i haven't tested
that scenario, and unfortuantely (again) it's one of those packages that
aren't so easy to test.
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-23 19:03 ` Brendan Heading
@ 2015-07-23 19:04 ` Gustavo Zacarias
0 siblings, 0 replies; 416+ messages in thread
From: Gustavo Zacarias @ 2015-07-23 19:04 UTC (permalink / raw)
To: buildroot
On 23/07/15 16:03, Brendan Heading wrote:
> Thanks for explaining. I agree with you, it's pointless going to a lot
> of trouble to support much older compilers unless there's a really good
> reason.
>
> I have a CI20 here, which is a mipsel arch. I will have a play with it
> some time during the next couple of days and report back.
By the way, the minimum required gcc version is 4.8.x, i've just tested
that.
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-23 18:15 ` Gustavo Zacarias
@ 2015-07-23 19:03 ` Brendan Heading
2015-07-23 19:04 ` Gustavo Zacarias
0 siblings, 1 reply; 416+ messages in thread
From: Brendan Heading @ 2015-07-23 19:03 UTC (permalink / raw)
To: buildroot
>
>
>> mips & mips64 are disabled for a whole different reason, which is endian
> breakage.
> mipsel & mips64el are enabled in fact, and use the libatomic trick, which
> are also used for i386 and superh (though superh is disabled in general
> because of segfaults, i kept the kludge for informational purposes). The
> kludge is also kept for mips for the same reason.
> Regarding the atomics fallback it's sort of accurate, however seems to be
> failing for some reason.
> I don't have those builds built at the moment to check the details.
> If you look at the comment inside Atomics.cpp it states that gcc >= 4.8
> will handle all of this, which is the reason for libatomic, so i doubt any
> more fixing will go into webkitgtk regarding this, specially since it
> requires 4.7-4.8+ to build anyway.
> Regards.
>
Thanks for explaining. I agree with you, it's pointless going to a lot of
trouble to support much older compilers unless there's a really good
reason.
I have a CI20 here, which is a mipsel arch. I will have a play with it some
time during the next couple of days and report back.
regards
Brendan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150723/9ee6c98a/attachment.html>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 21:03 ` Brendan Heading
@ 2015-07-23 18:15 ` Gustavo Zacarias
2015-07-23 19:03 ` Brendan Heading
0 siblings, 1 reply; 416+ messages in thread
From: Gustavo Zacarias @ 2015-07-23 18:15 UTC (permalink / raw)
To: buildroot
On 22/07/15 18:03, Brendan Heading wrote:
> Ah, sorry about that. Should have checked first.
>
> The newer webkit being picked up by Gustavo's patch seems to check the
> feature macros so in principle it shouldn't have this problem.
>
> That makes me curious, though. Gustavo, you said in your comments you
> disabled MIPS support due to the absence of __sync_fetch_and_add_8 -
> however, webkit appears to provide its own substitute for this function
> in the event that it is undefined by the compiler ? (see
> Source/WTF/wtf/Atomics.cpp). At first glance I would have thought this
> should cover all the relevant cases, but no doubt you identified an issue.
mips & mips64 are disabled for a whole different reason, which is endian
breakage.
mipsel & mips64el are enabled in fact, and use the libatomic trick,
which are also used for i386 and superh (though superh is disabled in
general because of segfaults, i kept the kludge for informational
purposes). The kludge is also kept for mips for the same reason.
Regarding the atomics fallback it's sort of accurate, however seems to
be failing for some reason.
I don't have those builds built at the moment to check the details.
If you look at the comment inside Atomics.cpp it states that gcc >= 4.8
will handle all of this, which is the reason for libatomic, so i doubt
any more fixing will go into webkitgtk regarding this, specially since
it requires 4.7-4.8+ to build anyway.
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 7:43 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (9 preceding siblings ...)
2015-07-22 17:04 ` Max Filippov
@ 2015-07-23 6:27 ` Angelo Compagnucci
10 siblings, 0 replies; 416+ messages in thread
From: Angelo Compagnucci @ 2015-07-23 6:27 UTC (permalink / raw)
To: buildroot
Dear Thomas Petazzoni,
2015-07-22 9:43 GMT+02:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Hello,
>
> Brendan, Alexey, Clayton, Gustavo, J?rg, Guillaume, Marcin, Waldemar,
> Nicolas, Bernd, Johan, R?mi, Paul, Max,Samuel, Vicente, Yegor, Yann,
> please have a look below. Some of the build failures need your
> help/attention. Thanks!
>
> On Wed, 22 Jul 2015 08:30:18 +0200 (CEST), Thomas Petazzoni wrote:
>
>> success : 208
>> failures : 146
>
> Quite huge number of failures, we probably need to do something about
> this. Let's have a look at this mess.
>
>> x86_64 | acpid-2.0.22 | NOK | http://autobuild.buildroot.net/results/83f9b5216aab22d2f3de69328457590b40d27fd4/
>
> musl build issue, there was a proposed patch to fix this, but I wasn't
> really happy with it. See http://patchwork.ozlabs.org/patch/497874/.
>
>> arc | alsa-lib-1.0.29 | NOK | http://autobuild.buildroot.net/results/b704016acfa38e7998739a2c70bcf6020c59bda8/
>
> Static linking issue with uClibc. Alexey is working on it.
>
>> arc | armadillo-5.100.2 | NOK | http://autobuild.buildroot.net/results/47f176ed06540b896a7d96ebea4cbf5bf92e42b7/
>
> .tbss issue, Alexey is working on it.
>
>> arc | atf-0.21 | NOK | http://autobuild.buildroot.net/results/bc2dc2752caadfe85f02c9d708ba44a152f2127e/
>
> Same.
>
>> arc | audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/5360fdeb211a46dada1aac2bd242834fb615879f/
>> arc | audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/d74589bc1f582c7304c86b3435b613419ee9966d/
>
> Same.
>
>> powerpc | audit-2.4.1 | NOK | http://autobuild.buildroot.net/results/3e85c2253f6bd4cfe6ac1dde947eb6d5afc78cfe/
>> powerpc | audit-2.4.1 | NOK | http://autobuild.buildroot.net/results/d0f0f7e7462d68331d4a2f87b1df05cc9a6fecfd/
>> powerpc | audit-2.4.1 | NOK | http://autobuild.buildroot.net/results/114de2422c56071141284fb2eb8044ffa48e77f4/
>> powerpc | audit-2.4.1 | NOK | http://autobuild.buildroot.net/results/0862cf008e7e4b52c46c40257adeda954afee394/
>
> This is an audit problem: it is building stuff for the host, but using
> CFLAGS for the target. Clayton, can you have a look?
>
>> arm | bcusdk-0.0.5 | NOK | http://autobuild.buildroot.net/results/d963117fd6b5c59935035166b7cc32d53c008c2b/
>
> Probably needs to use argp-standalone with musl as well.
>
>> sparc | boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/dd032aa7b387f3ba5b25bffcaf833ba0ea9ba199/
>
> sparc-linux-g++: error: unrecognized argument in option '-mcpu=c3'
>
> Gustavo, any idea?
>
>> powerpc | boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/49f5c0521fc90fbd4673ad233ff679be007d2953/
>> powerpc | boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/2ae4a83a22a1c172ec4778574b5c027d2c65540e/
>
> Wchar missing. J?rg, since you fixed the last wchar issue with boost,
> can you have a look?
>
>> sparc | boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/1183ea468797b6b70a56b75066445b811704d211/
>
> Same SPARC error as above.
>
>> sparc | busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/16b2aaad834bc19b3e35604e9bbcab7b6c060307/
>> sparc | busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/98bbb53c0fa8bedf52e8f4507e4b00e631470c25/
>
> Atomic issue. Gustavo?
>
>> arm | bwm-ng-0.6 | NOK | http://autobuild.buildroot.net/results/d8302a0e1f8a6cac9d91d7bff339cc901b31d46e/
>> arm | bwm-ng-0.6 | NOK | http://autobuild.buildroot.net/results/3eb488068c167f3f1c009036c659b6ee6a9535ed/
>> arm | bwm-ng-0.6 | NOK | http://autobuild.buildroot.net/results/e27ad662a2ca1f0482151d5136695105bd5b9e7d/
>> arm | bwm-ng-0.6 | NOK | http://autobuild.buildroot.net/results/c78b6bc6c4a57046eeb87ab4d75ec7fb9c1a7f5e/
>
> Smells like a gcc 5.1 issue.
>
>> i686 | c-icap-modules-0.3.2 | NOK | http://autobuild.buildroot.net/results/2a07d48d638f20b9fb58923c37f7c44d4e4b72d5/
>> powerpc | c-icap-modules-0.3.2 | NOK | http://autobuild.buildroot.net/results/f66f128a05e80c5f4d072d019569b849615d94e6/
>> arm | c-icap-modules-0.3.2 | NOK | http://autobuild.buildroot.net/results/aa8988bb5f36491ce58681a52a11441353eb4dad/
>
> ERROR: unsafe header/library path used in cross-compilation: '/usr/lib/'
>
> Guillaume, since you are the original submitter or c-icap-modules, can
> you have a look?
>
>> arm | c-periphery-v1.0.3 | NOK | http://autobuild.buildroot.net/results/d659568db814cec9f21e591c49cfb64f73796748/
>
> src/spi.c:100:24: error: '_IOC_SIZEBITS' undeclared (first use in this function)
>
> musl issue
>
>> arm | cc-tool-0.26 | NOK | http://autobuild.buildroot.net/results/51dfa189ed674418c44acc601a200558bb58926f/
>> arc | cc-tool-0.26 | NOK | http://autobuild.buildroot.net/results/b00dfcbeab9cbf68bda5069a28d7ed000fbceebb/
>
> checking for Boost's header version...
> configure: error: invalid value: boost_major_version=
> make: *** [/home/test/autobuild/instance-2/output/build/cc-tool-0.26/.stamp_configured] Error 1
>
> checking for the Boost program_options library... no
> configure: error: cannot find the flags to link with Boost program_options
> make: *** [/home/test/autobuild/instance-0/output/build/cc-tool-0.26/.stamp_configured] Error 1
>
> Marcin, you are the original submitter of the cc-tool package. Can you have a look?
>
>> i686 | cdrkit-1.1.11 | NOK | http://autobuild.buildroot.net/results/182424bd2fea36af95eea31f7dd53f0399433616/
>
> Static linking issue:
>
> /ssd1/thomas/autobuild/instance-2/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/lib/libpthread.a(lowlevellock.os): In function `__lll_lock_wait_private':
> (.text+0x0): multiple definition of `__lll_lock_wait_private'
>
> Waldemar, I don't remember, has this issue been fixed already in
> upstream uClibc-ng ?
>
>> arm | cppcms-1.0.4 | NOK | http://autobuild.buildroot.net/results/58d3d2605337fe1ce49d333cb712941711276100/
>
> Weird C++ problem:
>
> error: 'template<class T, class A> std::size_t cppcms_boost::hash_value' conflicts with a previous declaration
>
> Nicolas, you are the original submitter of cppcms, can you have a look?
>
>> x86_64 | cramfs-1.1 | NOK | http://autobuild.buildroot.net/results/e89e2582a426e1838808e9469d043c969396dbf2/
>
> mkcramfs.c: In function 'main':
> mkcramfs.c:743:2: error: unknown type name 'loff_t'
> loff_t fslen_ub = sizeof(struct cramfs_super);
> ^
>
> Musl related issue.
>
>> arm | empty-0.6.19b | NOK | http://autobuild.buildroot.net/results/4f543f140261d294fa641be0aa9174fd5334c17c/
>> arm | empty-0.6.19b | NOK | http://autobuild.buildroot.net/results/25127b72321c3cdf778afda1f4e99fc622281705/
>
> Should be fixed by http://patchwork.ozlabs.org/patch/493343/.
>
>> arm | exfat-utils-1.1.1 | NOK | http://autobuild.buildroot.net/results/c60d0f9a93c90d41c3c86c78b0a07ddfed22c56d/
>
> libexfat/platform.h:60:2: error: #error Unknown platform
> #error Unknown platform
>
> Don't know. It's a build with musl, maybe that's the problem?
>
>> mips64el | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/69cb66c6c4ff832b66437ab80cd6de3f60485ea1/
>> x86_64 | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/06321f6baddfa0461285fd22511b64c8503d2ed0/
>> nios2 | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/b96d2aa7829acab2a186e4840d25b7e9e50769f5/
>> arm | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/de29c661333c8c7a225b46aab999424beb59894a/
>> xtensa | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/903704fa469dcea5f59a62bbf3c7f838dd2a749c/
>> mips64el | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/74f59a99a00fba119f31c1687a0e78f430767d2a/
>
> SourceForge download problem, ignore.
>
>> aarch64 | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/9ad5bbc1c5b1d172e531f05dade9cc56f59bb352/
>> mips64el | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/dad954767a4baa358c01613616bc4f599c03dac3/
>> sh4a | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/8539102de9c70cf685f85c3d073858c3115c7eab/
>> arm | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/a79ccae103414336adff2f20a240e5e63d4e1cec/
>> arm | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/422dbe84d1c7021e7c8b8e61592fe69329a2769e/
>> arm | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/53719b9197532ceafba6da0502523895d687e993/
>> xtensa | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/7f266945274b0fbc39c9a97c0de4cc1e5fd00e61/
>> arm | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/10cefc8c3725350ea1ba0d40391488cfeb839e5d/
>> aarch64 | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/3f983bb0eacc2453b123b06241ddfe2b8ab29f03/
>> xtensa | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/428336d214fefb633ef187824181a5c7b0238971/
>> powerpc | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/0e16204e8e91a7a0e3cfc55a1d7f7ab6e28efdb2/
>> arm | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/bc99b0121562b2a5f4bcd9902820e6b976af54f1/
>> mips64el | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/a96ca16911fc3f53fcfd9bfa1d90a5a3c45531c3/
>> microblazeel | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/3289b1b460664af5f10ce1c2b5d398b4514fe6d7/
>> xtensa | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/ed7bdbf9b9eed593900df7b8fd0df66edcb08bdf/
>
> SourceForge download problem, ignore.
>
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/0de880719c243d49b05705aceae7ec0007d0193c/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/62811726f4a1a993c84ea6787a150f6a35ad305a/
>> mipsel | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/525659097f8517e14ced5878c8820459bd25ccf7/
>> mips | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/da03fb5741fb2235aadb021ab919f08abb118b17/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/09f669cb892d55256c38c6da5fd79dd8972e36dd/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/5903d6dbd0e0b64b5ef879445f552229f3c2d263/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/ba604b7543c654003dd04b40f0de768d2480c68f/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/6460a7c4a19f71684f50ad66d7cd57561fe963db/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/bdebcecc4de764afdb22f34f1a31490608a0492d/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/dae417dc1d585b1386effd87c9a71f460633177c/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/2e3594f6ce2ce722e7c4330656fddd8094d52a51/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/9e164507ffb4282b7b3e79a2bd8e8a1fa4350679/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/c7bc81ecd1fc125eb741b2e15c5a4db862c2a976/
>> mipsel | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/bda2df7a0466ec2769e22d6913b9a4af51139088/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/b9107d34fd8d5d15018f5f7316737cc047f70bb4/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/da87b7fa8689a18798a229a988c4cd9268c7c54c/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/12286b94d9f90297da46e6f2a9744d4e7279e500/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/7c80764d1e1004022bd02953a47cc1b391b35ffd/
>
> Tries to use <msa.h> while the toolchain doesn't have it. Bernd, can
> you have a look?
>
>> arm | filemq-482797b8aa30fcc9ea13... | NOK | http://autobuild.buildroot.net/results/ba8e353e23c693eb7e2f7a2263e320d882840425/
>
> checking for gawk... (cached) mawk
> checking for zmq_init in -lzmq... no
> configure: error: cannot link with -lzmq, install libzmq.
> make: *** [/home/test/autobuild/instance-0/output/build/filemq-482797b8aa30fcc9ea1377aabdf2b0769f9f698e/.stamp_configured] Error 1
> make: Leaving directory `/home/test/autobuild/instance-0/buildroot'
>
> Static linking issue.
>
>> x86_64 | grantlee-0.5.1 | NOK | http://autobuild.buildroot.net/results/4b1dac8443511a27678729e067c1dec3966820b6/
>
> /home/peko/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-buildroot-linux-uclibc/4.9.3/../../../../x86_64-buildroot-linux-uclibc/bin/ld: /home/peko/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-buildroot-linux-uclibc/4.9.3/crtbeginT.o: relocation R_X86_64_32 against `__TMC_END__' can not be used when making a shared object; recompile with -fPIC
> /home/peko/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-buildroot-linux-uclibc/4.9.3/crtbeginT.o: error adding symbols: Bad value
> collect2: error: ld returned 1 exit status
>
> Zoltan, you are the original submitter of this package, can you have a
> look?
>
>> arm | harfbuzz-0.9.41 | NOK | http://autobuild.buildroot.net/results/d81fe547227ffcbd270f2a00beb572755ab668f6/
>
> Discussed in http://patchwork.ozlabs.org/patch/473622/.
>
>> arm | host-erlang-rebar-2.5.1 | TIM | http://autobuild.buildroot.net/results/d475f6d7960d8eb774d35d238c46bf1a7128c791/
>> arm | host-erlang-rebar-2.5.1 | TIM | http://autobuild.buildroot.net/results/d4ae8c5e824de02801337bd856fa62a308456ef3/
>> powerpc | host-erlang-rebar-2.5.1 | TIM | http://autobuild.buildroot.net/results/8617c4791b4c8b29423dc2fe0067c4751069a748/
>
> Johan, can you have a look at these issues? They are not spurious
> timeouts: the build of host-erlang-rebar is really blocked. I already
> analyzed this problem some time ago, and gave some details on the
> mailing list.
>
>> powerpc | host-heimdal-1.6rc2 | NOK | http://autobuild.buildroot.net/results/a07198b3f7f8029d80863a998814877ec9994c60/
>> powerpc | host-heimdal-1.6rc2 | NOK | http://autobuild.buildroot.net/results/a6d22f80938fa19933940a19664c2354e01a871f/
>> aarch64 | host-heimdal-1.6rc2 | NOK | http://autobuild.buildroot.net/results/cd15555cf90dddacdbf9599313e6e0a118049b38/
>
> Parallel build problem. We'll make host-heimdal build with $(MAKE1) in
> the mean time. Gustavo, can you submit a patch to this effect?
>
>> x86_64 | host-nodejs-0.12.7 | NOK | http://autobuild.buildroot.net/results/2ee123ec8773bbcc6ef7ecd3f0b8050547a3340e/
>
> Temporary download problem, ignore.
>
>> powerpc | iproute2-4.1.1 | NOK | http://autobuild.buildroot.net/results/5c15e180973425a742629e9e8d0a56e1913d8c03/
>
> Smell very much like a too old kernel headers problem. Gustavo?
>
>> arm | kodi-14.2-Helix | NOK | http://autobuild.buildroot.net/results/1eefd8e23d8e1b4374c79201b4c631603372d431/
>
> checking for main in -lEGL... no
> configure: error: Could not find a required library. Please see the README for your platform.
>
> Bernd?
>
>> x86_64 | libedje-1.7.10 | NOK | http://autobuild.buildroot.net/results/6b1e2132a34e0c263bb0f2ea31caf4ce697e9c9c/
>
> Another uClibc static linking problem. Waldemar?
>
>> aarch64 | libepoxy-v1.2 | NOK | http://autobuild.buildroot.net/results/4b91baf853bd5d5aa416e9dc11fda2ce27723d12/
>> mips64el | libepoxy-v1.2 | NOK | http://autobuild.buildroot.net/results/ef338817d476802b585d6272cf15c8a96d9614a6/
>
> ../include/epoxy/egl_generated.h:10:29: fatal error: EGL/eglplatform.h: No such file or directory
> #include "EGL/eglplatform.h"
>
> Bernd? Maybe this is fixed by
> http://patchwork.ozlabs.org/patch/469121/, but my questions remained
> unanswered.
>
>> powerpc | libfreeimage-3.17.0 | NOK | http://autobuild.buildroot.net/results/4d8c76b1fcd9e4267d202a6c62358fc641761228/
>
> Needs wchar support. R?mi, you are the original submitter for
> libfreeimage, can you send a patch to add the wchar dependency?
>
>> x86_64 | libftdi-0.20 | NOK | http://autobuild.buildroot.net/results/4d0009cf6f5b294d2246286e1383f663a4215648/
>
> Build issue with musl. Anyone to look into this?
>
>> sparc | libglib2-2.44.1 | NOK | http://autobuild.buildroot.net/results/530bd5b0c9a46c9d4aea249bb308b116806c43a4/
>> sparc | libglib2-2.44.1 | NOK | http://autobuild.buildroot.net/results/20f10276ee40cac4dda38904f784e72f479a5264/
>> sparc | libglib2-2.44.1 | NOK | http://autobuild.buildroot.net/results/908f7cd2434bc4235683c8cce079b839b783764a/
>
> Atomic problem. Gustavo?
>
>> arm | libiio-0.5 | NOK | http://autobuild.buildroot.net/results/5b0d02aa3bdb4cddb0d316c99fada2e7ba9f9c1d/
>
> libiio build problem. Paul, can you have a look?
>
>> arc | libselinux-2.1.13 | NOK | http://autobuild.buildroot.net/results/f08644d1ff3e769a86c4f8a3b60e40abb5f0a64e/
>> arc | libselinux-2.1.13 | NOK | http://autobuild.buildroot.net/results/4848ead8ccf4fb7b0ff582c0fac94ce9b00fd341/
>> arc | libselinux-2.1.13 | NOK | http://autobuild.buildroot.net/results/196b28f2ecf12a03390c806b5f4e9f34577998b7/
>> arc | libselinux-2.1.13 | NOK | http://autobuild.buildroot.net/results/71ee8b5b2dce1d9f096c3667cd59eaf4a3b9af2b/
>
> /tmp/ccY5Q1ef.s: Assembler messages:
> /tmp/ccY5Q1ef.s:475: Error: internal error: fixup not contained within frag
> Makefile:138: recipe for target 'setrans_client.lo' failed
>
> Alexey ?
>
>> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/f02e721e1812d03b5990884aa8f8ff09dd88272c/
>> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/bf17b998dcdb81f37776765ca200e0e5c344bada/
>> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/1b38f55602c7aff2afae6f2588e0a8f04b80b09d/
>> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/b7d703cf97345463af373217fb90e076bb3dbeb6/
>
> Compiler too old. Maybe exclude the toolchain for now?
>
>> arm | libtirpc-0.3.1 | NOK | http://autobuild.buildroot.net/results/9bdd9a8514a297a07bfef341b4545080e7798201/
>> arm | libtirpc-0.3.1 | NOK | http://autobuild.buildroot.net/results/55223f7c75e3ab21bb43af18594a5d28f02b7d30/
>> x86_64 | libtirpc-0.3.1 | NOK | http://autobuild.buildroot.net/results/7420ea57d0659ec308c0f102d496f02ed0e4d640/
>> arm | libtirpc-0.3.1 | NOK | http://autobuild.buildroot.net/results/aa6eecb7d86c63bf79c795a2d121f300ecb05baf/
>
> musl build issue. Should be fixed by
> http://patchwork.ozlabs.org/patch/497913/.
>
>> arm | linux-pam-1.1.8 | NOK | http://autobuild.buildroot.net/results/848f6223e1634921f36056c1d468a1d5faf5777b/
>
> Another musl related problem?
>
> pam_lastlog.c:248:32: error: '_PATH_LASTLOG' undeclared (first use in this function)
> "file %s is locked/read", _PATH_LASTLOG);
>
>> arm | lirc-tools-0.9.2 | NOK | http://autobuild.buildroot.net/results/96ce76ea8952958ac233d904a33413dc3ddff156/
>
> drv_admin.c:16:19: fatal error: dlfcn.h: No such file or directory
> #include <dlfcn.h>
>
> Seems like we need dynamic library support.
>
>> arm | ltris-1.0.19 | NOK | http://autobuild.buildroot.net/results/4422287dfd556546eca59096391baf99084f98d4/
>> arm | ltris-1.0.19 | NOK | http://autobuild.buildroot.net/results/2e6bfa64b356e4e9170398bc360d989f647b25e6/
>
> GCC 5.x build issue.
>
>> arm | minidlna-1.1.4 | NOK | http://autobuild.buildroot.net/results/25536df514477f3210caf4af27f2f107683f7fb2/
>
> checking for avformat_open_input in -lavformat... no
> configure: error: Could not find libavformat - part of ffmpeg
> package/pkg-generic.mk:146: recipe for target '/home/buildroot/build/instance-0/output/build/minidlna-1.1.4/.stamp_configured' failed
> make: *** [/home/buildroot/build/instance-0/output/build/minidlna-1.1.4/.stamp_configured] Error 1
>
> Bernd, maybe?
>
>> arm | mongrel2-v1.9.1 | NOK | http://autobuild.buildroot.net/results/29a3c06653c95cf238fe5abc051270a6b6c4bd5b/
>
> Another zmq static linking problem, missing -lstdc++ somewhere.
>
>> arm | mono-4.0.2.5 | NOK | http://autobuild.buildroot.net/results/5e11117048d965bc1fc44c738bb51f11164304af/
>
> /home/peko/autobuild/instance-2/output/build/mono-4.0.2.5/eglib/src/.libs/libeglib.a(libeglib_la-gunicode.o): In function `monoeg_g_get_charset':
> /home/peko/autobuild/instance-2/output/build/mono-4.0.2.5/eglib/src/gunicode.c:223: undefined reference to `locale_charset'
> collect2: error: ld returned 1 exit status
>
> Needs locale support?
>
> Angelo, can you have a look?
I will look into this ASAP!
Sincerely, Angelo
>
>> powerpc | mono-4.0.2.5 | NOK | http://autobuild.buildroot.net/results/aa008f6ea8efede4d760fe86b8b91a55471eaa37/
>
> Same.
>
>> arm | netperf-2.6.0 | NOK | http://autobuild.buildroot.net/results/077714a0ee67057abcff680b244228a409243bbf/
>
> Smells like a GCC 5.x issue:
>
> nettest_omni.o: In function `send_omni_inner':
> nettest_omni.c:(.text+0x5688): undefined reference to `demo_interval_tick'
>
>> sh4 | opencv-3.0.0 | NOK | http://autobuild.buildroot.net/results/f89a80c90b4e8bbd910aebc1a1495a9e55b243dc/
>
> /tmp/cc880Ahp.s: Assembler messages:
> /tmp/cc880Ahp.s:19803: Error: pcrel too far
> make[3]: *** [modules/video/CMakeFiles/opencv_video.dir/src/ecc.cpp.o] Error 1
>
> I'll re-exclude OpenCV with the SH4 toolchain.
>
>> xtensa | opencv-3.0.0 | NOK | http://autobuild.buildroot.net/results/dd384fe0ef02a4205bea66a4a16ca2062afe53b4/
>
> /tmp/ccHCSuXp.s: Assembler messages:
> /tmp/ccHCSuXp.s:114393: Error: operand 2 of 'l32r' has out of range value '4294705124'
> /tmp/ccHCSuXp.s:114397: Error: operand 2 of 'l32r' has out of range value '4294705068'
>
> Max ?
>
>> x86_64 | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/0a9e2c887c91197089d53754b3ca6726adebe68b/
>> i686 | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/5b1f72208acf79dfe4164df25f039027e3556671/
>> arm | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/ee4d7c54c4b1bd08d11b1c5eb10d5fa759e9c9c1/
>> powerpc | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/4347eed5c460df0771b581d70f0067b72cb42fd3/
>> i686 | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/6b6a7d8e45ee7f0ae4682567b3983590aea9ee10/
>> arm | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/b2ec60e783345419c4cc688af1cdcc5270debc57/
>> xtensa | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/aba106a1b74161c8e9c741180e79ecf437702371/
>
> These should be fixed by http://patchwork.ozlabs.org/patch/498396/.
>
>> i686 | openssh-6.9p1 | NOK | http://autobuild.buildroot.net/results/dce0202e039f4636d68532c4aab8738938b76650/
>
> Weird build issues. Gustavo?
>
>> xtensa | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/a15c8b5cf90935e42d4605f7f95ff1814c94254c/
>> powerpc | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/f444ab04da5423db032bc12824da5f577156e957/
>> bfin | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/bf6b9bcc0cead87c8fb12ec4c7f5ff73e6d61d3f/
>> bfin | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/881f1e09ad3ba0c62f04349764446d4436a28781/
>
> Some should be fixed by http://patchwork.ozlabs.org/patch/495849/, but
> definitely not all of them. Samuel, since is package is CMake based,
> can you have a look?
>
>> mips64el | qt5base-5.4.1 | NOK | http://autobuild.buildroot.net/results/cddcc7413680a8e9ec5c1862eb0bbac431bc5961/
>> mips64el | qt5base-5.4.1 | NOK | http://autobuild.buildroot.net/results/272b4acf7dea6de07d24dda4e23e41b412ffc8c6/
>> mips64el | qt5base-5.4.1 | NOK | http://autobuild.buildroot.net/results/a605608b723993352016d2aa6ae0e1b4aa03c0dd/
>
> Vicente, a MIPS problem for you :-)
>
>> i686 | qt5webkit-5.4.1 | NOK | http://autobuild.buildroot.net/results/06ca186eb9be52b455806d9e965a95c1f6197790/
>> i686 | qt5webkit-5.4.1 | NOK | http://autobuild.buildroot.net/results/87e378800a2045f2768a912db28e630088da6f56/
>
> platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp:357:9: error: reference to 'GMutexLocker' is ambiguous
>
> See https://codereview.qt-project.org/#/c/107411/. Hopefully fixed in
> qt 5.5 which I committed yesterday;
>
>> nios2 | setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/e67ef47ea9ff4cbb012d374b3b290fb7bddf7ef3/
>
> /home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.8.3/../../../../nios2-linux-gnu/bin/ld: indexcon: No symbol version section for versioned symbol `qpol_policy_rebuild@@VERS_1.3'
> /home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.8.3/../../../../nios2-linux-gnu/bin/ld: final link failed: Nonrepresentable section on output
> collect2: error: ld returned 1 exit status
> Makefile:599: recipe for target 'indexcon' failed
>
> Probably some toolchain issue. Easiest solution is to exclude setools
> from NIOS II. Clayton?
>
>> bfin | setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/2ee84c0dc027912e059ca4ae518d6f11fd8317a7/
>> bfin | setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/401e4c48f4d865b2722f284f1038e25c5d420f43/
>
> Probably the infamous _ prefix used in Blackfin symbols. Maybe we can
> also just exclude setools on Blackfin. Who would want SELinux on a
> Blackfin DSP with noMMU anyway?
>
>> arc | snmppp-3.3.5 | NOK | http://autobuild.buildroot.net/results/ff7cbcbb32dc46bfd008241da4113f79cf440e97/
>
> .tbss issue. Alexey is already working on it.
>
>> arm | socketcand-8339e62a6bf60be5... | NOK | http://autobuild.buildroot.net/results/8eac9832554dbd1f2e14cf54e5c99e6bf4dfc2cc/
>
> GCC 5.x build issues. Yegor, can you have a look?
>
>> arm | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/5c310f4d8ffebca048074660de6707a8fc598778/
>
> Temporary download problem, ignore.
>
>> bfin | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/7417400bf7ce37d2c37e36b5ed31b2dc3e6cf382/
>> bfin | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/05c9e0504af6a6630890f0cff8fdb0033f8b41ff/
>> bfin | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/1f1daec5e7547fd7a1739ce43269110ccf2a5224/
>> bfin | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/3103c9028269a20aa6c53159a48f198e81c90303/
>> arm | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/55beb7af1392cd2bedddee01edde83ce1bbcac6a/
>
> Gustavo, you're regularly bumping usb_modeswitch. Can you have a look?
>
>> arm | ustr-1.0.4 | NOK | http://autobuild.buildroot.net/results/0e114a9b6289cbced6be94a218383fb012284853/
>
> ustr-cmp-code-so-dbg.o: In function `ustr_pool_make_subpool':
> ustr-cmp-dbg-code.c:(.text+0x0): multiple definition of `ustr_pool_make_subpool'
> ustr-b-code-so-dbg.o:ustr-b-dbg-code.c:(.text+0x0): first defined here
>
> Smells like a GCC 5.x issue.
>
> Clayton, this is for you :-)
>
>> arm | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/c7fc621245351eb31afab1b96d3f1f2e6ad0bfad/
>
> checking for GLES2/gl2.h... yes
> checking whether to use OpenGL ES 2 support... configure: error: Cannot enable OpenGL ES 2 support without EGL
> package/pkg-generic.mk:146: recipe for target '/home/buildroot/build/instance-0/output/build/webkit-1.11.5/.stamp_configured' failed
> make: *** [/home/buildroot/build/instance-0/output/build/webkit-1.11.5/.stamp_configured] Error 1
> make: Leaving directory '/home/buildroot/build/instance-0/buildroot'
>
> Bernd, Gustavo?
>
>> x86_64 | weston-1.8.0 | NOK | http://autobuild.buildroot.net/results/77501a806fb5f147912e70935b53c9c0a4cb1e74/
>
> RDP compositor doesn't build:
>
> CC shared/libshared_la-file-util.lo
> src/compositor-rdp.c: In function 'rdp_peer_init':
> src/compositor-rdp.c:1109:10: error: 'rdpSettings' has no member named 'SurfaceFrameMarkerEnabled'
> settings->SurfaceFrameMarkerEnabled = TRUE;
> ^
>
> Yann ?
>
>> aarch64 | x264-c8a773ebfca148ef04f5a6... | NOK | http://autobuild.buildroot.net/results/474aabb69017c2283daf5cdd83cbd050c1b5023f/
>
> Don't know what's going on. Bernd?
>
>> arc | zeromq-4.0.5 | NOK | http://autobuild.buildroot.net/results/9ba4de85136e9ac4a68dcb7ee4285e03168d4a15/
>
> Toolchain problem:
>
> CXX libzmq_la-sub.lo
> socket_base.cpp: In member function 'void zmq::socket_base_t::event_connected(std::string&, int)':
> socket_base.cpp:1157:1: error: Internal consistency failure: cfi row mismatch [-Werror]
> }
> ^
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
--
Profile: http://it.linkedin.com/in/compagnucciangelo
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 20:46 ` Thomas Petazzoni
@ 2015-07-22 21:03 ` Brendan Heading
2015-07-23 18:15 ` Gustavo Zacarias
0 siblings, 1 reply; 416+ messages in thread
From: Brendan Heading @ 2015-07-22 21:03 UTC (permalink / raw)
To: buildroot
>
> Which webkit did you look at? The one in package/webkitgtk/ which is
> going to be deprecated and that we don't really care about? Or the
> webkitgtk24 package submitted by Gustavo (only in patchwork for now,
> not merged yet).
>
Ah, sorry about that. Should have checked first.
The newer webkit being picked up by Gustavo's patch seems to check the
feature macros so in principle it shouldn't have this problem.
That makes me curious, though. Gustavo, you said in your comments you
disabled MIPS support due to the absence of __sync_fetch_and_add_8 -
however, webkit appears to provide its own substitute for this function in
the event that it is undefined by the compiler ? (see
Source/WTF/wtf/Atomics.cpp). At first glance I would have thought this
should cover all the relevant cases, but no doubt you identified an issue.
regards
Brendan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150722/ac3f397d/attachment.html>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 20:40 ` Brendan Heading
@ 2015-07-22 20:46 ` Thomas Petazzoni
2015-07-22 21:03 ` Brendan Heading
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2015-07-22 20:46 UTC (permalink / raw)
To: buildroot
Dear Brendan Heading,
On Wed, 22 Jul 2015 21:40:00 +0100, Brendan Heading wrote:
> > Let's have a look at the issue on a per-package basis. For webkit, can
> > it either avoid using atomic operations (like glib), or can we add a
> > configure.ac test for the availability of the atomic operations, and if
> > not available, attempt again with -latomic linked in?
> >
>
> Had a quick look at webkit. If we are talking about the same problem, the
> offending section is in Source/WTF/wtf/Atomics.h : ("wtf" is a great name
> for this module, with the amount of conditional stuff in here!)
Which webkit did you look at? The one in package/webkitgtk/ which is
going to be deprecated and that we don't really care about? Or the
webkitgtk24 package submitted by Gustavo (only in patchwork for now,
not merged yet).
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 20:06 ` Thomas Petazzoni
@ 2015-07-22 20:40 ` Brendan Heading
2015-07-22 20:46 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Brendan Heading @ 2015-07-22 20:40 UTC (permalink / raw)
To: buildroot
>
> Let's have a look at the issue on a per-package basis. For webkit, can
> it either avoid using atomic operations (like glib), or can we add a
> configure.ac test for the availability of the atomic operations, and if
> not available, attempt again with -latomic linked in?
>
Had a quick look at webkit. If we are talking about the same problem, the
offending section is in Source/WTF/wtf/Atomics.h : ("wtf" is a great name
for this module, with the amount of conditional stuff in here!)
==================
[..]
#elif COMPILER(GCC) && !CPU(SPARC64) // sizeof(_Atomic_word) != sizeof(int)
on sparc64 gcc
#define WTF_USE_LOCKFREE_THREADSAFEREFCOUNTED 1
inline int atomicIncrement(int volatile* addend) { return
__sync_add_and_fetch(addend, 1); }
inline int atomicDecrement(int volatile* addend) { return
__sync_sub_and_fetch(addend, 1); }
inline int64_t atomicIncrement(int64_t volatile* addend) { return
__sync_add_and_fetch(addend, 1); }
inline int64_t atomicDecrement(int64_t volatile* addend) { return
__sync_sub_and_fetch(addend, 1); }
#endif
==================
This is looks broken as it assumes that any non-SPARC GCC has a complete
atomic locking implementation. The WTF_USE_LOCKFREE_THREADSAREREFCOUNTED
part is then used to enable calls to the atomicIncrement functions. This
macro is checked in the same file, and also in ThreadSafeRefCounted.h in
the same directory. In each case they're doing something like this example:
==================
#if USE(LOCKFREE_THREADSAFEREFCOUNTED)
atomicIncrement(&m_refCount);
#else
MutexLocker locker(m_mutex);
++m_refCount;
#endif
==================
I think it would make sense to propose a similar upstream patch as glib, ie
check for __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 in addition to COMPILER(GCC).
I'd be happy to do this if you like.
Do we have a sample failing .config for this problem ? Is it also SPARC or
is it another arch ? (I think I saw Gustavo mentioning SH).
regards
Brendan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150722/89948f4b/attachment.html>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 15:40 ` Gustavo Zacarias
2015-07-22 15:44 ` Brendan Heading
@ 2015-07-22 20:06 ` Thomas Petazzoni
2015-07-22 20:40 ` Brendan Heading
1 sibling, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2015-07-22 20:06 UTC (permalink / raw)
To: buildroot
Gustavo,
On Wed, 22 Jul 2015 12:40:00 -0300, Gustavo Zacarias wrote:
> It's been a long time since i touched SPARC hardware, and even so i
> think this looks like the right approach.
> Though for other packages we'll still need to handle the libatomic
> situation on a per-arch basis, but it will need to be finer-grained than
> that since different ISA levels affect the availability of atomics as well.
Let's have a look at the issue on a per-package basis. For webkit, can
it either avoid using atomic operations (like glib), or can we add a
configure.ac test for the availability of the atomic operations, and if
not available, attempt again with -latomic linked in?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 16:27 ` Waldemar Brodkorb
@ 2015-07-22 17:53 ` Romain Naour
2015-07-30 10:46 ` Romain Naour
0 siblings, 1 reply; 416+ messages in thread
From: Romain Naour @ 2015-07-22 17:53 UTC (permalink / raw)
To: buildroot
Hi Waldemar,
Le 22/07/2015 18:27, Waldemar Brodkorb a ?crit :
> Hi Romain,
> Romain Naour wrote,
>
>>>> x86_64 | libedje-1.7.10 | NOK | http://autobuild.buildroot.net/results/6b1e2132a34e0c263bb0f2ea31caf4ce697e9c9c/
>>>
>>> Another uClibc static linking problem. Waldemar?
>>>
>>
>> Waldemar, I think you can skip this issue since I'm working on the efl bump to
>> the latest release and I had to disable the efl package for uClibc-ng.
>>
>> I had a link issue:
>> lib/eina/.libs/libeina.so: undefined reference to `mkstemps'
>> It turn out that mkstemps and mkostemps are not available in uClibc-ng.
>
> Do you have a patch to test your bump and the issue with buildroot?
You can try with efl-1.14.2-v3 branch from my github repo:
https://github.com/RomainNaour/buildroot/tree/efl-1.14.2-v3
With this config:
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-i386-pentium4-full-2015.05-496-g85945aa.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX="i686-buildroot-linux-uclibc"
BR2_TOOLCHAIN_EXTERNAL_HEADERS_3_2=y
BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
# BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set
BR2_TOOLCHAIN_EXTERNAL_INET_RPC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_PACKAGE_EFL=y
BR2_PACKAGE_EFL_JPEG=y
BR2_PACKAGE_XORG7=y
EFL libeina library use mkstemps from here:
https://git.enlightenment.org/core/efl.git/tree/src/lib/eina/eina_file_common.c?h=efl-1.14#n941
It seems that they really use the subfix at some place in the code.
> May be efl developers could be convinced to use something more standard like?
> mkstemps() seems very glibc specific.
Indeed, man pages says that mkstemps() is unstandardized.
Thanks for your help!
Best regards,
Romain
>
> best regards
> Waldemar
>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 7:43 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (8 preceding siblings ...)
2015-07-22 16:15 ` Waldemar Brodkorb
@ 2015-07-22 17:04 ` Max Filippov
2015-07-23 6:27 ` Angelo Compagnucci
10 siblings, 0 replies; 416+ messages in thread
From: Max Filippov @ 2015-07-22 17:04 UTC (permalink / raw)
To: buildroot
On Wed, Jul 22, 2015 at 10:43 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>> xtensa | opencv-3.0.0 | NOK | http://autobuild.buildroot.net/results/dd384fe0ef02a4205bea66a4a16ca2062afe53b4/
>
> /tmp/ccHCSuXp.s: Assembler messages:
> /tmp/ccHCSuXp.s:114393: Error: operand 2 of 'l32r' has out of range value '4294705124'
> /tmp/ccHCSuXp.s:114397: Error: operand 2 of 'l32r' has out of range value '4294705068'
That's xtensa gcc problem. Let me try to fix it...
--
Thanks.
-- Max
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 10:06 ` Romain Naour
2015-07-22 11:22 ` Thomas Petazzoni
@ 2015-07-22 16:27 ` Waldemar Brodkorb
2015-07-22 17:53 ` Romain Naour
1 sibling, 1 reply; 416+ messages in thread
From: Waldemar Brodkorb @ 2015-07-22 16:27 UTC (permalink / raw)
To: buildroot
Hi Romain,
Romain Naour wrote,
> >> x86_64 | libedje-1.7.10 | NOK | http://autobuild.buildroot.net/results/6b1e2132a34e0c263bb0f2ea31caf4ce697e9c9c/
> >
> > Another uClibc static linking problem. Waldemar?
> >
>
> Waldemar, I think you can skip this issue since I'm working on the efl bump to
> the latest release and I had to disable the efl package for uClibc-ng.
>
> I had a link issue:
> lib/eina/.libs/libeina.so: undefined reference to `mkstemps'
> It turn out that mkstemps and mkostemps are not available in uClibc-ng.
Do you have a patch to test your bump and the issue with buildroot?
May be efl developers could be convinced to use something more standard like?
mkstemps() seems very glibc specific.
best regards
Waldemar
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 7:43 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (7 preceding siblings ...)
2015-07-22 15:06 ` Alexey Brodkin
@ 2015-07-22 16:15 ` Waldemar Brodkorb
2015-07-22 17:04 ` Max Filippov
2015-07-23 6:27 ` Angelo Compagnucci
10 siblings, 0 replies; 416+ messages in thread
From: Waldemar Brodkorb @ 2015-07-22 16:15 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Thomas Petazzoni wrote,
> > i686 | cdrkit-1.1.11 | NOK | http://autobuild.buildroot.net/results/182424bd2fea36af95eea31f7dd53f0399433616/
>
> Static linking issue:
>
> /ssd1/thomas/autobuild/instance-2/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/lib/libpthread.a(lowlevellock.os): In function `__lll_lock_wait_private':
> (.text+0x0): multiple definition of `__lll_lock_wait_private'
>
> Waldemar, I don't remember, has this issue been fixed already in
> upstream uClibc-ng ?
No. It was fixed for ARM and other architectures, but not for
x86/x86_64.
I have sent a patch.
best regards
Waldemar
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 15:40 ` Gustavo Zacarias
@ 2015-07-22 15:44 ` Brendan Heading
2015-07-22 20:06 ` Thomas Petazzoni
1 sibling, 0 replies; 416+ messages in thread
From: Brendan Heading @ 2015-07-22 15:44 UTC (permalink / raw)
To: buildroot
>
> It's been a long time since i touched SPARC hardware, and even so i think
> this looks like the right approach.
> Though for other packages we'll still need to handle the libatomic
> situation on a per-arch basis, but it will need to be finer-grained than
> that since different ISA levels affect the availability of atomics as well.
> Regards.
>
A similarly long time since I've touched SPARC hardware. Even longer since
I've seen SPARC on an embedded box. I've seen telecom hardware with a SPARC
CPU but that was some time ago.
Do we use the 'D' word around here (deprecation) ?
regards
Brendan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150722/06d78341/attachment.html>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 15:27 ` Brendan Heading
@ 2015-07-22 15:40 ` Gustavo Zacarias
2015-07-22 15:44 ` Brendan Heading
2015-07-22 20:06 ` Thomas Petazzoni
0 siblings, 2 replies; 416+ messages in thread
From: Gustavo Zacarias @ 2015-07-22 15:40 UTC (permalink / raw)
To: buildroot
On 22/07/15 12:27, Brendan Heading wrote:
> Brendan,
>
> My fairly uninformed opinion is that this indeed looks like a good
> approach. Though maybe Gustavo's more informed opinion might contradict
> me on this.
>
>
> Like you I would bow to Gustavo's SPARC knowledge. But I submitted the
> patch upstream, let's see what they say. I think they *intend* glib to
> fall back with the USE_NATIVE_MUTEX macro when hw support isn't present
> - here, we're just fixing their detection of that case.
>
> https://bugzilla.gnome.org/show_bug.cgi?id=752731
It's been a long time since i touched SPARC hardware, and even so i
think this looks like the right approach.
Though for other packages we'll still need to handle the libatomic
situation on a per-arch basis, but it will need to be finer-grained than
that since different ISA levels affect the availability of atomics as well.
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 15:26 ` Alexey Brodkin
@ 2015-07-22 15:33 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-07-22 15:33 UTC (permalink / raw)
To: buildroot
Dear Alexey Brodkin,
On Wed, 22 Jul 2015 15:26:41 +0000, Alexey Brodkin wrote:
> > > This is a known thing in arc-2015.06 release.
> > > So please consider prebuilt toolchain update.
> >
> > I don't understand this one: arc-2015.06 is the latest release used in
> > Buildroot. Why would rebuilding the toolchain solve this?
>
> From git log I see that my patch that bumped arc tools from arc-2015.06-rc1 to arc-2015.06
> was applied on top of master on July 15th:
> http://git.buildroot.net/buildroot/commit/?id=1f0e184e402442331bd4cbe379721e109650f7a1
>
> But BR prebuilt tools for ARC used in this build (BR2_TOOLCHAIN_EXTERNAL_URL="
> http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2015.05-496-g85945aa.tar.bz2") are dated July 7th.
>
> And I know for sure that we completely disabled "cfi row mismatch" warning here:
> https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/commit/2f87d9183367392accf601d09ab067b3eed96cf0
>
> Makes sense?
Yes, but you said "this is a known thing in arc-2015.06 release", which
to me would mean the issue still exists in arc-2015.06.
But it's actually an issue in arc-2015.06-rc1, that was fixed in
arc-2015.06.
This is what confused me.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 14:54 ` Thomas Petazzoni
@ 2015-07-22 15:27 ` Brendan Heading
2015-07-22 15:40 ` Gustavo Zacarias
0 siblings, 1 reply; 416+ messages in thread
From: Brendan Heading @ 2015-07-22 15:27 UTC (permalink / raw)
To: buildroot
On 22 July 2015 at 15:54, Thomas Petazzoni <
thomas.petazzoni@free-electrons.com> wrote:
> Brendan,
>
> My fairly uninformed opinion is that this indeed looks like a good
> approach. Though maybe Gustavo's more informed opinion might contradict
> me on this.
>
Like you I would bow to Gustavo's SPARC knowledge. But I submitted the
patch upstream, let's see what they say. I think they *intend* glib to fall
back with the USE_NATIVE_MUTEX macro when hw support isn't present - here,
we're just fixing their detection of that case.
https://bugzilla.gnome.org/show_bug.cgi?id=752731
regards
Brendan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150722/1ec92d52/attachment.html>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 15:14 ` Thomas Petazzoni
@ 2015-07-22 15:26 ` Alexey Brodkin
2015-07-22 15:33 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Alexey Brodkin @ 2015-07-22 15:26 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Wed, 2015-07-22 at 17:14 +0200, Thomas Petazzoni wrote:
> Dear Alexey Brodkin,
>
>
> > > > arc | zeromq-4.0.5 | NOK |
> > > > http://autobuild.buildroot.net/results/9ba4de85136e9ac4a68dcb7ee4285e03168d4a15/
> > >
> > > Toolchain problem:
> > >
> > > CXX libzmq_la-sub.lo
> > > socket_base.cpp: In member function 'void zmq::socket_base_t::event_connected(std::string&, int)':
> > > socket_base.cpp:1157:1: error: Internal consistency failure: cfi row mismatch [-Werror]
> > > }
> > > ^
> >
> > This is a known thing in arc-2015.06 release.
> > So please consider prebuilt toolchain update.
>
> I don't understand this one: arc-2015.06 is the latest release used in
> Buildroot. Why would rebuilding the toolchain solve this?
From git log I see that my patch that bumped arc tools from arc-2015.06-rc1 to arc-2015.06
was applied on top of master on July 15th:
http://git.buildroot.net/buildroot/commit/?id=1f0e184e402442331bd4cbe379721e109650f7a1
But BR prebuilt tools for ARC used in this build (BR2_TOOLCHAIN_EXTERNAL_URL="
http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2015.05-496-g85945aa.tar.bz2") are dated July 7th.
And I know for sure that we completely disabled "cfi row mismatch" warning here:
https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/commit/2f87d9183367392accf601d09ab067b3eed96cf0
Makes sense?
-Alexey
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 15:06 ` Alexey Brodkin
@ 2015-07-22 15:14 ` Thomas Petazzoni
2015-07-22 15:26 ` Alexey Brodkin
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2015-07-22 15:14 UTC (permalink / raw)
To: buildroot
Dear Alexey Brodkin,
On Wed, 22 Jul 2015 15:06:01 +0000, Alexey Brodkin wrote:
> Looks like this is because a missing commit in uClibc -
> Remember that discussion - http://lists.busybox.net/pipermail/uclibc/2014-September/048597.html?
> That was applied to uClibc-ng but not to uClibc which we closely following.
> Will ping Bernard once again because patch still applies perfectly fine.
>
> Sent a not to Bernard asking to apply it to uClibc master.
Good luck to get anything merged in uClibc :-)
In the mean time, maybe we can get this patch in
package/uclibc/arc-2015.06/, or you could carry it in your Git
repository ?
> I bet this is a pre-built toolchain back from arc-2015.06-rc1 days.
> Please update it to something more up to date. At least I cannot reproduce this with
> newer toolchain.
Right.
> > > arc | zeromq-4.0.5 | NOK |
> > > http://autobuild.buildroot.net/results/9ba4de85136e9ac4a68dcb7ee4285e03168d4a15/
> >
> > Toolchain problem:
> >
> > CXX libzmq_la-sub.lo
> > socket_base.cpp: In member function 'void zmq::socket_base_t::event_connected(std::string&, int)':
> > socket_base.cpp:1157:1: error: Internal consistency failure: cfi row mismatch [-Werror]
> > }
> > ^
>
> This is a known thing in arc-2015.06 release.
> So please consider prebuilt toolchain update.
I don't understand this one: arc-2015.06 is the latest release used in
Buildroot. Why would rebuilding the toolchain solve this?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 7:43 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (6 preceding siblings ...)
2015-07-22 14:49 ` Clayton Shotwell
@ 2015-07-22 15:06 ` Alexey Brodkin
2015-07-22 15:14 ` Thomas Petazzoni
2015-07-22 16:15 ` Waldemar Brodkorb
` (2 subsequent siblings)
10 siblings, 1 reply; 416+ messages in thread
From: Alexey Brodkin @ 2015-07-22 15:06 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Wed, 2015-07-22 at 09:43 +0200, Thomas Petazzoni wrote:
>
> > arc | alsa-lib-1.0.29 | NOK |
> > http://autobuild.buildroot.net/results/b704016acfa38e7998739a2c70bcf6020c59bda8/
>
> Static linking issue with uClibc. Alexey is working on it.
Looks like this is because a missing commit in uClibc -
Remember that discussion - http://lists.busybox.net/pipermail/uclibc/2014-September/048597.html?
That was applied to uClibc-ng but not to uClibc which we closely following.
Will ping Bernard once again because patch still applies perfectly fine.
Sent a not to Bernard asking to apply it to uClibc master.
>
> .tbss issue, Alexey is working on it.
>
> > arc | atf-0.21 | NOK |
> > http://autobuild.buildroot.net/results/bc2dc2752caadfe85f02c9d708ba44a152f2127e/
>
> Same.
>
> > arc | audiofile-0.3.6 | NOK |
> > http://autobuild.buildroot.net/results/5360fdeb211a46dada1aac2bd242834fb615879f/
> > arc | audiofile-0.3.6 | NOK |
> > http://autobuild.buildroot.net/results/d74589bc1f582c7304c86b3435b613419ee9966d/
>
> Same.
Looks like we identified a root cause. Now it's time to fix it properly.
> > arc | libselinux-2.1.13 | NOK |
> > http://autobuild.buildroot.net/results/f08644d1ff3e769a86c4f8a3b60e40abb5f0a64e/
> > arc | libselinux-2.1.13 | NOK |
> > http://autobuild.buildroot.net/results/4848ead8ccf4fb7b0ff582c0fac94ce9b00fd341/
> > arc | libselinux-2.1.13 | NOK |
> > http://autobuild.buildroot.net/results/196b28f2ecf12a03390c806b5f4e9f34577998b7/
> > arc | libselinux-2.1.13 | NOK |
> > http://autobuild.buildroot.net/results/71ee8b5b2dce1d9f096c3667cd59eaf4a3b9af2b/
>
> /tmp/ccY5Q1ef.s: Assembler messages:
> /tmp/ccY5Q1ef.s:475: Error: internal error: fixup not contained within frag
> Makefile:138: recipe for target 'setrans_client.lo' failed
>
> Alexey ?
I bet this is a pre-built toolchain back from arc-2015.06-rc1 days.
Please update it to something more up to date. At least I cannot reproduce this with
newer toolchain.
> > arc | zeromq-4.0.5 | NOK |
> > http://autobuild.buildroot.net/results/9ba4de85136e9ac4a68dcb7ee4285e03168d4a15/
>
> Toolchain problem:
>
> CXX libzmq_la-sub.lo
> socket_base.cpp: In member function 'void zmq::socket_base_t::event_connected(std::string&, int)':
> socket_base.cpp:1157:1: error: Internal consistency failure: cfi row mismatch [-Werror]
> }
> ^
This is a known thing in arc-2015.06 release.
So please consider prebuilt toolchain update.
-Alexey
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 14:49 ` Clayton Shotwell
@ 2015-07-22 14:56 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-07-22 14:56 UTC (permalink / raw)
To: buildroot
Clayton,
On Wed, 22 Jul 2015 09:49:06 -0500, Clayton Shotwell wrote:
> >> powerpc | audit-2.4.1 | NOK | http://autobuild.buildroot.net/results/3e85c2253f6bd4cfe6ac1dde947eb6d5afc78cfe/
> >> powerpc | audit-2.4.1 | NOK | http://autobuild.buildroot.net/results/d0f0f7e7462d68331d4a2f87b1df05cc9a6fecfd/
> >> powerpc | audit-2.4.1 | NOK | http://autobuild.buildroot.net/results/114de2422c56071141284fb2eb8044ffa48e77f4/
> >> powerpc | audit-2.4.1 | NOK | http://autobuild.buildroot.net/results/0862cf008e7e4b52c46c40257adeda954afee394/
> >
> > This is an audit problem: it is building stuff for the host, but using
> > CFLAGS for the target. Clayton, can you have a look?
>
> I have a fix for it that I will be sending out shortly.
Great, thanks.
>
> >> nios2 | setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/e67ef47ea9ff4cbb012d374b3b290fb7bddf7ef3/
> >
> > /home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.8.3/../../../../nios2-linux-gnu/bin/ld: indexcon: No symbol version section for versioned symbol `qpol_policy_rebuild@@VERS_1.3'
> > /home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.8.3/../../../../nios2-linux-gnu/bin/ld: final link failed: Nonrepresentable section on output
> > collect2: error: ld returned 1 exit status
> > Makefile:599: recipe for target 'indexcon' failed
> >
> > Probably some toolchain issue. Easiest solution is to exclude setools
> > from NIOS II. Clayton?
> >
> >> bfin | setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/2ee84c0dc027912e059ca4ae518d6f11fd8317a7/
> >> bfin | setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/401e4c48f4d865b2722f284f1038e25c5d420f43/
> >
> > Probably the infamous _ prefix used in Blackfin symbols. Maybe we can
> > also just exclude setools on Blackfin. Who would want SELinux on a
> > Blackfin DSP with noMMU anyway?
>
> I think that would be the most reasonable thing to do. Would we want
> to disable just setools or all of SELinux for both NIOS II and
> Blackfin?
Just setools IMO. There's no reason to blacklist packages that can
actually be built, if someone ever wants to get SELinux working on
those platforms.
> >> arm | ustr-1.0.4 | NOK | http://autobuild.buildroot.net/results/0e114a9b6289cbced6be94a218383fb012284853/
> >
> > ustr-cmp-code-so-dbg.o: In function `ustr_pool_make_subpool':
> > ustr-cmp-dbg-code.c:(.text+0x0): multiple definition of `ustr_pool_make_subpool'
> > ustr-b-code-so-dbg.o:ustr-b-dbg-code.c:(.text+0x0): first defined here
> >
> > Smells like a GCC 5.x issue.
> >
> > Clayton, this is for you :-)
>
> I'll see what I can do.
Thanks a lot!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 14:23 ` Brendan Heading
@ 2015-07-22 14:54 ` Thomas Petazzoni
2015-07-22 15:27 ` Brendan Heading
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2015-07-22 14:54 UTC (permalink / raw)
To: buildroot
Brendan,
On Wed, 22 Jul 2015 15:23:30 +0100, Brendan Heading wrote:
> ===================
> /* clang defines __ATOMIC_SEQ_CST but doesn't support the GCC extension */
> #if defined(HAVE_FUTEX) && defined(__ATOMIC_SEQ_CST) && !defined(__clang__)
> #define USE_NATIVE_MUTEX
> #endif
> ===================
>
> In other words, they're assuming (in essence) that if __ATOMIC_SEQ_CST is
> defined then the architecture must support atomic instructions. This
> assumption appears to be invalid.
>
> GCC defines macros which indicate the presence of the atomic compare and
> swap functions, see :
> https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
>
> If we fix the above code to :
>
> ===================
> /* clang defines __ATOMIC_SEQ_CST but doesn't support the GCC extension */
> #if defined(HAVE_FUTEX) && defined(__ATOMIC_SEQ_CST) &&
> defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4) && !defined(__clang__)
> #define USE_NATIVE_MUTEX
> #endif
> ===================
>
> ... the package compiles cleanly. This sounds like what they actually
> intended to do, as their atomic macros (gatomic.h) test the compare & swap
> macros.
My fairly uninformed opinion is that this indeed looks like a good
approach. Though maybe Gustavo's more informed opinion might contradict
me on this.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 7:43 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (5 preceding siblings ...)
2015-07-22 12:51 ` Gustavo Zacarias
@ 2015-07-22 14:49 ` Clayton Shotwell
2015-07-22 14:56 ` Thomas Petazzoni
2015-07-22 15:06 ` Alexey Brodkin
` (3 subsequent siblings)
10 siblings, 1 reply; 416+ messages in thread
From: Clayton Shotwell @ 2015-07-22 14:49 UTC (permalink / raw)
To: buildroot
Thomas and All,
On Wed, Jul 22, 2015 at 2:43 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> Brendan, Alexey, Clayton, Gustavo, J?rg, Guillaume, Marcin, Waldemar,
> Nicolas, Bernd, Johan, R?mi, Paul, Max,Samuel, Vicente, Yegor, Yann,
> please have a look below. Some of the build failures need your
> help/attention. Thanks!
[..]
>> powerpc | audit-2.4.1 | NOK | http://autobuild.buildroot.net/results/3e85c2253f6bd4cfe6ac1dde947eb6d5afc78cfe/
>> powerpc | audit-2.4.1 | NOK | http://autobuild.buildroot.net/results/d0f0f7e7462d68331d4a2f87b1df05cc9a6fecfd/
>> powerpc | audit-2.4.1 | NOK | http://autobuild.buildroot.net/results/114de2422c56071141284fb2eb8044ffa48e77f4/
>> powerpc | audit-2.4.1 | NOK | http://autobuild.buildroot.net/results/0862cf008e7e4b52c46c40257adeda954afee394/
>
> This is an audit problem: it is building stuff for the host, but using
> CFLAGS for the target. Clayton, can you have a look?
I have a fix for it that I will be sending out shortly.
>> nios2 | setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/e67ef47ea9ff4cbb012d374b3b290fb7bddf7ef3/
>
> /home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.8.3/../../../../nios2-linux-gnu/bin/ld: indexcon: No symbol version section for versioned symbol `qpol_policy_rebuild@@VERS_1.3'
> /home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.8.3/../../../../nios2-linux-gnu/bin/ld: final link failed: Nonrepresentable section on output
> collect2: error: ld returned 1 exit status
> Makefile:599: recipe for target 'indexcon' failed
>
> Probably some toolchain issue. Easiest solution is to exclude setools
> from NIOS II. Clayton?
>
>> bfin | setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/2ee84c0dc027912e059ca4ae518d6f11fd8317a7/
>> bfin | setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/401e4c48f4d865b2722f284f1038e25c5d420f43/
>
> Probably the infamous _ prefix used in Blackfin symbols. Maybe we can
> also just exclude setools on Blackfin. Who would want SELinux on a
> Blackfin DSP with noMMU anyway?
I think that would be the most reasonable thing to do. Would we want
to disable just setools or all of SELinux for both NIOS II and
Blackfin?
>> arm | ustr-1.0.4 | NOK | http://autobuild.buildroot.net/results/0e114a9b6289cbced6be94a218383fb012284853/
>
> ustr-cmp-code-so-dbg.o: In function `ustr_pool_make_subpool':
> ustr-cmp-dbg-code.c:(.text+0x0): multiple definition of `ustr_pool_make_subpool'
> ustr-b-code-so-dbg.o:ustr-b-dbg-code.c:(.text+0x0): first defined here
>
> Smells like a GCC 5.x issue.
>
> Clayton, this is for you :-)
I'll see what I can do.
Thanks,
Clayton
Clayton Shotwell
Senior Software Engineer, Rockwell Collins
clayton.shotwell at rockwellcollins.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 12:51 ` Gustavo Zacarias
2015-07-22 12:52 ` Thomas Petazzoni
@ 2015-07-22 14:23 ` Brendan Heading
2015-07-22 14:54 ` Thomas Petazzoni
1 sibling, 1 reply; 416+ messages in thread
From: Brendan Heading @ 2015-07-22 14:23 UTC (permalink / raw)
To: buildroot
Gustavo, Thomas,
Thanks for the helpful explanation earlier.
>> *Or*, maybe better, we fix those packages so that they do the right
>> configure.ac test and automatically link with libatomic if needed.
>> Probably this is what glib should do, for example. This reduces the
>> crap in Buildroot, and allows to push the solution to the upstream
>> projects. I don't think that many packages have atomic operations
>> requirements, so it should not be a horrible effort.
>>
>> Thoughts?
>
>
> The problem is that packages might have a valid reason for not doing so,
like what glib explicitly says "lockless atomics", libatomic implements the
fallback via locks.
> One of the fallbacks is that performance will suffer possibly a lot
(depending on usage), there may be other drawbacks that i'm not aware of.
I have a compromise idea for libglib2. It involves asking the upstream to
patch but avoids extra configure.ac magic. I think the same principle
applies for all packages dealing with this problem.
The problematic code in libglib2's gthread-posix.c can be traced back to
this compile-time decision point :
===================
/* clang defines __ATOMIC_SEQ_CST but doesn't support the GCC extension */
#if defined(HAVE_FUTEX) && defined(__ATOMIC_SEQ_CST) && !defined(__clang__)
#define USE_NATIVE_MUTEX
#endif
===================
In other words, they're assuming (in essence) that if __ATOMIC_SEQ_CST is
defined then the architecture must support atomic instructions. This
assumption appears to be invalid.
GCC defines macros which indicate the presence of the atomic compare and
swap functions, see :
https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
If we fix the above code to :
===================
/* clang defines __ATOMIC_SEQ_CST but doesn't support the GCC extension */
#if defined(HAVE_FUTEX) && defined(__ATOMIC_SEQ_CST) &&
defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4) && !defined(__clang__)
#define USE_NATIVE_MUTEX
#endif
===================
... the package compiles cleanly. This sounds like what they actually
intended to do, as their atomic macros (gatomic.h) test the compare & swap
macros.
regards
Brendan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150722/a771c329/attachment.html>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 12:51 ` Gustavo Zacarias
@ 2015-07-22 13:03 ` Thomas Petazzoni
2015-07-28 13:56 ` Gustavo Zacarias
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2015-07-22 13:03 UTC (permalink / raw)
To: buildroot
Gustavo,
On Wed, 22 Jul 2015 09:51:54 -0300, Gustavo Zacarias wrote:
> >> sparc | boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/dd032aa7b387f3ba5b25bffcaf833ba0ea9ba199/
> >
> > sparc-linux-g++: error: unrecognized argument in option '-mcpu=c3'
> >
> > Gustavo, any idea?
>
> Hi.
> C3 sound very much like an x86 cpu (Via), i'll take a peek.
Interesting, an x86 -mcpu option used on sparc. Is boost smooking
weed? :-)
> >> powerpc | host-heimdal-1.6rc2 | NOK | http://autobuild.buildroot.net/results/a07198b3f7f8029d80863a998814877ec9994c60/
> >> powerpc | host-heimdal-1.6rc2 | NOK | http://autobuild.buildroot.net/results/a6d22f80938fa19933940a19664c2354e01a871f/
> >> aarch64 | host-heimdal-1.6rc2 | NOK | http://autobuild.buildroot.net/results/cd15555cf90dddacdbf9599313e6e0a118049b38/
> >
> > Parallel build problem. We'll make host-heimdal build with $(MAKE1) in
> > the mean time. Gustavo, can you submit a patch to this effect?
>
> Ok, seems the sanest until upstream fixes the issues.
I agree.
> >> powerpc | iproute2-4.1.1 | NOK | http://autobuild.buildroot.net/results/5c15e180973425a742629e9e8d0a56e1913d8c03/
> >
> > Smell very much like a too old kernel headers problem. Gustavo?
>
> Possible, though you know i generally hate those powerpc toolchains :)
> I think it's time to kill them.
I know you hate them. But I like them for one thing: they force us to
keep testing with older kernel headers. Look at Luca Ceresoli, who is
stuck with a 2.6.30 kernel.
> >> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/f02e721e1812d03b5990884aa8f8ff09dd88272c/
> >> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/bf17b998dcdb81f37776765ca200e0e5c344bada/
> >> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/1b38f55602c7aff2afae6f2588e0a8f04b80b09d/
> >> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/b7d703cf97345463af373217fb90e076bb3dbeb6/
> >
> > Compiler too old. Maybe exclude the toolchain for now?
>
> Ditto above, at this point i don't think these will benefit anyone.
Well, C11 is really new. Anyone using gcc 4.7 will hit these problems I
believe, not only these oldish PowerPC toolchains.
> >> arm | netperf-2.6.0 | NOK | http://autobuild.buildroot.net/results/077714a0ee67057abcff680b244228a409243bbf/
> >
> > Smells like a GCC 5.x issue:
> >
> > nettest_omni.o: In function `send_omni_inner':
> > nettest_omni.c:(.text+0x5688): undefined reference to `demo_interval_tick'
>
> There's a new release, worth trying a bump.
Right. Will you try this?
> >> i686 | openssh-6.9p1 | NOK | http://autobuild.buildroot.net/results/dce0202e039f4636d68532c4aab8738938b76650/
> >
> > Weird build issues. Gustavo?
>
> Seems like the portability layer is playing games, on a static build,
> that looks like it's triggering it, i'll investigate.
Great, thanks!
> >> arm | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/c7fc621245351eb31afab1b96d3f1f2e6ad0bfad/
> >
> > checking for GLES2/gl2.h... yes
> > checking whether to use OpenGL ES 2 support... configure: error: Cannot enable OpenGL ES 2 support without EGL
> > package/pkg-generic.mk:146: recipe for target '/home/buildroot/build/instance-0/output/build/webkit-1.11.5/.stamp_configured' failed
> > make: *** [/home/buildroot/build/instance-0/output/build/webkit-1.11.5/.stamp_configured] Error 1
> > make: Leaving directory '/home/buildroot/build/instance-0/buildroot'
> >
> > Bernd, Gustavo?
>
> I think the way forward is upgrading, there's no point in trying to fix
> such an old version full of security bugs.
> I've got a minimal dep fix as pointed by Yann on the latest version of
> the webkitgtk24 package, i was waiting on more (any!) feedback from the
> bunch of users wanting a newer/working webkitgtk/midori but they've been
> dissapointing to say the least.
Fully agreed. I'm planning on merging your webkit work soonish. It
should definitely be in 2015.08 IMO.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 12:51 ` Gustavo Zacarias
@ 2015-07-22 12:52 ` Thomas Petazzoni
2015-07-22 14:23 ` Brendan Heading
1 sibling, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-07-22 12:52 UTC (permalink / raw)
To: buildroot
Dear Gustavo Zacarias,
On Wed, 22 Jul 2015 09:51:01 -0300, Gustavo Zacarias wrote:
> The problem is that packages might have a valid reason for not doing so,
> like what glib explicitly says "lockless atomics", libatomic implements
> the fallback via locks.
> One of the fallbacks is that performance will suffer possibly a lot
> (depending on usage), there may be other drawbacks that i'm not aware of.
Right, but then until someone implements the SPARC specific code in
glib, using the fallback with locks is still better than nothing, no?
Even if performance suffers, they are still correct from a semantic
point of view.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 7:43 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (4 preceding siblings ...)
2015-07-22 10:48 ` Brendan Heading
@ 2015-07-22 12:51 ` Gustavo Zacarias
2015-07-22 13:03 ` Thomas Petazzoni
2015-07-22 14:49 ` Clayton Shotwell
` (4 subsequent siblings)
10 siblings, 1 reply; 416+ messages in thread
From: Gustavo Zacarias @ 2015-07-22 12:51 UTC (permalink / raw)
To: buildroot
On 22/07/15 04:43, Thomas Petazzoni wrote:
>> sparc | boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/dd032aa7b387f3ba5b25bffcaf833ba0ea9ba199/
>
> sparc-linux-g++: error: unrecognized argument in option '-mcpu=c3'
>
> Gustavo, any idea?
Hi.
C3 sound very much like an x86 cpu (Via), i'll take a peek.
>> powerpc | host-heimdal-1.6rc2 | NOK | http://autobuild.buildroot.net/results/a07198b3f7f8029d80863a998814877ec9994c60/
>> powerpc | host-heimdal-1.6rc2 | NOK | http://autobuild.buildroot.net/results/a6d22f80938fa19933940a19664c2354e01a871f/
>> aarch64 | host-heimdal-1.6rc2 | NOK | http://autobuild.buildroot.net/results/cd15555cf90dddacdbf9599313e6e0a118049b38/
>
> Parallel build problem. We'll make host-heimdal build with $(MAKE1) in
> the mean time. Gustavo, can you submit a patch to this effect?
Ok, seems the sanest until upstream fixes the issues.
>> powerpc | iproute2-4.1.1 | NOK | http://autobuild.buildroot.net/results/5c15e180973425a742629e9e8d0a56e1913d8c03/
>
> Smell very much like a too old kernel headers problem. Gustavo?
Possible, though you know i generally hate those powerpc toolchains :)
I think it's time to kill them.
>> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/f02e721e1812d03b5990884aa8f8ff09dd88272c/
>> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/bf17b998dcdb81f37776765ca200e0e5c344bada/
>> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/1b38f55602c7aff2afae6f2588e0a8f04b80b09d/
>> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/b7d703cf97345463af373217fb90e076bb3dbeb6/
>
> Compiler too old. Maybe exclude the toolchain for now?
Ditto above, at this point i don't think these will benefit anyone.
>> arm | netperf-2.6.0 | NOK | http://autobuild.buildroot.net/results/077714a0ee67057abcff680b244228a409243bbf/
>
> Smells like a GCC 5.x issue:
>
> nettest_omni.o: In function `send_omni_inner':
> nettest_omni.c:(.text+0x5688): undefined reference to `demo_interval_tick'
There's a new release, worth trying a bump.
>> i686 | openssh-6.9p1 | NOK | http://autobuild.buildroot.net/results/dce0202e039f4636d68532c4aab8738938b76650/
>
> Weird build issues. Gustavo?
Seems like the portability layer is playing games, on a static build,
that looks like it's triggering it, i'll investigate.
>> bfin | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/7417400bf7ce37d2c37e36b5ed31b2dc3e6cf382/
>> bfin | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/05c9e0504af6a6630890f0cff8fdb0033f8b41ff/
>> bfin | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/1f1daec5e7547fd7a1739ce43269110ccf2a5224/
>> bfin | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/3103c9028269a20aa6c53159a48f198e81c90303/
>> arm | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/55beb7af1392cd2bedddee01edde83ce1bbcac6a/
>
> Gustavo, you're regularly bumping usb_modeswitch. Can you have a look?
Sure.
>> arm | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/c7fc621245351eb31afab1b96d3f1f2e6ad0bfad/
>
> checking for GLES2/gl2.h... yes
> checking whether to use OpenGL ES 2 support... configure: error: Cannot enable OpenGL ES 2 support without EGL
> package/pkg-generic.mk:146: recipe for target '/home/buildroot/build/instance-0/output/build/webkit-1.11.5/.stamp_configured' failed
> make: *** [/home/buildroot/build/instance-0/output/build/webkit-1.11.5/.stamp_configured] Error 1
> make: Leaving directory '/home/buildroot/build/instance-0/buildroot'
>
> Bernd, Gustavo?
I think the way forward is upgrading, there's no point in trying to fix
such an old version full of security bugs.
I've got a minimal dep fix as pointed by Yann on the latest version of
the webkitgtk24 package, i was waiting on more (any!) feedback from the
bunch of users wanting a newer/working webkitgtk/midori but they've been
dissapointing to say the least.
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 12:45 ` Thomas Petazzoni
@ 2015-07-22 12:51 ` Gustavo Zacarias
2015-07-22 12:52 ` Thomas Petazzoni
2015-07-22 14:23 ` Brendan Heading
0 siblings, 2 replies; 416+ messages in thread
From: Gustavo Zacarias @ 2015-07-22 12:51 UTC (permalink / raw)
To: buildroot
On 22/07/15 09:45, Thomas Petazzoni wrote:
> Ok, thanks for the summary. If I summarize it another way:
>
> * Some packages use atomic operations, operating on values of
> different sizes
>
> * Some architectures implement all the atomic operations in a built-in
> way, but some architectures need libatomic to be linked in to
> provide the atomic operations on certain value sizes.
Yup, that nails it.
> *Or*, maybe better, we fix those packages so that they do the right
> configure.ac test and automatically link with libatomic if needed.
> Probably this is what glib should do, for example. This reduces the
> crap in Buildroot, and allows to push the solution to the upstream
> projects. I don't think that many packages have atomic operations
> requirements, so it should not be a horrible effort.
>
> Thoughts?
The problem is that packages might have a valid reason for not doing so,
like what glib explicitly says "lockless atomics", libatomic implements
the fallback via locks.
One of the fallbacks is that performance will suffer possibly a lot
(depending on usage), there may be other drawbacks that i'm not aware of.
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 12:30 ` Gustavo Zacarias
@ 2015-07-22 12:45 ` Thomas Petazzoni
2015-07-22 12:51 ` Gustavo Zacarias
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2015-07-22 12:45 UTC (permalink / raw)
To: buildroot
Gustavo,
On Wed, 22 Jul 2015 09:30:46 -0300, Gustavo Zacarias wrote:
> That's exactly the problem, though in your previous mail you had a
> slight conceptual slip, libatomic is provided by gcc itself.
> libatomic is provided to provide (sic!) fallback atomic operations,
> usually implemented via a lock.
> SPARC v8 doesn't provide lockless atomics, it needs stbar trickery.
> v9+ does implement them via membar (TSO), see:
> http://www.oracle.com/technetwork/server-storage/solaris10/index-142944.html
>
> Long story short not every architecture provides the necessary atomics
> for all packages (sparc v8 being the "none"), since there are varying
> sizes (bits=8,16,32,64 normally).
>
> A failure example would be building libglib2 for i386 which doesn't have
> them either, though glib captures this rather than failing later:
>
> checking for lock-free atomic intrinsics... configure: error: GLib must
> be build with -march=i486 or later.
>
> Another example is the trick i'm doing for the new webkit version and
> some arch combinations:
>
> # Some 32-bit architectures need libatomic support for 64-bit ops
> ifeq ($(BR2_i386)$(BR2_mips)$(BR2_mipsel)$(BR2_sh),y)
> WEBKITGTK24_CONF_ENV += LIBS="-latomic"
> endif
>
> So adding libatomic to LIBS normally "fixes" the problem, but enabling
> it on a global-scale doesn't look that great, and each package has a
> different set of requirements depending on the atomics size it uses.
> (example: microblaze and strongswan = 8 bits).
Ok, thanks for the summary. If I summarize it another way:
* Some packages use atomic operations, operating on values of
different sizes
* Some architectures implement all the atomic operations in a built-in
way, but some architectures need libatomic to be linked in to
provide the atomic operations on certain value sizes.
> We could "declare" each package atomics needs via selects and throw
> libatomic into some variable in the package infrastructure, that's the
> best i could think of so far - but it's some work, which sparc could
> help test because it generally needs it ;)
I don't think packages should declare atomics needs via selects,
because we certainly don't want to link all packages with libatomic if
they don't need that.
However, the architectures could declare through selects which atomic
operations they have, and then packages needing operations of a given
size could use those hidden options to decide whether they should link
against libatomic or not. Like:
config BR2_ARCH_HAS_1_BYTE_ATOMIC
bool
config BR2_ARCH_HAS_2_BYTES_ATOMIC
bool
config BR2_ARCH_HAS_4_BYTES_ATOMIC
bool
config BR2_ARCH_HAS_8_BYTES_ATOMIC
bool
and then in a package:
ifeq ($(BR2_ARCH_HAS_8_BYTES_ATOMIC),)
FOO_LIBS += -latomic
endif
FOO_CONF_ENV = LIBS="$(FOO_LIBS)"
*Or*, maybe better, we fix those packages so that they do the right
configure.ac test and automatically link with libatomic if needed.
Probably this is what glib should do, for example. This reduces the
crap in Buildroot, and allows to push the solution to the upstream
projects. I don't think that many packages have atomic operations
requirements, so it should not be a horrible effort.
Thoughts?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 11:24 ` Brendan Heading
@ 2015-07-22 12:30 ` Gustavo Zacarias
2015-07-22 12:45 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Gustavo Zacarias @ 2015-07-22 12:30 UTC (permalink / raw)
To: buildroot
On 22/07/15 08:24, Brendan Heading wrote:
> A bit of further info. buildroot is generating a toolchain for SPARC v8
> (25 years young!), which doesn't have the instructions available to
> support all of the atomic functions in GCC. It seems to support some of
> them, so naive source code *thinks* that since the macro indicating the
> presence of atomic support is defined, that all of the functions exist.
>
> I guess there are a few options. We could find some way of disabling
> atomic support completely when building for SPARC; or set up the LDFLAGS
> to always link libatomic; or try to patch upstream to detect atomic
> features better - the configure script could be extended to detect if
> libatomic is needed or not.
Hi Brendan.
That's exactly the problem, though in your previous mail you had a
slight conceptual slip, libatomic is provided by gcc itself.
libatomic is provided to provide (sic!) fallback atomic operations,
usually implemented via a lock.
SPARC v8 doesn't provide lockless atomics, it needs stbar trickery.
v9+ does implement them via membar (TSO), see:
http://www.oracle.com/technetwork/server-storage/solaris10/index-142944.html
Long story short not every architecture provides the necessary atomics
for all packages (sparc v8 being the "none"), since there are varying
sizes (bits=8,16,32,64 normally).
A failure example would be building libglib2 for i386 which doesn't have
them either, though glib captures this rather than failing later:
checking for lock-free atomic intrinsics... configure: error: GLib must
be build with -march=i486 or later.
Another example is the trick i'm doing for the new webkit version and
some arch combinations:
# Some 32-bit architectures need libatomic support for 64-bit ops
ifeq ($(BR2_i386)$(BR2_mips)$(BR2_mipsel)$(BR2_sh),y)
WEBKITGTK24_CONF_ENV += LIBS="-latomic"
endif
So adding libatomic to LIBS normally "fixes" the problem, but enabling
it on a global-scale doesn't look that great, and each package has a
different set of requirements depending on the atomics size it uses.
(example: microblaze and strongswan = 8 bits).
We could "declare" each package atomics needs via selects and throw
libatomic into some variable in the package infrastructure, that's the
best i could think of so far - but it's some work, which sparc could
help test because it generally needs it ;)
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 11:22 ` Thomas Petazzoni
@ 2015-07-22 12:15 ` Romain Naour
0 siblings, 0 replies; 416+ messages in thread
From: Romain Naour @ 2015-07-22 12:15 UTC (permalink / raw)
To: buildroot
Thomas,
Le 22/07/2015 13:22, Thomas Petazzoni a ?crit :
> Romain,
>
> On Wed, 22 Jul 2015 12:06:17 +0200, Romain Naour wrote:
>
>>>> arm | harfbuzz-0.9.41 | NOK | http://autobuild.buildroot.net/results/d81fe547227ffcbd270f2a00beb572755ab668f6/
>>>
>>> Discussed in http://patchwork.ozlabs.org/patch/473622/.
>>>
>>
>> Sorry, I haven't reworked on it after Peter's reply...
>
> Ok. It'd be great to close that topic.
Sure.
>
>>>
>>>> x86_64 | libedje-1.7.10 | NOK | http://autobuild.buildroot.net/results/6b1e2132a34e0c263bb0f2ea31caf4ce697e9c9c/
>>>
>>> Another uClibc static linking problem. Waldemar?
>>>
>>
>> Waldemar, I think you can skip this issue since I'm working on the efl bump to
>> the latest release and I had to disable the efl package for uClibc-ng.
>
> Actually the issue here is not libedje specific at all, it happens with
> several other packages when linking statically against uClibc-ng. So I
> believe it is still current.
Right, I haven't looked at the issue, my bad.
I wanted to say "skip efl related build failures" ;-)
>
>> I had a link issue:
>> lib/eina/.libs/libeina.so: undefined reference to `mkstemps'
>> It turn out that mkstemps and mkostemps are not available in uClibc-ng.
>
> And so you disabled it for uClibc-ng? I personally think it's a good
> idea for now. People really interested in EFL on uClibc can always work
> on fixing the remaining small issues.
Indeed, I also tried with a musl toolchain but the build stopped on pulseaudio
which is a mandatory dependency.
>
>>>> xtensa | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/a15c8b5cf90935e42d4605f7f95ff1814c94254c/
>>>> powerpc | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/f444ab04da5423db032bc12824da5f577156e957/
>>>> bfin | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/bf6b9bcc0cead87c8fb12ec4c7f5ff73e6d61d3f/
>>>> bfin | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/881f1e09ad3ba0c62f04349764446d4436a28781/
>>>
>>> Some should be fixed by http://patchwork.ozlabs.org/patch/495849/, but
>>> definitely not all of them. Samuel, since is package is CMake based,
>>> can you have a look?
>>
>> I've looked at it yesterday, and qpid-proton should be disabled for static only
>> build since it want to build unconditionally a shared library "libqpid-proton.so"
>>
>> Also host-swig dependency seems missing.
>
> Will you send patches, or should I fix those issues directly?
Ok, I'll send patches.
Best regards,
Romain
>
> Thanks!
>
> Thomas
>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 10:48 ` Brendan Heading
@ 2015-07-22 11:24 ` Brendan Heading
2015-07-22 12:30 ` Gustavo Zacarias
0 siblings, 1 reply; 416+ messages in thread
From: Brendan Heading @ 2015-07-22 11:24 UTC (permalink / raw)
To: buildroot
On 22 July 2015 at 11:48, Brendan Heading <brendanheading@gmail.com> wrote:
>
> It sounds like the kind of problem that should ordinarily be detected and
> handled by the configure script (ie automake). It strikes me as strange
> that the developer is supposed to know whether or not to link a library
> depending on what kind of code the compiler generated, so there must be
> something I'm missing.
>
> Since the problem doesn't seem to occur on i386/x86_64 I'm wondering if
> it's one of those cases where SPARC gcc is lagging ..
>
A bit of further info. buildroot is generating a toolchain for SPARC v8 (25
years young!), which doesn't have the instructions available to support all
of the atomic functions in GCC. It seems to support some of them, so naive
source code *thinks* that since the macro indicating the presence of atomic
support is defined, that all of the functions exist.
I guess there are a few options. We could find some way of disabling atomic
support completely when building for SPARC; or set up the LDFLAGS to always
link libatomic; or try to patch upstream to detect atomic features better -
the configure script could be extended to detect if libatomic is needed or
not.
regards
Brendan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150722/c3fa76e1/attachment.html>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 10:06 ` Romain Naour
@ 2015-07-22 11:22 ` Thomas Petazzoni
2015-07-22 12:15 ` Romain Naour
2015-07-22 16:27 ` Waldemar Brodkorb
1 sibling, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2015-07-22 11:22 UTC (permalink / raw)
To: buildroot
Romain,
On Wed, 22 Jul 2015 12:06:17 +0200, Romain Naour wrote:
> >> arm | harfbuzz-0.9.41 | NOK | http://autobuild.buildroot.net/results/d81fe547227ffcbd270f2a00beb572755ab668f6/
> >
> > Discussed in http://patchwork.ozlabs.org/patch/473622/.
> >
>
> Sorry, I haven't reworked on it after Peter's reply...
Ok. It'd be great to close that topic.
> >
> >> x86_64 | libedje-1.7.10 | NOK | http://autobuild.buildroot.net/results/6b1e2132a34e0c263bb0f2ea31caf4ce697e9c9c/
> >
> > Another uClibc static linking problem. Waldemar?
> >
>
> Waldemar, I think you can skip this issue since I'm working on the efl bump to
> the latest release and I had to disable the efl package for uClibc-ng.
Actually the issue here is not libedje specific at all, it happens with
several other packages when linking statically against uClibc-ng. So I
believe it is still current.
> I had a link issue:
> lib/eina/.libs/libeina.so: undefined reference to `mkstemps'
> It turn out that mkstemps and mkostemps are not available in uClibc-ng.
And so you disabled it for uClibc-ng? I personally think it's a good
idea for now. People really interested in EFL on uClibc can always work
on fixing the remaining small issues.
> >> xtensa | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/a15c8b5cf90935e42d4605f7f95ff1814c94254c/
> >> powerpc | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/f444ab04da5423db032bc12824da5f577156e957/
> >> bfin | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/bf6b9bcc0cead87c8fb12ec4c7f5ff73e6d61d3f/
> >> bfin | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/881f1e09ad3ba0c62f04349764446d4436a28781/
> >
> > Some should be fixed by http://patchwork.ozlabs.org/patch/495849/, but
> > definitely not all of them. Samuel, since is package is CMake based,
> > can you have a look?
>
> I've looked at it yesterday, and qpid-proton should be disabled for static only
> build since it want to build unconditionally a shared library "libqpid-proton.so"
>
> Also host-swig dependency seems missing.
Will you send patches, or should I fix those issues directly?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 10:04 ` Nicolas Ménégale
@ 2015-07-22 11:20 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-07-22 11:20 UTC (permalink / raw)
To: buildroot
Dear Nicolas M?n?gale,
On Wed, 22 Jul 2015 12:04:34 +0200 (CEST), Nicolas M?n?gale wrote:
> Hi Thomas,
>
> > > arm | cppcms-1.0.4 | NOK |
> > > http://autobuild.buildroot.net/results/58d3d2605337fe1ce49d333cb712941711276100/
> >
> > Weird C++ problem:
> >
> > error: 'template<class T, class A> std::size_t
> > cppcms_boost::hash_value' conflicts with a previous declaration
> >
> > Nicolas, you are the original submitter of cppcms, can you have a
> > look?
> >
>
> I just reproduced the problem but I have a different compilation error on my workstation:
> error: ?converter_to_utf? was not declared in this scope
> error: ?converter_between? was not declared in this scope
>
> I added in CC Lucile which added the support of uCLibc, in the case she would have an idea of what is going on.
>
> I continue to investigate on this problem.
It is worth mentioning that the failing configuration at
http://autobuild.buildroot.net/results/58d3d2605337fe1ce49d333cb712941711276100/
uses glibc, not uClibc. However, this toolchain has something special:
it uses GCC 5.x, which is known to cause some build issues with various
packages.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 7:43 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (3 preceding siblings ...)
2015-07-22 10:06 ` Romain Naour
@ 2015-07-22 10:48 ` Brendan Heading
2015-07-22 11:24 ` Brendan Heading
2015-07-22 12:51 ` Gustavo Zacarias
` (5 subsequent siblings)
10 siblings, 1 reply; 416+ messages in thread
From: Brendan Heading @ 2015-07-22 10:48 UTC (permalink / raw)
To: buildroot
Hi Thomas,
> > x86_64 | acpid-2.0.22 | NOK |
> http://autobuild.buildroot.net/results/83f9b5216aab22d2f3de69328457590b40d27fd4/
>
> musl build issue, there was a proposed patch to fix this, but I wasn't
> really happy with it. See http://patchwork.ozlabs.org/patch/497874/.
>
A revised patch was submitted to upstream - maintainer has requested a
couple more tweaks, hoping to get that done today.
> > sparc | busybox-1.23.2 | NOK |
> http://autobuild.buildroot.net/results/16b2aaad834bc19b3e35604e9bbcab7b6c060307/
> > sparc | busybox-1.23.2 | NOK |
> http://autobuild.buildroot.net/results/98bbb53c0fa8bedf52e8f4507e4b00e631470c25/
>
> Atomic issue. Gustavo?
>
> > sparc | libglib2-2.44.1 | NOK |
> http://autobuild.buildroot.net/results/530bd5b0c9a46c9d4aea249bb308b116806c43a4/
> > sparc | libglib2-2.44.1 | NOK |
> http://autobuild.buildroot.net/results/20f10276ee40cac4dda38904f784e72f479a5264/
> > sparc | libglib2-2.44.1 | NOK |
> http://autobuild.buildroot.net/results/908f7cd2434bc4235683c8cce079b839b783764a/
>
> Atomic problem. Gustavo?
>
I've been having a look at the atomic sparc problem. (there seem to be a
few other packages effected by it other than those listed above -
"libpthsem" is one; I think the ruby interpreter may also see the same
issue, but I've not checked it yet).
The problem is easily reproducible on buildroot toolchains as well as the
external ones. Doesn't matter if you're using uclibc or not.
libglib2 is trying to implement its own mutexes using GCC's atomic
functions. If I'm right, I think when the compiler encounters a case where
it cannot generate code for the required function, for whatever reason, it
falls back by issuing a call to an external library. This is supplied in
libatomic, which appears to be included with the toolchain (ie glibc). When
I hacked the libglib2 build to add -latomic the problem went away. I'd say
the same hack might apply to libtirpc (which is why busybox is failing as
it links this library).
It sounds like the kind of problem that should ordinarily be detected and
handled by the configure script (ie automake). It strikes me as strange
that the developer is supposed to know whether or not to link a library
depending on what kind of code the compiler generated, so there must be
something I'm missing.
Since the problem doesn't seem to occur on i386/x86_64 I'm wondering if
it's one of those cases where SPARC gcc is lagging ..
regards
Brendan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150722/398faa61/attachment.html>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 7:43 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (2 preceding siblings ...)
2015-07-22 10:04 ` Nicolas Ménégale
@ 2015-07-22 10:06 ` Romain Naour
2015-07-22 11:22 ` Thomas Petazzoni
2015-07-22 16:27 ` Waldemar Brodkorb
2015-07-22 10:48 ` Brendan Heading
` (6 subsequent siblings)
10 siblings, 2 replies; 416+ messages in thread
From: Romain Naour @ 2015-07-22 10:06 UTC (permalink / raw)
To: buildroot
Hi Thomas, all
Le 22/07/2015 09:43, Thomas Petazzoni a ?crit :
> Hello,
>
> Brendan, Alexey, Clayton, Gustavo, J?rg, Guillaume, Marcin, Waldemar,
> Nicolas, Bernd, Johan, R?mi, Paul, Max,Samuel, Vicente, Yegor, Yann,
> please have a look below. Some of the build failures need your
> help/attention. Thanks!
>
[snip]
>> arm | cppcms-1.0.4 | NOK | http://autobuild.buildroot.net/results/58d3d2605337fe1ce49d333cb712941711276100/
>
> Weird C++ problem:
>
> error: 'template<class T, class A> std::size_t cppcms_boost::hash_value' conflicts with a previous declaration
>
> Nicolas, you are the original submitter of cppcms, can you have a look?
Nicolas is working on it.
>
>> arm | harfbuzz-0.9.41 | NOK | http://autobuild.buildroot.net/results/d81fe547227ffcbd270f2a00beb572755ab668f6/
>
> Discussed in http://patchwork.ozlabs.org/patch/473622/.
>
Sorry, I haven't reworked on it after Peter's reply...
>
>> x86_64 | libedje-1.7.10 | NOK | http://autobuild.buildroot.net/results/6b1e2132a34e0c263bb0f2ea31caf4ce697e9c9c/
>
> Another uClibc static linking problem. Waldemar?
>
Waldemar, I think you can skip this issue since I'm working on the efl bump to
the latest release and I had to disable the efl package for uClibc-ng.
I had a link issue:
lib/eina/.libs/libeina.so: undefined reference to `mkstemps'
It turn out that mkstemps and mkostemps are not available in uClibc-ng.
>
>> xtensa | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/a15c8b5cf90935e42d4605f7f95ff1814c94254c/
>> powerpc | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/f444ab04da5423db032bc12824da5f577156e957/
>> bfin | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/bf6b9bcc0cead87c8fb12ec4c7f5ff73e6d61d3f/
>> bfin | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/881f1e09ad3ba0c62f04349764446d4436a28781/
>
> Some should be fixed by http://patchwork.ozlabs.org/patch/495849/, but
> definitely not all of them. Samuel, since is package is CMake based,
> can you have a look?
>
I've looked at it yesterday, and qpid-proton should be disabled for static only
build since it want to build unconditionally a shared library "libqpid-proton.so"
Also host-swig dependency seems missing.
Best regards,
Romain
>
> Thanks,
>
> Thomas
>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 7:43 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2015-07-22 9:07 ` Yegor Yefremov
2015-07-22 9:34 ` Guillaume GARDET - Oliséo
@ 2015-07-22 10:04 ` Nicolas Ménégale
2015-07-22 11:20 ` Thomas Petazzoni
2015-07-22 10:06 ` Romain Naour
` (7 subsequent siblings)
10 siblings, 1 reply; 416+ messages in thread
From: Nicolas Ménégale @ 2015-07-22 10:04 UTC (permalink / raw)
To: buildroot
Hi Thomas,
> > arm | cppcms-1.0.4 | NOK |
> > http://autobuild.buildroot.net/results/58d3d2605337fe1ce49d333cb712941711276100/
>
> Weird C++ problem:
>
> error: 'template<class T, class A> std::size_t
> cppcms_boost::hash_value' conflicts with a previous declaration
>
> Nicolas, you are the original submitter of cppcms, can you have a
> look?
>
I just reproduced the problem but I have a different compilation error on my workstation:
error: ?converter_to_utf? was not declared in this scope
error: ?converter_between? was not declared in this scope
I added in CC Lucile which added the support of uCLibc, in the case she would have an idea of what is going on.
I continue to investigate on this problem.
Thanks a lot,
Nicolas.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 7:43 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2015-07-22 9:07 ` Yegor Yefremov
@ 2015-07-22 9:34 ` Guillaume GARDET - Oliséo
2015-07-22 10:04 ` Nicolas Ménégale
` (8 subsequent siblings)
10 siblings, 0 replies; 416+ messages in thread
From: Guillaume GARDET - Oliséo @ 2015-07-22 9:34 UTC (permalink / raw)
To: buildroot
Hi,
Le 22/07/2015 09:43, Thomas Petazzoni a ?crit :
> Hello,
>
> Brendan, Alexey, Clayton, Gustavo, J?rg, Guillaume, Marcin, Waldemar,
> Nicolas, Bernd, Johan, R?mi, Paul, Max,Samuel, Vicente, Yegor, Yann,
> please have a look below. Some of the build failures need your
> help/attention. Thanks!
[...]
>
>> i686 | c-icap-modules-0.3.2 | NOK | http://autobuild.buildroot.net/results/2a07d48d638f20b9fb58923c37f7c44d4e4b72d5/
>> powerpc | c-icap-modules-0.3.2 | NOK | http://autobuild.buildroot.net/results/f66f128a05e80c5f4d072d019569b849615d94e6/
>> arm | c-icap-modules-0.3.2 | NOK | http://autobuild.buildroot.net/results/aa8988bb5f36491ce58681a52a11441353eb4dad/
> ERROR: unsafe header/library path used in cross-compilation: '/usr/lib/'
>
> Guillaume, since you are the original submitter or c-icap-modules, can
> you have a look?
I think this is the c-icap-config script (from c-icap package) which pass wrong lib path.
I will try to have a look at it this week.
Guillaume
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 9:07 ` Yegor Yefremov
@ 2015-07-22 9:19 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-07-22 9:19 UTC (permalink / raw)
To: buildroot
Dear Yegor Yefremov,
Please strip the quoted text when you reply to an e-mail, thanks!
On Wed, 22 Jul 2015 11:07:46 +0200, Yegor Yefremov wrote:
> >> arm | socketcand-8339e62a6bf60be5... | NOK | http://autobuild.buildroot.net/results/8eac9832554dbd1f2e14cf54e5c99e6bf4dfc2cc/
> >
> > GCC 5.x build issues. Yegor, can you have a look?
>
> Sent patch upstream and awaiting reaction:
> https://github.com/dschanoeh/socketcand/pull/12
The patch looks reasonable, maybe we can merge it in Buildroot in the
mean time?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 7:43 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2015-07-22 9:07 ` Yegor Yefremov
2015-07-22 9:19 ` Thomas Petazzoni
2015-07-22 9:34 ` Guillaume GARDET - Oliséo
` (9 subsequent siblings)
10 siblings, 1 reply; 416+ messages in thread
From: Yegor Yefremov @ 2015-07-22 9:07 UTC (permalink / raw)
To: buildroot
On Wed, Jul 22, 2015 at 9:43 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> Brendan, Alexey, Clayton, Gustavo, J?rg, Guillaume, Marcin, Waldemar,
> Nicolas, Bernd, Johan, R?mi, Paul, Max,Samuel, Vicente, Yegor, Yann,
> please have a look below. Some of the build failures need your
> help/attention. Thanks!
>
> On Wed, 22 Jul 2015 08:30:18 +0200 (CEST), Thomas Petazzoni wrote:
>
>> success : 208
>> failures : 146
>
> Quite huge number of failures, we probably need to do something about
> this. Let's have a look at this mess.
>
>> x86_64 | acpid-2.0.22 | NOK | http://autobuild.buildroot.net/results/83f9b5216aab22d2f3de69328457590b40d27fd4/
>
> musl build issue, there was a proposed patch to fix this, but I wasn't
> really happy with it. See http://patchwork.ozlabs.org/patch/497874/.
>
>> arc | alsa-lib-1.0.29 | NOK | http://autobuild.buildroot.net/results/b704016acfa38e7998739a2c70bcf6020c59bda8/
>
> Static linking issue with uClibc. Alexey is working on it.
>
>> arc | armadillo-5.100.2 | NOK | http://autobuild.buildroot.net/results/47f176ed06540b896a7d96ebea4cbf5bf92e42b7/
>
> .tbss issue, Alexey is working on it.
>
>> arc | atf-0.21 | NOK | http://autobuild.buildroot.net/results/bc2dc2752caadfe85f02c9d708ba44a152f2127e/
>
> Same.
>
>> arc | audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/5360fdeb211a46dada1aac2bd242834fb615879f/
>> arc | audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/d74589bc1f582c7304c86b3435b613419ee9966d/
>
> Same.
>
>> powerpc | audit-2.4.1 | NOK | http://autobuild.buildroot.net/results/3e85c2253f6bd4cfe6ac1dde947eb6d5afc78cfe/
>> powerpc | audit-2.4.1 | NOK | http://autobuild.buildroot.net/results/d0f0f7e7462d68331d4a2f87b1df05cc9a6fecfd/
>> powerpc | audit-2.4.1 | NOK | http://autobuild.buildroot.net/results/114de2422c56071141284fb2eb8044ffa48e77f4/
>> powerpc | audit-2.4.1 | NOK | http://autobuild.buildroot.net/results/0862cf008e7e4b52c46c40257adeda954afee394/
>
> This is an audit problem: it is building stuff for the host, but using
> CFLAGS for the target. Clayton, can you have a look?
>
>> arm | bcusdk-0.0.5 | NOK | http://autobuild.buildroot.net/results/d963117fd6b5c59935035166b7cc32d53c008c2b/
>
> Probably needs to use argp-standalone with musl as well.
>
>> sparc | boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/dd032aa7b387f3ba5b25bffcaf833ba0ea9ba199/
>
> sparc-linux-g++: error: unrecognized argument in option '-mcpu=c3'
>
> Gustavo, any idea?
>
>> powerpc | boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/49f5c0521fc90fbd4673ad233ff679be007d2953/
>> powerpc | boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/2ae4a83a22a1c172ec4778574b5c027d2c65540e/
>
> Wchar missing. J?rg, since you fixed the last wchar issue with boost,
> can you have a look?
>
>> sparc | boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/1183ea468797b6b70a56b75066445b811704d211/
>
> Same SPARC error as above.
>
>> sparc | busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/16b2aaad834bc19b3e35604e9bbcab7b6c060307/
>> sparc | busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/98bbb53c0fa8bedf52e8f4507e4b00e631470c25/
>
> Atomic issue. Gustavo?
>
>> arm | bwm-ng-0.6 | NOK | http://autobuild.buildroot.net/results/d8302a0e1f8a6cac9d91d7bff339cc901b31d46e/
>> arm | bwm-ng-0.6 | NOK | http://autobuild.buildroot.net/results/3eb488068c167f3f1c009036c659b6ee6a9535ed/
>> arm | bwm-ng-0.6 | NOK | http://autobuild.buildroot.net/results/e27ad662a2ca1f0482151d5136695105bd5b9e7d/
>> arm | bwm-ng-0.6 | NOK | http://autobuild.buildroot.net/results/c78b6bc6c4a57046eeb87ab4d75ec7fb9c1a7f5e/
>
> Smells like a gcc 5.1 issue.
>
>> i686 | c-icap-modules-0.3.2 | NOK | http://autobuild.buildroot.net/results/2a07d48d638f20b9fb58923c37f7c44d4e4b72d5/
>> powerpc | c-icap-modules-0.3.2 | NOK | http://autobuild.buildroot.net/results/f66f128a05e80c5f4d072d019569b849615d94e6/
>> arm | c-icap-modules-0.3.2 | NOK | http://autobuild.buildroot.net/results/aa8988bb5f36491ce58681a52a11441353eb4dad/
>
> ERROR: unsafe header/library path used in cross-compilation: '/usr/lib/'
>
> Guillaume, since you are the original submitter or c-icap-modules, can
> you have a look?
>
>> arm | c-periphery-v1.0.3 | NOK | http://autobuild.buildroot.net/results/d659568db814cec9f21e591c49cfb64f73796748/
>
> src/spi.c:100:24: error: '_IOC_SIZEBITS' undeclared (first use in this function)
>
> musl issue
>
>> arm | cc-tool-0.26 | NOK | http://autobuild.buildroot.net/results/51dfa189ed674418c44acc601a200558bb58926f/
>> arc | cc-tool-0.26 | NOK | http://autobuild.buildroot.net/results/b00dfcbeab9cbf68bda5069a28d7ed000fbceebb/
>
> checking for Boost's header version...
> configure: error: invalid value: boost_major_version=
> make: *** [/home/test/autobuild/instance-2/output/build/cc-tool-0.26/.stamp_configured] Error 1
>
> checking for the Boost program_options library... no
> configure: error: cannot find the flags to link with Boost program_options
> make: *** [/home/test/autobuild/instance-0/output/build/cc-tool-0.26/.stamp_configured] Error 1
>
> Marcin, you are the original submitter of the cc-tool package. Can you have a look?
>
>> i686 | cdrkit-1.1.11 | NOK | http://autobuild.buildroot.net/results/182424bd2fea36af95eea31f7dd53f0399433616/
>
> Static linking issue:
>
> /ssd1/thomas/autobuild/instance-2/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/lib/libpthread.a(lowlevellock.os): In function `__lll_lock_wait_private':
> (.text+0x0): multiple definition of `__lll_lock_wait_private'
>
> Waldemar, I don't remember, has this issue been fixed already in
> upstream uClibc-ng ?
>
>> arm | cppcms-1.0.4 | NOK | http://autobuild.buildroot.net/results/58d3d2605337fe1ce49d333cb712941711276100/
>
> Weird C++ problem:
>
> error: 'template<class T, class A> std::size_t cppcms_boost::hash_value' conflicts with a previous declaration
>
> Nicolas, you are the original submitter of cppcms, can you have a look?
>
>> x86_64 | cramfs-1.1 | NOK | http://autobuild.buildroot.net/results/e89e2582a426e1838808e9469d043c969396dbf2/
>
> mkcramfs.c: In function 'main':
> mkcramfs.c:743:2: error: unknown type name 'loff_t'
> loff_t fslen_ub = sizeof(struct cramfs_super);
> ^
>
> Musl related issue.
>
>> arm | empty-0.6.19b | NOK | http://autobuild.buildroot.net/results/4f543f140261d294fa641be0aa9174fd5334c17c/
>> arm | empty-0.6.19b | NOK | http://autobuild.buildroot.net/results/25127b72321c3cdf778afda1f4e99fc622281705/
>
> Should be fixed by http://patchwork.ozlabs.org/patch/493343/.
>
>> arm | exfat-utils-1.1.1 | NOK | http://autobuild.buildroot.net/results/c60d0f9a93c90d41c3c86c78b0a07ddfed22c56d/
>
> libexfat/platform.h:60:2: error: #error Unknown platform
> #error Unknown platform
>
> Don't know. It's a build with musl, maybe that's the problem?
>
>> mips64el | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/69cb66c6c4ff832b66437ab80cd6de3f60485ea1/
>> x86_64 | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/06321f6baddfa0461285fd22511b64c8503d2ed0/
>> nios2 | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/b96d2aa7829acab2a186e4840d25b7e9e50769f5/
>> arm | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/de29c661333c8c7a225b46aab999424beb59894a/
>> xtensa | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/903704fa469dcea5f59a62bbf3c7f838dd2a749c/
>> mips64el | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/74f59a99a00fba119f31c1687a0e78f430767d2a/
>
> SourceForge download problem, ignore.
>
>> aarch64 | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/9ad5bbc1c5b1d172e531f05dade9cc56f59bb352/
>> mips64el | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/dad954767a4baa358c01613616bc4f599c03dac3/
>> sh4a | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/8539102de9c70cf685f85c3d073858c3115c7eab/
>> arm | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/a79ccae103414336adff2f20a240e5e63d4e1cec/
>> arm | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/422dbe84d1c7021e7c8b8e61592fe69329a2769e/
>> arm | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/53719b9197532ceafba6da0502523895d687e993/
>> xtensa | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/7f266945274b0fbc39c9a97c0de4cc1e5fd00e61/
>> arm | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/10cefc8c3725350ea1ba0d40391488cfeb839e5d/
>> aarch64 | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/3f983bb0eacc2453b123b06241ddfe2b8ab29f03/
>> xtensa | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/428336d214fefb633ef187824181a5c7b0238971/
>> powerpc | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/0e16204e8e91a7a0e3cfc55a1d7f7ab6e28efdb2/
>> arm | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/bc99b0121562b2a5f4bcd9902820e6b976af54f1/
>> mips64el | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/a96ca16911fc3f53fcfd9bfa1d90a5a3c45531c3/
>> microblazeel | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/3289b1b460664af5f10ce1c2b5d398b4514fe6d7/
>> xtensa | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/ed7bdbf9b9eed593900df7b8fd0df66edcb08bdf/
>
> SourceForge download problem, ignore.
>
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/0de880719c243d49b05705aceae7ec0007d0193c/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/62811726f4a1a993c84ea6787a150f6a35ad305a/
>> mipsel | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/525659097f8517e14ced5878c8820459bd25ccf7/
>> mips | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/da03fb5741fb2235aadb021ab919f08abb118b17/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/09f669cb892d55256c38c6da5fd79dd8972e36dd/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/5903d6dbd0e0b64b5ef879445f552229f3c2d263/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/ba604b7543c654003dd04b40f0de768d2480c68f/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/6460a7c4a19f71684f50ad66d7cd57561fe963db/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/bdebcecc4de764afdb22f34f1a31490608a0492d/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/dae417dc1d585b1386effd87c9a71f460633177c/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/2e3594f6ce2ce722e7c4330656fddd8094d52a51/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/9e164507ffb4282b7b3e79a2bd8e8a1fa4350679/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/c7bc81ecd1fc125eb741b2e15c5a4db862c2a976/
>> mipsel | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/bda2df7a0466ec2769e22d6913b9a4af51139088/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/b9107d34fd8d5d15018f5f7316737cc047f70bb4/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/da87b7fa8689a18798a229a988c4cd9268c7c54c/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/12286b94d9f90297da46e6f2a9744d4e7279e500/
>> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/7c80764d1e1004022bd02953a47cc1b391b35ffd/
>
> Tries to use <msa.h> while the toolchain doesn't have it. Bernd, can
> you have a look?
>
>> arm | filemq-482797b8aa30fcc9ea13... | NOK | http://autobuild.buildroot.net/results/ba8e353e23c693eb7e2f7a2263e320d882840425/
>
> checking for gawk... (cached) mawk
> checking for zmq_init in -lzmq... no
> configure: error: cannot link with -lzmq, install libzmq.
> make: *** [/home/test/autobuild/instance-0/output/build/filemq-482797b8aa30fcc9ea1377aabdf2b0769f9f698e/.stamp_configured] Error 1
> make: Leaving directory `/home/test/autobuild/instance-0/buildroot'
>
> Static linking issue.
>
>> x86_64 | grantlee-0.5.1 | NOK | http://autobuild.buildroot.net/results/4b1dac8443511a27678729e067c1dec3966820b6/
>
> /home/peko/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-buildroot-linux-uclibc/4.9.3/../../../../x86_64-buildroot-linux-uclibc/bin/ld: /home/peko/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-buildroot-linux-uclibc/4.9.3/crtbeginT.o: relocation R_X86_64_32 against `__TMC_END__' can not be used when making a shared object; recompile with -fPIC
> /home/peko/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-buildroot-linux-uclibc/4.9.3/crtbeginT.o: error adding symbols: Bad value
> collect2: error: ld returned 1 exit status
>
> Zoltan, you are the original submitter of this package, can you have a
> look?
>
>> arm | harfbuzz-0.9.41 | NOK | http://autobuild.buildroot.net/results/d81fe547227ffcbd270f2a00beb572755ab668f6/
>
> Discussed in http://patchwork.ozlabs.org/patch/473622/.
>
>> arm | host-erlang-rebar-2.5.1 | TIM | http://autobuild.buildroot.net/results/d475f6d7960d8eb774d35d238c46bf1a7128c791/
>> arm | host-erlang-rebar-2.5.1 | TIM | http://autobuild.buildroot.net/results/d4ae8c5e824de02801337bd856fa62a308456ef3/
>> powerpc | host-erlang-rebar-2.5.1 | TIM | http://autobuild.buildroot.net/results/8617c4791b4c8b29423dc2fe0067c4751069a748/
>
> Johan, can you have a look at these issues? They are not spurious
> timeouts: the build of host-erlang-rebar is really blocked. I already
> analyzed this problem some time ago, and gave some details on the
> mailing list.
>
>> powerpc | host-heimdal-1.6rc2 | NOK | http://autobuild.buildroot.net/results/a07198b3f7f8029d80863a998814877ec9994c60/
>> powerpc | host-heimdal-1.6rc2 | NOK | http://autobuild.buildroot.net/results/a6d22f80938fa19933940a19664c2354e01a871f/
>> aarch64 | host-heimdal-1.6rc2 | NOK | http://autobuild.buildroot.net/results/cd15555cf90dddacdbf9599313e6e0a118049b38/
>
> Parallel build problem. We'll make host-heimdal build with $(MAKE1) in
> the mean time. Gustavo, can you submit a patch to this effect?
>
>> x86_64 | host-nodejs-0.12.7 | NOK | http://autobuild.buildroot.net/results/2ee123ec8773bbcc6ef7ecd3f0b8050547a3340e/
>
> Temporary download problem, ignore.
>
>> powerpc | iproute2-4.1.1 | NOK | http://autobuild.buildroot.net/results/5c15e180973425a742629e9e8d0a56e1913d8c03/
>
> Smell very much like a too old kernel headers problem. Gustavo?
>
>> arm | kodi-14.2-Helix | NOK | http://autobuild.buildroot.net/results/1eefd8e23d8e1b4374c79201b4c631603372d431/
>
> checking for main in -lEGL... no
> configure: error: Could not find a required library. Please see the README for your platform.
>
> Bernd?
>
>> x86_64 | libedje-1.7.10 | NOK | http://autobuild.buildroot.net/results/6b1e2132a34e0c263bb0f2ea31caf4ce697e9c9c/
>
> Another uClibc static linking problem. Waldemar?
>
>> aarch64 | libepoxy-v1.2 | NOK | http://autobuild.buildroot.net/results/4b91baf853bd5d5aa416e9dc11fda2ce27723d12/
>> mips64el | libepoxy-v1.2 | NOK | http://autobuild.buildroot.net/results/ef338817d476802b585d6272cf15c8a96d9614a6/
>
> ../include/epoxy/egl_generated.h:10:29: fatal error: EGL/eglplatform.h: No such file or directory
> #include "EGL/eglplatform.h"
>
> Bernd? Maybe this is fixed by
> http://patchwork.ozlabs.org/patch/469121/, but my questions remained
> unanswered.
>
>> powerpc | libfreeimage-3.17.0 | NOK | http://autobuild.buildroot.net/results/4d8c76b1fcd9e4267d202a6c62358fc641761228/
>
> Needs wchar support. R?mi, you are the original submitter for
> libfreeimage, can you send a patch to add the wchar dependency?
>
>> x86_64 | libftdi-0.20 | NOK | http://autobuild.buildroot.net/results/4d0009cf6f5b294d2246286e1383f663a4215648/
>
> Build issue with musl. Anyone to look into this?
>
>> sparc | libglib2-2.44.1 | NOK | http://autobuild.buildroot.net/results/530bd5b0c9a46c9d4aea249bb308b116806c43a4/
>> sparc | libglib2-2.44.1 | NOK | http://autobuild.buildroot.net/results/20f10276ee40cac4dda38904f784e72f479a5264/
>> sparc | libglib2-2.44.1 | NOK | http://autobuild.buildroot.net/results/908f7cd2434bc4235683c8cce079b839b783764a/
>
> Atomic problem. Gustavo?
>
>> arm | libiio-0.5 | NOK | http://autobuild.buildroot.net/results/5b0d02aa3bdb4cddb0d316c99fada2e7ba9f9c1d/
>
> libiio build problem. Paul, can you have a look?
>
>> arc | libselinux-2.1.13 | NOK | http://autobuild.buildroot.net/results/f08644d1ff3e769a86c4f8a3b60e40abb5f0a64e/
>> arc | libselinux-2.1.13 | NOK | http://autobuild.buildroot.net/results/4848ead8ccf4fb7b0ff582c0fac94ce9b00fd341/
>> arc | libselinux-2.1.13 | NOK | http://autobuild.buildroot.net/results/196b28f2ecf12a03390c806b5f4e9f34577998b7/
>> arc | libselinux-2.1.13 | NOK | http://autobuild.buildroot.net/results/71ee8b5b2dce1d9f096c3667cd59eaf4a3b9af2b/
>
> /tmp/ccY5Q1ef.s: Assembler messages:
> /tmp/ccY5Q1ef.s:475: Error: internal error: fixup not contained within frag
> Makefile:138: recipe for target 'setrans_client.lo' failed
>
> Alexey ?
>
>> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/f02e721e1812d03b5990884aa8f8ff09dd88272c/
>> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/bf17b998dcdb81f37776765ca200e0e5c344bada/
>> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/1b38f55602c7aff2afae6f2588e0a8f04b80b09d/
>> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/b7d703cf97345463af373217fb90e076bb3dbeb6/
>
> Compiler too old. Maybe exclude the toolchain for now?
>
>> arm | libtirpc-0.3.1 | NOK | http://autobuild.buildroot.net/results/9bdd9a8514a297a07bfef341b4545080e7798201/
>> arm | libtirpc-0.3.1 | NOK | http://autobuild.buildroot.net/results/55223f7c75e3ab21bb43af18594a5d28f02b7d30/
>> x86_64 | libtirpc-0.3.1 | NOK | http://autobuild.buildroot.net/results/7420ea57d0659ec308c0f102d496f02ed0e4d640/
>> arm | libtirpc-0.3.1 | NOK | http://autobuild.buildroot.net/results/aa6eecb7d86c63bf79c795a2d121f300ecb05baf/
>
> musl build issue. Should be fixed by
> http://patchwork.ozlabs.org/patch/497913/.
>
>> arm | linux-pam-1.1.8 | NOK | http://autobuild.buildroot.net/results/848f6223e1634921f36056c1d468a1d5faf5777b/
>
> Another musl related problem?
>
> pam_lastlog.c:248:32: error: '_PATH_LASTLOG' undeclared (first use in this function)
> "file %s is locked/read", _PATH_LASTLOG);
>
>> arm | lirc-tools-0.9.2 | NOK | http://autobuild.buildroot.net/results/96ce76ea8952958ac233d904a33413dc3ddff156/
>
> drv_admin.c:16:19: fatal error: dlfcn.h: No such file or directory
> #include <dlfcn.h>
>
> Seems like we need dynamic library support.
>
>> arm | ltris-1.0.19 | NOK | http://autobuild.buildroot.net/results/4422287dfd556546eca59096391baf99084f98d4/
>> arm | ltris-1.0.19 | NOK | http://autobuild.buildroot.net/results/2e6bfa64b356e4e9170398bc360d989f647b25e6/
>
> GCC 5.x build issue.
>
>> arm | minidlna-1.1.4 | NOK | http://autobuild.buildroot.net/results/25536df514477f3210caf4af27f2f107683f7fb2/
>
> checking for avformat_open_input in -lavformat... no
> configure: error: Could not find libavformat - part of ffmpeg
> package/pkg-generic.mk:146: recipe for target '/home/buildroot/build/instance-0/output/build/minidlna-1.1.4/.stamp_configured' failed
> make: *** [/home/buildroot/build/instance-0/output/build/minidlna-1.1.4/.stamp_configured] Error 1
>
> Bernd, maybe?
>
>> arm | mongrel2-v1.9.1 | NOK | http://autobuild.buildroot.net/results/29a3c06653c95cf238fe5abc051270a6b6c4bd5b/
>
> Another zmq static linking problem, missing -lstdc++ somewhere.
>
>> arm | mono-4.0.2.5 | NOK | http://autobuild.buildroot.net/results/5e11117048d965bc1fc44c738bb51f11164304af/
>
> /home/peko/autobuild/instance-2/output/build/mono-4.0.2.5/eglib/src/.libs/libeglib.a(libeglib_la-gunicode.o): In function `monoeg_g_get_charset':
> /home/peko/autobuild/instance-2/output/build/mono-4.0.2.5/eglib/src/gunicode.c:223: undefined reference to `locale_charset'
> collect2: error: ld returned 1 exit status
>
> Needs locale support?
>
> Angelo, can you have a look?
>
>> powerpc | mono-4.0.2.5 | NOK | http://autobuild.buildroot.net/results/aa008f6ea8efede4d760fe86b8b91a55471eaa37/
>
> Same.
>
>> arm | netperf-2.6.0 | NOK | http://autobuild.buildroot.net/results/077714a0ee67057abcff680b244228a409243bbf/
>
> Smells like a GCC 5.x issue:
>
> nettest_omni.o: In function `send_omni_inner':
> nettest_omni.c:(.text+0x5688): undefined reference to `demo_interval_tick'
>
>> sh4 | opencv-3.0.0 | NOK | http://autobuild.buildroot.net/results/f89a80c90b4e8bbd910aebc1a1495a9e55b243dc/
>
> /tmp/cc880Ahp.s: Assembler messages:
> /tmp/cc880Ahp.s:19803: Error: pcrel too far
> make[3]: *** [modules/video/CMakeFiles/opencv_video.dir/src/ecc.cpp.o] Error 1
>
> I'll re-exclude OpenCV with the SH4 toolchain.
>
>> xtensa | opencv-3.0.0 | NOK | http://autobuild.buildroot.net/results/dd384fe0ef02a4205bea66a4a16ca2062afe53b4/
>
> /tmp/ccHCSuXp.s: Assembler messages:
> /tmp/ccHCSuXp.s:114393: Error: operand 2 of 'l32r' has out of range value '4294705124'
> /tmp/ccHCSuXp.s:114397: Error: operand 2 of 'l32r' has out of range value '4294705068'
>
> Max ?
>
>> x86_64 | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/0a9e2c887c91197089d53754b3ca6726adebe68b/
>> i686 | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/5b1f72208acf79dfe4164df25f039027e3556671/
>> arm | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/ee4d7c54c4b1bd08d11b1c5eb10d5fa759e9c9c1/
>> powerpc | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/4347eed5c460df0771b581d70f0067b72cb42fd3/
>> i686 | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/6b6a7d8e45ee7f0ae4682567b3983590aea9ee10/
>> arm | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/b2ec60e783345419c4cc688af1cdcc5270debc57/
>> xtensa | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/aba106a1b74161c8e9c741180e79ecf437702371/
>
> These should be fixed by http://patchwork.ozlabs.org/patch/498396/.
>
>> i686 | openssh-6.9p1 | NOK | http://autobuild.buildroot.net/results/dce0202e039f4636d68532c4aab8738938b76650/
>
> Weird build issues. Gustavo?
>
>> xtensa | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/a15c8b5cf90935e42d4605f7f95ff1814c94254c/
>> powerpc | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/f444ab04da5423db032bc12824da5f577156e957/
>> bfin | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/bf6b9bcc0cead87c8fb12ec4c7f5ff73e6d61d3f/
>> bfin | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/881f1e09ad3ba0c62f04349764446d4436a28781/
>
> Some should be fixed by http://patchwork.ozlabs.org/patch/495849/, but
> definitely not all of them. Samuel, since is package is CMake based,
> can you have a look?
>
>> mips64el | qt5base-5.4.1 | NOK | http://autobuild.buildroot.net/results/cddcc7413680a8e9ec5c1862eb0bbac431bc5961/
>> mips64el | qt5base-5.4.1 | NOK | http://autobuild.buildroot.net/results/272b4acf7dea6de07d24dda4e23e41b412ffc8c6/
>> mips64el | qt5base-5.4.1 | NOK | http://autobuild.buildroot.net/results/a605608b723993352016d2aa6ae0e1b4aa03c0dd/
>
> Vicente, a MIPS problem for you :-)
>
>> i686 | qt5webkit-5.4.1 | NOK | http://autobuild.buildroot.net/results/06ca186eb9be52b455806d9e965a95c1f6197790/
>> i686 | qt5webkit-5.4.1 | NOK | http://autobuild.buildroot.net/results/87e378800a2045f2768a912db28e630088da6f56/
>
> platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp:357:9: error: reference to 'GMutexLocker' is ambiguous
>
> See https://codereview.qt-project.org/#/c/107411/. Hopefully fixed in
> qt 5.5 which I committed yesterday;
>
>> nios2 | setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/e67ef47ea9ff4cbb012d374b3b290fb7bddf7ef3/
>
> /home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.8.3/../../../../nios2-linux-gnu/bin/ld: indexcon: No symbol version section for versioned symbol `qpol_policy_rebuild@@VERS_1.3'
> /home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.8.3/../../../../nios2-linux-gnu/bin/ld: final link failed: Nonrepresentable section on output
> collect2: error: ld returned 1 exit status
> Makefile:599: recipe for target 'indexcon' failed
>
> Probably some toolchain issue. Easiest solution is to exclude setools
> from NIOS II. Clayton?
>
>> bfin | setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/2ee84c0dc027912e059ca4ae518d6f11fd8317a7/
>> bfin | setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/401e4c48f4d865b2722f284f1038e25c5d420f43/
>
> Probably the infamous _ prefix used in Blackfin symbols. Maybe we can
> also just exclude setools on Blackfin. Who would want SELinux on a
> Blackfin DSP with noMMU anyway?
>
>> arc | snmppp-3.3.5 | NOK | http://autobuild.buildroot.net/results/ff7cbcbb32dc46bfd008241da4113f79cf440e97/
>
> .tbss issue. Alexey is already working on it.
>
>> arm | socketcand-8339e62a6bf60be5... | NOK | http://autobuild.buildroot.net/results/8eac9832554dbd1f2e14cf54e5c99e6bf4dfc2cc/
>
> GCC 5.x build issues. Yegor, can you have a look?
Sent patch upstream and awaiting reaction:
https://github.com/dschanoeh/socketcand/pull/12
>> arm | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/5c310f4d8ffebca048074660de6707a8fc598778/
>
> Temporary download problem, ignore.
>
>> bfin | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/7417400bf7ce37d2c37e36b5ed31b2dc3e6cf382/
>> bfin | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/05c9e0504af6a6630890f0cff8fdb0033f8b41ff/
>> bfin | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/1f1daec5e7547fd7a1739ce43269110ccf2a5224/
>> bfin | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/3103c9028269a20aa6c53159a48f198e81c90303/
>> arm | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/55beb7af1392cd2bedddee01edde83ce1bbcac6a/
>
> Gustavo, you're regularly bumping usb_modeswitch. Can you have a look?
>
>> arm | ustr-1.0.4 | NOK | http://autobuild.buildroot.net/results/0e114a9b6289cbced6be94a218383fb012284853/
>
> ustr-cmp-code-so-dbg.o: In function `ustr_pool_make_subpool':
> ustr-cmp-dbg-code.c:(.text+0x0): multiple definition of `ustr_pool_make_subpool'
> ustr-b-code-so-dbg.o:ustr-b-dbg-code.c:(.text+0x0): first defined here
>
> Smells like a GCC 5.x issue.
>
> Clayton, this is for you :-)
>
>> arm | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/c7fc621245351eb31afab1b96d3f1f2e6ad0bfad/
>
> checking for GLES2/gl2.h... yes
> checking whether to use OpenGL ES 2 support... configure: error: Cannot enable OpenGL ES 2 support without EGL
> package/pkg-generic.mk:146: recipe for target '/home/buildroot/build/instance-0/output/build/webkit-1.11.5/.stamp_configured' failed
> make: *** [/home/buildroot/build/instance-0/output/build/webkit-1.11.5/.stamp_configured] Error 1
> make: Leaving directory '/home/buildroot/build/instance-0/buildroot'
>
> Bernd, Gustavo?
>
>> x86_64 | weston-1.8.0 | NOK | http://autobuild.buildroot.net/results/77501a806fb5f147912e70935b53c9c0a4cb1e74/
>
> RDP compositor doesn't build:
>
> CC shared/libshared_la-file-util.lo
> src/compositor-rdp.c: In function 'rdp_peer_init':
> src/compositor-rdp.c:1109:10: error: 'rdpSettings' has no member named 'SurfaceFrameMarkerEnabled'
> settings->SurfaceFrameMarkerEnabled = TRUE;
> ^
>
> Yann ?
>
>> aarch64 | x264-c8a773ebfca148ef04f5a6... | NOK | http://autobuild.buildroot.net/results/474aabb69017c2283daf5cdd83cbd050c1b5023f/
>
> Don't know what's going on. Bernd?
>
>> arc | zeromq-4.0.5 | NOK | http://autobuild.buildroot.net/results/9ba4de85136e9ac4a68dcb7ee4285e03168d4a15/
>
> Toolchain problem:
>
> CXX libzmq_la-sub.lo
> socket_base.cpp: In member function 'void zmq::socket_base_t::event_connected(std::string&, int)':
> socket_base.cpp:1157:1: error: Internal consistency failure: cfi row mismatch [-Werror]
> }
> ^
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-07-22 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2015-07-21 Thomas Petazzoni
@ 2015-07-22 7:43 ` Thomas Petazzoni
2015-07-22 9:07 ` Yegor Yefremov
` (10 more replies)
0 siblings, 11 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-07-22 7:43 UTC (permalink / raw)
To: buildroot
Hello,
Brendan, Alexey, Clayton, Gustavo, J?rg, Guillaume, Marcin, Waldemar,
Nicolas, Bernd, Johan, R?mi, Paul, Max,Samuel, Vicente, Yegor, Yann,
please have a look below. Some of the build failures need your
help/attention. Thanks!
On Wed, 22 Jul 2015 08:30:18 +0200 (CEST), Thomas Petazzoni wrote:
> success : 208
> failures : 146
Quite huge number of failures, we probably need to do something about
this. Let's have a look at this mess.
> x86_64 | acpid-2.0.22 | NOK | http://autobuild.buildroot.net/results/83f9b5216aab22d2f3de69328457590b40d27fd4/
musl build issue, there was a proposed patch to fix this, but I wasn't
really happy with it. See http://patchwork.ozlabs.org/patch/497874/.
> arc | alsa-lib-1.0.29 | NOK | http://autobuild.buildroot.net/results/b704016acfa38e7998739a2c70bcf6020c59bda8/
Static linking issue with uClibc. Alexey is working on it.
> arc | armadillo-5.100.2 | NOK | http://autobuild.buildroot.net/results/47f176ed06540b896a7d96ebea4cbf5bf92e42b7/
.tbss issue, Alexey is working on it.
> arc | atf-0.21 | NOK | http://autobuild.buildroot.net/results/bc2dc2752caadfe85f02c9d708ba44a152f2127e/
Same.
> arc | audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/5360fdeb211a46dada1aac2bd242834fb615879f/
> arc | audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/d74589bc1f582c7304c86b3435b613419ee9966d/
Same.
> powerpc | audit-2.4.1 | NOK | http://autobuild.buildroot.net/results/3e85c2253f6bd4cfe6ac1dde947eb6d5afc78cfe/
> powerpc | audit-2.4.1 | NOK | http://autobuild.buildroot.net/results/d0f0f7e7462d68331d4a2f87b1df05cc9a6fecfd/
> powerpc | audit-2.4.1 | NOK | http://autobuild.buildroot.net/results/114de2422c56071141284fb2eb8044ffa48e77f4/
> powerpc | audit-2.4.1 | NOK | http://autobuild.buildroot.net/results/0862cf008e7e4b52c46c40257adeda954afee394/
This is an audit problem: it is building stuff for the host, but using
CFLAGS for the target. Clayton, can you have a look?
> arm | bcusdk-0.0.5 | NOK | http://autobuild.buildroot.net/results/d963117fd6b5c59935035166b7cc32d53c008c2b/
Probably needs to use argp-standalone with musl as well.
> sparc | boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/dd032aa7b387f3ba5b25bffcaf833ba0ea9ba199/
sparc-linux-g++: error: unrecognized argument in option '-mcpu=c3'
Gustavo, any idea?
> powerpc | boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/49f5c0521fc90fbd4673ad233ff679be007d2953/
> powerpc | boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/2ae4a83a22a1c172ec4778574b5c027d2c65540e/
Wchar missing. J?rg, since you fixed the last wchar issue with boost,
can you have a look?
> sparc | boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/1183ea468797b6b70a56b75066445b811704d211/
Same SPARC error as above.
> sparc | busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/16b2aaad834bc19b3e35604e9bbcab7b6c060307/
> sparc | busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/98bbb53c0fa8bedf52e8f4507e4b00e631470c25/
Atomic issue. Gustavo?
> arm | bwm-ng-0.6 | NOK | http://autobuild.buildroot.net/results/d8302a0e1f8a6cac9d91d7bff339cc901b31d46e/
> arm | bwm-ng-0.6 | NOK | http://autobuild.buildroot.net/results/3eb488068c167f3f1c009036c659b6ee6a9535ed/
> arm | bwm-ng-0.6 | NOK | http://autobuild.buildroot.net/results/e27ad662a2ca1f0482151d5136695105bd5b9e7d/
> arm | bwm-ng-0.6 | NOK | http://autobuild.buildroot.net/results/c78b6bc6c4a57046eeb87ab4d75ec7fb9c1a7f5e/
Smells like a gcc 5.1 issue.
> i686 | c-icap-modules-0.3.2 | NOK | http://autobuild.buildroot.net/results/2a07d48d638f20b9fb58923c37f7c44d4e4b72d5/
> powerpc | c-icap-modules-0.3.2 | NOK | http://autobuild.buildroot.net/results/f66f128a05e80c5f4d072d019569b849615d94e6/
> arm | c-icap-modules-0.3.2 | NOK | http://autobuild.buildroot.net/results/aa8988bb5f36491ce58681a52a11441353eb4dad/
ERROR: unsafe header/library path used in cross-compilation: '/usr/lib/'
Guillaume, since you are the original submitter or c-icap-modules, can
you have a look?
> arm | c-periphery-v1.0.3 | NOK | http://autobuild.buildroot.net/results/d659568db814cec9f21e591c49cfb64f73796748/
src/spi.c:100:24: error: '_IOC_SIZEBITS' undeclared (first use in this function)
musl issue
> arm | cc-tool-0.26 | NOK | http://autobuild.buildroot.net/results/51dfa189ed674418c44acc601a200558bb58926f/
> arc | cc-tool-0.26 | NOK | http://autobuild.buildroot.net/results/b00dfcbeab9cbf68bda5069a28d7ed000fbceebb/
checking for Boost's header version...
configure: error: invalid value: boost_major_version=
make: *** [/home/test/autobuild/instance-2/output/build/cc-tool-0.26/.stamp_configured] Error 1
checking for the Boost program_options library... no
configure: error: cannot find the flags to link with Boost program_options
make: *** [/home/test/autobuild/instance-0/output/build/cc-tool-0.26/.stamp_configured] Error 1
Marcin, you are the original submitter of the cc-tool package. Can you have a look?
> i686 | cdrkit-1.1.11 | NOK | http://autobuild.buildroot.net/results/182424bd2fea36af95eea31f7dd53f0399433616/
Static linking issue:
/ssd1/thomas/autobuild/instance-2/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/lib/libpthread.a(lowlevellock.os): In function `__lll_lock_wait_private':
(.text+0x0): multiple definition of `__lll_lock_wait_private'
Waldemar, I don't remember, has this issue been fixed already in
upstream uClibc-ng ?
> arm | cppcms-1.0.4 | NOK | http://autobuild.buildroot.net/results/58d3d2605337fe1ce49d333cb712941711276100/
Weird C++ problem:
error: 'template<class T, class A> std::size_t cppcms_boost::hash_value' conflicts with a previous declaration
Nicolas, you are the original submitter of cppcms, can you have a look?
> x86_64 | cramfs-1.1 | NOK | http://autobuild.buildroot.net/results/e89e2582a426e1838808e9469d043c969396dbf2/
mkcramfs.c: In function 'main':
mkcramfs.c:743:2: error: unknown type name 'loff_t'
loff_t fslen_ub = sizeof(struct cramfs_super);
^
Musl related issue.
> arm | empty-0.6.19b | NOK | http://autobuild.buildroot.net/results/4f543f140261d294fa641be0aa9174fd5334c17c/
> arm | empty-0.6.19b | NOK | http://autobuild.buildroot.net/results/25127b72321c3cdf778afda1f4e99fc622281705/
Should be fixed by http://patchwork.ozlabs.org/patch/493343/.
> arm | exfat-utils-1.1.1 | NOK | http://autobuild.buildroot.net/results/c60d0f9a93c90d41c3c86c78b0a07ddfed22c56d/
libexfat/platform.h:60:2: error: #error Unknown platform
#error Unknown platform
Don't know. It's a build with musl, maybe that's the problem?
> mips64el | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/69cb66c6c4ff832b66437ab80cd6de3f60485ea1/
> x86_64 | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/06321f6baddfa0461285fd22511b64c8503d2ed0/
> nios2 | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/b96d2aa7829acab2a186e4840d25b7e9e50769f5/
> arm | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/de29c661333c8c7a225b46aab999424beb59894a/
> xtensa | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/903704fa469dcea5f59a62bbf3c7f838dd2a749c/
> mips64el | expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/74f59a99a00fba119f31c1687a0e78f430767d2a/
SourceForge download problem, ignore.
> aarch64 | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/9ad5bbc1c5b1d172e531f05dade9cc56f59bb352/
> mips64el | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/dad954767a4baa358c01613616bc4f599c03dac3/
> sh4a | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/8539102de9c70cf685f85c3d073858c3115c7eab/
> arm | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/a79ccae103414336adff2f20a240e5e63d4e1cec/
> arm | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/422dbe84d1c7021e7c8b8e61592fe69329a2769e/
> arm | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/53719b9197532ceafba6da0502523895d687e993/
> xtensa | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/7f266945274b0fbc39c9a97c0de4cc1e5fd00e61/
> arm | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/10cefc8c3725350ea1ba0d40391488cfeb839e5d/
> aarch64 | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/3f983bb0eacc2453b123b06241ddfe2b8ab29f03/
> xtensa | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/428336d214fefb633ef187824181a5c7b0238971/
> powerpc | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/0e16204e8e91a7a0e3cfc55a1d7f7ab6e28efdb2/
> arm | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/bc99b0121562b2a5f4bcd9902820e6b976af54f1/
> mips64el | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/a96ca16911fc3f53fcfd9bfa1d90a5a3c45531c3/
> microblazeel | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/3289b1b460664af5f10ce1c2b5d398b4514fe6d7/
> xtensa | fan-ctrl-1.3 | NOK | http://autobuild.buildroot.net/results/ed7bdbf9b9eed593900df7b8fd0df66edcb08bdf/
SourceForge download problem, ignore.
> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/0de880719c243d49b05705aceae7ec0007d0193c/
> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/62811726f4a1a993c84ea6787a150f6a35ad305a/
> mipsel | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/525659097f8517e14ced5878c8820459bd25ccf7/
> mips | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/da03fb5741fb2235aadb021ab919f08abb118b17/
> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/09f669cb892d55256c38c6da5fd79dd8972e36dd/
> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/5903d6dbd0e0b64b5ef879445f552229f3c2d263/
> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/ba604b7543c654003dd04b40f0de768d2480c68f/
> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/6460a7c4a19f71684f50ad66d7cd57561fe963db/
> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/bdebcecc4de764afdb22f34f1a31490608a0492d/
> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/dae417dc1d585b1386effd87c9a71f460633177c/
> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/2e3594f6ce2ce722e7c4330656fddd8094d52a51/
> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/9e164507ffb4282b7b3e79a2bd8e8a1fa4350679/
> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/c7bc81ecd1fc125eb741b2e15c5a4db862c2a976/
> mipsel | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/bda2df7a0466ec2769e22d6913b9a4af51139088/
> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/b9107d34fd8d5d15018f5f7316737cc047f70bb4/
> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/da87b7fa8689a18798a229a988c4cd9268c7c54c/
> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/12286b94d9f90297da46e6f2a9744d4e7279e500/
> mips64el | ffmpeg-2.7.1 | NOK | http://autobuild.buildroot.net/results/7c80764d1e1004022bd02953a47cc1b391b35ffd/
Tries to use <msa.h> while the toolchain doesn't have it. Bernd, can
you have a look?
> arm | filemq-482797b8aa30fcc9ea13... | NOK | http://autobuild.buildroot.net/results/ba8e353e23c693eb7e2f7a2263e320d882840425/
checking for gawk... (cached) mawk
checking for zmq_init in -lzmq... no
configure: error: cannot link with -lzmq, install libzmq.
make: *** [/home/test/autobuild/instance-0/output/build/filemq-482797b8aa30fcc9ea1377aabdf2b0769f9f698e/.stamp_configured] Error 1
make: Leaving directory `/home/test/autobuild/instance-0/buildroot'
Static linking issue.
> x86_64 | grantlee-0.5.1 | NOK | http://autobuild.buildroot.net/results/4b1dac8443511a27678729e067c1dec3966820b6/
/home/peko/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-buildroot-linux-uclibc/4.9.3/../../../../x86_64-buildroot-linux-uclibc/bin/ld: /home/peko/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-buildroot-linux-uclibc/4.9.3/crtbeginT.o: relocation R_X86_64_32 against `__TMC_END__' can not be used when making a shared object; recompile with -fPIC
/home/peko/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-buildroot-linux-uclibc/4.9.3/crtbeginT.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Zoltan, you are the original submitter of this package, can you have a
look?
> arm | harfbuzz-0.9.41 | NOK | http://autobuild.buildroot.net/results/d81fe547227ffcbd270f2a00beb572755ab668f6/
Discussed in http://patchwork.ozlabs.org/patch/473622/.
> arm | host-erlang-rebar-2.5.1 | TIM | http://autobuild.buildroot.net/results/d475f6d7960d8eb774d35d238c46bf1a7128c791/
> arm | host-erlang-rebar-2.5.1 | TIM | http://autobuild.buildroot.net/results/d4ae8c5e824de02801337bd856fa62a308456ef3/
> powerpc | host-erlang-rebar-2.5.1 | TIM | http://autobuild.buildroot.net/results/8617c4791b4c8b29423dc2fe0067c4751069a748/
Johan, can you have a look at these issues? They are not spurious
timeouts: the build of host-erlang-rebar is really blocked. I already
analyzed this problem some time ago, and gave some details on the
mailing list.
> powerpc | host-heimdal-1.6rc2 | NOK | http://autobuild.buildroot.net/results/a07198b3f7f8029d80863a998814877ec9994c60/
> powerpc | host-heimdal-1.6rc2 | NOK | http://autobuild.buildroot.net/results/a6d22f80938fa19933940a19664c2354e01a871f/
> aarch64 | host-heimdal-1.6rc2 | NOK | http://autobuild.buildroot.net/results/cd15555cf90dddacdbf9599313e6e0a118049b38/
Parallel build problem. We'll make host-heimdal build with $(MAKE1) in
the mean time. Gustavo, can you submit a patch to this effect?
> x86_64 | host-nodejs-0.12.7 | NOK | http://autobuild.buildroot.net/results/2ee123ec8773bbcc6ef7ecd3f0b8050547a3340e/
Temporary download problem, ignore.
> powerpc | iproute2-4.1.1 | NOK | http://autobuild.buildroot.net/results/5c15e180973425a742629e9e8d0a56e1913d8c03/
Smell very much like a too old kernel headers problem. Gustavo?
> arm | kodi-14.2-Helix | NOK | http://autobuild.buildroot.net/results/1eefd8e23d8e1b4374c79201b4c631603372d431/
checking for main in -lEGL... no
configure: error: Could not find a required library. Please see the README for your platform.
Bernd?
> x86_64 | libedje-1.7.10 | NOK | http://autobuild.buildroot.net/results/6b1e2132a34e0c263bb0f2ea31caf4ce697e9c9c/
Another uClibc static linking problem. Waldemar?
> aarch64 | libepoxy-v1.2 | NOK | http://autobuild.buildroot.net/results/4b91baf853bd5d5aa416e9dc11fda2ce27723d12/
> mips64el | libepoxy-v1.2 | NOK | http://autobuild.buildroot.net/results/ef338817d476802b585d6272cf15c8a96d9614a6/
../include/epoxy/egl_generated.h:10:29: fatal error: EGL/eglplatform.h: No such file or directory
#include "EGL/eglplatform.h"
Bernd? Maybe this is fixed by
http://patchwork.ozlabs.org/patch/469121/, but my questions remained
unanswered.
> powerpc | libfreeimage-3.17.0 | NOK | http://autobuild.buildroot.net/results/4d8c76b1fcd9e4267d202a6c62358fc641761228/
Needs wchar support. R?mi, you are the original submitter for
libfreeimage, can you send a patch to add the wchar dependency?
> x86_64 | libftdi-0.20 | NOK | http://autobuild.buildroot.net/results/4d0009cf6f5b294d2246286e1383f663a4215648/
Build issue with musl. Anyone to look into this?
> sparc | libglib2-2.44.1 | NOK | http://autobuild.buildroot.net/results/530bd5b0c9a46c9d4aea249bb308b116806c43a4/
> sparc | libglib2-2.44.1 | NOK | http://autobuild.buildroot.net/results/20f10276ee40cac4dda38904f784e72f479a5264/
> sparc | libglib2-2.44.1 | NOK | http://autobuild.buildroot.net/results/908f7cd2434bc4235683c8cce079b839b783764a/
Atomic problem. Gustavo?
> arm | libiio-0.5 | NOK | http://autobuild.buildroot.net/results/5b0d02aa3bdb4cddb0d316c99fada2e7ba9f9c1d/
libiio build problem. Paul, can you have a look?
> arc | libselinux-2.1.13 | NOK | http://autobuild.buildroot.net/results/f08644d1ff3e769a86c4f8a3b60e40abb5f0a64e/
> arc | libselinux-2.1.13 | NOK | http://autobuild.buildroot.net/results/4848ead8ccf4fb7b0ff582c0fac94ce9b00fd341/
> arc | libselinux-2.1.13 | NOK | http://autobuild.buildroot.net/results/196b28f2ecf12a03390c806b5f4e9f34577998b7/
> arc | libselinux-2.1.13 | NOK | http://autobuild.buildroot.net/results/71ee8b5b2dce1d9f096c3667cd59eaf4a3b9af2b/
/tmp/ccY5Q1ef.s: Assembler messages:
/tmp/ccY5Q1ef.s:475: Error: internal error: fixup not contained within frag
Makefile:138: recipe for target 'setrans_client.lo' failed
Alexey ?
> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/f02e721e1812d03b5990884aa8f8ff09dd88272c/
> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/bf17b998dcdb81f37776765ca200e0e5c344bada/
> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/1b38f55602c7aff2afae6f2588e0a8f04b80b09d/
> powerpc | libsigrok-fe473123ba836445d... | NOK | http://autobuild.buildroot.net/results/b7d703cf97345463af373217fb90e076bb3dbeb6/
Compiler too old. Maybe exclude the toolchain for now?
> arm | libtirpc-0.3.1 | NOK | http://autobuild.buildroot.net/results/9bdd9a8514a297a07bfef341b4545080e7798201/
> arm | libtirpc-0.3.1 | NOK | http://autobuild.buildroot.net/results/55223f7c75e3ab21bb43af18594a5d28f02b7d30/
> x86_64 | libtirpc-0.3.1 | NOK | http://autobuild.buildroot.net/results/7420ea57d0659ec308c0f102d496f02ed0e4d640/
> arm | libtirpc-0.3.1 | NOK | http://autobuild.buildroot.net/results/aa6eecb7d86c63bf79c795a2d121f300ecb05baf/
musl build issue. Should be fixed by
http://patchwork.ozlabs.org/patch/497913/.
> arm | linux-pam-1.1.8 | NOK | http://autobuild.buildroot.net/results/848f6223e1634921f36056c1d468a1d5faf5777b/
Another musl related problem?
pam_lastlog.c:248:32: error: '_PATH_LASTLOG' undeclared (first use in this function)
"file %s is locked/read", _PATH_LASTLOG);
> arm | lirc-tools-0.9.2 | NOK | http://autobuild.buildroot.net/results/96ce76ea8952958ac233d904a33413dc3ddff156/
drv_admin.c:16:19: fatal error: dlfcn.h: No such file or directory
#include <dlfcn.h>
Seems like we need dynamic library support.
> arm | ltris-1.0.19 | NOK | http://autobuild.buildroot.net/results/4422287dfd556546eca59096391baf99084f98d4/
> arm | ltris-1.0.19 | NOK | http://autobuild.buildroot.net/results/2e6bfa64b356e4e9170398bc360d989f647b25e6/
GCC 5.x build issue.
> arm | minidlna-1.1.4 | NOK | http://autobuild.buildroot.net/results/25536df514477f3210caf4af27f2f107683f7fb2/
checking for avformat_open_input in -lavformat... no
configure: error: Could not find libavformat - part of ffmpeg
package/pkg-generic.mk:146: recipe for target '/home/buildroot/build/instance-0/output/build/minidlna-1.1.4/.stamp_configured' failed
make: *** [/home/buildroot/build/instance-0/output/build/minidlna-1.1.4/.stamp_configured] Error 1
Bernd, maybe?
> arm | mongrel2-v1.9.1 | NOK | http://autobuild.buildroot.net/results/29a3c06653c95cf238fe5abc051270a6b6c4bd5b/
Another zmq static linking problem, missing -lstdc++ somewhere.
> arm | mono-4.0.2.5 | NOK | http://autobuild.buildroot.net/results/5e11117048d965bc1fc44c738bb51f11164304af/
/home/peko/autobuild/instance-2/output/build/mono-4.0.2.5/eglib/src/.libs/libeglib.a(libeglib_la-gunicode.o): In function `monoeg_g_get_charset':
/home/peko/autobuild/instance-2/output/build/mono-4.0.2.5/eglib/src/gunicode.c:223: undefined reference to `locale_charset'
collect2: error: ld returned 1 exit status
Needs locale support?
Angelo, can you have a look?
> powerpc | mono-4.0.2.5 | NOK | http://autobuild.buildroot.net/results/aa008f6ea8efede4d760fe86b8b91a55471eaa37/
Same.
> arm | netperf-2.6.0 | NOK | http://autobuild.buildroot.net/results/077714a0ee67057abcff680b244228a409243bbf/
Smells like a GCC 5.x issue:
nettest_omni.o: In function `send_omni_inner':
nettest_omni.c:(.text+0x5688): undefined reference to `demo_interval_tick'
> sh4 | opencv-3.0.0 | NOK | http://autobuild.buildroot.net/results/f89a80c90b4e8bbd910aebc1a1495a9e55b243dc/
/tmp/cc880Ahp.s: Assembler messages:
/tmp/cc880Ahp.s:19803: Error: pcrel too far
make[3]: *** [modules/video/CMakeFiles/opencv_video.dir/src/ecc.cpp.o] Error 1
I'll re-exclude OpenCV with the SH4 toolchain.
> xtensa | opencv-3.0.0 | NOK | http://autobuild.buildroot.net/results/dd384fe0ef02a4205bea66a4a16ca2062afe53b4/
/tmp/ccHCSuXp.s: Assembler messages:
/tmp/ccHCSuXp.s:114393: Error: operand 2 of 'l32r' has out of range value '4294705124'
/tmp/ccHCSuXp.s:114397: Error: operand 2 of 'l32r' has out of range value '4294705068'
Max ?
> x86_64 | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/0a9e2c887c91197089d53754b3ca6726adebe68b/
> i686 | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/5b1f72208acf79dfe4164df25f039027e3556671/
> arm | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/ee4d7c54c4b1bd08d11b1c5eb10d5fa759e9c9c1/
> powerpc | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/4347eed5c460df0771b581d70f0067b72cb42fd3/
> i686 | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/6b6a7d8e45ee7f0ae4682567b3983590aea9ee10/
> arm | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/b2ec60e783345419c4cc688af1cdcc5270debc57/
> xtensa | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/aba106a1b74161c8e9c741180e79ecf437702371/
These should be fixed by http://patchwork.ozlabs.org/patch/498396/.
> i686 | openssh-6.9p1 | NOK | http://autobuild.buildroot.net/results/dce0202e039f4636d68532c4aab8738938b76650/
Weird build issues. Gustavo?
> xtensa | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/a15c8b5cf90935e42d4605f7f95ff1814c94254c/
> powerpc | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/f444ab04da5423db032bc12824da5f577156e957/
> bfin | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/bf6b9bcc0cead87c8fb12ec4c7f5ff73e6d61d3f/
> bfin | qpid-proton-0.9.1 | NOK | http://autobuild.buildroot.net/results/881f1e09ad3ba0c62f04349764446d4436a28781/
Some should be fixed by http://patchwork.ozlabs.org/patch/495849/, but
definitely not all of them. Samuel, since is package is CMake based,
can you have a look?
> mips64el | qt5base-5.4.1 | NOK | http://autobuild.buildroot.net/results/cddcc7413680a8e9ec5c1862eb0bbac431bc5961/
> mips64el | qt5base-5.4.1 | NOK | http://autobuild.buildroot.net/results/272b4acf7dea6de07d24dda4e23e41b412ffc8c6/
> mips64el | qt5base-5.4.1 | NOK | http://autobuild.buildroot.net/results/a605608b723993352016d2aa6ae0e1b4aa03c0dd/
Vicente, a MIPS problem for you :-)
> i686 | qt5webkit-5.4.1 | NOK | http://autobuild.buildroot.net/results/06ca186eb9be52b455806d9e965a95c1f6197790/
> i686 | qt5webkit-5.4.1 | NOK | http://autobuild.buildroot.net/results/87e378800a2045f2768a912db28e630088da6f56/
platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp:357:9: error: reference to 'GMutexLocker' is ambiguous
See https://codereview.qt-project.org/#/c/107411/. Hopefully fixed in
qt 5.5 which I committed yesterday;
> nios2 | setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/e67ef47ea9ff4cbb012d374b3b290fb7bddf7ef3/
/home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.8.3/../../../../nios2-linux-gnu/bin/ld: indexcon: No symbol version section for versioned symbol `qpol_policy_rebuild@@VERS_1.3'
/home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.8.3/../../../../nios2-linux-gnu/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
Makefile:599: recipe for target 'indexcon' failed
Probably some toolchain issue. Easiest solution is to exclude setools
from NIOS II. Clayton?
> bfin | setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/2ee84c0dc027912e059ca4ae518d6f11fd8317a7/
> bfin | setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/401e4c48f4d865b2722f284f1038e25c5d420f43/
Probably the infamous _ prefix used in Blackfin symbols. Maybe we can
also just exclude setools on Blackfin. Who would want SELinux on a
Blackfin DSP with noMMU anyway?
> arc | snmppp-3.3.5 | NOK | http://autobuild.buildroot.net/results/ff7cbcbb32dc46bfd008241da4113f79cf440e97/
.tbss issue. Alexey is already working on it.
> arm | socketcand-8339e62a6bf60be5... | NOK | http://autobuild.buildroot.net/results/8eac9832554dbd1f2e14cf54e5c99e6bf4dfc2cc/
GCC 5.x build issues. Yegor, can you have a look?
> arm | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/5c310f4d8ffebca048074660de6707a8fc598778/
Temporary download problem, ignore.
> bfin | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/7417400bf7ce37d2c37e36b5ed31b2dc3e6cf382/
> bfin | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/05c9e0504af6a6630890f0cff8fdb0033f8b41ff/
> bfin | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/1f1daec5e7547fd7a1739ce43269110ccf2a5224/
> bfin | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/3103c9028269a20aa6c53159a48f198e81c90303/
> arm | usb_modeswitch-2.2.5 | NOK | http://autobuild.buildroot.net/results/55beb7af1392cd2bedddee01edde83ce1bbcac6a/
Gustavo, you're regularly bumping usb_modeswitch. Can you have a look?
> arm | ustr-1.0.4 | NOK | http://autobuild.buildroot.net/results/0e114a9b6289cbced6be94a218383fb012284853/
ustr-cmp-code-so-dbg.o: In function `ustr_pool_make_subpool':
ustr-cmp-dbg-code.c:(.text+0x0): multiple definition of `ustr_pool_make_subpool'
ustr-b-code-so-dbg.o:ustr-b-dbg-code.c:(.text+0x0): first defined here
Smells like a GCC 5.x issue.
Clayton, this is for you :-)
> arm | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/c7fc621245351eb31afab1b96d3f1f2e6ad0bfad/
checking for GLES2/gl2.h... yes
checking whether to use OpenGL ES 2 support... configure: error: Cannot enable OpenGL ES 2 support without EGL
package/pkg-generic.mk:146: recipe for target '/home/buildroot/build/instance-0/output/build/webkit-1.11.5/.stamp_configured' failed
make: *** [/home/buildroot/build/instance-0/output/build/webkit-1.11.5/.stamp_configured] Error 1
make: Leaving directory '/home/buildroot/build/instance-0/buildroot'
Bernd, Gustavo?
> x86_64 | weston-1.8.0 | NOK | http://autobuild.buildroot.net/results/77501a806fb5f147912e70935b53c9c0a4cb1e74/
RDP compositor doesn't build:
CC shared/libshared_la-file-util.lo
src/compositor-rdp.c: In function 'rdp_peer_init':
src/compositor-rdp.c:1109:10: error: 'rdpSettings' has no member named 'SurfaceFrameMarkerEnabled'
settings->SurfaceFrameMarkerEnabled = TRUE;
^
Yann ?
> aarch64 | x264-c8a773ebfca148ef04f5a6... | NOK | http://autobuild.buildroot.net/results/474aabb69017c2283daf5cdd83cbd050c1b5023f/
Don't know what's going on. Bernd?
> arc | zeromq-4.0.5 | NOK | http://autobuild.buildroot.net/results/9ba4de85136e9ac4a68dcb7ee4285e03168d4a15/
Toolchain problem:
CXX libzmq_la-sub.lo
socket_base.cpp: In member function 'void zmq::socket_base_t::event_connected(std::string&, int)':
socket_base.cpp:1157:1: error: Internal consistency failure: cfi row mismatch [-Werror]
}
^
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-19 15:48 ` Thomas Petazzoni
@ 2015-05-25 11:08 ` Alexey Brodkin
0 siblings, 0 replies; 416+ messages in thread
From: Alexey Brodkin @ 2015-05-25 11:08 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Tue, 2015-05-19 at 17:48 +0200, Thomas Petazzoni wrote:
> Alexey,
>
> On Tue, 19 May 2015 13:49:46 +0000, Alexey Brodkin wrote:
>
> > > /tmp/ccQkdXjH.s: Assembler messages:
> > > /tmp/ccQkdXjH.s: Error: unaligned opcodes detected in executable segment
> > > make[2]: *** [.obj/release-shared-emb-generic/qxquerytokenizer.o] Error 1
> > >
> > > Alexey, can you have a look? Thanks!
> >
> > Well this is sort of expected failure. Even though I have never tried
> > building vanilla Qt for ARC, but as it turned out that doesn't work.
> >
> > But we've been sitting for a while on Qt4 patches that enable building
> > for and running on ARC. And now decision has been made to finally submit
> > those pretty simple patches upstream and in parallel (until patches are
> > accepted and the next minor release of Qt 4.x is cut.. if ever) add
> > patches in Buildroot so people may happily build and run Qt on ARC.
> >
> > I'll send patches shortly.
>
> Great, that would be nice.
Looks like I spoke too soon. The problem reported by autobuilder has
nothing to do with missing patches for ARC in Qt.
That's just a tools problem (I assume on compiler side) that happens on
compilation of the one particular file with following combination of
compiler options "-Os -g". This has been filed as internal bug report
and I expect we'll fix it before the upcoming release.
Still I posted my patches in Qt's Gerrit here:
[1] https://codereview.qt-project.org/#/c/112667/
[2] https://codereview.qt-project.org/#/c/112668/
But as correctly mentioned by Peter these days Qt4 could only be updated
with a back-port of Qt5 change (even though that "back-port" may have
nothing in common with change in Qt5 considering differences in
code-bases).
And so I have no other options other than creating patch for Qt5. And I
started to look into it but was a bit surprised that in Buildroot we
still don't have QtWebEngine (which is considered as a better
replacement of QtWebKit). I assume that's not because we don't want
QtWebEngine but just because nobody ever needed it, right?
If so then I'll try to fill this missing entry because I'll need to make
sure web-related apps could be built and run on ARC.
> Well, don't assume too much about my Qt5 knowledge. I've indeed done
> the initial packaging, so I have a limited knowledge of the Qt5 build
> system, but it doesn't go much beyond that. The rest of Qt5 remains
> largely a thing I've never looked at. But I will be happy to look at
> your patches. I think what we will be the most interested in is to make
> sure that the effort to push them upstream is being done, but I know
> you have a good track record of pushing ARC related fixes to the
> relevant upstream projects, so I'm really not worried at all about this.
From the first glance it looks like there's not much to do in Qt5
really. For example I was able to build and run "analogclock" app with
existing Buildroot with zero changes for ARC - which is really
promising. And if we put aside infrastructure things that were required
in Qt4 for Qt5 generic things work very well. The only other change that
was required for Qt4 - it was fix for unaligned access in WebKit's
JavaScript engine.
But now with switch from WebKit to Chromium looks like unaligned access
is no longer a problem (one of the reasons behind switch from WebKit to
Chromiom/Blink was significantly better support of multiple
architectures), i.e. there's no need in ARC-specific quirks.
So hopefully patches for Qt5 will be very short if at all.
-Alexey
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-21 13:28 ` Bartosz Golaszewski
@ 2015-05-21 13:33 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-21 13:33 UTC (permalink / raw)
To: buildroot
Dear Bartosz Golaszewski,
On Thu, 21 May 2015 15:28:24 +0200, Bartosz Golaszewski wrote:
> Sorry, I didn't see this message before. I can see Romain's patch in
> current git - has it fixed the issue?
Yes, I've committed Romain's patch. It does the job.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-19 8:12 ` Romain Naour
@ 2015-05-21 13:28 ` Bartosz Golaszewski
2015-05-21 13:33 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Bartosz Golaszewski @ 2015-05-21 13:28 UTC (permalink / raw)
To: buildroot
2015-05-19 10:12 GMT+02:00 Romain Naour <romain.naour@openwide.fr>:
>> Bartosz, since you are the author of the pulseview package, can you
>> have a look? Thanks!
>
> libsigrokcxx needs C++11
> see http://patchwork.ozlabs.org/patch/473213/
>
> Best regards,
> Romain
Hi Romain, Thomas,
Sorry, I didn't see this message before. I can see Romain's patch in
current git - has it fixed the issue?
Best regards,
Bartosz Golaszewski
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-19 8:00 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2015-05-19 8:12 ` Romain Naour
2015-05-19 13:49 ` Alexey Brodkin
@ 2015-05-20 17:49 ` Yann E. MORIN
2 siblings, 0 replies; 416+ messages in thread
From: Yann E. MORIN @ 2015-05-20 17:49 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2015-05-19 10:00 +0200, Thomas Petazzoni spake thusly:
> > powerpc | sqlite-3081000 | NOK | http://autobuild.buildroot.net/results/aed3690689b60844e3278626da3c3eb75f2a2586/
>
> Parallel build issue, Yann already reproduced the issue and was
> investigating it yesterday evening, but I'm not sure if he managed to
> find a solution.
Sorry, I haven't had time to commit to this task since monday evening.
I'll resume investigatign tonight.
However, it looks like sqlite does not build a lot of files (something
like 3 or four .o, a .so I think, and an executable) so it looks like a
quick workaround would be to disable parallel builds for sqlite, without
incurring too big a penalty on build time.
If I can't get aroudn a proper fix tonight, I'll submit that workaround.
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] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-19 13:49 ` Alexey Brodkin
2015-05-19 15:48 ` Thomas Petazzoni
@ 2015-05-19 17:59 ` Peter Korsgaard
1 sibling, 0 replies; 416+ messages in thread
From: Peter Korsgaard @ 2015-05-19 17:59 UTC (permalink / raw)
To: buildroot
>>>>> "Alexey" == Alexey Brodkin <Alexey.Brodkin@synopsys.com> writes:
Hi,
> Well this is sort of expected failure. Even though I have never tried
> building vanilla Qt for ARC, but as it turned out that doesn't work.
> But we've been sitting for a while on Qt4 patches that enable building
> for and running on ARC. And now decision has been made to finally submit
> those pretty simple patches upstream and in parallel (until patches are
> accepted and the next minor release of Qt 4.x is cut.. if ever) add
> patches in Buildroot so people may happily build and run Qt on ARC.
> I'll send patches shortly.
Qt4? Really? Is upstream really accepting feature patches for Qt4
nowadays?
> As for Qt5:
> [1] It requires tools with NPTL which (I really hope) will be available
> for ARC in few weeks, but until that time we may not worry about Qt5 for
> ARC - it won't be built.
> [2] Once ARC toolchain with NPTL is in Buildroot we'll need to cook
> something similar to what we've done for Qt4 and I hope it will really
> be that same simple. But probably for starters we'll disable Qt5 for
> ARC.
Ok, ARC support patches for Qt5 are probably more likely to get accepted
upstream than Qt4 ones.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-19 13:49 ` Alexey Brodkin
@ 2015-05-19 15:48 ` Thomas Petazzoni
2015-05-25 11:08 ` Alexey Brodkin
2015-05-19 17:59 ` Peter Korsgaard
1 sibling, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-19 15:48 UTC (permalink / raw)
To: buildroot
Alexey,
On Tue, 19 May 2015 13:49:46 +0000, Alexey Brodkin wrote:
> > /tmp/ccQkdXjH.s: Assembler messages:
> > /tmp/ccQkdXjH.s: Error: unaligned opcodes detected in executable segment
> > make[2]: *** [.obj/release-shared-emb-generic/qxquerytokenizer.o] Error 1
> >
> > Alexey, can you have a look? Thanks!
>
> Well this is sort of expected failure. Even though I have never tried
> building vanilla Qt for ARC, but as it turned out that doesn't work.
>
> But we've been sitting for a while on Qt4 patches that enable building
> for and running on ARC. And now decision has been made to finally submit
> those pretty simple patches upstream and in parallel (until patches are
> accepted and the next minor release of Qt 4.x is cut.. if ever) add
> patches in Buildroot so people may happily build and run Qt on ARC.
>
> I'll send patches shortly.
Great, that would be nice.
>
> As for Qt5:
> [1] It requires tools with NPTL which (I really hope) will be available
> for ARC in few weeks, but until that time we may not worry about Qt5 for
> ARC - it won't be built.
Yes, and since our Qt5 package depends on
BR2_TOOLCHAIN_HAS_THREADS_NPTL, Buildroot doesn't try to build it on
ARC, so we're fine.
> [2] Once ARC toolchain with NPTL is in Buildroot we'll need to cook
> something similar to what we've done for Qt4 and I hope it will really
> be that same simple. But probably for starters we'll disable Qt5 for
> ARC.
That's already the case, see above.
> BTW if I'm not mistaken (and "git log" is my witness) it was you who
> initially added Qt5 support in Buildroot, so I may assume you have some
> experience with that animal and if so I would really like to ask you to
> do my first external reviewer of Qt patch for ARC (for Qt4 now and Qt5
> later).
Well, don't assume too much about my Qt5 knowledge. I've indeed done
the initial packaging, so I have a limited knowledge of the Qt5 build
system, but it doesn't go much beyond that. The rest of Qt5 remains
largely a thing I've never looked at. But I will be happy to look at
your patches. I think what we will be the most interested in is to make
sure that the effort to push them upstream is being done, but I know
you have a good track record of pushing ARC related fixes to the
relevant upstream projects, so I'm really not worried at all about this.
Thanks a lot!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-19 8:00 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2015-05-19 8:12 ` Romain Naour
@ 2015-05-19 13:49 ` Alexey Brodkin
2015-05-19 15:48 ` Thomas Petazzoni
2015-05-19 17:59 ` Peter Korsgaard
2015-05-20 17:49 ` Yann E. MORIN
2 siblings, 2 replies; 416+ messages in thread
From: Alexey Brodkin @ 2015-05-19 13:49 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Tue, 2015-05-19 at 10:00 +0200, Thomas Petazzoni wrote:
> > arc | qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/e781d4ce27ce17067b2e5e298e1e8ba9add41371/
>
> Compiler problem:
>
> /tmp/ccQkdXjH.s: Assembler messages:
> /tmp/ccQkdXjH.s: Error: unaligned opcodes detected in executable segment
> make[2]: *** [.obj/release-shared-emb-generic/qxquerytokenizer.o] Error 1
>
> Alexey, can you have a look? Thanks!
Well this is sort of expected failure. Even though I have never tried
building vanilla Qt for ARC, but as it turned out that doesn't work.
But we've been sitting for a while on Qt4 patches that enable building
for and running on ARC. And now decision has been made to finally submit
those pretty simple patches upstream and in parallel (until patches are
accepted and the next minor release of Qt 4.x is cut.. if ever) add
patches in Buildroot so people may happily build and run Qt on ARC.
I'll send patches shortly.
As for Qt5:
[1] It requires tools with NPTL which (I really hope) will be available
for ARC in few weeks, but until that time we may not worry about Qt5 for
ARC - it won't be built.
[2] Once ARC toolchain with NPTL is in Buildroot we'll need to cook
something similar to what we've done for Qt4 and I hope it will really
be that same simple. But probably for starters we'll disable Qt5 for
ARC.
BTW if I'm not mistaken (and "git log" is my witness) it was you who
initially added Qt5 support in Buildroot, so I may assume you have some
experience with that animal and if so I would really like to ask you to
do my first external reviewer of Qt patch for ARC (for Qt4 now and Qt5
later).
Regards,
Alexey
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-19 8:00 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2015-05-19 8:12 ` Romain Naour
2015-05-21 13:28 ` Bartosz Golaszewski
2015-05-19 13:49 ` Alexey Brodkin
2015-05-20 17:49 ` Yann E. MORIN
2 siblings, 1 reply; 416+ messages in thread
From: Romain Naour @ 2015-05-19 8:12 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Le 19/05/2015 10:00, Thomas Petazzoni a ?crit :
> Hello all,
>
> This is *really* looking better and better. There are still around 10
> days left before the final release, I'm sure we can reach even lower
> build failure numbers.
>
> Let's have a look at the build issues from yesterday. Yann, Alexey,
> Bartosz, there are some questions/things for you, see below.
>
[snip]
>
>> powerpc | pulseview-198f9bc74d6c955a7... | NOK | http://autobuild.buildroot.net/results/90d8a0cad1ec56f251970b591e9cdf35e57b35ef/
>
> -- checking for module 'libsigrokcxx>=0.3.0'
> -- package 'libsigrokcxx>=0.3.0' not found
> CMake Error at /ssd1/thomas/autobuild/instance-0/output/host/usr/share/cmake-3.1/Modules/FindPkgConfig.cmake:340 (message):
>
> Bartosz, since you are the author of the pulseview package, can you
> have a look? Thanks!
libsigrokcxx needs C++11
see http://patchwork.ozlabs.org/patch/473213/
Best regards,
Romain
[snip]
>
> So let's do the overall math, on 11 build failures, we have:
>
> * 2 build failures already handled by a new exception in the
> autobuilder script.
>
> * 2 build failures already fixed by committed patches
>
> * 1 build failure fixed by a proposed patch
>
> * 2 build failures that look quite easy to solve (conntrack-tools,
> sysstat)
>
> * 4 that look a bit more complicated (qt, sqlite, pulseview)
>
> Best regards,
>
> Thomas
>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-19 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2015-05-18 Thomas Petazzoni
@ 2015-05-19 8:00 ` Thomas Petazzoni
2015-05-19 8:12 ` Romain Naour
` (2 more replies)
0 siblings, 3 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-19 8:00 UTC (permalink / raw)
To: buildroot
Hello all,
This is *really* looking better and better. There are still around 10
days left before the final release, I'm sure we can reach even lower
build failure numbers.
Let's have a look at the build issues from yesterday. Yann, Alexey,
Bartosz, there are some questions/things for you, see below.
On Tue, 19 May 2015 08:30:12 +0200 (CEST), Thomas Petazzoni wrote:
> xtensa | conntrack-tools-1.4.2 | NOK | http://autobuild.buildroot.net/results/ab1ae40f1862300cd7667b7bd03cc59d7455a769/
Tries to include <dlfcn.h> in a static linking configuration, and
conntrack-tools is using dlopen(), so we should mark this package as
not available for static builds.
> arm | gpsd-3.11 | NOK | http://autobuild.buildroot.net/results/f5261a0933f9b5449d1f4e5cab1bb02e7154e683/
Does not build in static linking configs, fixed by
http://git.buildroot.net/buildroot/commit/?id=db989f89c9fb1ebc3997d8a3c517948392611d77.
> arm | harfbuzz-0.9.40 | NOK | http://autobuild.buildroot.net/results/057499012d6443a736f384fd1d7e283396ab1c2e/
Would be fixed by http://patchwork.ozlabs.org/patch/473622/.
> xtensa | kmod-20 | NOK | http://autobuild.buildroot.net/results/a12744849118fd49b9c811f31919ddb12c1eff29/
> xtensa | kmod-20 | NOK | http://autobuild.buildroot.net/results/5af2245025568af230d682863307236700d0d206/
Those are regressions caused by the revert of the kmod Xtensa
workaround, and the fact that the external toolchain has not been
rebuilt with the latest Xtensa binutils fixes. For now, I've added an
exception in the autobuilder script, I'll rebuild the toolchain later.
> powerpc | pulseview-198f9bc74d6c955a7... | NOK | http://autobuild.buildroot.net/results/90d8a0cad1ec56f251970b591e9cdf35e57b35ef/
-- checking for module 'libsigrokcxx>=0.3.0'
-- package 'libsigrokcxx>=0.3.0' not found
CMake Error at /ssd1/thomas/autobuild/instance-0/output/host/usr/share/cmake-3.1/Modules/FindPkgConfig.cmake:340 (message):
Bartosz, since you are the author of the pulseview package, can you
have a look? Thanks!
> arc | qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/e781d4ce27ce17067b2e5e298e1e8ba9add41371/
Compiler problem:
/tmp/ccQkdXjH.s: Assembler messages:
/tmp/ccQkdXjH.s: Error: unaligned opcodes detected in executable segment
make[2]: *** [.obj/release-shared-emb-generic/qxquerytokenizer.o] Error 1
Alexey, can you have a look? Thanks!
> nios2 | qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/7a478f03e0b38ffdcffa4153c17eef9cc4457b8c/
Compiler error when linking QtGui. I already disabled QtWebkit for this
toolchain recently. Maybe we should simply disable Qt completely with
this toolchain, which seems quite broken. And Qt is quite unlikely to
be used on NIOS II systems. Thoughts?
> powerpc | sqlite-3081000 | NOK | http://autobuild.buildroot.net/results/aed3690689b60844e3278626da3c3eb75f2a2586/
Parallel build issue, Yann already reproduced the issue and was
investigating it yesterday evening, but I'm not sure if he managed to
find a solution.
> arm | sysstat-11.0.4 | NOK | http://autobuild.buildroot.net/results/bea726de24801385f335e02271671e030f857e3e/
Forgets to link against libintl when static linking. Can someone have a
look at this one?
> arc | wvstreams-4.6.1 | NOK | http://autobuild.buildroot.net/results/0cd5e0263b42e6845504d97688632e16206bd000/
Already fixed by
http://git.buildroot.net/buildroot/commit/?id=be1287e7e5ca2a11cd6dea84ac481d10eaa48edb.
So let's do the overall math, on 11 build failures, we have:
* 2 build failures already handled by a new exception in the
autobuilder script.
* 2 build failures already fixed by committed patches
* 1 build failure fixed by a proposed patch
* 2 build failures that look quite easy to solve (conntrack-tools,
sysstat)
* 4 that look a bit more complicated (qt, sqlite, pulseview)
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-17 13:52 ` Thomas Petazzoni
@ 2015-05-17 14:19 ` Romain Naour
0 siblings, 0 replies; 416+ messages in thread
From: Romain Naour @ 2015-05-17 14:19 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Le 17/05/2015 15:52, Thomas Petazzoni a ?crit :
> Dear Romain Naour,
>
> On Sun, 17 May 2015 14:08:23 +0200, Romain Naour wrote:
>
>>>> xtensa | enlightenment-0.17.6 | NOK | http://autobuild.buildroot.net/results/c1ef3b4fae3ddf3206ee79141dc36bef50085b6a/
>>>
>>> Max, can you have a look at this one?
>>
>> There is a patch for this one but with some comment on it:
>> http://patchwork.ozlabs.org/patch/470073/
>>
>> The proposal was to disable ptrace for xtensa with uClibc/uClibc-ng toolchains,
Ok I should have said uClibc-xtensa/uClibc-ng...
>> but those toolchain can also be fixed by a patch like this one for PowerPC:
>> http://git.buildroot.net/buildroot/commit/?id=e0a4d9fa6fa68b95181fbaf1babcbb3cf2c9c63b
>>
>> Or better yet, use the upstream commit made by Baruch Siach:
>> http://git.uclibc.org/uClibc/commit/?id=de6561f6669308e5d2297589b39a217d4c14df1c
>>
>> Waldemar, can you have a look for uClibc-ng ?
>
> Hum, Xtensa is using uClibc master, not uClibc-ng. And Xtensa uses the
> uClibc commit 7bf35c8b7d4a1f97174eb49f47f33946b282114c, whic includes
> commit de6561f6669308e5d2297589b39a217d4c14df1c.
... but indeed uClibc-xtensa is already fixed.
>
> So why are we seeing the issue?
If you look at the config file from [1] and [2], uClibc-ng is used.
BR2_UCLIBC_VERSION_STRING="1.0.2"
BR2_UCLIBC_CONFIG="package/uclibc/uClibc-ng.config"
The commit de6561f6669308e5d2297589b39a217d4c14df1c from uClibc is not
backported yet in uClibc-ng 1.0.2.
We should instead disable pthread on xtensa only with uClibc-ng.
[1] http://autobuild.buildroot.net/results/c1ef3b4fae3ddf3206ee79141dc36bef50085b6a/
[2]
http://autobuild.buildroot.org/results/d03/d035e3735e414acb26ae79a8cf55a562c89d01e8/
Best regards,
Romain
>
> Thanks,
>
> Thomas
>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-17 12:08 ` Romain Naour
@ 2015-05-17 13:52 ` Thomas Petazzoni
2015-05-17 14:19 ` Romain Naour
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-17 13:52 UTC (permalink / raw)
To: buildroot
Dear Romain Naour,
On Sun, 17 May 2015 14:08:23 +0200, Romain Naour wrote:
> >> xtensa | enlightenment-0.17.6 | NOK | http://autobuild.buildroot.net/results/c1ef3b4fae3ddf3206ee79141dc36bef50085b6a/
> >
> > Max, can you have a look at this one?
>
> There is a patch for this one but with some comment on it:
> http://patchwork.ozlabs.org/patch/470073/
>
> The proposal was to disable ptrace for xtensa with uClibc/uClibc-ng toolchains,
> but those toolchain can also be fixed by a patch like this one for PowerPC:
> http://git.buildroot.net/buildroot/commit/?id=e0a4d9fa6fa68b95181fbaf1babcbb3cf2c9c63b
>
> Or better yet, use the upstream commit made by Baruch Siach:
> http://git.uclibc.org/uClibc/commit/?id=de6561f6669308e5d2297589b39a217d4c14df1c
>
> Waldemar, can you have a look for uClibc-ng ?
Hum, Xtensa is using uClibc master, not uClibc-ng. And Xtensa uses the
uClibc commit 7bf35c8b7d4a1f97174eb49f47f33946b282114c, whic includes
commit de6561f6669308e5d2297589b39a217d4c14df1c.
So why are we seeing the issue?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-17 10:49 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2015-05-17 11:37 ` Yann E. MORIN
@ 2015-05-17 12:08 ` Romain Naour
2015-05-17 13:52 ` Thomas Petazzoni
1 sibling, 1 reply; 416+ messages in thread
From: Romain Naour @ 2015-05-17 12:08 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Le 17/05/2015 12:49, Thomas Petazzoni a ?crit :
> Hello all,
>
> On Sun, 17 May 2015 08:30:17 +0200 (CEST), Thomas Petazzoni wrote:
>
[snip]
>
>> xtensa | enlightenment-0.17.6 | NOK | http://autobuild.buildroot.net/results/c1ef3b4fae3ddf3206ee79141dc36bef50085b6a/
>
> Max, can you have a look at this one?
>
There is a patch for this one but with some comment on it:
http://patchwork.ozlabs.org/patch/470073/
The proposal was to disable ptrace for xtensa with uClibc/uClibc-ng toolchains,
but those toolchain can also be fixed by a patch like this one for PowerPC:
http://git.buildroot.net/buildroot/commit/?id=e0a4d9fa6fa68b95181fbaf1babcbb3cf2c9c63b
Or better yet, use the upstream commit made by Baruch Siach:
http://git.uclibc.org/uClibc/commit/?id=de6561f6669308e5d2297589b39a217d4c14df1c
Waldemar, can you have a look for uClibc-ng ?
Best regards,
Romain
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-17 10:49 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2015-05-17 11:37 ` Yann E. MORIN
2015-05-17 12:08 ` Romain Naour
1 sibling, 0 replies; 416+ messages in thread
From: Yann E. MORIN @ 2015-05-17 11:37 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2015-05-17 12:49 +0200, Thomas Petazzoni spake thusly:
> > arm | gst1-plugins-bad-1.4.5 | NOK | http://autobuild.buildroot.net/results/e0392859a1943d1db2a5ee2f7fdf93764369d979/
>
> This is an OpenCV issue. Samuel, can you have a look?
>
> *** Warning: Linking the shared library libgstopencv.la against the
> *** static library /usr/lib/libopencv_ts.a is not portable!
> arm-linux-gnueabihf-g++: error: /usr/lib/libopencv_ts.a: No such file
> or directory
Samuel is already working on it, and I have also had a look.
The reason is known, and will be (hopefully!) fixed when Samuel has
finished his bump of opencv. See:
http://lists.busybox.net/pipermail/buildroot/2015-May/128402.html
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] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-17 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2015-05-16 Thomas Petazzoni
@ 2015-05-17 10:49 ` Thomas Petazzoni
2015-05-17 11:37 ` Yann E. MORIN
2015-05-17 12:08 ` Romain Naour
0 siblings, 2 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-17 10:49 UTC (permalink / raw)
To: buildroot
Hello all,
On Sun, 17 May 2015 08:30:17 +0200 (CEST), Thomas Petazzoni wrote:
> mipsel | cdrkit-1.1.11 | NOK | http://autobuild.buildroot.net/results/22cdb25b20dd41075a6096b38f6ef76f781763b1/
> i686 | cdrkit-1.1.11 | NOK | http://autobuild.buildroot.net/results/9455dd040520ac06249314295714e0765e8485c9/
uClibc static linking issues, exceptions added in autobuilder script.
> xtensa | duma-2.5.15 | NOK | http://autobuild.buildroot.net/results/ccfc79586516a6ebb05badfad258aad0b6b9d2a2/
duma is trying to build a shared library in a static environment. Since
duma relies on LD_PRELOAD I believe, there's no point in building numa
in a static only environment. I'll send a patch to address that.
> xtensa | enlightenment-0.17.6 | NOK | http://autobuild.buildroot.net/results/c1ef3b4fae3ddf3206ee79141dc36bef50085b6a/
Max, can you have a look at this one?
> arm | gst1-plugins-bad-1.4.5 | NOK | http://autobuild.buildroot.net/results/e0392859a1943d1db2a5ee2f7fdf93764369d979/
This is an OpenCV issue. Samuel, can you have a look?
*** Warning: Linking the shared library libgstopencv.la against the
*** static library /usr/lib/libopencv_ts.a is not portable!
arm-linux-gnueabihf-g++: error: /usr/lib/libopencv_ts.a: No such file
or directory
> nios2 | heirloom-mailx-12.5 | NOK | http://autobuild.buildroot.net/results/33346f4555ed403bab7b739dd5d47814efa8eb4c/
> nios2 | heirloom-mailx-12.5 | NOK | http://autobuild.buildroot.net/results/d4683dd0913340c0aec143adde141658ef36cfc0/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=d4171c5192e44f2733ccd217222680e597e6397d.
> powerpc | host-mono-4.0.0 | NOK | http://autobuild.buildroot.net/results/c3288c5d1fb94474f14a4a889e76135878d403bc/
> powerpc | host-mono-4.0.0 | NOK | http://autobuild.buildroot.net/results/f708e89f613ec0b42cdf49ccbef39b02f4a271fb/
> arm | host-mono-4.0.0 | NOK | http://autobuild.buildroot.net/results/3cb99e5c5672cbaa2a86020129a05dfde47cdb8f/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=f28af782655c8c4ccc2d9180d6c9f3ac36d71d00.
> i686 | ipmiutil-2.9.5 | NOK | http://autobuild.buildroot.net/results/b42e16c664c70ccb430f848060e7fe26a3c9bd09/
obj/ipmilan.o: file not recognized: File truncated
> i686 | ipmiutil-2.9.5 | NOK | http://autobuild.buildroot.net/results/100098242091ca5844177e6ed1d3cecb77072f3a/
ipmilan.c:843: undefined reference to `md2_sum'
This has been fixed by
http://git.buildroot.net/buildroot/commit/?id=25e15fd17fa51a79b40159629dea1eea7b5f8d96.
> bfin | libmatroska-1.4.2 | NOK | http://autobuild.buildroot.net/results/80a9f0f5594ab833600ea8514dc184e50d2bf08c/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=c69bafe0aef71b9846866270da9462c3492d9508.
> mips | lua-periphery-1.0.4-1 | NOK | http://autobuild.buildroot.net/results/0ad656970b3cbc84b5531b28155ba2f747715fe3/
> mips64el | lua-periphery-1.0.4-1 | NOK | http://autobuild.buildroot.net/results/65bc6e4f6e0c6d2110a5de67b04f2f746a510a1b/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=01dfbb48c5c0725a4656518864af792c0f532e99.
> powerpc | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/7af8b620028ead3731c170b9cd16382701860267/
> arm | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/f05f5c6de0f5b0c1389cd916baaf29151f91c753/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=5d496bdddb44c6f8f97d0f573a7220ebf0ec41eb.
> sh4a | qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/508cdeb67f272b61209f331ab7b990cb56f30817/
Binutils assertion failure while building webkit, I'll send a patch to
disable this toolchain.
> sh4 | qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/b28993215e09840cfa4d2c0c0d50466b1b6f94b3/
Project ERROR: Package gstreamer-app-0.10 not found
> bfin | tinyxml2-2.2.0 | NOK | http://autobuild.buildroot.net/results/b749e7af2ab3e118ec1e0cfaa037e6c030a191cf/
> powerpc | tinyxml2-2.2.0 | NOK | http://autobuild.buildroot.net/results/3a5a9c5df751f730e59e94b4c886373da3a005be/
> xtensa | tinyxml2-2.2.0 | NOK | http://autobuild.buildroot.net/results/9a0dd91cd52faebb2b76874d3909fa7993318c25/
> mips64el | tinyxml2-2.2.0 | NOK | http://autobuild.buildroot.net/results/06c6c0407d6ad9e63b14e651fa8ba08190dbd466/
> powerpc | tinyxml2-2.2.0 | NOK | http://autobuild.buildroot.net/results/4210adfcb9006e77742849e2c632729e2c124c5d/
> arm | tinyxml2-2.2.0 | NOK | http://autobuild.buildroot.net/results/4b469274cf1a29e84143795b47c533d56dc233ee/
> arm | tinyxml2-2.2.0 | NOK | http://autobuild.buildroot.net/results/469de84e49b9a8237f972f433a447e760106e7ef/
> bfin | tinyxml2-2.2.0 | NOK | http://autobuild.buildroot.net/results/c84589011b9ad9ab7e5d5ab7b40ba5a3b2d8fff8/
> mips64el | tinyxml2-2.2.0 | NOK | http://autobuild.buildroot.net/results/408825465ea861721be91459d39f5fa9a039bf6b/
All fixed by
http://git.buildroot.net/buildroot/commit/?id=ecea41003003bed3f3ecf6fd991077b225f625f5.
> mips | uboot-tools-2015.04 | NOK | http://autobuild.buildroot.net/results/48345d936c7972dc27ea12bdccfe0d02bbc4112b/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=66a3f7a240d8804306c1eafa354c2de319097b36.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-14 22:58 ` Peter Korsgaard
@ 2015-05-15 16:02 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-15 16:02 UTC (permalink / raw)
To: buildroot
Peter,
On Fri, 15 May 2015 00:58:15 +0200, Peter Korsgaard wrote:
> > The nios2 problems are due to a toolchain issue. We should simply
> > disable boost with this toolchain.
>
> Yes, will you send a patch?
Yes, patch ready, will be part of my next batch of autobuilder fixes.
> > The PowerPC problems are due to a uClibc bug. I've done some tests, and
> > boost-1.57.0 builds fine on PowerPC/glibc, ARM/uClibc, but fails on
> > PowerPC/uClibc. It's the boost-log module that causes the problem.
>
> So what then, make the boost-log option depend on
> !(BR2_powerpc && BR2_TOOLCHAIN_USES_UCLIBC)?
Done, part of my next batch.
> >> bfin | libarchive-3.1.2 | NOK |
> >> http://autobuild.buildroot.net/results/5f7b69a324b72dfb522a9299804c113414db348c/
>
> > libacl.a: No such file or directory
>
> > I don't know.
>
> The .libs/libacl.a sounds like libtool getting confused. Other than that
> I also don't know.
Currently working on it, though I think I already spent some time on it
a while ago, and could never reach a conclusion.
> >> nios2 | mosquitto-1.4.1 | NOK |
> >> http://autobuild.buildroot.net/results/b853369452115b0c6f32c6c960af2dbdf71a74af/
>
> > Infamous "undefined reference to symbol '_gp'" issue.
>
> :/ Should we depend on !BR2_nios2?
Yes, added to my next batch of autobuilder fixes.
> >> mipsel | postgresql-9.4.1 | NOK |
> >> http://autobuild.buildroot.net/results/f9ed96d22e91cdba9ad92c4d4ea52e422bf1f1c9/
>
> > /home/buildroot/build/instance-0/output/host/usr/mipsel-buildroot-linux-uclibc/sysroot/usr/lib/libcrypto.a(c_zlib.o):
> > In function `zlib_stateful_expand_block':
> > c_zlib.c:(.text+0x78): undefined reference to `inflate'
>
> > Static linking issue. Do we really want to support static linking of
> > postgresql?
>
> I don't think so, lets just mark it as !BR2_STATIC_LIBS.
Done, will also be part of my next batch.
> >> powerpc | python-pyqt-4.11.3 | NOK |
> >> http://autobuild.buildroot.net/results/d2bf71cdd0fe9b0049ba2889de89ccc36cfdc58a/
>
> > We need to apply http://patchwork.ozlabs.org/patch/468134/.
>
> Is that an ack? If so, please reply to the patch with it.
I'm honestly too lazy to do the full build of this stuff to verify, but
I think the patch is OK.
> >> arm | qt5base-5.4.1 | NOK |
> >> http://autobuild.buildroot.net/results/f403a76ac0abbf8488373c0dffb4487f5d98c55d/
>
> > g++: error: unrecognized command line option '-fuse-ld=gold'
>
> The problem is that qt5base doesn't understand cross compilation. It
> correctly checks if the target compiler supports the gold linker and
> then ends up using -fuse-ld=gold with both the host and target
> compilers, so it breaks on old hosts.
>
> I'm not sure how we should fix that. Any ideas?
I've added a fix for that one as well, which makes sure -fuse-ld=gold
is not use for host builds, but only for target builds.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-15 14:06 ` Waldemar Brodkorb
@ 2015-05-15 15:17 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-15 15:17 UTC (permalink / raw)
To: buildroot
Dear Waldemar Brodkorb,
On Fri, 15 May 2015 16:06:33 +0200, Waldemar Brodkorb wrote:
> Hi,
> Thomas Petazzoni wrote,
>
> > > powerpc | boost-1.57.0 | NOK | http://autobuild.buildroot.net/results/9faeba9f811bb3507861003d78eec245f8a93db9/
> > > nios2 | boost-1.57.0 | NOK | http://autobuild.buildroot.net/results/46f9d84e6db10ce7cbe48653f6da4450aceceb4c/
> > > powerpc | boost-1.57.0 | NOK | http://autobuild.buildroot.net/results/7852f40e6bae93f953a588bbd6902c2b1cee8a42/
> > > powerpc | boost-1.57.0 | NOK | http://autobuild.buildroot.net/results/13b43105caf4d3952de70030b51f8d96cf6604ee/
> > > nios2 | boost-1.57.0 | NOK | http://autobuild.buildroot.net/results/e119b1ef55c546e0d0598b85c46ceefa5c43d5a6/
> >
> > The nios2 problems are due to a toolchain issue. We should simply
> > disable boost with this toolchain.
> >
> > The PowerPC problems are due to a uClibc bug. I've done some tests, and
> > boost-1.57.0 builds fine on PowerPC/glibc, ARM/uClibc, but fails on
> > PowerPC/uClibc. It's the boost-log module that causes the problem.
>
> Where do you see a uClibc problem?
Well, it simply works fine with PowerPC/glibc, and ARM/uClibc, but not
PowerPC/uClibc.
> Any short error message?
See the powerpc failures above, and search for 'error:'. The errors are:
./boost/spirit/home/support/detail/sign.hpp:60:36: error: no type named 'bits' in 'traits_type {aka struct boost::math::detail::fp_traits_non_native<long double, boost::math::detail::extended_double_precision>}'
typename traits_type::bits a;
^
./boost/spirit/home/support/detail/sign.hpp:61:35: error: 'get_bits' is not a member of 'traits_type {aka boost::math::detail::fp_traits_non_native<long double, boost::math::detail::extended_double_precision>}'
traits_type::get_bits(x, a);
^
./boost/spirit/home/support/detail/sign.hpp:60:36: error: no type named 'bits' in 'traits_type {aka struct boost::math::detail::fp_traits_non_native<long double, boost::math::detail::extended_double_precision>}'
typename traits_type::bits a;
^
./boost/spirit/home/support/detail/sign.hpp:62:11: error: 'sign' is not a member of 'traits_type {aka boost::math::detail::fp_traits_non_native<long double, boost::math::detail::extended_double_precision>}'
a ^= traits_type::sign;
^
./boost/spirit/home/support/detail/sign.hpp:60:36: error: no type named 'bits' in 'traits_type {aka struct boost::math::detail::fp_traits_non_native<long double, boost::math::detail::extended_double_precision>}'
typename traits_type::bits a;
^
./boost/spirit/home/support/detail/sign.hpp:63:35: error: 'set_bits' is not a member of 'traits_type {aka boost::math::detail::fp_traits_non_native<long double, boost::math::detail::extended_double_precision>}'
traits_type::set_bits(x, a);
^
./boost/spirit/home/support/detail/sign.hpp:60:36: error: no type named 'bits' in 'traits_type {aka struct boost::math::detail::fp_traits_non_native<long double, boost::math::detail::extended_double_precision>}'
typename traits_type::bits a;
^
> I tried boost 1.57 with PPC and getting GCC ICE when using 4.9.2
> while compiling test.
Weird, it builds just fine here, as long as you disable the boost-log
component, which is the one causing the build error above.
> With GCC 5.1 the compile works fine.
> Both tested with uClibc-ng (ppc soft-float target)
Note that I don't think I have tested with uClibc-ng.
Here is a defconfig that fails:
BR2_powerpc=y
BR2_COMPILER_PARANOID_UNSAFE_PATH=y
BR2_TOOLCHAIN_BUILDROOT_INET_RPC=y
BR2_TOOLCHAIN_BUILDROOT_LOCALE=y
BR2_GCC_VERSION_4_9_X=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PACKAGE_BOOST=y
BR2_PACKAGE_BOOST_CONTEXT=y
BR2_PACKAGE_BOOST_EXCEPTION=y
BR2_PACKAGE_BOOST_LOCALE=y
BR2_PACKAGE_BOOST_LOG=y
BR2_PACKAGE_BOOST_SYSTEM=y
BR2_PACKAGE_BOOST_WAVE=y
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-14 21:13 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2015-05-14 22:58 ` Peter Korsgaard
@ 2015-05-15 14:06 ` Waldemar Brodkorb
2015-05-15 15:17 ` Thomas Petazzoni
1 sibling, 1 reply; 416+ messages in thread
From: Waldemar Brodkorb @ 2015-05-15 14:06 UTC (permalink / raw)
To: buildroot
Hi,
Thomas Petazzoni wrote,
> > powerpc | boost-1.57.0 | NOK | http://autobuild.buildroot.net/results/9faeba9f811bb3507861003d78eec245f8a93db9/
> > nios2 | boost-1.57.0 | NOK | http://autobuild.buildroot.net/results/46f9d84e6db10ce7cbe48653f6da4450aceceb4c/
> > powerpc | boost-1.57.0 | NOK | http://autobuild.buildroot.net/results/7852f40e6bae93f953a588bbd6902c2b1cee8a42/
> > powerpc | boost-1.57.0 | NOK | http://autobuild.buildroot.net/results/13b43105caf4d3952de70030b51f8d96cf6604ee/
> > nios2 | boost-1.57.0 | NOK | http://autobuild.buildroot.net/results/e119b1ef55c546e0d0598b85c46ceefa5c43d5a6/
>
> The nios2 problems are due to a toolchain issue. We should simply
> disable boost with this toolchain.
>
> The PowerPC problems are due to a uClibc bug. I've done some tests, and
> boost-1.57.0 builds fine on PowerPC/glibc, ARM/uClibc, but fails on
> PowerPC/uClibc. It's the boost-log module that causes the problem.
Where do you see a uClibc problem?
Any short error message?
I tried boost 1.57 with PPC and getting GCC ICE when using 4.9.2
while compiling test. With GCC 5.1 the compile works fine.
Both tested with uClibc-ng (ppc soft-float target)
best regards
Waldemar
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-14 21:13 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2015-05-14 22:58 ` Peter Korsgaard
2015-05-15 16:02 ` Thomas Petazzoni
2015-05-15 14:06 ` Waldemar Brodkorb
1 sibling, 1 reply; 416+ messages in thread
From: Peter Korsgaard @ 2015-05-14 22:58 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> Hello,
> On Thu, 14 May 2015 08:30:16 +0200 (CEST), Thomas Petazzoni wrote:
>> xtensa | alsa-utils-1.0.29 | NOK |
>> http://autobuild.buildroot.net/results/5347b57d23b44e1b011a499875ce638ed654418a/
> Static linking issue:
> undefined reference to `_snd_module_rawmidi_virt'
Kind of, but the real issue is just a dependency issue.
alsa-lib/src/rawmidi/Makefile.am has:
if BUILD_SEQ
librawmidi_la_SOURCES += rawmidi_virt.c
endif
So alsa-utils-amidi needs to select alsa-lib-seq as well. rawmidi_virt.c
does have some code depending on shared/static, so that might explain
why it only triggers for static builds.
I've added a commit to add this dependency.
>> arm | armadillo-4.000.4 | NOK |
>> http://autobuild.buildroot.net/results/31be76d4cbc1193458d3a4cdd4a0ccc1087d313e/
> Fixed by http://patchwork.ozlabs.org/patch/472141/.
Committed.
>> powerpc | boost-1.57.0 | NOK |
>> http://autobuild.buildroot.net/results/9faeba9f811bb3507861003d78eec245f8a93db9/
>> nios2 | boost-1.57.0 | NOK |
>> http://autobuild.buildroot.net/results/46f9d84e6db10ce7cbe48653f6da4450aceceb4c/
>> powerpc | boost-1.57.0 | NOK |
>> http://autobuild.buildroot.net/results/7852f40e6bae93f953a588bbd6902c2b1cee8a42/
>> powerpc | boost-1.57.0 | NOK |
>> http://autobuild.buildroot.net/results/13b43105caf4d3952de70030b51f8d96cf6604ee/
>> nios2 | boost-1.57.0 | NOK |
>> http://autobuild.buildroot.net/results/e119b1ef55c546e0d0598b85c46ceefa5c43d5a6/
> The nios2 problems are due to a toolchain issue. We should simply
> disable boost with this toolchain.
Yes, will you send a patch?
> The PowerPC problems are due to a uClibc bug. I've done some tests, and
> boost-1.57.0 builds fine on PowerPC/glibc, ARM/uClibc, but fails on
> PowerPC/uClibc. It's the boost-log module that causes the problem.
So what then, make the boost-log option depend on
!(BR2_powerpc && BR2_TOOLCHAIN_USES_UCLIBC)?
>> arm | lcdproc-0.5.7 | NOK |
>> http://autobuild.buildroot.net/results/4ac625f4e888ba859a5867671664dc8d041ec9b9/
>> arm | lcdproc-0.5.7 | NOK |
>> http://autobuild.buildroot.net/results/61450e889c3912e38e52759812fbb6ce03270788/
> Builds with -shared -static when static linking. Bad.
From a very quick look it didn't seem trivial to fix, so I've simply
marked it as !BR2_STATIC_LIBS.
>> bfin | libarchive-3.1.2 | NOK |
>> http://autobuild.buildroot.net/results/5f7b69a324b72dfb522a9299804c113414db348c/
> libacl.a: No such file or directory
> I don't know.
The .libs/libacl.a sounds like libtool getting confused. Other than that
I also don't know.
>> nios2 | libcap-ng-0.7.4 | NOK |
>> http://autobuild.buildroot.net/results/d136f763ca3389cdc6a404db7a4fc0cd18329955/
> Compiler bug:
> /tmp/ccAiYLAw.s: Assembler messages:
> /tmp/ccAiYLAw.s:951: Error: bad expression
I've blacklisted that toolchain for libcap-ng (and the reverse deps).
>> x86_64 | libupnpp-0.8.6 | NOK |
>> http://autobuild.buildroot.net/results/f383bf4d7572a7dd59d382cd06a9baeb37e9161c/
> checking for curl_easy_init in -lcurl... no
> configure: error: libcurl not found
> Smells like a static linking issue.
Yes, fixed already:
http://git.buildroot.net/buildroot/commit/?id=f7638ca23229bc9dfe3696f562afc63bda6bd1f0
>> arm | mongoose-5.6 | NOK |
>> http://autobuild.buildroot.net/results/372515ba0a09a23237ae34024658f21c2625d6e7/
> mongoose.c:1326:19: fatal error: dlfcn.h: No such file or directory
> Needs shared library support.
Or better, it needs to be built with -DMONGOOSE_NO_DL as the shared
library support doesn't do anything sensible.
I've added a commit to do so.
>> nios2 | mosquitto-1.4.1 | NOK |
>> http://autobuild.buildroot.net/results/b853369452115b0c6f32c6c960af2dbdf71a74af/
> Infamous "undefined reference to symbol '_gp'" issue.
:/ Should we depend on !BR2_nios2?
>> mipsel | postgresql-9.4.1 | NOK |
>> http://autobuild.buildroot.net/results/f9ed96d22e91cdba9ad92c4d4ea52e422bf1f1c9/
> /home/buildroot/build/instance-0/output/host/usr/mipsel-buildroot-linux-uclibc/sysroot/usr/lib/libcrypto.a(c_zlib.o):
> In function `zlib_stateful_expand_block':
> c_zlib.c:(.text+0x78): undefined reference to `inflate'
> Static linking issue. Do we really want to support static linking of
> postgresql?
I don't think so, lets just mark it as !BR2_STATIC_LIBS.
>> powerpc | python-pyqt-4.11.3 | NOK |
>> http://autobuild.buildroot.net/results/d2bf71cdd0fe9b0049ba2889de89ccc36cfdc58a/
> We need to apply http://patchwork.ozlabs.org/patch/468134/.
Is that an ack? If so, please reply to the patch with it.
>> arm | qt5base-5.4.1 | NOK |
>> http://autobuild.buildroot.net/results/f403a76ac0abbf8488373c0dffb4487f5d98c55d/
> g++: error: unrecognized command line option '-fuse-ld=gold'
The problem is that qt5base doesn't understand cross compilation. It
correctly checks if the target compiler supports the gold linker and
then ends up using -fuse-ld=gold with both the host and target
compilers, so it breaks on old hosts.
I'm not sure how we should fix that. Any ideas?
Thanks for all checking all these build issues!
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-14 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2015-05-13 Thomas Petazzoni
@ 2015-05-14 21:13 ` Thomas Petazzoni
2015-05-14 22:58 ` Peter Korsgaard
2015-05-15 14:06 ` Waldemar Brodkorb
0 siblings, 2 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-14 21:13 UTC (permalink / raw)
To: buildroot
Hello,
On Thu, 14 May 2015 08:30:16 +0200 (CEST), Thomas Petazzoni wrote:
> xtensa | alsa-utils-1.0.29 | NOK | http://autobuild.buildroot.net/results/5347b57d23b44e1b011a499875ce638ed654418a/
Static linking issue:
undefined reference to `_snd_module_rawmidi_virt'
> arm | armadillo-4.000.4 | NOK | http://autobuild.buildroot.net/results/31be76d4cbc1193458d3a4cdd4a0ccc1087d313e/
Fixed by http://patchwork.ozlabs.org/patch/472141/.
> powerpc | boost-1.57.0 | NOK | http://autobuild.buildroot.net/results/9faeba9f811bb3507861003d78eec245f8a93db9/
> nios2 | boost-1.57.0 | NOK | http://autobuild.buildroot.net/results/46f9d84e6db10ce7cbe48653f6da4450aceceb4c/
> powerpc | boost-1.57.0 | NOK | http://autobuild.buildroot.net/results/7852f40e6bae93f953a588bbd6902c2b1cee8a42/
> powerpc | boost-1.57.0 | NOK | http://autobuild.buildroot.net/results/13b43105caf4d3952de70030b51f8d96cf6604ee/
> nios2 | boost-1.57.0 | NOK | http://autobuild.buildroot.net/results/e119b1ef55c546e0d0598b85c46ceefa5c43d5a6/
The nios2 problems are due to a toolchain issue. We should simply
disable boost with this toolchain.
The PowerPC problems are due to a uClibc bug. I've done some tests, and
boost-1.57.0 builds fine on PowerPC/glibc, ARM/uClibc, but fails on
PowerPC/uClibc. It's the boost-log module that causes the problem.
> arc | host-gdb-arc-2014.12-gdb | NOK | http://autobuild.buildroot.net/results/ec8ad71c51939a4548b413d447c48a29d53cb988/
> arc | host-gdb-arc-2014.12-gdb | NOK | http://autobuild.buildroot.net/results/ca45297aa0ffbc9062ed92dc7ac070b0b33001de/
> arc | host-gdb-arc-2014.12-gdb | NOK | http://autobuild.buildroot.net/results/4346e4417809f1b80b63b115137f27598b7e450d/
Already fixed by
http://git.buildroot.net/buildroot/commit/?id=0c12f72775b332fe7e3f7589ec4d08534b8ec64e.
> powerpc | host-mono-4.0.0 | NOK | http://autobuild.buildroot.net/results/c72d96a9747ffd3456e86728dc08fdce39fc7273/
> powerpc | host-mono-4.0.0 | NOK | http://autobuild.buildroot.net/results/d855645e625e7909e38205855a9a4c66a98720e8/
Parallel installation issue, still unsolved.
> arm | lcdproc-0.5.7 | NOK | http://autobuild.buildroot.net/results/4ac625f4e888ba859a5867671664dc8d041ec9b9/
> arm | lcdproc-0.5.7 | NOK | http://autobuild.buildroot.net/results/61450e889c3912e38e52759812fbb6ce03270788/
Builds with -shared -static when static linking. Bad.
> bfin | libarchive-3.1.2 | NOK | http://autobuild.buildroot.net/results/5f7b69a324b72dfb522a9299804c113414db348c/
libacl.a: No such file or directory
I don't know.
> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/d136f763ca3389cdc6a404db7a4fc0cd18329955/
Compiler bug:
/tmp/ccAiYLAw.s: Assembler messages:
/tmp/ccAiYLAw.s:951: Error: bad expression
> arm | libefreet-1.7.10 | NOK | http://autobuild.buildroot.net/results/4de0d4ebb92bda9904d9085b744705f109e99126/
uClibc static linking bug, yet another one...
> powerpc | libgtk3-3.14.11 | NOK | http://autobuild.buildroot.net/results/045f75e42815e3bb1f06aa121e7917e4617e186b/
gdkwindow-wayland.c:50:34: error: redefinition of typedef
'GdkWaylandWindow' ../../gdk/wayland/gdkwaylandwindow.h:32:34: note:
previous declaration of 'GdkWaylandWindow' was here
gdkwindow-wayland.c:51:39: error: redefinition of typedef
'GdkWaylandWindowClass' ../../gdk/wayland/gdkwaylandwindow.h:36:39:
note: previous declaration of 'GdkWaylandWindowClass' was here
Wayland backend issue?
> x86_64 | libupnpp-0.8.6 | NOK | http://autobuild.buildroot.net/results/f383bf4d7572a7dd59d382cd06a9baeb37e9161c/
checking for curl_easy_init in -lcurl... no
configure: error: libcurl not found
Smells like a static linking issue.
> arm | mongoose-5.6 | NOK | http://autobuild.buildroot.net/results/372515ba0a09a23237ae34024658f21c2625d6e7/
mongoose.c:1326:19: fatal error: dlfcn.h: No such file or directory
Needs shared library support.
> nios2 | mosquitto-1.4.1 | NOK | http://autobuild.buildroot.net/results/b853369452115b0c6f32c6c960af2dbdf71a74af/
Infamous "undefined reference to symbol '_gp'" issue.
> bfin | ncurses-5.9 | NOK | http://autobuild.buildroot.net/results/5173b841460cac17639958afe2abcef803f9eb81/
Lots and lots of weird errors.
> i686 | neardal-33b54a55032b047fd88... | NOK | http://autobuild.buildroot.net/results/586fa95149aa37df7ef430e3a47a3418e6f7ed97/
checking for library containing rl_initialize... no
configure: error: editline or readline is required
Smells like a static linking issue.
> mipsel | postgresql-9.4.1 | NOK | http://autobuild.buildroot.net/results/f9ed96d22e91cdba9ad92c4d4ea52e422bf1f1c9/
/home/buildroot/build/instance-0/output/host/usr/mipsel-buildroot-linux-uclibc/sysroot/usr/lib/libcrypto.a(c_zlib.o): In function `zlib_stateful_expand_block':
c_zlib.c:(.text+0x78): undefined reference to `inflate'
Static linking issue. Do we really want to support static linking of
postgresql?
> powerpc | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/d2bf71cdd0fe9b0049ba2889de89ccc36cfdc58a/
We need to apply http://patchwork.ozlabs.org/patch/468134/.
> arm | qt5base-5.4.1 | NOK | http://autobuild.buildroot.net/results/f403a76ac0abbf8488373c0dffb4487f5d98c55d/
g++: error: unrecognized command line option '-fuse-ld=gold'
> xtensa | rsyslog-8.9.0 | NOK | http://autobuild.buildroot.net/results/d15a31eedb92bb22f0f22188913d15c93ac8d776/
> powerpc | rsyslog-8.9.0 | NOK | http://autobuild.buildroot.net/results/d14f8451f0488ca79ff4f131c68af83a974b3853/
> xtensa | rsyslog-8.9.0 | NOK | http://autobuild.buildroot.net/results/e70c54b55988a1bed0eb0bad7d0050ebf860a3a3/
Fixed by http://git.buildroot.net/buildroot/commit/?id=3d3f70b567718ae308b5704ddd7d107c4849309e.
> mipsel | sofia-sip-1.12.11 | NOK | http://autobuild.buildroot.net/results/d748025d17e131921d114d8baa20bab2722b26b8/
uClibc static linking bug.
> xtensa | uboot-tools-2015.04 | NOK | http://autobuild.buildroot.net/results/208e93e36d20df0137625c47edc44181a8ac24fa/
> x86_64 | uboot-tools-2015.04 | NOK | http://autobuild.buildroot.net/results/9b7cedbf3eec5125385e73fbfd4988c382986be6/
Fixed by http://git.buildroot.net/buildroot/commit/?id=95f9a5c3df8e4226b99438efccf0bf21eecb573d.
> x86_64 | vsftpd-3.0.2 | NOK | http://autobuild.buildroot.net/results/3bf7d288f77418b933d5f479c14fa3dab0e5b1ae/
> mipsel | vsftpd-3.0.2 | NOK | http://autobuild.buildroot.net/results/90cea7c4fdb3e5af923eedf96d79594d6d02e563/
> arm | vsftpd-3.0.2 | NOK | http://autobuild.buildroot.net/results/4be4623329f30d403b29ac77b9ce4379e530d341/
> mips64el | vsftpd-3.0.2 | NOK | http://autobuild.buildroot.net/results/440e208a475577580be7042d52e10dda47d837ba/
> arm | vsftpd-3.0.2 | NOK | http://autobuild.buildroot.net/results/a37fe465561a073a193ebcf8458f24738b64b296/
> arm | vsftpd-3.0.2 | NOK | http://autobuild.buildroot.net/results/221c987a9657caefad54bcc2fe9d2d71189c94c5/
> i686 | vsftpd-3.0.2 | NOK | http://autobuild.buildroot.net/results/3662e59003080ef1e5105d35fe8215768c2a899e/
Fixed by http://git.buildroot.net/buildroot/commit/?id=205f07755661b64da21509469b46006ea0badcf9.
> bfin | xmlstarlet-1.5.0 | NOK | http://autobuild.buildroot.net/results/2d6ff7466a0626566082e98188a3e1224d1e1ad0/
/home/peko/autobuild/instance-1/output/host/usr/bfin-buildroot-uclinux-uclibc/sysroot/usr/lib/libexslt.a(crypto.o): In function `_exsltCryptoGcryptInit':
crypto.c:(.text+0x112): undefined reference to `_gcry_check_version'
/home/peko/autobuild/instance-1/output/host/usr/bfin-buildroot-uclinux-uclibc/sysroot/usr/lib/libexslt.a(crypto.o): In function `_exsltCryptoRc4DecryptFunction':
crypto.c:(.text+0x316): undefined reference to `_gcry_cipher_open'
Static linking issue.
> sh4 | zmqpp-3.2.0 | NOK | http://autobuild.buildroot.net/results/2c48cd13fc453ba399e57a3703375f4eecd65685/
src/client/main.cpp: In function 'int main(int, const char**)':
src/client/main.cpp:30:10: error: 'EXIT_FAILURE' was not declared in this scope
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-07 7:33 ` Thomas Petazzoni
@ 2015-05-07 7:42 ` Peter Korsgaard
0 siblings, 0 replies; 416+ messages in thread
From: Peter Korsgaard @ 2015-05-07 7:42 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> It is not fixed in uClibc master.
> Ok, thanks for the confirmation.
> So here is my proposal:
> 1/ For the 2015.05 release, we simply add exceptions to the
> autobuilder script to avoid such problematic cases.
> 2/ For the 2015.08 release, we switch to uClibc-ng as the default
> uClibc version, and I rebuild all uClibc based external toolchains
> to use uClibc-ng.
> What do others think?
Sounds good to me.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-07 4:05 ` Waldemar Brodkorb
@ 2015-05-07 7:33 ` Thomas Petazzoni
2015-05-07 7:42 ` Peter Korsgaard
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-07 7:33 UTC (permalink / raw)
To: buildroot
Waldemar,
On Thu, 7 May 2015 06:05:26 +0200, Waldemar Brodkorb wrote:
> Fixed in uClibc-ng.
> wbx at helium:~/buildroot $ grep UCLIBC_VERSION_NG .config
> BR2_UCLIBC_VERSION_NG=y
> wbx at helium:~/buildroot $ file output/target/usr/bin/genisoimage
> output/target/usr/bin/genisoimage: ELF 32-bit LSB executable, ARM,
> version 1 (SYSV), statically linked, stripped
>
> It is not fixed in uClibc master.
Ok, thanks for the confirmation.
So here is my proposal:
1/ For the 2015.05 release, we simply add exceptions to the
autobuilder script to avoid such problematic cases.
2/ For the 2015.08 release, we switch to uClibc-ng as the default
uClibc version, and I rebuild all uClibc based external toolchains
to use uClibc-ng.
What do others think?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-07 6:51 ` Peter Korsgaard
@ 2015-05-07 7:31 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-07 7:31 UTC (permalink / raw)
To: buildroot
Peter,
On Thu, 07 May 2015 08:51:29 +0200, Peter Korsgaard wrote:
> > My suggestion would therefore be to change host-autoconf-archive to
> > install in a path that isn't in the standard include path of
> > autoreconf/aclocal. This way, no package doing AUTORECONF = YES would
> > be "polluted" by the presence of host-autoconf-archive. And only those
> > few packages that actually need host-autoconf-archive can add the
> > relevant -I option to AUTORECONF_OPTS. I've tested that installing
> > host-autoconf-archive to a custom location works, but I haven't tested
> > the other part of the solution.
>
> > Thoughts?
>
> Yes, that also sounds like the best approach to me. Will you send a
> patch to do so?
I'll try, but I'm not sure when I'll have the time to do so. It might
have to wait until next week.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-06 22:01 ` Thomas Petazzoni
@ 2015-05-07 6:51 ` Peter Korsgaard
2015-05-07 7:31 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Peter Korsgaard @ 2015-05-07 6:51 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
> My suggestion would therefore be to change host-autoconf-archive to
> install in a path that isn't in the standard include path of
> autoreconf/aclocal. This way, no package doing AUTORECONF = YES would
> be "polluted" by the presence of host-autoconf-archive. And only those
> few packages that actually need host-autoconf-archive can add the
> relevant -I option to AUTORECONF_OPTS. I've tested that installing
> host-autoconf-archive to a custom location works, but I haven't tested
> the other part of the solution.
> Thoughts?
Yes, that also sounds like the best approach to me. Will you send a
patch to do so?
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-06 7:42 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (3 preceding siblings ...)
2015-05-06 22:01 ` Thomas Petazzoni
@ 2015-05-07 4:05 ` Waldemar Brodkorb
2015-05-07 7:33 ` Thomas Petazzoni
4 siblings, 1 reply; 416+ messages in thread
From: Waldemar Brodkorb @ 2015-05-07 4:05 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Thomas Petazzoni wrote,
> > x86_64 | cdrkit-1.1.11 | NOK | http://autobuild.buildroot.net/results/2bd48ed578a143749d4503aca96f661647afe525/
>
> multiple definition of `__lll_lock_wait_private'
> multiple definition of `__lll_unlock_wake_private'
>
> This is a uClibc static linking problem. Waldemar, can you let us know
> whether it was fixed upstream and/or in uClibc-ng ?
Fixed in uClibc-ng.
wbx at helium:~/buildroot $ grep UCLIBC_VERSION_NG .config
BR2_UCLIBC_VERSION_NG=y
wbx at helium:~/buildroot $ file output/target/usr/bin/genisoimage
output/target/usr/bin/genisoimage: ELF 32-bit LSB executable, ARM,
version 1 (SYSV), statically linked, stripped
It is not fixed in uClibc master.
best regards
Waldemar
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-06 7:42 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (2 preceding siblings ...)
2015-05-06 20:58 ` Alexey Brodkin
@ 2015-05-06 22:01 ` Thomas Petazzoni
2015-05-07 6:51 ` Peter Korsgaard
2015-05-07 4:05 ` Waldemar Brodkorb
4 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-06 22:01 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 6 May 2015 09:42:36 +0200, Thomas Petazzoni wrote:
> > x86_64 | snmppp-3.3.4 | NOK | http://autobuild.buildroot.net/results/45858c9754b8aa017a58f3f74463b28042fdf9cb/
> > powerpc | snmppp-3.3.4 | NOK | http://autobuild.buildroot.net/results/c479c9a9f1ba2271ece2f316cc7b6c2c9d39e60d/
>
> Weird stuff happening:
>
> libtool: error: unrecognised option: '-DHAVE_CONFIG_H'
> libtool: error: unrecognised option: '-DHAVE_CONFIG_H'
I've analyzed this one. It happens when host-autoconf-archive is built
before snmpp. The problem is that snmpp defines and uses its own
ACX_PTHREAD m4 macro, and host-autoconf-archive as well. But they don't
behave in the same way: snmpp macro's define PTHREAD_CXX, but not
host-autoconf-archive's one. Then CXX is empty, which leads to the
above failure.
The exact same problem was solved by Romain on the ola package in
commit 884af65fd5ddc548f19a26162f905a32ef0b53b3. However, I am not too
happy with the solution: it consists in tweaking the ola configure.ac
script so that it can work with either the ola-provided ACX_PTHREAD
macro or the host-autoconf-archive provided ACX_PTHREAD macro.
I researched a bit, and it is apparently normal for the macros
in /usr/share/aclocal/ to take precedence over the ones defined in the
local m4/ directory.
My suggestion would therefore be to change host-autoconf-archive to
install in a path that isn't in the standard include path of
autoreconf/aclocal. This way, no package doing AUTORECONF = YES would
be "polluted" by the presence of host-autoconf-archive. And only those
few packages that actually need host-autoconf-archive can add the
relevant -I option to AUTORECONF_OPTS. I've tested that installing
host-autoconf-archive to a custom location works, but I haven't tested
the other part of the solution.
Thoughts?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-06 20:58 ` Alexey Brodkin
2015-05-06 21:32 ` Peter Korsgaard
@ 2015-05-06 21:42 ` Thomas Petazzoni
1 sibling, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-06 21:42 UTC (permalink / raw)
To: buildroot
Dear Alexey Brodkin,
On Wed, 6 May 2015 20:58:43 +0000, Alexey Brodkin wrote:
> That failure looks pretty expected to me.
[...]
> So I'm not sure how to solve it properly.
> I would say that building of shared object should not happen if
> BR2_STATIC_LIBS=y, and probably we need to patch Python build system to
> troubleshoot that problem.
>
> I'm also wondering if something similar happens for other arches?
You're absolutely correct.
However, python has been marked as "depends on !BR2_STATIC_LIBS"
recently, in commit 5b4d18dd1cc33c4cfd62a20704f4c48d2097c9c1. So this
means that something is selecting Python without taking care of this
dependency.
Peter, it seems like when you did this commit, you didn't take into
account the places where BR2_PACKAGE_PYTHON is selected. Did you?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-06 20:58 ` Alexey Brodkin
@ 2015-05-06 21:32 ` Peter Korsgaard
2015-05-06 21:42 ` Thomas Petazzoni
1 sibling, 0 replies; 416+ messages in thread
From: Peter Korsgaard @ 2015-05-06 21:32 UTC (permalink / raw)
To: buildroot
>>>>> "Alexey" == Alexey Brodkin <Alexey.Brodkin@synopsys.com> writes:
> Hi Thomas,
> On Wed, 2015-05-06 at 09:42 +0200, Thomas Petazzoni wrote:
>> > arc | python-2.7.9 | NOK |
>> http://autobuild.buildroot.net/results/4c694d715f66de49964ef36f7236c7575c3a0b5a/
>>
>> relocation R_ARC_32 against `.text' can not be used when making a
>> shared object; recompile with -fPIC
> That failure looks pretty expected to me.
> In defconfig
> (http://autobuild.buildroot.net/results/4c6/4c694d715f66de49964ef36f7236c7575c3a0b5a/defconfig)
> I see "BR2_STATIC_LIBS=y". And libffi is built statically then. In
> that case fixed relocation R_ARC_32 is used (symbol gets resolved
> during final linkage and then offset is inserted in-place in .text
> section which means there's no way to relocate that symbol later on).
> ctypes.so is attempted to be built dynamically and here our linker
> throws an error:
Hmm, why is it even building python when python depends on
!BR2_STATIC_LIBS?
It seems like I forgot to propagate that dependency:
git grep -l 'select BR2_PACKAGE_PYTHON$'
package/dstat/Config.in
package/gnuradio/Config.in
package/kodi/Config.in
package/ola/Config.in
package/samba4/Config.in
But everything but kodi and gnuradio can be built statically:
git grep -l 'select BR2_PACKAGE_PYTHON$'|xargs grep -l STATIC_LIBS
package/gnuradio/Config.in
package/kodi/Config.in
From the defconfig I guess the reason here was dstat.
I'll fix these dependencies now, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-06 7:42 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2015-05-06 8:07 ` gwenhael.goavec
2015-05-06 17:53 ` Waldemar Brodkorb
@ 2015-05-06 20:58 ` Alexey Brodkin
2015-05-06 21:32 ` Peter Korsgaard
2015-05-06 21:42 ` Thomas Petazzoni
2015-05-06 22:01 ` Thomas Petazzoni
2015-05-07 4:05 ` Waldemar Brodkorb
4 siblings, 2 replies; 416+ messages in thread
From: Alexey Brodkin @ 2015-05-06 20:58 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Wed, 2015-05-06 at 09:42 +0200, Thomas Petazzoni wrote:
> > arc | python-2.7.9 | NOK | http://autobuild.buildroot.net/results/4c694d715f66de49964ef36f7236c7575c3a0b5a/
>
> relocation R_ARC_32 against `.text' can not be used when making a
> shared object; recompile with -fPIC
That failure looks pretty expected to me.
In defconfig
(http://autobuild.buildroot.net/results/4c6/4c694d715f66de49964ef36f7236c7575c3a0b5a/defconfig) I see "BR2_STATIC_LIBS=y". And libffi is built statically then. In that case fixed relocation R_ARC_32 is used (symbol gets resolved during final linkage and then offset is inserted in-place in .text section which means there's no way to relocate that symbol later on).
But even though we expect to build everything statically there's what
happens in the end of build log:
--->8---
/home/peko/autobuild/instance-1/output/host/usr/bin/arc-linux-gcc
-shared -static
build/temp.linux2-arc-2.7/home/peko/autobuild/instance-1/output/build/python-2.7.9/Modules/_ctypes/_ctypes.o build/temp.linux2-arc-2.7/home/peko/autobuild/instance-1/output/build/python-2.7.9/Modules/_ctypes/callbacks.o build/temp.linux2-arc-2.7/home/peko/autobuild/instance-1/output/build/python-2.7.9/Modules/_ctypes/callproc.o build/temp.linux2-arc-2.7/home/peko/autobuild/instance-1/output/build/python-2.7.9/Modules/_ctypes/stgdict.o build/temp.linux2-arc-2.7/home/peko/autobuild/instance-1/output/build/python-2.7.9/Modules/_ctypes/cfield.o -L/home/peko/autobuild/instance-1/output/host/usr/arc-buildroot-linux-uclibc/sysroot/usr/lib -L/home/peko/autobuild/instance-1/output/host/usr/arc-buildroot-linux-uclibc/sysroot/lib -L/home/peko/autobuild/instance-1/output/host/opt/ext-toolchain/arc-buildroot-linux-uclibc/lib -L/home/peko/autobuild/instance-1/output/host/opt/ext-toolchain/lib/gcc -lffi -o build/lib.linux2-arc-2.7/_ctypes.so
--->8---
ctypes.so is attempted to be built dynamically and here our linker
throws an error:
--->8---
/home/peko/autobuild/instance-1/output/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/4.8.3/../../../../arc-buildroot-linux-uclibc/bin/ld: /home/peko/autobuild/instance-1/output/host/usr/arc-buildroot-linux-uclibc/sysroot/usr/lib/libffi.a(prep_cif.o): relocation R_ARC_32 against `.text' can not be used when making a shared object; recompile with -fPIC
/home/peko/autobuild/instance-1/output/host/usr/arc-buildroot-linux-uclibc/sysroot/usr/lib/libffi.a: could not read symbols: Bad value
--->8---
So I'm not sure how to solve it properly.
I would say that building of shared object should not happen if
BR2_STATIC_LIBS=y, and probably we need to patch Python build system to
troubleshoot that problem.
I'm also wondering if something similar happens for other arches?
Any thoughts?
-Alexey
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-06 7:42 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2015-05-06 8:07 ` gwenhael.goavec
@ 2015-05-06 17:53 ` Waldemar Brodkorb
2015-05-06 20:58 ` Alexey Brodkin
` (2 subsequent siblings)
4 siblings, 0 replies; 416+ messages in thread
From: Waldemar Brodkorb @ 2015-05-06 17:53 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Thomas Petazzoni wrote,
> > arm | libsigsegv-2.10 | NOK | http://autobuild.buildroot.net/results/a144bc6024415a5272c3cbe60ff636d078d0a555/
> > arm | libsigsegv-2.10 | NOK | http://autobuild.buildroot.net/results/00195d89a115a314bf4916af127407f61cd1b418/
>
> error: unknown type name 'ucontext_t'
>
> Happens with uClibc-ng only it seems. Waldemar, can you have a look?
Patch sent. A symbol in the config is required to enable these
needed SuSv3 functions. Fixes also the mongrel2 compile errors.
best regards
Waldemar
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-06 7:42 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2015-05-06 8:07 ` gwenhael.goavec
2015-05-06 17:53 ` Waldemar Brodkorb
` (3 subsequent siblings)
4 siblings, 0 replies; 416+ messages in thread
From: gwenhael.goavec @ 2015-05-06 8:07 UTC (permalink / raw)
To: buildroot
hello
On Wed, 6 May 2015 09:42:36 +0200
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
[SNIP]
>
> > sh4a | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/09302c153418c3af6dc4cdd12a0149505cfbca0b/
> > sh4 | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/96f8a9758f0116aec999028fde1b9c983c143809/
> > sh4a | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/848b9433c09d6cbc81c8d1e22778ae68223b43f3/
> > arm | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/2062208c171207428c9121215971e00c52bf306a/
> > arm | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/57ef99b9dd0623e3e9b61e5964eb45e611b89cd5/
>
> Some of these were due to the Qt coord patch that we reverted. However,
> one of them,
> http://autobuild.buildroot.org/results/848/848b9433c09d6cbc81c8d1e22778ae68223b43f3/,
> appeared after the revert. So there is still a problem with python-pyqt
> it seems. Gwenhael, can you have a look?
>
It's seems strange. I've tested with PyQt_qreal_double enabled, this works.
Theorically PyQt_qreal_double must be disabled for SH4(a) because QT_NO_FPU is
not set...
I need to check for the first ARM build failure.
The last build failure is fixed by http://patchwork.ozlabs.org/patch/468134/
[SNIP]
Gwenhael Goavec-Merou
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-06 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2015-05-05 Thomas Petazzoni
@ 2015-05-06 7:42 ` Thomas Petazzoni
2015-05-06 8:07 ` gwenhael.goavec
` (4 more replies)
0 siblings, 5 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-06 7:42 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 6 May 2015 08:30:17 +0200 (CEST), Thomas Petazzoni wrote:
> success : 301
> failures : 50
> timeouts : 1
Seems like switching to a 8 hours timeout has helped reducing the
number of timeouts.
> powerpc | boost-1.57.0 | NOK | http://autobuild.buildroot.net/results/b64fd94a8ccff7fa8c5e0ca0c4acb7254f9cddc3/
The infamous:
error: no type named 'bits' in 'traits_type
If someone could start tackling this long standing problem, it would be
great.
> bfin | cc-tool-0.26 | NOK | http://autobuild.buildroot.net/results/5f84d5696a52c75416c85f802278ee776053b4b9/
> xtensa | cc-tool-0.26 | NOK | http://autobuild.buildroot.net/results/d971db839e84480a565c5b2970f13296700dbd51/
> arc | cc-tool-0.26 | NOK | http://autobuild.buildroot.net/results/8126d59d06f5452a7ce2a4cdcda3103fb64046ee/
> bfin | cc-tool-0.26 | NOK | http://autobuild.buildroot.net/results/37009dda6344dcf25ca52878e9a5beb37f2a0a93/
Should be fixed by applying http://patchwork.ozlabs.org/patch/468487/.
> x86_64 | cdrkit-1.1.11 | NOK | http://autobuild.buildroot.net/results/2bd48ed578a143749d4503aca96f661647afe525/
multiple definition of `__lll_lock_wait_private'
multiple definition of `__lll_unlock_wake_private'
This is a uClibc static linking problem. Waldemar, can you let us know
whether it was fixed upstream and/or in uClibc-ng ?
> nios2 | cryptsetup-1.6.6 | NOK | http://autobuild.buildroot.net/results/ff456344eb5bc8af619c1f5d88be0cb758dd5075/
> nios2 | cryptsetup-1.6.6 | NOK | http://autobuild.buildroot.net/results/a288b0c5b437c3d82dae4f3bf391c59236739c3a/
Should be "fixed" by http://patchwork.ozlabs.org/patch/468461/.
> xtensa | czmq-v3.0.0 | NOK | http://autobuild.buildroot.net/results/4d3dea604da9a5a1e7fe20548813f8de474ae33f/
I'm not sure, but it smells like gcc is used instead of g++. Someone to
look into this?
> xtensa | freerdp-770c67d340d5f0a7b48... | NOK | http://autobuild.buildroot.net/results/a4caf2b035ea5b7d5318635bf78373d6229aa496/
> arc | freerdp-770c67d340d5f0a7b48... | NOK | http://autobuild.buildroot.net/results/88a4c76e3a48fae42f78eba8febfe4eb29fc9904/
> arm | freerdp-770c67d340d5f0a7b48... | NOK | http://autobuild.buildroot.net/results/0889a99bc4092ab553889de458b534e4da2cbfd0/
> xtensa | freerdp-770c67d340d5f0a7b48... | NOK | http://autobuild.buildroot.net/results/4c1a244db94dbd37e26a4fec5ba506f0525c1d00/
> arc | freerdp-770c67d340d5f0a7b48... | NOK | http://autobuild.buildroot.net/results/50ad78fc35fa90cda5e0453b6867b3ce0dbf65be/
> arc | freerdp-770c67d340d5f0a7b48... | NOK | http://autobuild.buildroot.net/results/e94cdc19a18c91eb851c007b833f0dfa08be5cc0/
Should be fixed by
http://git.buildroot.net/buildroot/commit/?id=5e701275d96ccebd69dbfceec5fb92e0b7049c71.
> aarch64 | google-breakpad-1373 | NOK | http://autobuild.buildroot.net/results/c9f116443199dab708a18c23fcea3e623664d947/
Pascal asked the Google Breakpad developers about this breakage. We
might want to disable on AArch64 in the mean time.
> mips64el | gst1-plugins-bad-1.4.5 | NOK | http://autobuild.buildroot.net/results/a23401c97a11636799b685d9eec8c96e5e202cd0/
mips64el-ctng_n64-linux-gnu-g++: error: /usr/lib/libopencv_ts.a: No
such file or directory
Samuel, this is an OpenCV related issue, can you have a look?
> sh4a | host-qemu-2.3.0 | NOK | http://autobuild.buildroot.net/results/40a47f11daa201c488519c0b1270cc2e71cc3116/
We need to tweak qemu.mk, since sh4a instead a valid architecture name:
ERROR: Unknown target name 'sh4a-linux-user'
I'll send a patch for this one.
> i686 | ipmiutil-2.9.5 | NOK | http://autobuild.buildroot.net/results/e0a198d88c746c6ad24916d723b5faa9024f8abd/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=ec45eb1619da40ea97fa39dfe60cee2a9b8e78c6.
> bfin | libarchive-3.1.2 | NOK | http://autobuild.buildroot.net/results/6c0225e109d87178e80cf7edfff1461b077629b2/
/home/test/autobuild/instance-0/output/host/usr/bfin-buildroot-uclinux-uclibc/sysroot/usr/lib/.libs/libacl.a:
No such file or directory
Not sure. Someone interested?
> arm | libepoxy-v1.2 | NOK | http://autobuild.buildroot.net/results/fee1e3a4eb7923d7ce166184323b908ed069b3b6/
fatal error: EGL/eglplatform.h: No such file or directory
Bernd?
> arc | librsvg-2.26.3 | TIM | http://autobuild.buildroot.net/results/858daf884d04d56d37e3a2e481c45f7b9a2a88f8/
Ignore.
> arm | libsigsegv-2.10 | NOK | http://autobuild.buildroot.net/results/a144bc6024415a5272c3cbe60ff636d078d0a555/
> arm | libsigsegv-2.10 | NOK | http://autobuild.buildroot.net/results/00195d89a115a314bf4916af127407f61cd1b418/
error: unknown type name 'ucontext_t'
Happens with uClibc-ng only it seems. Waldemar, can you have a look?
> mips | lua-periphery-1.0.4-1 | NOK | http://autobuild.buildroot.net/results/2c7bd050917ab0a65a53f3516a7023cac5be078a/
lua-periphery is using an old version of c-periphery (and is doing the
Git clone itself, workarounding Buildroot download mechanism!). I've
started working on this issue yesterday night.
> xtensa | mesa3d-10.5.4 | NOK | http://autobuild.buildroot.net/results/3e2e24f697e26c93d4d95782b1cb7799fa620a7a/
Linker bug, Max Filipov said he would have a look.
> x86_64 | numactl-2.0.10 | NOK | http://autobuild.buildroot.net/results/c7d63606065b7c53545ba498493661e760647812/
> x86_64 | numactl-2.0.10 | NOK | http://autobuild.buildroot.net/results/9c1088f1676474014c5977856e0bfb1dbdc121fb/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=1f55934c8adbf3146e622abfdab9173d63169347.
> xtensa | postgresql-9.4.1 | NOK | http://autobuild.buildroot.net/results/1d9d11291d8e0591144f0652cd42615fd8993cd2/
> xtensa | postgresql-9.4.1 | NOK | http://autobuild.buildroot.net/results/24253e3a9183a0bf0f8f021cf1eb59d631f27839/
> xtensa | postgresql-9.4.1 | NOK | http://autobuild.buildroot.net/results/d2d1fc7ceb35b25ef68947b2cf0e219616313121/
> xtensa | postgresql-9.4.1 | NOK | http://autobuild.buildroot.net/results/7d1e92b61431b83e7bc38da1bb211b5f2b3dd119/
> xtensa | postgresql-9.4.1 | NOK | http://autobuild.buildroot.net/results/ebf2e54d0d6f08c57bf6d4946b1df8df4a84c422/
I think we should apply http://patchwork.ozlabs.org/patch/453567/. It's
not a very nice fix, but it's not really the fix that isn't nice, but
the original logic.
> arc | python-2.7.9 | NOK | http://autobuild.buildroot.net/results/4c694d715f66de49964ef36f7236c7575c3a0b5a/
relocation R_ARC_32 against `.text' can not be used when making a
shared object; recompile with -fPIC
Alexey, can you have a look?
> sh4a | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/09302c153418c3af6dc4cdd12a0149505cfbca0b/
> sh4 | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/96f8a9758f0116aec999028fde1b9c983c143809/
> sh4a | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/848b9433c09d6cbc81c8d1e22778ae68223b43f3/
> arm | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/2062208c171207428c9121215971e00c52bf306a/
> arm | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/57ef99b9dd0623e3e9b61e5964eb45e611b89cd5/
Some of these were due to the Qt coord patch that we reverted. However,
one of them,
http://autobuild.buildroot.org/results/848/848b9433c09d6cbc81c8d1e22778ae68223b43f3/,
appeared after the revert. So there is still a problem with python-pyqt
it seems. Gwenhael, can you have a look?
> i686 | qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/50315ab70d313f40a0caeff51dc76354495a5cf9/
PostgreSQL testing issue:
PostgreSQL support cannot be enabled due to functionality tests!
Turn on verbose messaging (-v) to ./configure to see the final report.
If you believe this message is in error you may use the continue
switch (-continue) to ./configure to continue.
Maybe it's the same problem as the one affecting rsyslog when detecting
postgresql (missing -lpthread).
> mips64el | qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/0e2e877cb75a49d0560ab785c4afa51065fbd54f/
Most likely fixed by the revert of the Qt coord patch.
> arm | qt5webkit-5.4.1 | NOK | http://autobuild.buildroot.net/results/b6d6e19cfe484afabcd392f6095e8425dd591540/
Compiler error, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61207. Can
someone have a look at the conclusion of this bug and see if we can
backport the fix?
> powerpc | rsyslog-8.9.0 | NOK | http://autobuild.buildroot.net/results/d9c388b15c20c934426400c8e85775ea1efcc007/
Postgresql detection problem. Should be fixed by
http://patchwork.ozlabs.org/patch/460332/, but this patch raised some
discussion.
> xtensa | sane-backends-1.0.24 | NOK | http://autobuild.buildroot.net/results/6f6f3aa826bc3521e29aa0755cbeb3f333f511ad/
> xtensa | sane-backends-1.0.24 | NOK | http://autobuild.buildroot.net/results/a27442aca5b2df58e37eff7209117c787673baf3/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=083ec2df6c38b444f0e76cd708f5600a9f149a83.
> x86_64 | snmppp-3.3.4 | NOK | http://autobuild.buildroot.net/results/45858c9754b8aa017a58f3f74463b28042fdf9cb/
> powerpc | snmppp-3.3.4 | NOK | http://autobuild.buildroot.net/results/c479c9a9f1ba2271ece2f316cc7b6c2c9d39e60d/
Weird stuff happening:
libtool: error: unrecognised option: '-DHAVE_CONFIG_H'
libtool: error: unrecognised option: '-DHAVE_CONFIG_H'
> bfin | tinyxml2-2.2.0 | NOK | http://autobuild.buildroot.net/results/349c1ec8ee9f2e1e1f8f37b6e6823761cad5edc8/
> bfin | tinyxml2-2.2.0 | NOK | http://autobuild.buildroot.net/results/c96e4bd3044c89df8e67d9c383886eb61c438e24/
Samuel, can you have a look at this one? This is CMake stuff, trying to
build a shared library when it should not.
> sh4a | weston-1.7.0 | NOK | http://autobuild.buildroot.net/results/b4da4e9f0c85c9fb402cb5a1bb5a8d1d63b05b13/
undefined reference to symbol 'clock_gettime@@GLIBC_2.2'
Bernd, can you have a look?
> sh4 | zmqpp-3.2.0 | NOK | http://autobuild.buildroot.net/results/73e5b739887dd0d62fb215bd03b13a31e4a0d1fa/
src/client/main.cpp: In function 'int main(int, const char**)':
src/client/main.cpp:30:10: error: 'EXIT_FAILURE' was not declared in
this scope
This should be quite easy.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-04 21:30 ` Thomas Petazzoni
@ 2015-05-05 11:00 ` Richard Genoud
0 siblings, 0 replies; 416+ messages in thread
From: Richard Genoud @ 2015-05-05 11:00 UTC (permalink / raw)
To: buildroot
On 04/05/2015 23:30, Thomas Petazzoni wrote:
> Dear Richard Genoud,
>
> On Mon, 4 May 2015 16:57:59 +0200, Richard Genoud wrote:
>
>>> > We currently only allow BR2_PACKAGE_QT_QT_COORD_TYPE_DOUBLE for soft
>>> > float toolchains, but perhaps it needs to also be disallowed for mips64?
>>> > Richard, care to take a look?
>>>
>>> QT_COORD_TYPE_DOUBLE also causes issues with python-pyqt because of
>>> qreal* -> float* conversion. Could you take a look?
>>>
>>> http://autobuild.buildroot.net/results/891/891dc6ad46039740867a0b436281fc489cfb2772/build-end.log
>>
>> yes, no problem.
>
> And I also believe
> http://autobuild.buildroot.org/results/3a7/3a70305be4a78af9404b0bd027dbcdd011ca01b3/build-end.log
> is caused by BR2_PACKAGE_QT_QT_COORD_TYPE_DOUBLE:
>
> ../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QPen::setWidthF(float)'
> ../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QTransform::translate(float, float)'
> ../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QMatrix::setMatrix(float, float, float, float, float, float)'
> ../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QTransform::rotate(float, Qt::Axis)'
> ../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QColor::setRgbF(float, float, float, float)'
> ../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QPen::setDashOffset(float)'
> ../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QColor::setAlphaF(float)'
> ../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QPen::setMiterLimit(float)'
> ../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QTransform::QTransform(float, float, float, float, float, float)'
> ../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QColor::setCmykF(float, float, float, float, float)'
> ../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QPen::setDashPattern(QVector<float> const&)'
>
> The libpoppler code is expecting "float" arguments for all these
> functions, but they are now taking "double" instead.
>
> Seems like using a double type is breaking a lot of assumptions of
> existing applications and libraries. Do we really want to support this
> option?
>
> I would personally suggest to revert the patch for now in 2015.05, and
> take the time to make sure it is properly tested with all the Qt-based
> libraries and applications.
>
> Richard, what do you think?
Ok, I've found the right Config.in depends to set to BR2_PACKAGE_QT_QT_COORD_TYPE_DOUBLE.
It shouldn't break in any arch now.
I also corrected the breakage with python-pyqt.
BUT, there's still some packages (at least poppler and pinentry (I started to compile more packages, but my internet liaison at work stalls quite often))
that are breaking when BR2_PACKAGE_QT_QT_COORD_TYPE_DOUBLE is set.
The reason is that those packages are not using qmake, so the -DQT_COORD_TYPE=double doesn't appear in their CFLAGS/CXXFLAGS.
So, for all packages that use Qt but not qmake, the CFLAGS/CXXFLAGS have to be appended with -DQT_COORD_TYPE=double
That said, this option was originally created for QWT (http://qwt.sourceforge.net/ ):
The problem was that QWT uses qreals to draw its curves/plots/... and when you want to have dates(QwtDate) on an axe, the dates are converted to qreal,
and if qreal is float, the precision is not enough (not even by a day).
So, forcing qreal to float seems a good solution.
Given the fact that 2015.05 is close, and that there's quite some packages to test with this option (and that it's not a huge feature-killer), I agree with
Thomas for reverting it.
For reference, I'm pasting the patch I've come with to prevent breaking any architecture.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-04 14:57 ` Richard Genoud
@ 2015-05-04 21:30 ` Thomas Petazzoni
2015-05-05 11:00 ` Richard Genoud
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-04 21:30 UTC (permalink / raw)
To: buildroot
Dear Richard Genoud,
On Mon, 4 May 2015 16:57:59 +0200, Richard Genoud wrote:
> > > We currently only allow BR2_PACKAGE_QT_QT_COORD_TYPE_DOUBLE for soft
> > > float toolchains, but perhaps it needs to also be disallowed for mips64?
> > > Richard, care to take a look?
> >
> > QT_COORD_TYPE_DOUBLE also causes issues with python-pyqt because of
> > qreal* -> float* conversion. Could you take a look?
> >
> > http://autobuild.buildroot.net/results/891/891dc6ad46039740867a0b436281fc489cfb2772/build-end.log
>
> yes, no problem.
And I also believe
http://autobuild.buildroot.org/results/3a7/3a70305be4a78af9404b0bd027dbcdd011ca01b3/build-end.log
is caused by BR2_PACKAGE_QT_QT_COORD_TYPE_DOUBLE:
../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QPen::setWidthF(float)'
../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QTransform::translate(float, float)'
../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QMatrix::setMatrix(float, float, float, float, float, float)'
../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QTransform::rotate(float, Qt::Axis)'
../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QColor::setRgbF(float, float, float, float)'
../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QPen::setDashOffset(float)'
../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QColor::setAlphaF(float)'
../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QPen::setMiterLimit(float)'
../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QTransform::QTransform(float, float, float, float, float, float)'
../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QColor::setCmykF(float, float, float, float, float)'
../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `QPen::setDashPattern(QVector<float> const&)'
The libpoppler code is expecting "float" arguments for all these
functions, but they are now taking "double" instead.
Seems like using a double type is breaking a lot of assumptions of
existing applications and libraries. Do we really want to support this
option?
I would personally suggest to revert the patch for now in 2015.05, and
take the time to make sure it is properly tested with all the Qt-based
libraries and applications.
Richard, what do you think?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-04 13:52 ` Peter Korsgaard
@ 2015-05-04 14:57 ` Richard Genoud
2015-05-04 21:30 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Richard Genoud @ 2015-05-04 14:57 UTC (permalink / raw)
To: buildroot
2015-05-04 15:52 GMT+02:00 Peter Korsgaard <peter@korsgaard.com>:
>>>>>> "Peter" == Peter Korsgaard <peter@korsgaard.com> writes:
>
>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> > Hi,
>
> >> Hello,
> >> On Sat, 2 May 2015 08:30:16 +0200 (CEST), Thomas Petazzoni wrote:
>
> >>> mips64el | qt-4.8.6 | NOK |
> >>> http://autobuild.buildroot.net/results/3c50ed4bb15ab35341c7682ce4706b7a05a6f702/
> >>> mips64el | qt-4.8.6 | NOK |
> >>> http://autobuild.buildroot.net/results/07aca0c27a07761621d46fb690e3ccd50cbc2ef5/
>
> >> error: redefinition of 'bool QTest::qCompare
>
> >> Needs investigation.
>
> > Sounds related to:
>
> > http://lists.busybox.net/pipermail/buildroot/2015-April/127153.html
>
> > We currently only allow BR2_PACKAGE_QT_QT_COORD_TYPE_DOUBLE for soft
> > float toolchains, but perhaps it needs to also be disallowed for mips64?
> > Richard, care to take a look?
>
> QT_COORD_TYPE_DOUBLE also causes issues with python-pyqt because of
> qreal* -> float* conversion. Could you take a look?
>
> http://autobuild.buildroot.net/results/891/891dc6ad46039740867a0b436281fc489cfb2772/build-end.log
yes, no problem.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-03 11:23 ` Peter Korsgaard
2015-05-04 6:50 ` Richard Genoud
@ 2015-05-04 13:52 ` Peter Korsgaard
2015-05-04 14:57 ` Richard Genoud
1 sibling, 1 reply; 416+ messages in thread
From: Peter Korsgaard @ 2015-05-04 13:52 UTC (permalink / raw)
To: buildroot
>>>>> "Peter" == Peter Korsgaard <peter@korsgaard.com> writes:
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> Hi,
>> Hello,
>> On Sat, 2 May 2015 08:30:16 +0200 (CEST), Thomas Petazzoni wrote:
>>> mips64el | qt-4.8.6 | NOK |
>>> http://autobuild.buildroot.net/results/3c50ed4bb15ab35341c7682ce4706b7a05a6f702/
>>> mips64el | qt-4.8.6 | NOK |
>>> http://autobuild.buildroot.net/results/07aca0c27a07761621d46fb690e3ccd50cbc2ef5/
>> error: redefinition of 'bool QTest::qCompare
>> Needs investigation.
> Sounds related to:
> http://lists.busybox.net/pipermail/buildroot/2015-April/127153.html
> We currently only allow BR2_PACKAGE_QT_QT_COORD_TYPE_DOUBLE for soft
> float toolchains, but perhaps it needs to also be disallowed for mips64?
> Richard, care to take a look?
QT_COORD_TYPE_DOUBLE also causes issues with python-pyqt because of
qreal* -> float* conversion. Could you take a look?
http://autobuild.buildroot.net/results/891/891dc6ad46039740867a0b436281fc489cfb2772/build-end.log
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-03 8:50 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (2 preceding siblings ...)
2015-05-03 11:53 ` Baruch Siach
@ 2015-05-04 10:28 ` Jörg Krause
3 siblings, 0 replies; 416+ messages in thread
From: Jörg Krause @ 2015-05-04 10:28 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On So, 2015-05-03 at 10:50 +0200, Thomas Petazzoni wrote:
> Hello,
>
> > sh4a | boost-1.58.0 | NOK | http://autobu
> > ild.buildroot.net/results/ccd5c83963032ba49b1627b1dff39e34a9486943/
> > mipsel | boost-1.58.0 | NOK | http://autobu
> > ild.buildroot.net/results/66c3a868816dfe4bd4d0ffafec6988fd87a2c058/
>
> Fixed by reverting to 1.57.
Fixed by http://patchwork.ozlabs.org/patch/467255/?
>
> > arm | libtirpc-0.2.4 | NOK | http://autobu
> > ild.buildroot.net/results/c64cb1874e6287da1942533d85d26b12192c73df/
> > arm | libtirpc-0.2.4 | NOK | http://autobu
> > ild.buildroot.net/results/9f08353e94eadb914332aa80fc90c4315bfef7c2/
>
> libtirpc fails to build on musl.
> I started working on this topic, but it's not that simple...
Me, too. Yeah, removing sys/cdefs.h, replacing __BEGIN_DECLS,
__END_DECLS, and __THROW, replacing sys/queue.h, and some things
more...
Best regards
J?rg Krause
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-03 11:23 ` Peter Korsgaard
@ 2015-05-04 6:50 ` Richard Genoud
2015-05-04 13:52 ` Peter Korsgaard
1 sibling, 0 replies; 416+ messages in thread
From: Richard Genoud @ 2015-05-04 6:50 UTC (permalink / raw)
To: buildroot
2015-05-03 13:23 GMT+02:00 Peter Korsgaard <peter@korsgaard.com>:
>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>
> Hi,
>
> > Hello,
> > On Sat, 2 May 2015 08:30:16 +0200 (CEST), Thomas Petazzoni wrote:
>
> >> mips64el | qt-4.8.6 | NOK |
> >> http://autobuild.buildroot.net/results/3c50ed4bb15ab35341c7682ce4706b7a05a6f702/
> >> mips64el | qt-4.8.6 | NOK |
> >> http://autobuild.buildroot.net/results/07aca0c27a07761621d46fb690e3ccd50cbc2ef5/
>
> > error: redefinition of 'bool QTest::qCompare
>
> > Needs investigation.
>
> Sounds related to:
>
> http://lists.busybox.net/pipermail/buildroot/2015-April/127153.html
>
> We currently only allow BR2_PACKAGE_QT_QT_COORD_TYPE_DOUBLE for soft
> float toolchains, but perhaps it needs to also be disallowed for mips64?
> Richard, care to take a look?
Yes, I'm gonna look at that.
Richard.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-03 8:50 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2015-05-03 10:39 ` Romain Naour
2015-05-03 11:23 ` Peter Korsgaard
@ 2015-05-03 11:53 ` Baruch Siach
2015-05-04 10:28 ` Jörg Krause
3 siblings, 0 replies; 416+ messages in thread
From: Baruch Siach @ 2015-05-03 11:53 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Sun, May 03, 2015 at 10:50:09AM +0200, Thomas Petazzoni wrote:
>
> > arm | freerdp-770c67d340d5f0a7b48... | NOK | http://autobuild.buildroot.net/results/12fd2a248b121d9178406f3216e35c866d391667/
> > arm | freerdp-770c67d340d5f0a7b48... | NOK | http://autobuild.buildroot.net/results/b69dcc39847e927349c598a840caecfd14c36b87/
> > xtensa | freerdp-770c67d340d5f0a7b48... | NOK | http://autobuild.buildroot.net/results/971bd6e6b66f0c3c3fcd06a830d83b87a53f03b2/
> > arm | freerdp-770c67d340d5f0a7b48... | NOK | http://autobuild.buildroot.net/results/029cd2c19681445d38d76b7fcd8f939652e8fcf1/
>
> libm missing when linking. Could some CMake person have a look?
I don't think so. uClibc variants don't export the 'long double' versions of
pow(), ceil(), etc., even with DO_C99_MATH=y. We'll probably need to add
another check_symbol_exists() to CMakeLists.txt.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-03 8:50 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2015-05-03 10:39 ` Romain Naour
@ 2015-05-03 11:23 ` Peter Korsgaard
2015-05-04 6:50 ` Richard Genoud
2015-05-04 13:52 ` Peter Korsgaard
2015-05-03 11:53 ` Baruch Siach
2015-05-04 10:28 ` Jörg Krause
3 siblings, 2 replies; 416+ messages in thread
From: Peter Korsgaard @ 2015-05-03 11:23 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
> Hello,
> On Sat, 2 May 2015 08:30:16 +0200 (CEST), Thomas Petazzoni wrote:
>> mips64el | qt-4.8.6 | NOK |
>> http://autobuild.buildroot.net/results/3c50ed4bb15ab35341c7682ce4706b7a05a6f702/
>> mips64el | qt-4.8.6 | NOK |
>> http://autobuild.buildroot.net/results/07aca0c27a07761621d46fb690e3ccd50cbc2ef5/
> error: redefinition of 'bool QTest::qCompare
> Needs investigation.
Sounds related to:
http://lists.busybox.net/pipermail/buildroot/2015-April/127153.html
We currently only allow BR2_PACKAGE_QT_QT_COORD_TYPE_DOUBLE for soft
float toolchains, but perhaps it needs to also be disallowed for mips64?
Richard, care to take a look?
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-03 8:50 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2015-05-03 10:39 ` Romain Naour
2015-05-03 11:23 ` Peter Korsgaard
` (2 subsequent siblings)
3 siblings, 0 replies; 416+ messages in thread
From: Romain Naour @ 2015-05-03 10:39 UTC (permalink / raw)
To: buildroot
Hi Thomas,all
Le 03/05/2015 10:50, Thomas Petazzoni a ?crit :
> Hello,
>
> On Sat, 2 May 2015 08:30:16 +0200 (CEST), Thomas Petazzoni wrote:
>> powerpc | boost-1.57.0 | NOK | http://autobuild.buildroot.net/results/df8f87a34f59f81aa288c72673a80757f00ea6a2/
>
> Weird C++ issue.
This issue appears since boost-log has been added (BR2_PACKAGE_BOOST_LOG=y).
May be an issue specific to uClibc 0.9.33 ?
Needs to test with uClibc-snapshot and uClibc-ng.
>
>> arc | host-gdb-arc-2014.12-gdb | NOK | http://autobuild.buildroot.net/results/d44753dfe7e2aaa9fd803b4a69db65728f8301a8/
>> arc | host-gdb-arc-2014.12-gdb | NOK | http://autobuild.buildroot.net/results/ac3391023b13f405ef633688f714a10c22dc2db2/
>
> The dynamic linking issue.
There is two proposal to fixes this issue:
http://patchwork.ozlabs.org/patch/460494/
http://patchwork.ozlabs.org/patch/449686/
Also, it's not a issue specific to the arc toolchain:
http://autobuild.buildroot.net/results/deb/deb284ccaeac9c2de409adccf41ee888577621b7/
>
>> i686 | numactl-2.0.10 | NOK | http://autobuild.buildroot.net/results/619339810617212a667fe72278ec727ee992ffbf/
>
> Don't know:
>
> checking for thread local storage (TLS) class... __thread
> ./configure: line 12681: syntax error near unexpected token `fi'
> ./configure: line 12681: `fi'
Weird because this package is autoreconfed... but wait.
If you look to the build-time.log, you'll see that host-autoconf-archive has
been installed before numactl.
host-autoconf-archive can suppressed several m4 macro bundled with a package.
Needs to test with and without host-autoconf-archive.
Best regards,
Romain
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2015-05-02 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2015-05-01 Thomas Petazzoni
@ 2015-05-03 8:50 ` Thomas Petazzoni
2015-05-03 10:39 ` Romain Naour
` (3 more replies)
0 siblings, 4 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2015-05-03 8:50 UTC (permalink / raw)
To: buildroot
Hello,
On Sat, 2 May 2015 08:30:16 +0200 (CEST), Thomas Petazzoni wrote:
> arm | arptables-0.0.4 | NOK | http://autobuild.buildroot.net/results/063d3c2649116e7a43774055df45926a38c7f088/
Musl build problem.
> powerpc | boost-1.57.0 | NOK | http://autobuild.buildroot.net/results/df8f87a34f59f81aa288c72673a80757f00ea6a2/
Weird C++ issue.
> sh4a | boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/ccd5c83963032ba49b1627b1dff39e34a9486943/
> mipsel | boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/66c3a868816dfe4bd4d0ffafec6988fd87a2c058/
Fixed by reverting to 1.57.
> nios2 | cryptsetup-1.6.6 | NOK | http://autobuild.buildroot.net/results/11bd680d7ad7994723826e4654dfb4993c91d058/
Infamous "undefined reference to symbol '_gp'" issue. I suggest to
simply disable this package on NIOS 2.
> powerpc | fbterm-1.7.0 | NOK | http://autobuild.buildroot.net/results/f343d015b127f29d614e7ea38b173d3a5c270d84/
pthread static linking issue
> arm | freerdp-770c67d340d5f0a7b48... | NOK | http://autobuild.buildroot.net/results/12fd2a248b121d9178406f3216e35c866d391667/
> arm | freerdp-770c67d340d5f0a7b48... | NOK | http://autobuild.buildroot.net/results/b69dcc39847e927349c598a840caecfd14c36b87/
> xtensa | freerdp-770c67d340d5f0a7b48... | NOK | http://autobuild.buildroot.net/results/971bd6e6b66f0c3c3fcd06a830d83b87a53f03b2/
> arm | freerdp-770c67d340d5f0a7b48... | NOK | http://autobuild.buildroot.net/results/029cd2c19681445d38d76b7fcd8f939652e8fcf1/
libm missing when linking. Could some CMake person have a look?
> bfin | gdb-7.8.2 | NOK | http://autobuild.buildroot.net/results/bb9d178902c1dcb65c2a0ccb943a02ddda68912f/
Since we removed the internal toolchain support for Blackfin, I believe
we should also disable gdb.
> arm | gptfdisk-0.8.10 | NOK | http://autobuild.buildroot.net/results/a9092d01a71e2d799e5b7b3afb9fd3e304370d0c/
randutils.c:(.text+0x21c): undefined reference to `libintl_gettext'
Missing -lintl ?
> arc | host-gdb-arc-2014.12-gdb | NOK | http://autobuild.buildroot.net/results/d44753dfe7e2aaa9fd803b4a69db65728f8301a8/
> arc | host-gdb-arc-2014.12-gdb | NOK | http://autobuild.buildroot.net/results/ac3391023b13f405ef633688f714a10c22dc2db2/
The dynamic linking issue.
> i686 | host-ola-0.9.4 | NOK | http://autobuild.buildroot.net/results/85d7fcda63d7bbba0eb4d0876c50a3f6d443f93d/
> i686 | host-ola-0.9.4 | NOK | http://autobuild.buildroot.net/results/8fa0a64422a96023a926412a033d9a4f01af5a71/
> x86_64 | host-ola-0.9.4 | NOK | http://autobuild.buildroot.net/results/04ad18c48f38f8ca6f968b3e16af74729fca0d9e/
Fixed by http://git.buildroot.net/buildroot/commit/?id=884af65fd5ddc548f19a26162f905a32ef0b53b3.
> sh4a | host-qemu-2.3.0 | NOK | http://autobuild.buildroot.net/results/2af3954a9171d64dcca8f251ccd6e2ce19f88883/
We should disable sh4a, or handle it properly.
> i686 | ipmiutil-2.9.5 | NOK | http://autobuild.buildroot.net/results/083ddb8c96a30e0c3c443ffded27428f70870b85/
Missing symbols from OpenSSL ?
md2.o: In function `md2_sum':
md2.c:(.text+0x15): undefined reference to `EVP_md2'
> bfin | leveldb-v1.18 | NOK | http://autobuild.buildroot.net/results/f7930231cadeef7ccb0df6acf41b62c2c6fd1e02/
Fixed by http://git.buildroot.net/buildroot/commit/?id=4cc236784e5783fef0fd7bf9437e55a38cc8c291.
> xtensa | libecore-1.7.10 | NOK | http://autobuild.buildroot.net/results/257d5d35ce18356829a36d8f5dd0e4f8dacfb810/
> i686 | libecore-1.7.10 | NOK | http://autobuild.buildroot.net/results/306c9fc737ee76d4659e14bf3102b94a57ea45dd/
Being worked on by Romain.
> i686 | libfreeimage-3.17.0 | NOK | http://autobuild.buildroot.net/results/fe72243a84a91b68ef3138847294674b36f16c58/
I had a look, I will submit a fix.
> bfin | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/20421cb8ef86b99ad9beef7056879ccf9edc188f/
> bfin | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/e42dd08ea5fe15ac8224f8ea2a96b6e2d3ea382d/
> bfin | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/12622a78b1482dfbdb1a197ca070de699c86c9f9/
Not sure what's going on.
> arm | libtirpc-0.2.4 | NOK | http://autobuild.buildroot.net/results/c64cb1874e6287da1942533d85d26b12192c73df/
> arm | libtirpc-0.2.4 | NOK | http://autobuild.buildroot.net/results/9f08353e94eadb914332aa80fc90c4315bfef7c2/
libtirpc fails to build on musl. I started working on this topic, but
it's not that simple...
> x86_64 | libubox-5a0bbefc8fa44044625... | NOK | http://autobuild.buildroot.net/results/b2d7e1997f534cf93b845807342e33cfa6b8ec45/
> xtensa | libubox-5a0bbefc8fa44044625... | NOK | http://autobuild.buildroot.net/results/c8793d89e6fc609f02b73c6f20185d4a1b86edff/
> xtensa | libubox-5a0bbefc8fa44044625... | NOK | http://autobuild.buildroot.net/results/c65ac04797759b19c847376a2cf7adc5598fc0a1/
Fixed by http://git.buildroot.net/buildroot/commit/?id=4e99abc47511c2f0bc3b5a7da9e877aba6a84b9f.
> powerpc | libvncserver-0.9.10 | TIM | http://autobuild.buildroot.net/results/b8ebb345bd9122f151cd705c7d04d3a38f182838/
Ignore.
> mips64el | lshw-B.02.16 | NOK | http://autobuild.buildroot.net/results/59fa68ac7f4cb88cdf26ad40dfd5bfcff643536d/
Spurious download problem.
> x86_64 | make: *** [target-finalize]... | TIM | http://autobuild.buildroot.net/results/5ca9ed6701b56efd399649faaba9c9551eb4f7a7/
> arm | mongrel2-v1.9.1 | TIM | http://autobuild.buildroot.net/results/8cc256baf2f20f52d1f173176f8543c8f068832d/
Ignore.
> arm | mongrel2-v1.9.1 | NOK | http://autobuild.buildroot.net/results/5ee7e83ebcfa43f6ee0a2a8b9f40f1ae84664aca/
This is with uclibc-ng. Not sure it's related.
In file included from src/task/context.c:3:0:
src/task/taskimpl.h:108:17: error: unknown type name 'mcontext_t'
int getmcontext(mcontext_t*);
> arm | monit-5.12.2 | TIM | http://autobuild.buildroot.net/results/fd2d611f95f7a3743312a720b39ec1fc57bfb6e4/
> arm | musepack-r475 | TIM | http://autobuild.buildroot.net/results/6b4b7e0f4b911507bcb9f73adf4b893fa597c591/
Ignore.
> i686 | numactl-2.0.10 | NOK | http://autobuild.buildroot.net/results/619339810617212a667fe72278ec727ee992ffbf/
Don't know:
checking for thread local storage (TLS) class... __thread
./configure: line 12681: syntax error near unexpected token `fi'
./configure: line 12681: `fi'
> xtensa | postgresql-9.4.1 | NOK | http://autobuild.buildroot.net/results/36e5c81b87bf6eaf3e3cb52f59577640eeb1c2c6/
Should be fixed by http://patchwork.ozlabs.org/patch/453567/.
> arc | python-2.7.9 | NOK | http://autobuild.buildroot.net/results/aade9a1d5864af1977f4bed03ed59b45e0ad873b/
Fixed by http://git.buildroot.net/buildroot/commit/?id=5b4d18dd1cc33c4cfd62a20704f4c48d2097c9c1.
> sh4 | python-pyqt-4.11.3 | NOK | http://autobuild.buildroot.net/results/7f54162747eee6b4a9017a7d5f3ec3ee1cf12085/
Ah, sh4 having an issue with the double/float thing.
> mips64el | qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/3c50ed4bb15ab35341c7682ce4706b7a05a6f702/
> mips64el | qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/07aca0c27a07761621d46fb690e3ccd50cbc2ef5/
error: redefinition of 'bool QTest::qCompare
Needs investigation.
> arm | qt-4.8.6 | TIM | http://autobuild.buildroot.net/results/00fede225eea29d392f3c2cc67825616300ffdff/
Ignore.
> arc | rsyslog-8.9.0 | NOK | http://autobuild.buildroot.net/results/894a650b3f46fb57d2e57bead2d591817e6c24f7/
msg.c: In function 'MsgSetPropsViaJSON':
msg.c:4135:15: error: 'json_tokener_errors' undeclared (first use in this function)
errMsg = json_tokener_errors[err];
> mips64el | samba4-4.2.1 | TIM | http://autobuild.buildroot.net/results/8d227b36e9ab0a1b9f1094e52018835f8f096398/
Ignore.
> bfin | tinyxml2-2.2.0 | NOK | http://autobuild.buildroot.net/results/800de7c682b885e6fddebd390dc3c97eabe5f36c/
It's trying to build a shared library even in static only scenario.
Could a CMake person have a look?
> arc | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/29bba97c253feba446808465cc2ede1b1e454956/
> arc | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/aa98ff875ef39db1a20e144385219c5ced433b37/
Fixed by disabling the ARC toolchain.
> xtensa | vlc-2.2.1 | NOK | http://autobuild.buildroot.net/results/504cf78a08315e2fc6eaeb9a29ae791972753830/
> xtensa | vlc-2.2.1 | NOK | http://autobuild.buildroot.net/results/09280c5d63da9b8b58916c32e6040a98f7ff0ee8/
Fixed by http://autobuild.buildroot.net/results/09280c5d63da9b8b58916c32e6040a98f7ff0ee8/
> mips64el | wvstreams-4.6.1 | NOK | http://autobuild.buildroot.net/results/e8d92b8dfb666bbdda6799f2ea5c72fd8c491bf8/
> arm | wvstreams-4.6.1 | NOK | http://autobuild.buildroot.net/results/b802cc638a4b11d2a2098b82615f2c0ccadf8e3f/
> arm | wvstreams-4.6.1 | NOK | http://autobuild.buildroot.net/results/b188207df8b8618b536a67763a6c06f0d235ead0/
> powerpc | wvstreams-4.6.1 | NOK | http://autobuild.buildroot.net/results/4f4f4bbae4129822eb56aef23ae2885c2c455a16/
> powerpc | wvstreams-4.6.1 | NOK | http://autobuild.buildroot.net/results/fc182ff06ae42a1679827b2d924774649153a59d/
> arm | wvstreams-4.6.1 | NOK | http://autobuild.buildroot.net/results/bd120ada4830fda3db96da945513d4f6f7b2d419/
> arm | wvstreams-4.6.1 | NOK | http://autobuild.buildroot.net/results/a705ce4beac0bba08a93d8cf95080b67a395c715/
Fixed by http://git.buildroot.net/buildroot/commit/?id=2a4ece2ed3e3766c463ef8f61a3362ba86c8a6cf.
> sh4 | zmqpp-3.2.0 | NOK | http://autobuild.buildroot.net/results/b77596e12b78a88cc35d50f466100d320213f0e4/
src/client/main.cpp: In function 'int main(int, const char**)':
src/client/main.cpp:30:10: error: 'EXIT_FAILURE' was not declared in this scope
src/client/main.cpp:38:10: error: 'EXIT_FAILURE' was not declared in this scope
> nios2 | zyre-v1.0.0 | NOK | http://autobuild.buildroot.net/results/4923039f57286653ec164809b9f0c37bf9e323b5/
checking for zmq_init in -lzmq... no
configure: error: cannot link with -lzmq, install libzmq.
make: *** [/home/buildroot/instance-0/output/build/zyre-v1.0.0/.stamp_configured] Error 1
make: Leaving directory `/home/buildroot/instance-0/buildroot'
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-12-29 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-12-28 Thomas Petazzoni
@ 2014-12-29 8:30 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-12-29 8:30 UTC (permalink / raw)
To: buildroot
Hello,
On Mon, 29 Dec 2014 08:30:15 +0100 (CET), Thomas Petazzoni wrote:
> arm | cppcms-1.0.4 | NOK | http://autobuild.buildroot.net/results/23398bc625ad2719f001c1ab0c76713bc2adbf07/
The infamous cppcms issue, which has been happening since months.
> powerpc | dhcpcd-6.6.7 | NOK | http://autobuild.buildroot.net/results/ca32c4de8b645c96cedb80b6270a792e9601ad84/
> powerpc | dhcpcd-6.6.7 | NOK | http://autobuild.buildroot.net/results/e97e980a2f1e0ff4138a6dc03d86ad3ff0973e4a/
Kernel headers issue with this old toolchain?
> mips64el | dmalloc-5.4.3 | NOK | http://autobuild.buildroot.net/results/6afd10f435692c72363f065d654d07eb4d74cd37/
mv dmalloc.h.t dmalloc.h
./dmallocc.cc:41:21: fatal error: dmalloc.h: No such file or directory
#include "dmalloc.h"
Parallel build issue, maybe?
> arm | erlang-17.4 | NOK | http://autobuild.buildroot.net/results/89101289474d51e48f80e353aa4e4449113c083b/
checking for a usable libatomic_ops implementation... no
configure: error: No usable libatomic_ops implementation found
configure: error: /bin/bash '/home/peko/autobuild/instance-2/output/build/erlang-17.4/erts/configure' failed for erts
There are some patches from Frank pending about this, but I am not
entirely convinced yet. We had some discussion about it last night with
Yann. To be investigated.
> arc | freerdp-440916eae2e07463912... | NOK | http://autobuild.buildroot.net/results/c1fdc7df0821641a0876da4f3138f6854d9d989a/
../../libwinpr/utils/libwinpr-utils.so.0.1.0: undefined reference to `powl'
../../libwinpr/utils/libwinpr-utils.so.0.1.0: undefined reference to `fmodl'
../../libwinpr/utils/libwinpr-utils.so.0.1.0: undefined reference to `ceill'
../../libwinpr/utils/libwinpr-utils.so.0.1.0: undefined reference to `log10l'
../../libwinpr/utils/libwinpr-utils.so.0.1.0: undefined reference to `floorl'
collect2: error: ld returned 1 exit status
Forgets to link with libm? Weird because it's not a static link configuration.
> bfin | gptfdisk-0.8.6 | NOK | http://autobuild.buildroot.net/results/0a74f37517f9944018d343361575479496a9bc6e/
/ssd1/thomas/autobuild/instance-2/output/host/usr/bfin-buildroot-uclinux-uclibc/sysroot/usr/lib/libpopt.a(poptint.o): In function `strdup_locale_from_utf8':
/ssd1/thomas/autobuild/instance-2/output/build/popt-1.16/poptint.c:93: undefined reference to `_libiconv_open'
/ssd1/thomas/autobuild/instance-2/output/build/popt-1.16/poptint.c:108: undefined reference to `_libiconv'
/ssd1/thomas/autobuild/instance-2/output/build/popt-1.16/poptint.c:111: undefined reference to `_libiconv'
/ssd1/thomas/autobuild/instance-2/output/build/popt-1.16/poptint.c:138: undefined reference to `_libiconv_close'
collect2: ld returned 1 exit status
Forgets to link against libiconv in static linking situation.
> mips64el | gptfdisk-0.8.6 | NOK | http://autobuild.buildroot.net/results/f1c1b05223fd62b96b9f2f4d780650c4d2d634b4/
Corrupted tarball, should be resolved thanks to the addition of hash
files for all Sourceforge packages.
> arm | gptfdisk-0.8.6 | NOK | http://autobuild.buildroot.net/results/1d3839229c11979210d6a8ad440a66d0587ea546/
Same.
> bfin | libiio-v0.3 | NOK | http://autobuild.buildroot.net/results/964f98fafdcd7e994ea25cf0993915d81537c31c/
Static linking issue: it doesn't take into account the fact that
libxml2 is linked against libz and libm.
> bfin | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/7a6ca3c1f6b7bae6365fac0ffba9c16542cb9255/
Not sure, but it seems it is trying to build a shared library on a FLAT
system.
> xtensa | libvncserver-0.9.10 | NOK | http://autobuild.buildroot.net/results/e648ed8e7d96d2727c4446d12f5864e5691a4210/
Would be fixed by http://patchwork.ozlabs.org/patch/424327/.
> xtensa | libvncserver-0.9.10 | NOK | http://autobuild.buildroot.net/results/e92cf4025b0f573d4a9ade30025954168d8469f6/
Ditto.
> arc | libvncserver-0.9.10 | NOK | http://autobuild.buildroot.net/results/be20dec9ffe7de3adc46a834852b20353d39baff/
Ditto.
> mips64el | mpdecimal-2.4.0 | TIM | http://autobuild.buildroot.net/results/d5d13915a57503d0df5fec6d10ae23b04946c120/
Ignore.
> bfin | opentyrian-2.1.20130907 | NOK | http://autobuild.buildroot.net/results/3815ba4ff4d43b53bd5b6195b9d3174e424672b5/
> bfin | opentyrian-2.1.20130907 | NOK | http://autobuild.buildroot.net/results/b4c2a802946e75c6e50da68cef71e5d3cc2b2552/
/ssd1/thomas/autobuild/instance-0/output/host/usr/bfin-buildroot-uclinux-uclibc/sysroot/usr/lib/libc.a(strchrnul.o): In function `*___GI_strchrnul':
/usr/src/packages/BUILD/blackfin-toolchain-uclibc-full-2014R1/uClibc/libc/string/generic/strchrnul.c:33: multiple definition of `_strchrnul'
obj/mingw_fixes.o:src/mingw_fixes.c:(.text+0x0): first defined here
> arm | oprofile-1.0.0 | NOK | http://autobuild.buildroot.net/results/e822d62bbf21f8a9ef6cffbf888947fb0d09a861/
> arm | oprofile-1.0.0 | NOK | http://autobuild.buildroot.net/results/e5e9ed8277dda1dcefbae4b75c673693a85ea422/
operf.cpp: In function ???end_code_t _run()???:
operf.cpp:668:33: error: ???nanosleep??? was not declared in this scope
(void)nanosleep(&ts_req, NULL);
> mipsel | qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/dd78faeaffe79bb4ed14e8d06ac7033fcb0341c1/
Project ERROR: Package gstreamer-app-0.10 not found
make[2]: *** [WebCore/Makefile.WebKit] Error 2
make[2]: *** Waiting for unfinished jobs....
Not sure what's going on here.
> x86_64 | sdl_sound-1.0.3 | NOK | http://autobuild.buildroot.net/results/b9770aabb317d2e123a26b9c642a72759de836f1/
mpglib.c:147:9: error: overflow in implicit constant conversion [-Werror=overflow]
SDL_RWseek(internal->rw, -sizeof (mp3_magic), SEEK_CUR);
^
cc1: all warnings being treated as errors
> mips64el | sispmctl-3.1 | NOK | http://autobuild.buildroot.net/results/1efca09d28f3724abe6973016d654af6c594752e/
> arm | sispmctl-3.1 | NOK | http://autobuild.buildroot.net/results/21e30bcb6df9b2b6170ecf0dc9d0ed157fd5e018/
> i686 | sispmctl-3.1 | NOK | http://autobuild.buildroot.net/results/0e993cab4b2923631909ad47eb11ca50e23f6bcd/
> microblazeel | sispmctl-3.1 | NOK | http://autobuild.buildroot.net/results/fcb0cf4bf8e8e739162877a9ba74ce8df8ea4ba6/
Download issues, also fixed by the addition of Sourceforge hashes.
> bfin | thrift-0.9.2 | NOK | http://autobuild.buildroot.net/results/d58de379451a175b9eeda63535c17d6f2034639a/
> bfin | thrift-0.9.2 | NOK | http://autobuild.buildroot.net/results/ad7bff258854f11a0921a583e2f756f75f512f48/
Weird issue, I know Yann was looking into it.
> arm | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/5955a3415ecf1c420249ac02b86321221463a43c/
Temporary download issue. Maybe we should mirror the toolchains on sources.buildroot.net ?
> bfin | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/0c0ff63aef4d92c57d203e32740b48f971870785/
Download issue, fixed by the addition of hashes for Blackfin toolchains.
> mips64el | unknown | TIM | http://autobuild.buildroot.net/results/4b3a5246a02fcfe0971698cc33248e4f62c25556/
> powerpc | wvdial-1.61 | TIM | http://autobuild.buildroot.net/results/27189e551008f4fe10bd029b1058e1fd2d70865f/
> sh4a | yaml-cpp-0.5.1 | TIM | http://autobuild.buildroot.net/results/94555403981dad96ceab660f681a0ae069becc7b/
Ignore.
> bfin | zeromq-4.0.5 | NOK | http://autobuild.buildroot.net/results/1a85103724ccb7d2b5a4a39dd054b8491d6bc077/
Missing atomic operations.
> bfin | zmqpp-36413487f05b165dfc82a... | NOK | http://autobuild.buildroot.net/results/fefe865edebf4627e92a8bca3ac0b3c8dbac6cd6/
Weird C++ issues.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-14 10:19 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-09-15 2:52 ` Matthew Weber
[not found] ` <CA+-urNSSKAn3=oXPM2553CO6+8XQB=4hKjzNR4mSg61aAY_LgQ@mail.gmail.com>
@ 2014-09-28 10:47 ` Bernd Kuhls
2 siblings, 0 replies; 416+ messages in thread
From: Bernd Kuhls @ 2014-09-28 10:47 UTC (permalink / raw)
To: buildroot
Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
@public.gmane.org> wrote in news:20140914121904.0c2ebcbd at free-electrons.com:
>> arm | vlc-2.1.5 | NOK |
http://autobuild.buildroot.net/results/2d2bbd633dc09e7471e8b48be39b74fb1bf633
6f/
> main_interface.moc.cpp:14:2: error: #error "This file was generated using
the moc from 4.6.3. It"
> #error "This file was generated using the moc from 4.6.3. It"
> ^
> main_interface.moc.cpp:15:2: error: #error "cannot be used with the include
files from this version of Qt."
> #error "cannot be used with the include files from this version of Qt."
> Qt/VLC issue. Bernd?
Hi,
I can not reproduce this build error, maybe a local moc binary is getting in
the way here?
Regards, Bernd
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-12 8:11 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (3 preceding siblings ...)
2014-09-12 9:45 ` Anton Kolesov
@ 2014-09-20 12:10 ` Bernd Kuhls
4 siblings, 0 replies; 416+ messages in thread
From: Bernd Kuhls @ 2014-09-20 12:10 UTC (permalink / raw)
To: buildroot
Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
@public.gmane.org> wrote in news:20140912101105.1e932cb8 at free-electrons.com:
>> arm | vlc-2.1.5 | NOK |
http://autobuild.buildroot.net/results/7102921b0a8d3a09bf7b3f5f18e56dab6ef364
02/
>
> -L/usr/lib used, bad!
>
> /home/peko/autobuild/instance-0/output/host/opt/ext-
toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.3/../../../../arm-none-
linux-gnueabi/bin/ld: warning: library search path "/usr/lib" is unsafe for
cross-compilation
> /usr/lib/librt.so: file not recognized: File format not recognized
> collect2: error: ld returned 1 exit status
>
> Bernd, maybe?
Hi,
I cannot reproduce this error here.
Regards, Bernd
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-15 13:59 ` Thomas Petazzoni
@ 2014-09-15 14:48 ` Frank Hunleth
0 siblings, 0 replies; 416+ messages in thread
From: Frank Hunleth @ 2014-09-15 14:48 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Mon, Sep 15, 2014 at 9:59 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Frank Hunleth,
>
> Please don't reply to me directly, keep the list in Cc. Thanks!
:) Ahh, I've been on too many "reply-to-list" mailing lists recently...
>
> On Mon, 15 Sep 2014 09:49:20 -0400, Frank Hunleth wrote:
>
>> > compiling qwt_plot_glcanvas.cpp
>> > In file included from qwt_plot_glcanvas.cpp:10:0:
>> > qwt_plot_glcanvas.h:15:17: fatal error: qgl.h: No such file or directory
>> > compilation terminated.
>> >
>> > Frank, you updated qwt recently. Could you have a look at this issue?
>>
>> I'll check this out later today or tomorrow. I have an idea on the issue.
>
> Note that the issue has already been fixed by Peter, see
> http://git.buildroot.net/buildroot/commit/?id=6de4afc3b4353327eb5a2dc57b9f449a4d14a969.
> Of course, you're welcome to check Peter's patch.
Great! I hadn't seen his patch, so thanks for pointing me to it
Frank
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
[not found] ` <CA+-urNSSKAn3=oXPM2553CO6+8XQB=4hKjzNR4mSg61aAY_LgQ@mail.gmail.com>
@ 2014-09-15 13:59 ` Thomas Petazzoni
2014-09-15 14:48 ` Frank Hunleth
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-09-15 13:59 UTC (permalink / raw)
To: buildroot
Dear Frank Hunleth,
Please don't reply to me directly, keep the list in Cc. Thanks!
On Mon, 15 Sep 2014 09:49:20 -0400, Frank Hunleth wrote:
> > compiling qwt_plot_glcanvas.cpp
> > In file included from qwt_plot_glcanvas.cpp:10:0:
> > qwt_plot_glcanvas.h:15:17: fatal error: qgl.h: No such file or directory
> > compilation terminated.
> >
> > Frank, you updated qwt recently. Could you have a look at this issue?
>
> I'll check this out later today or tomorrow. I have an idea on the issue.
Note that the issue has already been fixed by Peter, see
http://git.buildroot.net/buildroot/commit/?id=6de4afc3b4353327eb5a2dc57b9f449a4d14a969.
Of course, you're welcome to check Peter's patch.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-14 10:19 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2014-09-15 2:52 ` Matthew Weber
[not found] ` <CA+-urNSSKAn3=oXPM2553CO6+8XQB=4hKjzNR4mSg61aAY_LgQ@mail.gmail.com>
2014-09-28 10:47 ` Bernd Kuhls
2 siblings, 0 replies; 416+ messages in thread
From: Matthew Weber @ 2014-09-15 2:52 UTC (permalink / raw)
To: buildroot
Thomas,
On Sun, Sep 14, 2014 at 5:19 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
<snip>
>> bfin | omniorb-4.1.6 | NOK | http://autobuild.buildroot.net/results/fbe6c722b92fe4ddf7ac36a8fe1be3a3891c11fd/
>
> Weird thread related issue:
>
> /home/peko/autobuild/instance-0/output/host/usr/bfin-buildroot-uclinux-uclibc/sysroot/usr/include/pthread.h: In static member function ???static omni_thread* omni_thread::self()???:
> /home/peko/autobuild/instance-0/output/host/usr/bfin-buildroot-uclinux-uclibc/sysroot/usr/include/pthread.h:575: error: too many arguments to function ???void*
>
The code is attempting to handle multi-platform posix API support, but
doesn't have a good failure path to show when it can't detect the OS
(it uses the toolchain prefix).
Here's what's happening......
The assert in the posix.cc is becuase of the PthreadDraftVersion being
set to zero
src/lib/omnithread/posix.cc:602:#if (PthreadDraftVersion <= 6)
The PthreadDraftVersion is set to zero because the OSVERSION is 0.
-D__OSVERSION__=0
The OSVERSION is 0 because of the configure failing to set the OS
based on the toolchain prefix being uclinux.
I don't have a hardware to adequately test a bfin build with omniorb
(with omni, it usually builds... but when you run it you see the
datatype or threading issues), so for now I'll prepare a patch that
limits omniorb builds to glibc only.
Based on the few discussions I found on the omni mailing list, uclibc
support is experimental and the omniorb codebase hasn't been updated
to support that target.
--
Matthew L Weber / Pr Software Engineer
Airborne Information Systems / Security Systems and Software
MS 131-100, C Ave NE, Cedar Rapids, IA, 52498, USA
www.rockwellcollins.com
Note: Any Export License Required Information and License Restricted
Third Party Intellectual Property (TPIP) content must be encrypted and
sent to matthew.weber@corp.rockwellcollins.com.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-14 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-09-13 Thomas Petazzoni
@ 2014-09-14 10:19 ` Thomas Petazzoni
2014-09-15 2:52 ` Matthew Weber
` (2 more replies)
0 siblings, 3 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-09-14 10:19 UTC (permalink / raw)
To: buildroot
Hello,
Peter, Danomi, Fran?ois, Frank, Bernd, see below. Others are also
welcome to help!
On Sun, 14 Sep 2014 08:30:13 +0200 (CEST), Thomas Petazzoni wrote:
> powerpc | alsa-lib-1.0.28 | NOK | http://autobuild.buildroot.net/results/1da77cd666772a55110395fe257d73f55b6fd95d/
The usual vfork() problem. Peter, can you apply
http://patchwork.ozlabs.org/patch/384916/ ? It has been sent two weeks
ago, and I tested it one week ago. It will not fix immediately builds
based on external toolchains (I'll have to rebuild the Buildroot
external toolchains first), but it's going to be a first step.
> x86_64 | bluez5_utils-5.21 | NOK | http://autobuild.buildroot.net/results/448373dd6028829cb71175cf6dba5573d23e035a/
/home/test/autobuild/instance-1/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/usr/lib/libdbus-1.a(libdbus_1_la-sd-daemon.o): In function `sd_listen_fds':
/home/test/autobuild/instance-1/output/build/dbus-1.8.6/dbus/sd-daemon.c:64: multiple definition of `sd_listen_fds'
In a static library configuration.
> powerpc | gnupg2-2.0.26 | NOK | http://autobuild.buildroot.net/results/b3b409ab78f2f9a9eb0e0b54847d7964c3bb36ad/
> arm | gnupg2-2.0.26 | NOK | http://autobuild.buildroot.net/results/b560b4c53fabd88ebca1f78d0ffedbcb0ef1c5db/
The usual intmax_t problem.
> bfin | gnuplot-4.6.2 | NOK | http://autobuild.buildroot.net/results/5ded5a7f80544f131f82027958a541a3733db7c5/
Could be fixed by http://patchwork.ozlabs.org/patch/375696/. Someone
needs to test the patch.
> microblazeel | gst-ffmpeg-0.10.13 | TIM | http://autobuild.buildroot.net/results/e860a8b90397f3c34b899eafb58df167a117d741/
Ignore.
> x86_64 | gst1-plugins-good-1.4.1 | NOK | http://autobuild.buildroot.net/results/9f0aacfbd0c459ede47826ea2e42924a0ff63fdf/
gstv4l2allocator.c: In function 'gst_v4l2_allocator_alloc_dmabuf':
gstv4l2allocator.c:868:22: error: 'O_CLOEXEC' undeclared (first use in this function)
expbuf.flags = O_CLOEXEC | O_RDWR;
^
Weird, because it's an external toolchain built with Buildroot 2014.08,
with uClibc, and 3.16 kernel headers... Needs investigation.
> bfin | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/a49c369b4b251580c8f64ad019aba3258c95656b/
Trying to build some shared stuff in a static only case.
> bfin | libqrencode-3.4.2 | NOK | http://autobuild.buildroot.net/results/1ca0719dd1fe0bbc528ec99b5bc2b42e985bfdca/
Forgets to link with pthread.
> x86_64 | libraw-0.13.4 | NOK | http://autobuild.buildroot.net/results/3d65cf351d3dd89b5ef5b339d5b8f474c96e2c19/
Don't know:
/home/test/autobuild/instance-3/output/host/usr/bin/x86_64-ctng_locales-linux-gnu-ranlib: 'libraw.a': No such file
> bfin | libssh2-1.4.3 | NOK | http://autobuild.buildroot.net/results/5d49bd0b0d592567deda94b38d487d868e995196/
Forgets to link with zlib. Might be related to
http://patchwork.ozlabs.org/patch/364983/, but not sure.
> x86_64 | libsvg-cairo-0.1.6 | NOK | http://autobuild.buildroot.net/results/465597702c314ca04e910b00b6b94419997cec72/
> mips64el | libsvg-cairo-0.1.6 | NOK | http://autobuild.buildroot.net/results/d63e3d835af9546826a019ee395b584c3a5c3ec9/
> mips64el | libsvg-cairo-0.1.6 | NOK | http://autobuild.buildroot.net/results/2954206a3bf1401583fc069500988fc0837e619b/
> mips64el | libsvg-cairo-0.1.6 | NOK | http://autobuild.buildroot.net/results/740b14ce3a75cb89d296b9cb7fefa2956de9c924/
> i686 | libsvg-cairo-0.1.6 | NOK | http://autobuild.buildroot.net/results/3c0f2d7665417771b1bb461d13630250832c1073/
> mips64el | libsvg-cairo-0.1.6 | NOK | http://autobuild.buildroot.net/results/1f7fb838b039f4e85e14346bbe5ddc8bef26edf1/
> aarch64 | libsvg-cairo-0.1.6 | NOK | http://autobuild.buildroot.net/results/2e09642ec05bbfc68d9c39454cac45b3a4fb520c/
> mips64el | libsvg-cairo-0.1.6 | NOK | http://autobuild.buildroot.net/results/d19635a8be054d1cb14f575c045b47020d44b582/
Should be fixed by
http://git.buildroot.net/buildroot/commit/?id=4c443f0247bde405e57e8b7db078a56a7cf9130a.
> nios2 | libsvgtiny-12121 | NOK | http://autobuild.buildroot.net/results/37161481eeea74bb67d40755a98ea9f38c6ea44a/
glibc 2.20 issue, _BSD_SOURCE and _SVID_SOURCE are deprecated. Easy to
fix.
> bfin | omniorb-4.1.6 | NOK | http://autobuild.buildroot.net/results/fbe6c722b92fe4ddf7ac36a8fe1be3a3891c11fd/
Weird thread related issue:
/home/peko/autobuild/instance-0/output/host/usr/bfin-buildroot-uclinux-uclibc/sysroot/usr/include/pthread.h: In static member function ???static omni_thread* omni_thread::self()???:
/home/peko/autobuild/instance-0/output/host/usr/bfin-buildroot-uclinux-uclibc/sysroot/usr/include/pthread.h:575: error: too many arguments to function ???void*
> i486 | perl-xml-libxml-2.0116 | NOK | http://autobuild.buildroot.net/results/c3d48c3b3d6c1e616d8e20a2f65d8ba33abe61da/
make[1]: *** No rule to make target '/home/chroot/media/code/buildroot/autobuilder/instance-1/output/host/usr/i486-buildroot-linux-uclibc/sysroot/usr/lib/perl5/5.18.2/i486-linux/CORE/vutil.h', needed by 'Av_CharPtrPtr.o'. Stop.
make[1]: Leaving directory '/home/chroot/media/code/buildroot/autobuilder/instance-1/output/build/perl-xml-libxml-2.0116'
Fran?ois, yet another thing that would require host-perl ?
> i686 | qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/389617c7c36dfe92b85d3a3db12a706ae092c73d/
Project ERROR: Package gstreamer-app-0.10 not found
make[2]: *** [WebCore/Makefile.WebKit] Error 2
make[2]: *** Waiting for unfinished jobs....
Danomi, since you sent some qt patches recently, could you have a look?
Thanks!
> i686 | qwt-6.1.0 | NOK | http://autobuild.buildroot.net/results/54df19105c151ba4ffe30ec7b76592c5ad03f182/
compiling qwt_plot_glcanvas.cpp
In file included from qwt_plot_glcanvas.cpp:10:0:
qwt_plot_glcanvas.h:15:17: fatal error: qgl.h: No such file or directory
compilation terminated.
Frank, you updated qwt recently. Could you have a look at this issue?
> mipsel | strace-4.9 | NOK | http://autobuild.buildroot.net/results/aa644a9ec6a702033499fd194ccd340e4aa194a4/
> mips | strace-4.9 | NOK | http://autobuild.buildroot.net/results/32c3860edaf14e0dc149856bc6b997369e166833/
> mipsel | strace-4.9 | NOK | http://autobuild.buildroot.net/results/e8f4965b27c9dcc58d6ec77cdc48b83c218c5bec/
strace is now disabled on mips/uClibc:
http://git.buildroot.net/buildroot/commit/?id=c97562af4b0e873dfe41baa5ae0156d3b626f46b
> bfin | ti-utils-06dbdb2727354b5f3a... | NOK | http://autobuild.buildroot.net/results/b1c6e25f2f90b329eee57fdd7cdc66d7f551cf9a/
Missing link against -lpthread.
> aarch64 | tn5250-0.17.4 | NOK | http://autobuild.buildroot.net/results/5d1b59b73a476a9267805f6844cccbffcbb199ac/
> microblazeel | tn5250-0.17.4 | NOK | http://autobuild.buildroot.net/results/4831e82f91187afd7d78f4824df189ef062987ac/
> arm | tn5250-0.17.4 | NOK | http://autobuild.buildroot.net/results/85a8e8b771f1d118fd4a25163ab44558a4de5ed0/
Presumably fixed by
http://git.buildroot.net/buildroot/commit/?id=1c102abb56a5396c9822bb630b6d1a31f0751548.
> x86_64 | tstools-1_11 | NOK | http://autobuild.buildroot.net/results/e7cc022ca102a837207f9f0453fb265d2ac00b88/
Weird:
esfilter.c:1145:1: fatal error: error writing to -: Broken pipe.
Any idea?
> powerpc | uemacs-4.0.15-lt | TIM | http://autobuild.buildroot.net/results/d301c796eb11936a7bab374c221806c6d83e2198/
Ignore.
> arm | vlc-2.1.5 | NOK | http://autobuild.buildroot.net/results/2d2bbd633dc09e7471e8b48be39b74fb1bf6336f/
main_interface.moc.cpp:14:2: error: #error "This file was generated using the moc from 4.6.3. It"
#error "This file was generated using the moc from 4.6.3. It"
^
main_interface.moc.cpp:15:2: error: #error "cannot be used with the include files from this version of Qt."
#error "cannot be used with the include files from this version of Qt."
Qt/VLC issue. Bernd?
> bfin | wayland-1.5.0 | NOK | http://autobuild.buildroot.net/results/ff5b1895325204e060cb500f9ac40dd373df2c64/
CC src/libwayland_server_la-wayland-shm.lo
src/wayland-server.c:36:19: error: dlfcn.h: No such file or directory
> i686 | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/a2bcf55a304d1129a7cd58f4725511f96abe1968/
This error is weird. It never happened in the past, and it started
appearing recently. Not sure what is causing this...
GEN stamp-webkitenumtypes.h
cp: cannot create regular file `DerivedSources/webkit/webkitenumtypes.cpp': No such file or directory
> sh4a | xerces-3.1.1 | TIM | http://autobuild.buildroot.net/results/a34cd26d34acd185fcae01a0e6ea4a8a217dd5a3/
Ignore.
> bfin | zeromq-4.0.4 | NOK | http://autobuild.buildroot.net/results/fb851ecb9794c0ffe15138664cda0ef276fea548/
> bfin | zeromq-4.0.4 | NOK | http://autobuild.buildroot.net/results/779ff42d63d7d192771575e11902b43a0b63274c/
Atomic intrinsics needed.
> bfin | zmqpp-36413487f05b165dfc82a... | NOK | http://autobuild.buildroot.net/results/de0da33dad120f5fd02601d3da68ddbcddd552fb/
Completely weird C++ errors.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-12 9:45 ` Anton Kolesov
@ 2014-09-12 9:50 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-09-12 9:50 UTC (permalink / raw)
To: buildroot
Dear Anton Kolesov,
On Fri, 12 Sep 2014 09:45:26 +0000, Anton Kolesov wrote:
> This issue has been reported to our compiler engineers half a year ago. That
> seems to be a bug in the type definitions in ARC GCC, because GCC expects
> arguments of type "signed size_t", yet it doesn't even allows to declare a
> variable of this type. I've just sent a reminder about this issue to the team.
Ok.
> As a workaround we can submit patch that will add -Wno-error=format to this
> package. Is it ok?
That would be OK, but a better fix would be to change the package to
remove -Werror entirely, or at least make it conditional (in which case
the patch could be proposed upstream).
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-12 8:11 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (2 preceding siblings ...)
2014-09-12 9:01 ` Jörg Krause
@ 2014-09-12 9:45 ` Anton Kolesov
2014-09-12 9:50 ` Thomas Petazzoni
2014-09-20 12:10 ` Bernd Kuhls
4 siblings, 1 reply; 416+ messages in thread
From: Anton Kolesov @ 2014-09-12 9:45 UTC (permalink / raw)
To: buildroot
Hi Thomas,
>
> > arc | libpfm4-4.3.0 | NOK |
> http://autobuild.buildroot.net/results/405da9a945511329929b18740b983c51
> b8dcc43e/
>
> Stupid warning beind treated as an error:
>
> task.c: In function 'read_groups':
> task.c:110:5: error: format '%zd' expects argument of type 'signed size_t', but
> argument 4 has type 'ssize_t' [-Werror=format=]
> evt, new_sz, ret);
> ^
> cc1: all warnings being treated as errors
>
> Anton, since the problem is seen on ARC, maybe you could have a look,
> fix the warning, and try to see if -Werror can be removed?
>
This issue has been reported to our compiler engineers half a year ago. That
seems to be a bug in the type definitions in ARC GCC, because GCC expects
arguments of type "signed size_t", yet it doesn't even allows to declare a
variable of this type. I've just sent a reminder about this issue to the team.
As a workaround we can submit patch that will add -Wno-error=format to this
package. Is it ok?
Anton
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-12 8:11 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-09-12 8:20 ` Nathaniel Roach
2014-09-12 8:53 ` Vicente Olivert Riera
@ 2014-09-12 9:01 ` Jörg Krause
2014-09-12 9:45 ` Anton Kolesov
2014-09-20 12:10 ` Bernd Kuhls
4 siblings, 0 replies; 416+ messages in thread
From: Jörg Krause @ 2014-09-12 9:01 UTC (permalink / raw)
To: buildroot
On 09/12/2014 10:11 AM, Thomas Petazzoni wrote:
> Hello,
>
> Samuel, Anton, Nathaniel, Vicente, Peter, Bernd, please see below.
>
>> bfin | libshairplay-139d5ef5556451... | NOK | http://autobuild.buildroot.net/results/561817d8b3156b537f4bf76eb539658144a6efb4/
>> bfin | libshairplay-139d5ef5556451... | NOK | http://autobuild.buildroot.net/results/5e7bb6c3c1bde627fc8129b734f3f9222c2331e9/
>> bfin | libshairplay-139d5ef5556451... | NOK | http://autobuild.buildroot.net/results/b27466d56518e47d75cc437a962ae3c3a9a2aa3e/
>> bfin | libshairplay-139d5ef5556451... | NOK | http://autobuild.buildroot.net/results/78340ee174029d7a24b5078751b5b53a3547e10e/
> dnssd.c:64:21: error: dns_sd.h: No such file or directory
Same issue:
http://lists.busybox.net/pipermail/buildroot/2014-August/105120.html
No solution provided yet.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-12 8:57 ` Thomas Petazzoni
@ 2014-09-12 9:00 ` Vicente Olivert Riera
0 siblings, 0 replies; 416+ messages in thread
From: Vicente Olivert Riera @ 2014-09-12 9:00 UTC (permalink / raw)
To: buildroot
On 09/12/2014 09:57 AM, Thomas Petazzoni wrote:
> Dear Vicente Olivert Riera,
>
> On Fri, 12 Sep 2014 09:53:40 +0100, Vicente Olivert Riera wrote:
>
>> One of them (sa_restorer) is very close to be fixed upstream. Maybe
>> today? Hopefully.
>>
>> To fix the other one (si_timerid) we need to patch uClibc, but that
>> patch will add some members to a struct, so that woulb be an ABI
>> breakage. We need to talk first to the person in maintaining uClibc for
>> MIPS and see what he thinks about this.
>
> So in the mean time, let's have a patch that disables building strace
> on MIPS with uClibc, no?
>
> Thomas
Yes, I'll do it now.
--
Vincent
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-12 8:53 ` Vicente Olivert Riera
@ 2014-09-12 8:57 ` Thomas Petazzoni
2014-09-12 9:00 ` Vicente Olivert Riera
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-09-12 8:57 UTC (permalink / raw)
To: buildroot
Dear Vicente Olivert Riera,
On Fri, 12 Sep 2014 09:53:40 +0100, Vicente Olivert Riera wrote:
> One of them (sa_restorer) is very close to be fixed upstream. Maybe
> today? Hopefully.
>
> To fix the other one (si_timerid) we need to patch uClibc, but that
> patch will add some members to a struct, so that woulb be an ABI
> breakage. We need to talk first to the person in maintaining uClibc for
> MIPS and see what he thinks about this.
So in the mean time, let's have a patch that disables building strace
on MIPS with uClibc, no?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-12 8:11 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-09-12 8:20 ` Nathaniel Roach
@ 2014-09-12 8:53 ` Vicente Olivert Riera
2014-09-12 8:57 ` Thomas Petazzoni
2014-09-12 9:01 ` Jörg Krause
` (2 subsequent siblings)
4 siblings, 1 reply; 416+ messages in thread
From: Vicente Olivert Riera @ 2014-09-12 8:53 UTC (permalink / raw)
To: buildroot
On 09/12/2014 09:11 AM, Thomas Petazzoni wrote:
>> mips | strace-4.9 | NOK | http://autobuild.buildroot.net/results/04de887fd501e1a1b9f811dacdf17596256097e6/
>> mipsel | strace-4.9 | NOK | http://autobuild.buildroot.net/results/91c0413e755c365332bc15d1d69ab3d6160ae78c/
>
> Vicente, I think you looked into one of the two issues. Can you look at
> the other one, and send the corresponding patches?
One of them (sa_restorer) is very close to be fixed upstream. Maybe
today? Hopefully.
To fix the other one (si_timerid) we need to patch uClibc, but that
patch will add some members to a struct, so that woulb be an ABI
breakage. We need to talk first to the person in maintaining uClibc for
MIPS and see what he thinks about this.
--
Vincent
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-12 8:11 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2014-09-12 8:20 ` Nathaniel Roach
2014-09-12 8:53 ` Vicente Olivert Riera
` (3 subsequent siblings)
4 siblings, 0 replies; 416+ messages in thread
From: Nathaniel Roach @ 2014-09-12 8:20 UTC (permalink / raw)
To: buildroot
On 12/09/14 16:11, Thomas Petazzoni wrote:
> Hello,
>
> Samuel, Anton, Nathaniel, Vicente, Peter, Bernd, please see below.
>
> On Fri, 12 Sep 2014 08:30:12 +0200 (CEST), Thomas Petazzoni wrote:
>
>> x86_64 | bandwidthd-v2.0.1-auto-r08 | NOK | http://autobuild.buildroot.net/results/ed2d4261aef005cd7a567bd01dd8e7c8a96aa2be/
>
> Yet another bandwidthd issue in detecting libpng. Weird.
>
> checking for png_read_info in -lpng... no
> configure: error: Bandwidthd requires but cannot libpng
> make: *** [/home/test/autobuild/instance-2/output/build/bandwidthd-v2.0.1-auto-r08/.stamp_configured] Error 1
> make: Leaving directory `/home/test/autobuild/instance-2/buildroot'
>
This should be fixed by my patch that's in patchwork
(http://patchwork.ozlabs.org/patch/381899/)
The issue is configure can't check for libpng (in some cases) because
it's test fails when lz is not tested for. (Linking the libpng test
build fails due to -lz not being in LDFLAGS)
>> arm | php-yaml-1.1.1 | NOK | http://autobuild.buildroot.net/results/a2d9e701494bdb5b1f3cf0e44b872c3665ac1186/
>
> Yet another download issue. Nathaniel, can you have a look at what the file contains?
>
Weird, that file doesn't exist anymore. Sounds like it was one I missed
before, and then got randomly picked to be removed. I don't believe I
have had any networking interruptions since that initial issue.
> Thanks,
>
> Thomas
>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-12 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-09-11 Thomas Petazzoni
@ 2014-09-12 8:11 ` Thomas Petazzoni
2014-09-12 8:20 ` Nathaniel Roach
` (4 more replies)
0 siblings, 5 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-09-12 8:11 UTC (permalink / raw)
To: buildroot
Hello,
Samuel, Anton, Nathaniel, Vicente, Peter, Bernd, please see below.
On Fri, 12 Sep 2014 08:30:12 +0200 (CEST), Thomas Petazzoni wrote:
> x86_64 | bandwidthd-v2.0.1-auto-r08 | NOK | http://autobuild.buildroot.net/results/ed2d4261aef005cd7a567bd01dd8e7c8a96aa2be/
Yet another bandwidthd issue in detecting libpng. Weird.
checking for png_read_info in -lpng... no
configure: error: Bandwidthd requires but cannot libpng
make: *** [/home/test/autobuild/instance-2/output/build/bandwidthd-v2.0.1-auto-r08/.stamp_configured] Error 1
make: Leaving directory `/home/test/autobuild/instance-2/buildroot'
> bfin | directfb-examples-1.6.0 | NOK | http://autobuild.buildroot.net/results/d887796b7bd54dc167a266cb2dd9ac13722bc51c/
Weird C++ related problem.
> arm | elfutils-0.155 | NOK | http://autobuild.buildroot.net/results/5f33b561e46c8ec263e7cf25d91d9a73a85dfed8/
Static linking issue: -static -shared are used at the same time.
> arm | erlang-17.1 | NOK | http://autobuild.buildroot.net/results/631ec8b719fb8878141a4ad87c1fe84b1297a96b/
> arm | erlang-17.1 | NOK | http://autobuild.buildroot.net/results/1f313aee75328c27e260c55dbf7caa5d3d6a07d3/
> arm | erlang-17.1 | NOK | http://autobuild.buildroot.net/results/2f213d8cf6f828a68a2f36bb95564b8db043e7a2/
Should be fixed by http://patchwork.ozlabs.org/patch/388399/.
> arm | gnupg2-2.0.26 | NOK | http://autobuild.buildroot.net/results/5d66eb9e0976963adf30edd32db6db26b92a8e66/
> i486 | gnupg2-2.0.26 | NOK | http://autobuild.buildroot.net/results/3b14a241da1b4756b082d1aeff79c6bc80f9f04c/
> arm | gnupg2-2.0.26 | NOK | http://autobuild.buildroot.net/results/d379b236b5b7e2476d0ee1537e72e9ca14ecbb8a/
> i486 | gnupg2-2.0.26 | NOK | http://autobuild.buildroot.net/results/7b018d7f44f37b566259465f563e528b7be5b9cb/
The infamous intmax_t issue.
> arm | host-gcc-final-4.8.3 | NOK | http://autobuild.buildroot.net/results/cc62c9ba0e4e03bb2695b66d8d6284bad699802f/
Really weird problem:
/usr/include/sys/types.h:100: error: two or more data types in declaration specifiers
/usr/include/sys/types.h:110: error: two or more data types in declaration specifiers
> mips64el | host-ruby-2.1.2 | TIM | http://autobuild.buildroot.net/results/104c289e79921221b7f625f01cea44998350fed4/
Ignore.
> arm | libinput-0.3.0 | NOK | http://autobuild.buildroot.net/results/9a9572a421db1a5733f96dc47d9b889da0de7dc7/
/home/peko/autobuild/instance-2/output/host/opt/ext-toolchain/bin/../lib/gcc/armv7-ctng-linux-gnueabihf/4.8.3/../../../../armv7-ctng-linux-gnueabihf/bin/ld: attempted static link of dynamic object `/home/peko/autobuild/instance-2/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libudev.so'
collect2: error: ld returned 1 exit status
Strange, because the build is not BR2_PREFER_STATIC_LIB=y.
> arc | libpfm4-4.3.0 | NOK | http://autobuild.buildroot.net/results/405da9a945511329929b18740b983c51b8dcc43e/
Stupid warning beind treated as an error:
task.c: In function 'read_groups':
task.c:110:5: error: format '%zd' expects argument of type 'signed size_t', but argument 4 has type 'ssize_t' [-Werror=format=]
evt, new_sz, ret);
^
cc1: all warnings being treated as errors
Anton, since the problem is seen on ARC, maybe you could have a look,
fix the warning, and try to see if -Werror can be removed?
> bfin | librtlsdr-v0.5.3 | NOK | http://autobuild.buildroot.net/results/27e0b6d00cd0f75d1be7294f4798d5fd422f5f32/
> bfin | librtlsdr-v0.5.3 | NOK | http://autobuild.buildroot.net/results/cb52ed3d34dca6c68669bfcd9b28c6e1a5aca019/
Static linking issue. Samuel, this package is using CMake, could you
have a look?
> bfin | libshairplay-139d5ef5556451... | NOK | http://autobuild.buildroot.net/results/561817d8b3156b537f4bf76eb539658144a6efb4/
> bfin | libshairplay-139d5ef5556451... | NOK | http://autobuild.buildroot.net/results/5e7bb6c3c1bde627fc8129b734f3f9222c2331e9/
> bfin | libshairplay-139d5ef5556451... | NOK | http://autobuild.buildroot.net/results/b27466d56518e47d75cc437a962ae3c3a9a2aa3e/
> bfin | libshairplay-139d5ef5556451... | NOK | http://autobuild.buildroot.net/results/78340ee174029d7a24b5078751b5b53a3547e10e/
dnssd.c:64:21: error: dns_sd.h: No such file or directory
> microblazeel | libsvg-cairo-0.1.6 | NOK | http://autobuild.buildroot.net/results/f66b449228825765146a6098529d7705695a217e/
> mips64el | libsvg-cairo-0.1.6 | NOK | http://autobuild.buildroot.net/results/0b3fb2ee9916aa265df5b6e4f04f6dfa25d1fc84/
> mips64el | libsvg-cairo-0.1.6 | NOK | http://autobuild.buildroot.net/results/b7e490b7d024bdd9ae0ee09fa209aa4dd40b3fd1/
> i686 | libsvg-cairo-0.1.6 | NOK | http://autobuild.buildroot.net/results/df9dfd5ef36f64390bf0f6a6de6ef16f5c01e778/
> i686 | libsvg-cairo-0.1.6 | NOK | http://autobuild.buildroot.net/results/d0fc233bb97c2ea18344746a5b7c63c8de65330a/
> aarch64 | libsvg-cairo-0.1.6 | NOK | http://autobuild.buildroot.net/results/146944da7c5fee565c801c02886eed2bdd48e2d9/
Patch sent at http://patchwork.ozlabs.org/patch/388400/.
> mips | libwebsockets-v1.23-chrome3... | NOK | http://autobuild.buildroot.net/results/34935667d4318863a6166153d78d8f3195763eda/
> powerpc | libwebsockets-v1.23-chrome3... | NOK | http://autobuild.buildroot.net/results/cdc36e0bcff3299b6707375d2882508f50fbe886/
Weird, the tarball was not complete. It's really a tarball, it can
uncompress the beginning, but then it fails. How can this happen with
the super-safe new download infrastructure? Yann? I've kept the bad
tarball around in case an analysis needs to be done.
> mips64el | php-geoip-1.1.0 | NOK | http://autobuild.buildroot.net/results/e0cc0e0b10c721bcaf442203f47d5f7083084c31/
This one is a XHTML document, which says:
<div class="errors">ERROR:<ul><li>DB Error: connect failed</li>
Seems like the upstream download site is a bit crappy.
> arm | php-yaml-1.1.1 | NOK | http://autobuild.buildroot.net/results/a2d9e701494bdb5b1f3cf0e44b872c3665ac1186/
Yet another download issue. Nathaniel, can you have a look at what the file contains?
> arm | ruby-2.1.2 | NOK | http://autobuild.buildroot.net/results/c483e65783d41907042d06b8fabedf15ef415cbc/
loadpath.c:30:2: error: #error RUBY_EXEC_PREFIX must be defined
#error RUBY_EXEC_PREFIX must be defined
Probably a fallout of the ruby bump I did no long ago. I'll try to have
a look.
> mips | strace-4.9 | NOK | http://autobuild.buildroot.net/results/04de887fd501e1a1b9f811dacdf17596256097e6/
> mipsel | strace-4.9 | NOK | http://autobuild.buildroot.net/results/91c0413e755c365332bc15d1d69ab3d6160ae78c/
Vicente, I think you looked into one of the two issues. Can you look at
the other one, and send the corresponding patches?
> x86_64 | tcl-8.6.2 | NOK | http://autobuild.buildroot.net/results/340c62da3e456bd6a5280e7f79d759ab30d5efec/
error: 'SQLITE_RECURSIVE' undeclared (first use in this function)
Incompatibility between tcl and sqlite ?
> bfin | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/dd2345008cf7e14c68f16dfd6bfc34d865b97fa3/
bfin-linux-uclibc-g++: /home/chroot/media/code/buildroot/autobuilder/instance-1/output/host/usr/bfin-buildroot-linux-uclibc/sysroot/opt/uClinux/bfin-linux-uclibc/lib/gcc/bfin-linux-uclibc/4.3.5/libstdc++.so: No such file or directory
> mips64el | tn5250-0.17.4 | NOK | http://autobuild.buildroot.net/results/25276f4224795c2c81c3df0447d0ff5ddb60c283/
checking for CRYPTO_num_locks in -lcrypto... no
configure: error: ** Unable to find OpenSSL libraries!
make: *** [/home/peko/autobuild/instance-0/output/build/tn5250-0.17.4/.stamp_configured] Error 1
make: Leaving directory `/home/peko/autobuild/instance-0/buildroot'
Would be fixed once http://patchwork.ozlabs.org/patch/387696/ is
committed.
> i686 | tstools-1_11 | NOK | http://autobuild.buildroot.net/results/5f430a8e210240d27d19abc626f6be6743a8b6b4/
esfilter.c:1145:1: fatal error: error writing to -: Broken pipe
compilation terminated.
make[1]: *** [obj/esfilter.o] Error 1
Don't know. Peter?
> arm | vlc-2.1.5 | NOK | http://autobuild.buildroot.net/results/7102921b0a8d3a09bf7b3f5f18e56dab6ef36402/
-L/usr/lib used, bad!
/home/peko/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.3/../../../../arm-none-linux-gnueabi/bin/ld: warning: library search path "/usr/lib" is unsafe for cross-compilation
/usr/lib/librt.so: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
Bernd, maybe?
> arm | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/b81759d9645bf653c4fb4b79ad39377a7e377083/
The new webkit issue... We should work on merging Hadrien's bump of
webkit, but it is causing another issue with make 3.82 :-(
> microblazeel | xapp_xfs-1.1.4 | NOK | http://autobuild.buildroot.net/results/c36eeeb7a410b00a5d0cf79e783f3237b9720d77/
In file included from ./include/misc.h:72:0,
from os/xfstrans.c:33:
./include/os.h:103:13: warning: redundant redeclaration of 'ErrorF' [-Wredundant-decls]
extern void ErrorF(const char * f, ...) _X_ATTRIBUTE_PRINTF(1, 2);
^
In file included from /home/test/autobuild/instance-0/output/host/usr/microblazeel-buildroot-linux-gnu/sysroot/usr/include/X11/Xtrans/transport.c:55:0,
from os/xfstrans.c:29:
/home/test/autobuild/instance-0/output/host/usr/microblazeel-buildroot-linux-gnu/sysroot/usr/include/X11/Xtrans/Xtransint.h:424:1: note: previous definition of 'ErrorF' was here
ErrorF(const char *f, ...)
^
os/xfstrans.c: In function '_FontTransGetInetdListenInfo':
os/xfstrans.c:38:18: warning: initialization discards 'const' qualifier from pointer target type
char *port = "0";
^
Bernd, maybe?
> powerpc | xserver_xorg-server-1.16.0 | TIM | http://autobuild.buildroot.net/results/01fb76df24ded1e32ea3e524b39e43b12ab6a1f3/
Ignore.
> bfin | zeromq-4.0.4 | NOK | http://autobuild.buildroot.net/results/5204f6c2f965f945403ae88203ea7c9cd5a5cef3/
> bfin | zeromq-4.0.4 | NOK | http://autobuild.buildroot.net/results/aca005531eb70f171888fe9cda9690a6f1ec1f21/
Atomic instructions issue.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-08 12:59 ` Vicente Olivert Riera
@ 2014-09-08 13:18 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-09-08 13:18 UTC (permalink / raw)
To: buildroot
Dear Vicente Olivert Riera,
On Mon, 8 Sep 2014 13:59:11 +0100, Vicente Olivert Riera wrote:
> Those were my first days with Buildroot. Less than two weeks I guess.
No problem with that at all.
> Well, I think we should remove the dependence on
> BR2_PACKAGE_QT_ARCH_SUPPORTS_WEBKIT in both grantlee and qt_script
> packages. I made a confusion because qt_webkit was failing due to it's
> JavaScriptCore part. That's not related to the Qt's script modue, so
> qt_script (and the packages depending on qt_script) shouldn't depend on
> BR2_PACKAGE_QT_ARCH_SUPPORTS_WEBKIT.
>
> Does this make sense to you?
I think we need to understand whether the set of architectures
supported by QtScript is the same or not as the set of architectures
supported by QtWebkit, and if not, see if one set is a superset of the
other or not.
If QtScript and QtWebkit don't support the same set of architectures,
then we indeed need separate BR2_PACKAGE_QT_ARCH_SUPPORTS_SCRIPT and
BR2_PACKAGE_QT_ARCH_SUPPORTS_WEBKIT options. And if there is an
interaction between the two sets, then maybe
BR2_PACKAGE_QT_ARCH_SUPPORTS_WEBKIT can be defined as
BR2_PACKAGE_QT_ARCH_SUPPORTS_SCRIPT with some additional exceptions,
for example. Like (fictional code) :
config BR2_PACKAGE_QT_ARCH_SUPPORTS_SCRIPT
default y if BR2_arm || BR2_powerpc || BR2_mips || ...
config BR2_PACKAGE_QT_ARCH_SUPPORTS_WEBKIT
default y if BR2_PACKAGE_QT_ARCH_SUPPORTS_SCRIPT && !BR2_mipsn32
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-08 12:29 ` Thomas Petazzoni
@ 2014-09-08 12:59 ` Vicente Olivert Riera
2014-09-08 13:18 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Vicente Olivert Riera @ 2014-09-08 12:59 UTC (permalink / raw)
To: buildroot
On 09/08/2014 01:29 PM, Thomas Petazzoni wrote:
> Dear Vicente Olivert Riera,
>
> On Mon, 8 Sep 2014 13:20:56 +0100, Vicente Olivert Riera wrote:
>
>> One could think we should add that dependence to the
>> BR2_PACKAGE_QT_ARCH_SUPPORTS_WEBKIT symbols instead, but there are
>> packages depending on that symbol which compile fine on MIPS64 n32, for
>> instance grantlee.
>
> That doesn't make sense. More precisely, it's your commit
> a88dceb951de977ad2d896d697f87d98e9705280 that doesn't make sense.
> You're adding a "depends on BR2_PACKAGE_QT_ARCH_SUPPORTS_WEBKIT" to
> grantlee because grantlee has "select BR2_PACKAGE_QT_SCRIPT".
>
> The reason why your commit doesn't make sense appears clearly now: the
> set of architectures that have support for QtScript and QtWebkit is not
> the same. So, if QtScript is restricted to certain architectures,
> please introduce a BR2_PACKAGE_QT_ARCH_SUPPORTS_SCRIPT separate from
> BR2_PACKAGE_QT_ARCH_SUPPORTS_WEBKIT, and use them appropriately.
>
> Thomas
Those were my first days with Buildroot. Less than two weeks I guess.
Well, I think we should remove the dependence on
BR2_PACKAGE_QT_ARCH_SUPPORTS_WEBKIT in both grantlee and qt_script
packages. I made a confusion because qt_webkit was failing due to it's
JavaScriptCore part. That's not related to the Qt's script modue, so
qt_script (and the packages depending on qt_script) shouldn't depend on
BR2_PACKAGE_QT_ARCH_SUPPORTS_WEBKIT.
Does this make sense to you?
--
Vincent
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-08 12:20 ` Vicente Olivert Riera
@ 2014-09-08 12:29 ` Thomas Petazzoni
2014-09-08 12:59 ` Vicente Olivert Riera
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-09-08 12:29 UTC (permalink / raw)
To: buildroot
Dear Vicente Olivert Riera,
On Mon, 8 Sep 2014 13:20:56 +0100, Vicente Olivert Riera wrote:
> One could think we should add that dependence to the
> BR2_PACKAGE_QT_ARCH_SUPPORTS_WEBKIT symbols instead, but there are
> packages depending on that symbol which compile fine on MIPS64 n32, for
> instance grantlee.
That doesn't make sense. More precisely, it's your commit
a88dceb951de977ad2d896d697f87d98e9705280 that doesn't make sense.
You're adding a "depends on BR2_PACKAGE_QT_ARCH_SUPPORTS_WEBKIT" to
grantlee because grantlee has "select BR2_PACKAGE_QT_SCRIPT".
The reason why your commit doesn't make sense appears clearly now: the
set of architectures that have support for QtScript and QtWebkit is not
the same. So, if QtScript is restricted to certain architectures,
please introduce a BR2_PACKAGE_QT_ARCH_SUPPORTS_SCRIPT separate from
BR2_PACKAGE_QT_ARCH_SUPPORTS_WEBKIT, and use them appropriately.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-08 9:17 ` Thomas Petazzoni
@ 2014-09-08 12:20 ` Vicente Olivert Riera
2014-09-08 12:29 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Vicente Olivert Riera @ 2014-09-08 12:20 UTC (permalink / raw)
To: buildroot
On 09/08/2014 10:17 AM, Thomas Petazzoni wrote:
> Dear Vicente Olivert Riera,
>
> On Mon, 8 Sep 2014 09:37:47 +0100, Vicente Olivert Riera wrote:
>
>> Well, more build logs related to this issue are useless because it's
>> being handled upstream, so, yes, maybe we should disable it for MIPS64
>> n32 until this problem gets fixed.
>
> Well, the issue has been reported upstream in May 2014 according to
> what you said, and upstream did react much since then. With Qt5 being
> out since quite some time now, I fear that upstream may simply never
> fix the bug for Qt4. Which indeed is another reason to disable Qt4 on
> MIPS64 n32.
>
> Thomas
Here is the patch to disable qt4 webkit for MIPS64 n32:
http://patchwork.ozlabs.org/patch/386910/
One could think we should add that dependence to the
BR2_PACKAGE_QT_ARCH_SUPPORTS_WEBKIT symbols instead, but there are
packages depending on that symbol which compile fine on MIPS64 n32, for
instance grantlee.
--
Vincent
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-08 8:37 ` Vicente Olivert Riera
@ 2014-09-08 9:17 ` Thomas Petazzoni
2014-09-08 12:20 ` Vicente Olivert Riera
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-09-08 9:17 UTC (permalink / raw)
To: buildroot
Dear Vicente Olivert Riera,
On Mon, 8 Sep 2014 09:37:47 +0100, Vicente Olivert Riera wrote:
> Well, more build logs related to this issue are useless because it's
> being handled upstream, so, yes, maybe we should disable it for MIPS64
> n32 until this problem gets fixed.
Well, the issue has been reported upstream in May 2014 according to
what you said, and upstream did react much since then. With Qt5 being
out since quite some time now, I fear that upstream may simply never
fix the bug for Qt4. Which indeed is another reason to disable Qt4 on
MIPS64 n32.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-08 8:34 ` Thomas Petazzoni
@ 2014-09-08 8:37 ` Vicente Olivert Riera
2014-09-08 9:17 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Vicente Olivert Riera @ 2014-09-08 8:37 UTC (permalink / raw)
To: buildroot
On 09/08/2014 09:34 AM, Thomas Petazzoni wrote:
> Dear Vicente Olivert Riera,
>
> On Mon, 8 Sep 2014 09:32:36 +0100, Vicente Olivert Riera wrote:
>> On 09/07/2014 09:09 AM, Thomas Petazzoni wrote:
>>>> mips64el | qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/2ab5ab179dab9e1a47092b066f97d48c75ab935b/
>>>
>>> Lots of crazy errors. Vicente?
>>
>> I reported this upstream on 23-May-2014.
>>
>> https://bugreports.qt-project.org/browse/QTBUG-39224
>
> So maybe we should simply disable the selection of QtWebkit in Qt4 for
> MIPS64 n32 ?
>
> Thomas
Well, more build logs related to this issue are useless because it's
being handled upstream, so, yes, maybe we should disable it for MIPS64
n32 until this problem gets fixed.
--
Vincent
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-08 8:32 ` Vicente Olivert Riera
@ 2014-09-08 8:34 ` Thomas Petazzoni
2014-09-08 8:37 ` Vicente Olivert Riera
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-09-08 8:34 UTC (permalink / raw)
To: buildroot
Dear Vicente Olivert Riera,
On Mon, 8 Sep 2014 09:32:36 +0100, Vicente Olivert Riera wrote:
> On 09/07/2014 09:09 AM, Thomas Petazzoni wrote:
> >> mips64el | qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/2ab5ab179dab9e1a47092b066f97d48c75ab935b/
> >
> > Lots of crazy errors. Vicente?
>
> I reported this upstream on 23-May-2014.
>
> https://bugreports.qt-project.org/browse/QTBUG-39224
So maybe we should simply disable the selection of QtWebkit in Qt4 for
MIPS64 n32 ?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-07 8:09 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-09-07 12:56 ` Gustavo Zacarias
@ 2014-09-08 8:32 ` Vicente Olivert Riera
2014-09-08 8:34 ` Thomas Petazzoni
1 sibling, 1 reply; 416+ messages in thread
From: Vicente Olivert Riera @ 2014-09-08 8:32 UTC (permalink / raw)
To: buildroot
On 09/07/2014 09:09 AM, Thomas Petazzoni wrote:
>> mips64el | qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/2ab5ab179dab9e1a47092b066f97d48c75ab935b/
>
> Lots of crazy errors. Vicente?
I reported this upstream on 23-May-2014.
https://bugreports.qt-project.org/browse/QTBUG-39224
--
Vincent
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-07 15:44 ` Yann E. MORIN
@ 2014-09-07 18:18 ` Peter Korsgaard
0 siblings, 0 replies; 416+ messages in thread
From: Peter Korsgaard @ 2014-09-07 18:18 UTC (permalink / raw)
To: buildroot
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
Hi,
>> Just my two cents:
>>
>> For anything that requires user interaction like xconfig for menuconfig
>> (for buildroot or the kernel for example), use the host's libraries -
>> They are likely to have them installed and it will be quicker if I want
>> to change a config option. Also, none of the config binaries will be
>> copied to the target.
>>
>> For any package that depends on ncurses to build, build host-ncurses -
>> This provides isolation against any changes between distributions and
>> ensures that we have control over versions.
> I totally agree on those two points.
Yeah, sounds sensible.
Should we document this somewhere in the manual?
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-07 15:34 ` Nathaniel Roach
@ 2014-09-07 15:44 ` Yann E. MORIN
2014-09-07 18:18 ` Peter Korsgaard
0 siblings, 1 reply; 416+ messages in thread
From: Yann E. MORIN @ 2014-09-07 15:44 UTC (permalink / raw)
To: buildroot
Nathaniel, All,
On 2014-09-07 23:34 +0800, Nathaniel Roach spake thusly:
> On 07/09/14 20:17, Thomas De Schampheleire wrote:
> > On Sun, Sep 7, 2014 at 9:21 AM, Thomas Petazzoni
> > <thomas.petazzoni@free-electrons.com> wrote:
> >> Hello,
> >>
> >> On Sat, 06 Sep 2014 22:25:33 +0200, Peter Korsgaard wrote:
> >>
> >>> > Seems like Nathaniel autobuilder does not have the ncurses development
> >>> > libraries installed (also causing build failures in host-mysql, for
> >>> > example). What is our policy regarding ncurses? I have it installed in
> >>> > my autobuilder because I use it to run "make menuconfig". But it's true
> >>> > it's not technically absolutely required to run a Buildroot build.
> >>>
> >>> > Should we add dependency on host-ncurses where appropriate? Or should
> >>> > we make ncurses development files on the build machine a mandatory
> >>> > dependency? What if the user uses only xconfig or gconfig?
> >>>
> >>> Given how many people use menuconfig, I think we should just make
> >>> ncurses a mandatory dependency. Just about anybody doing embedded Linux
> >>> development needs them anyway to configure
> >>> barebox/linux/busybox/uclibc/ctng/..
> >>>
> >>> If not, then we would also need to add host-ncurses to our
> >>> barebox/linux/busybox/uclibc-menuconfig targets.
> >>
> >> Well not sure we want to go down this road: it would mean we should add
> >> host-qt as a dependency of the linux-xconfig target for example. We
> >> could also decide that the *-menuconfig targets need to have curses-dev
> >> installed on the build machine, but that the package that we build and
> >> that need host-curses will depend on host-curses.
> >>
> >> But well, menuconfig is indeed widely used, so maybe the easiest
> >> solution would be to make ncurses-dev a mandatory dependency.
> >>
> >
> > An alternative is to use the suitable-host-package mechanism in such
> > cases: if the host does have ncurses (but the same could be done for
> > autoconf, automake, flex, bison, and other host packages) then build
> > it inside buildroot. If it does, then just use them directly.
> > Since the build of host-ncurses does take some time, it may be
> > advantageous for the user to install ncurses on the host anyway, to
> > avoid long build times, so a notice at the end of the build process to
> > suggest that could be useful.
> >
> > Best regards,
> > Thomas
> > _______________________________________________
> > buildroot mailing list
> > buildroot at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot
> >
>
>
> Just my two cents:
>
> For anything that requires user interaction like xconfig for menuconfig
> (for buildroot or the kernel for example), use the host's libraries -
> They are likely to have them installed and it will be quicker if I want
> to change a config option. Also, none of the config binaries will be
> copied to the target.
>
> For any package that depends on ncurses to build, build host-ncurses -
> This provides isolation against any changes between distributions and
> ensures that we have control over versions.
I totally agree on those two points.
> Additionally, if the build time dependencies of BR are kept to a
> minimum, it may be beneficial some situations where the user may not
> have control of the building system - I doubt anyone actually uses BR in
> this situation, but it's possible. I can see a situation where the user
> configures BR on their laptop, and pushes the config to a more powerful
> shared system to build it.
Yes, exactly what I am doing. Well, was doing until that big machine
finally completely died a few months ago.
I edit on my laptop (since that's the only machine I always have with
me) and can build on it. But for biggish builds, I rsync my development
directory to my build server (fast, because Gibps LAN, and plugged into
the same switch.) Then I ssh into the build machine to run the build.
Of course, all that nicely bundled in an automation script. :-)
> Finally, I'm not fond of the suitable-host-package approach Thomas has
> mentioned: while again, I doubt the probability of such a case
> happening, things like distro-specific patches or behavior may change
> builds. (For example, my router firmware segfaults during build on
> Ubuntu but not on Debian)
Yup. I like your proposal.
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] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-07 12:17 ` Thomas De Schampheleire
2014-09-07 12:26 ` Thomas Petazzoni
@ 2014-09-07 15:34 ` Nathaniel Roach
2014-09-07 15:44 ` Yann E. MORIN
1 sibling, 1 reply; 416+ messages in thread
From: Nathaniel Roach @ 2014-09-07 15:34 UTC (permalink / raw)
To: buildroot
On 07/09/14 20:17, Thomas De Schampheleire wrote:
> On Sun, Sep 7, 2014 at 9:21 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Hello,
>>
>> On Sat, 06 Sep 2014 22:25:33 +0200, Peter Korsgaard wrote:
>>
>>> > Seems like Nathaniel autobuilder does not have the ncurses development
>>> > libraries installed (also causing build failures in host-mysql, for
>>> > example). What is our policy regarding ncurses? I have it installed in
>>> > my autobuilder because I use it to run "make menuconfig". But it's true
>>> > it's not technically absolutely required to run a Buildroot build.
>>>
>>> > Should we add dependency on host-ncurses where appropriate? Or should
>>> > we make ncurses development files on the build machine a mandatory
>>> > dependency? What if the user uses only xconfig or gconfig?
>>>
>>> Given how many people use menuconfig, I think we should just make
>>> ncurses a mandatory dependency. Just about anybody doing embedded Linux
>>> development needs them anyway to configure
>>> barebox/linux/busybox/uclibc/ctng/..
>>>
>>> If not, then we would also need to add host-ncurses to our
>>> barebox/linux/busybox/uclibc-menuconfig targets.
>>
>> Well not sure we want to go down this road: it would mean we should add
>> host-qt as a dependency of the linux-xconfig target for example. We
>> could also decide that the *-menuconfig targets need to have curses-dev
>> installed on the build machine, but that the package that we build and
>> that need host-curses will depend on host-curses.
>>
>> But well, menuconfig is indeed widely used, so maybe the easiest
>> solution would be to make ncurses-dev a mandatory dependency.
>>
>
> An alternative is to use the suitable-host-package mechanism in such
> cases: if the host does have ncurses (but the same could be done for
> autoconf, automake, flex, bison, and other host packages) then build
> it inside buildroot. If it does, then just use them directly.
> Since the build of host-ncurses does take some time, it may be
> advantageous for the user to install ncurses on the host anyway, to
> avoid long build times, so a notice at the end of the build process to
> suggest that could be useful.
>
> Best regards,
> Thomas
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
Just my two cents:
For anything that requires user interaction like xconfig for menuconfig
(for buildroot or the kernel for example), use the host's libraries -
They are likely to have them installed and it will be quicker if I want
to change a config option. Also, none of the config binaries will be
copied to the target.
For any package that depends on ncurses to build, build host-ncurses -
This provides isolation against any changes between distributions and
ensures that we have control over versions.
Additionally, if the build time dependencies of BR are kept to a
minimum, it may be beneficial some situations where the user may not
have control of the building system - I doubt anyone actually uses BR in
this situation, but it's possible. I can see a situation where the user
configures BR on their laptop, and pushes the config to a more powerful
shared system to build it.
Finally, I'm not fond of the suitable-host-package approach Thomas has
mentioned: while again, I doubt the probability of such a case
happening, things like distro-specific patches or behavior may change
builds. (For example, my router firmware segfaults during build on
Ubuntu but not on Debian)
Thanks, Nathaniel
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-07 13:06 ` Thomas Petazzoni
@ 2014-09-07 13:07 ` Gustavo Zacarias
0 siblings, 0 replies; 416+ messages in thread
From: Gustavo Zacarias @ 2014-09-07 13:07 UTC (permalink / raw)
To: buildroot
On 09/07/2014 10:06 AM, Thomas Petazzoni wrote:
>> Outdated uclibc ptrace.h header, sparc is also affected by this however
>> since there's no autobuilder for that target it's going unnoticed.
>> glibc has the necessary definitions, so a uclibc header update is in order.
>
> We already have
> package/uclibc/0.9.33.2/uclibc-0020-update-ptrace.h-to-latest-from-glibc.patch
> but I guess it doesn't handle those definitions.
That updated common, but powerpc, sparc, microblaze and some other dead
architectures have their own (same on *glibc).
> Like ac_cv_header_sys_ptrace_h=no ?
Probably, i'm running a test build at the moment and submit a patch shortly.
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-07 12:56 ` Gustavo Zacarias
@ 2014-09-07 13:06 ` Thomas Petazzoni
2014-09-07 13:07 ` Gustavo Zacarias
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-09-07 13:06 UTC (permalink / raw)
To: buildroot
Dear Gustavo Zacarias,
On Sun, 07 Sep 2014 09:56:23 -0300, Gustavo Zacarias wrote:
> Outdated uclibc ptrace.h header, sparc is also affected by this however
> since there's no autobuilder for that target it's going unnoticed.
> glibc has the necessary definitions, so a uclibc header update is in order.
We already have
package/uclibc/0.9.33.2/uclibc-0020-update-ptrace.h-to-latest-from-glibc.patch
but I guess it doesn't handle those definitions.
> We can exclude ptrace for powerpc & sparc in the meantime.
Like ac_cv_header_sys_ptrace_h=no ?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-07 8:09 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2014-09-07 12:56 ` Gustavo Zacarias
2014-09-07 13:06 ` Thomas Petazzoni
2014-09-08 8:32 ` Vicente Olivert Riera
1 sibling, 1 reply; 416+ messages in thread
From: Gustavo Zacarias @ 2014-09-07 12:56 UTC (permalink / raw)
To: buildroot
On 09/07/2014 05:09 AM, Thomas Petazzoni wrote:
>> powerpc | enlightenment-0.17.3 | NOK | http://autobuild.buildroot.net/results/a7f95353f5592a9399c542d8d56c3ca040f8a61a/
>
> e_start_main.c:478:42: error: 'PT_GETSIGINFO' undeclared (first use in this function)
> r = ptrace(PT_GETSIGINFO, child, NULL, &sig);
>
> Gustavo, maybe?
Hi.
Outdated uclibc ptrace.h header, sparc is also affected by this however
since there's no autobuilder for that target it's going unnoticed.
glibc has the necessary definitions, so a uclibc header update is in order.
We can exclude ptrace for powerpc & sparc in the meantime.
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-07 12:17 ` Thomas De Schampheleire
@ 2014-09-07 12:26 ` Thomas Petazzoni
2014-09-07 15:34 ` Nathaniel Roach
1 sibling, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-09-07 12:26 UTC (permalink / raw)
To: buildroot
Dear Thomas De Schampheleire,
On Sun, 7 Sep 2014 14:17:21 +0200, Thomas De Schampheleire wrote:
> An alternative is to use the suitable-host-package mechanism in such
> cases: if the host does have ncurses (but the same could be done for
> autoconf, automake, flex, bison, and other host packages) then build
> it inside buildroot. If it does, then just use them directly.
> Since the build of host-ncurses does take some time, it may be
> advantageous for the user to install ncurses on the host anyway, to
> avoid long build times, so a notice at the end of the build process to
> suggest that could be useful.
That's one option indeed, but I must say I don't like it that much. It
means that from one user to the other, the build behavior will be
different, not really a great thing.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-07 7:21 ` Thomas Petazzoni
@ 2014-09-07 12:17 ` Thomas De Schampheleire
2014-09-07 12:26 ` Thomas Petazzoni
2014-09-07 15:34 ` Nathaniel Roach
0 siblings, 2 replies; 416+ messages in thread
From: Thomas De Schampheleire @ 2014-09-07 12:17 UTC (permalink / raw)
To: buildroot
On Sun, Sep 7, 2014 at 9:21 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Sat, 06 Sep 2014 22:25:33 +0200, Peter Korsgaard wrote:
>
>> > Seems like Nathaniel autobuilder does not have the ncurses development
>> > libraries installed (also causing build failures in host-mysql, for
>> > example). What is our policy regarding ncurses? I have it installed in
>> > my autobuilder because I use it to run "make menuconfig". But it's true
>> > it's not technically absolutely required to run a Buildroot build.
>>
>> > Should we add dependency on host-ncurses where appropriate? Or should
>> > we make ncurses development files on the build machine a mandatory
>> > dependency? What if the user uses only xconfig or gconfig?
>>
>> Given how many people use menuconfig, I think we should just make
>> ncurses a mandatory dependency. Just about anybody doing embedded Linux
>> development needs them anyway to configure
>> barebox/linux/busybox/uclibc/ctng/..
>>
>> If not, then we would also need to add host-ncurses to our
>> barebox/linux/busybox/uclibc-menuconfig targets.
>
> Well not sure we want to go down this road: it would mean we should add
> host-qt as a dependency of the linux-xconfig target for example. We
> could also decide that the *-menuconfig targets need to have curses-dev
> installed on the build machine, but that the package that we build and
> that need host-curses will depend on host-curses.
>
> But well, menuconfig is indeed widely used, so maybe the easiest
> solution would be to make ncurses-dev a mandatory dependency.
>
An alternative is to use the suitable-host-package mechanism in such
cases: if the host does have ncurses (but the same could be done for
autoconf, automake, flex, bison, and other host packages) then build
it inside buildroot. If it does, then just use them directly.
Since the build of host-ncurses does take some time, it may be
advantageous for the user to install ncurses on the host anyway, to
avoid long build times, so a notice at the end of the build process to
suggest that could be useful.
Best regards,
Thomas
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-07 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-09-06 Thomas Petazzoni
@ 2014-09-07 8:09 ` Thomas Petazzoni
2014-09-07 12:56 ` Gustavo Zacarias
2014-09-08 8:32 ` Vicente Olivert Riera
0 siblings, 2 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-09-07 8:09 UTC (permalink / raw)
To: buildroot
Hello,
On Sun, 7 Sep 2014 08:30:12 +0200 (CEST), Thomas Petazzoni wrote:
> Build statistics for 2014-09-06
> ===============================
>
> success : 144
> failures : 37
> timeouts : 0
> TOTAL : 181
That's really great: we now build about 180-200 configurations each
day. Definitely a really good thing! With Peter moving to the
autobuild-run script, maybe he'll be able to run multiple instances of
the build logic on each machine, which would allow to build even more
configurations each day.
> Detail of failures
> ===================
>
> i486 | alsa-lib-1.0.28 | NOK | http://autobuild.buildroot.net/results/ca098ae672956cf50d808fcff83bf4956bf4e31d/
vfork() issue, being fixed.
> arm | boost-1.56.0 | NOK | http://autobuild.buildroot.net/results/5aeb3a9f067faf6687051643bf49a0b619cb4c3b/
> arm | boost-1.56.0 | NOK | http://autobuild.buildroot.net/results/c8be1d63dbc4143955c665a090f0606f20d75127/
> arm | boost-1.56.0 | NOK | http://autobuild.buildroot.net/results/ffbc880af29a0308bef4964bdc6b01b4604d7f56/
> arm | boost-1.56.0 | NOK | http://autobuild.buildroot.net/results/c79533249d3eb08e6c46579b8da8a315305c058c/
Fixed.
> arc | busybox-1.22.1 | NOK | http://autobuild.buildroot.net/results/fe75ffe3734dae9190259b06ef2debed9fadc3d3/
Atomic intrinsic issue. To be fixed.
> powerpc | cppcms-1.0.4 | NOK | http://autobuild.buildroot.net/results/2be62c58fbed40eed8fc8e8453336190cb1083d1/
Fixed.
> nios2 | czmq-v2.2.0 | NOK | http://autobuild.buildroot.net/results/a87e5bd299a1dcfbd5fdc0232736c779b938c7fe/
> nios2 | czmq-v2.2.0 | NOK | http://autobuild.buildroot.net/results/4853f7fa4ebfaa3f778c3f36fdcdd9a03e77dfca/
error: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Werror=cpp]
Maybe we should turn warning into warnings :)
> bfin | directfb-examples-1.6.0 | NOK | http://autobuild.buildroot.net/results/9e3b165543f69edcd2ea99e03a3da8c5d42c52ba/
Crazy C++ issue.
> powerpc | enlightenment-0.17.3 | NOK | http://autobuild.buildroot.net/results/a7f95353f5592a9399c542d8d56c3ca040f8a61a/
e_start_main.c:478:42: error: 'PT_GETSIGINFO' undeclared (first use in this function)
r = ptrace(PT_GETSIGINFO, child, NULL, &sig);
Gustavo, maybe?
> microblazeel | ftop-1.0 | NOK | http://autobuild.buildroot.net/results/e9d55202ebbd7595bde48e2a471fbf33c85a239b/
> x86_64 | ftop-1.0 | NOK | http://autobuild.buildroot.net/results/c93f0e8f10e4e905276ce5a9eb96cdebb4294d8d/
> mips64el | ftop-1.0 | NOK | http://autobuild.buildroot.net/results/517175ba8df3a3c354c2a21413b438cc73c9dc64/
Download issues, ignore.
> arm | gnupg2-2.0.26 | NOK | http://autobuild.buildroot.net/results/fcfde09a8c0121192dc550c72d55b1dd277ec6bc/
> i486 | gnupg2-2.0.26 | NOK | http://autobuild.buildroot.net/results/ebee75bfb89f6b8cdd2bf555ad947e36057dbf0e/
intmax_t issue.
> sh4a | host-mysql-5.1.73 | NOK | http://autobuild.buildroot.net/results/a6d967056de06bd07dc69f4fc1ec9b0f1e1d3927/
ncurses not available on Nathaniel's build machine. Discussion on-going
on whether we should make ncurses-dev a mandatory dependency of
Buildroot, or add the appropriate host-ncurses dependencies.
> arm | host-nodejs-0.10.31 | NOK | http://autobuild.buildroot.net/results/ea4703de4285f557b52921f13f44f0d0ee6ddb2c/
> arm | host-nodejs-0.10.31 | NOK | http://autobuild.buildroot.net/results/91ed7072347b980129b56c8ba291a87d078814c7/
> arm | host-nodejs-0.10.31 | NOK | http://autobuild.buildroot.net/results/0240160f9ebfa35d3f5b5b0d64814a521bd9bec4/
> arm | host-nodejs-0.10.31 | NOK | http://autobuild.buildroot.net/results/99dbab7726f362b2a5a9c840426abea80340567b/
> i686 | host-nodejs-0.10.31 | NOK | http://autobuild.buildroot.net/results/4899f4e6d0ad58fe5bd5e46a311179f08c6a5b2a/
> x86_64 | host-nodejs-0.10.31 | NOK | http://autobuild.buildroot.net/results/802134ceb92d82d2d4ef6a81c67ad1c98696663a/
Fixed.
> arm | host-ruby-2.1.2 | NOK | http://autobuild.buildroot.net/results/a01c5f90e9dd8c5134a326db6ba9db3a7b5e6d91/
Fixed.
> arc | host-texinfo-4.13a | NOK | http://autobuild.buildroot.net/results/24e94a6cea3d79ac3dab6c0baca615ddaeb9e04a/
> arc | host-texinfo-4.13a | NOK | http://autobuild.buildroot.net/results/0f96c0f86f9fb733b531dcd5ed98e29a9bad3745/
Same ncurses issue on Nathaniel's autobuilder.
> powerpc | jq-1.4 | NOK | http://autobuild.buildroot.net/results/8422492ff88761d81e54172a5ec6950e8ff847ce/
> powerpc | jq-1.4 | NOK | http://autobuild.buildroot.net/results/5d3611f42f879947083635eeec705841da04b83f/
./.libs/libjq.a(builtin.o): In function `f_y1':
builtin.c:(.text+0x2b2c): undefined reference to `y1'
./.libs/libjq.a(builtin.o): In function `f_y0':
builtin.c:(.text+0x2be0): undefined reference to `y0'
./.libs/libjq.a(builtin.o): In function `f_j1':
builtin.c:(.text+0x31a4): undefined reference to `j1'
./.libs/libjq.a(builtin.o): In function `f_j0':
builtin.c:(.text+0x3258): undefined reference to `j0'
collect2: error: ld returned 1 exit status
> bfin | libmatroska-1.3.0 | NOK | http://autobuild.buildroot.net/results/12e752330b30adb5078acd72a548cc172fa9ecb8/
Fixed.
> mipsel | libnspr-4.10.6 | NOK | http://autobuild.buildroot.net/results/7e06a73a31069faba96658ab7f0181018c4a0a8e/
/home/test/autobuild/instance-2/output/host/opt/ext-toolchain/bin/../lib/gcc/mipsel-ctng-linux-uclibc/4.8.2/../../../../mipsel-ctng-linux-uclibc/bin/ld: /home/test/autobuild/instance-2/output/host/opt/ext-toolchain/bin/../lib/gcc/mipsel-ctng-linux-uclibc/4.8.2/crtbeginT.o: relocation R_MIPS_HI16 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/home/test/autobuild/instance-2/output/host/opt/ext-toolchain/bin/../lib/gcc/mipsel-ctng-linux-uclibc/4.8.2/crtbeginT.o: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make[4]: *** [libnspr4.so] Error 1
make[4]: Leaving directory `/home/test/autobuild/instance-2/out
fPIC issue apparently. Vicente, maybe?
> x86_64 | perl-net-ssleay-1.65 | NOK | http://autobuild.buildroot.net/results/42153224cc0edd1a4976e8d1237f01feaed6ab2c/
host-perl problem.
> mips64el | python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/357ab3aef1a1989e42a9ea4cc3b605bcb827b606/
error: 'SYS_getdents64' undeclared (first use in this function)
Too old toolchain to build Python3 on MIPS64. I need to blacklist this toolchain.
> mips64el | qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/2ab5ab179dab9e1a47092b066f97d48c75ab935b/
Lots of crazy errors. Vicente?
> sh4 | slang-2.2.4 | NOK | http://autobuild.buildroot.net/results/5bab4c127047275a640c1d55ed54316e960e5af0/
Another ncurses issue on Nathaniel's chroot.
> nios2 | upmpdcli-0.8.0 | NOK | http://autobuild.buildroot.net/results/a193527b34c7b8c458904a7f1b5f88d236bd8261/
checking for UpnpInit in -lupnp... no
configure: error: libupnp not found
make: *** [/home/buildroot/instance-0/output/build/upmpdcli-0.8.0/.stamp_configured] Error 1
make: Leaving directory `/home/buildroot/instance-0/buildroot'
> arm | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/31ac17cc64328bbb6531a45b071c1d0429520e2d/
> x86_64 | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/da11f76cacfd05999700c38d40628b526622ff6d/
Don't know what changed in webkit to cause this build failure:
GEN stamp-webkitmarshal.cpp
/bin/bash: ./DerivedSources/webkit/webkitmarshal.cpp: No such file or directory
GEN DerivedSources/webkit/webkitenumtypes.cpp
GEN stamp-webkitenumtypes.h
GEN stamp-webkitmarshal.h
GEN DerivedSources/WebCore/InternalSettingsGenerated.idl
/bin/bash: ./DerivedSources/webkit/webkitmarshal.h: No such file or directory
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-07 3:49 ` Nathaniel Roach
@ 2014-09-07 7:41 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-09-07 7:41 UTC (permalink / raw)
To: buildroot
Dear Nathaniel Roach,
On Sun, 07 Sep 2014 11:49:18 +0800, Nathaniel Roach wrote:
> I don't have it installed purely because this chroot is *just* for the
> autobuilder.
>
> I'm leaning towards host-ncurses because it seems to be the cleaner way
> to do it, but assuming that the host has it installed is probably a
> fairly safe assumption.
>
> Only issue is that some people might have a build server they upload the
> config to, but even then installing ncurses-dev shouldn't really be a
> big deal.
See the discussion going with Peter, and the decision we need to take
on this.
> The offending tarballs have been moved out. I've checked them with file,
> gzip and even opened them in file-roller and I can't see an issue. They
> are up at http://nroach44.info/misc/br/ if you want to take a look.
Ok, strange.
> I have a suspicion that they may have been redownloaded, but I'm not
> sure if buildroot does wget -c or similar size checking logic by default.
We don't do size checking nor 'wget -c'. However, the autobuild-run
script deletes 5 random tarballs at the end of each build, in order to
make sure we regularly re-download the upstream tarballs. This is a way
to detect no longer available upstream sites, tarballs that have
changed and other similar things. Maybe you were lucky and the two
offending tarballs had been deleted and re-downloaded?
I guess we'll see over time what happens. Thanks for checking!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-06 20:25 ` Peter Korsgaard
@ 2014-09-07 7:21 ` Thomas Petazzoni
2014-09-07 12:17 ` Thomas De Schampheleire
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-09-07 7:21 UTC (permalink / raw)
To: buildroot
Hello,
On Sat, 06 Sep 2014 22:25:33 +0200, Peter Korsgaard wrote:
> > Seems like Nathaniel autobuilder does not have the ncurses development
> > libraries installed (also causing build failures in host-mysql, for
> > example). What is our policy regarding ncurses? I have it installed in
> > my autobuilder because I use it to run "make menuconfig". But it's true
> > it's not technically absolutely required to run a Buildroot build.
>
> > Should we add dependency on host-ncurses where appropriate? Or should
> > we make ncurses development files on the build machine a mandatory
> > dependency? What if the user uses only xconfig or gconfig?
>
> Given how many people use menuconfig, I think we should just make
> ncurses a mandatory dependency. Just about anybody doing embedded Linux
> development needs them anyway to configure
> barebox/linux/busybox/uclibc/ctng/..
>
> If not, then we would also need to add host-ncurses to our
> barebox/linux/busybox/uclibc-menuconfig targets.
Well not sure we want to go down this road: it would mean we should add
host-qt as a dependency of the linux-xconfig target for example. We
could also decide that the *-menuconfig targets need to have curses-dev
installed on the build machine, but that the package that we build and
that need host-curses will depend on host-curses.
But well, menuconfig is indeed widely used, so maybe the easiest
solution would be to make ncurses-dev a mandatory dependency.
> >> arm | make: *** [core-dependencie... | NOK | http://autobuild.buildroot.net/results/a42c4d1abdee3ee28048e68f28781d5914dcd23b/
>
> > Peter should move to the autobuild-run script.
>
> Yeah, I'll work on it this weekend.
Cool! For now, only migrate your x86/x86-64 machines. Note that instead
of using your toolchain, it will be randomly chosing from the toolchain
configurations available at
http://autobuild.buildroot.org/toolchains/configs/. If you think there
is some useful configuration that is missing, let me know.
We'll work on moving the PowerPC machine at a later point (that will
require building a toolchain on it, and then putting it on
http://autobuild.buildroot.org/toolchains/tarballs/).
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-06 18:36 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-09-06 20:25 ` Peter Korsgaard
@ 2014-09-07 3:49 ` Nathaniel Roach
2014-09-07 7:41 ` Thomas Petazzoni
1 sibling, 1 reply; 416+ messages in thread
From: Nathaniel Roach @ 2014-09-07 3:49 UTC (permalink / raw)
To: buildroot
On 07/09/14 02:36, Thomas Petazzoni wrote:
> Hello,
>
> Fran?ois, Nathaniel, see below.
>
>
>> arm | host-gdb-7.6.2 | NOK | http://autobuild.buildroot.net/results/03b15dde13d804e5b8b0df7f887ce0552c69fa6d/
>
> configure: error: no termcap library found
> Makefile:8229: recipe for target 'configure-gdb' failed
>
> Seems like Nathaniel autobuilder does not have the ncurses development
> libraries installed (also causing build failures in host-mysql, for
> example). What is our policy regarding ncurses? I have it installed in
> my autobuilder because I use it to run "make menuconfig". But it's true
> it's not technically absolutely required to run a Buildroot build.
>
> Should we add dependency on host-ncurses where appropriate? Or should
> we make ncurses development files on the build machine a mandatory
> dependency? What if the user uses only xconfig or gconfig?
>
I don't have it installed purely because this chroot is *just* for the
autobuilder.
I'm leaning towards host-ncurses because it seems to be the cleaner way
to do it, but assuming that the host has it installed is probably a
fairly safe assumption.
Only issue is that some people might have a build server they upload the
config to, but even then installing ncurses-dev shouldn't really be a
big deal.
>
> /usr/bin/perl "-Iinc" /usr/share/perl/5.20/ExtUtils/xsubpp -typemap /usr/share/perl/5.20/ExtUtils/typemap -typemap typemap SSLeay.xs > SSLeay.xsc && mv SSLeay.xsc SSLeay.c
> make[1]: *** No rule to make target '/home/chroot/media/code/buildroot/autobuilder/instance-1/output/host/usr/i686-buildroot-linux-gnu/sysroot/usr/lib/perl5/5.18.2/i686-linux/CORE/vutil.h', needed by 'SSLeay.o'. Stop.
>
>> arm | php-yaml-1.1.1 | NOK | http://autobuild.buildroot.net/results/c1454491c21c81a2f01b5f21aeff5c39f0a49155/
>
> Issue on Nathaniel autobuilder instance:
>
> gzip: /home/chroot/media/code/buildroot/autobuilder/instance-0/dl/yaml-1.1.1.tgz: not in gzip format
>
> Nathaniel, could you have a look at the yaml-1.1.1.tgz tarball? Also,
> look at ftop-1.0.tar.gz, which has a similar issue. It would be good to:
>
> *) Save those tarballs somewhere else so we can study what they look
> like and hopefully understand the problem.
>
> *) Then immediately remove them from the instance-<X>/dl/ directory,
> so that future builds will not fail due to this.
The offending tarballs have been moved out. I've checked them with file,
gzip and even opened them in file-roller and I can't see an issue. They
are up at http://nroach44.info/misc/br/ if you want to take a look.
I have a suspicion that they may have been redownloaded, but I'm not
sure if buildroot does wget -c or similar size checking logic by default.
A few days back when I was testing the autobuilder I was getting errors
on a mirror, from memory php's, so that might have something to do with
the issue.
>
> Thomas
>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-06 18:36 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2014-09-06 20:25 ` Peter Korsgaard
2014-09-07 7:21 ` Thomas Petazzoni
2014-09-07 3:49 ` Nathaniel Roach
1 sibling, 1 reply; 416+ messages in thread
From: Peter Korsgaard @ 2014-09-06 20:25 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> arm | host-gdb-7.6.2 | NOK | http://autobuild.buildroot.net/results/03b15dde13d804e5b8b0df7f887ce0552c69fa6d/
> configure: error: no termcap library found
> Makefile:8229: recipe for target 'configure-gdb' failed
> Seems like Nathaniel autobuilder does not have the ncurses development
> libraries installed (also causing build failures in host-mysql, for
> example). What is our policy regarding ncurses? I have it installed in
> my autobuilder because I use it to run "make menuconfig". But it's true
> it's not technically absolutely required to run a Buildroot build.
> Should we add dependency on host-ncurses where appropriate? Or should
> we make ncurses development files on the build machine a mandatory
> dependency? What if the user uses only xconfig or gconfig?
Given how many people use menuconfig, I think we should just make
ncurses a mandatory dependency. Just about anybody doing embedded Linux
development needs them anyway to configure
barebox/linux/busybox/uclibc/ctng/..
If not, then we would also need to add host-ncurses to our
barebox/linux/busybox/uclibc-menuconfig targets.
>> arm | make: *** [core-dependencie... | NOK | http://autobuild.buildroot.net/results/a42c4d1abdee3ee28048e68f28781d5914dcd23b/
> Peter should move to the autobuild-run script.
Yeah, I'll work on it this weekend.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-09-06 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-09-05 Thomas Petazzoni
@ 2014-09-06 18:36 ` Thomas Petazzoni
2014-09-06 20:25 ` Peter Korsgaard
2014-09-07 3:49 ` Nathaniel Roach
0 siblings, 2 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-09-06 18:36 UTC (permalink / raw)
To: buildroot
Hello,
Fran?ois, Nathaniel, see below.
On Sat, 6 Sep 2014 08:30:10 +0200 (CEST), Thomas Petazzoni wrote:
> arm | boost-1.56.0 | NOK | http://autobuild.buildroot.net/results/ac5ad7be5500d50cdb0a1d649361b6fe14d29570/
> arm | boost-1.56.0 | NOK | http://autobuild.buildroot.net/results/812226d89a3d79ce95c53b5f5c736225969cb35a/
> arm | boost-1.56.0 | NOK | http://autobuild.buildroot.net/results/1c98cddde2e4f28ba8b7d653313b12a7c88dbb60/
Should be fixed by http://patchwork.ozlabs.org/patch/386642/.
> arc | busybox-1.22.1 | NOK | http://autobuild.buildroot.net/results/994a84d192848b90a70e28e5ebaa769701bcaec9/
Due to libtirpc using atomic intrinsics not available on ARC. I've
started having a look, but adding the dependency
on !BR2_ARCH_HAS_ATOMIC_INTRINSICS to all reverse dependencies on
libtirpc is not simple in terms of handling the comments.
> powerpc | cppcms-1.0.4 | NOK | http://autobuild.buildroot.net/results/d0a1f7a64c0b6a0748123f2525ee09af7369336c/
Should be fixed by http://patchwork.ozlabs.org/patch/386626/.
> arm | gnupg2-2.0.26 | NOK | http://autobuild.buildroot.net/results/87127e51d49ec5281c4ea86a9637fd527ce483d6/
The infamous:
error: unknown type name 'intmax_t'
problem.
> arm | host-gdb-7.6.2 | NOK | http://autobuild.buildroot.net/results/03b15dde13d804e5b8b0df7f887ce0552c69fa6d/
configure: error: no termcap library found
Makefile:8229: recipe for target 'configure-gdb' failed
Seems like Nathaniel autobuilder does not have the ncurses development
libraries installed (also causing build failures in host-mysql, for
example). What is our policy regarding ncurses? I have it installed in
my autobuilder because I use it to run "make menuconfig". But it's true
it's not technically absolutely required to run a Buildroot build.
Should we add dependency on host-ncurses where appropriate? Or should
we make ncurses development files on the build machine a mandatory
dependency? What if the user uses only xconfig or gconfig?
> x86_64 | host-nodejs-0.10.31 | NOK | http://autobuild.buildroot.net/results/d66c0941009b442292011721d900699023e143e8/
> arm | host-nodejs-0.10.31 | NOK | http://autobuild.buildroot.net/results/6dc5a30ab02289d28b12fe736ec3fe34cc804da1/
> arm | host-nodejs-0.10.31 | NOK | http://autobuild.buildroot.net/results/dab15db53aeda3115945fc7befcdaa895ebd79e0/
> arm | host-nodejs-0.10.31 | NOK | http://autobuild.buildroot.net/results/89b1b745c52fa65313a69a157a4198180fd80cf1/
> arm | host-nodejs-0.10.31 | NOK | http://autobuild.buildroot.net/results/267f69143908a33054468179f934b28ba3fc4b40/
> arm | host-nodejs-0.10.31 | NOK | http://autobuild.buildroot.net/results/043c4a940d2cfea56be14b86fabf18b64db0987f/
Should be fixed by http://patchwork.ozlabs.org/patch/386639/.
> powerpc | host-ruby-2.1.2 | NOK | http://autobuild.buildroot.net/results/e197f20bd5ec4aae6d8692d67df4f539a9df33e2/
> microblazeel | host-ruby-2.1.2 | NOK | http://autobuild.buildroot.net/results/b1fad7600afd4e9c747834d9585949260c82385a/
> powerpc | host-ruby-2.1.2 | NOK | http://autobuild.buildroot.net/results/625419c6c20b957fe4d0c9f309da8730f0860304/
> aarch64 | host-ruby-2.1.2 | NOK | http://autobuild.buildroot.net/results/521ea04ac7d16ff23901f92600b1b67235a00dbe/
Should be fixed by http://patchwork.ozlabs.org/patch/386617/.
> arm | libgcrypt-1.6.2 | NOK | http://autobuild.buildroot.net/results/194d91880aefa05bbfec2b83daeed133ddaee495/
Transient error, ignore:
Resolving ftp.gnupg.org... failed: Name or service not known.
wget: unable to resolve host address ???ftp.gnupg.org???
> bfin | libiscsi-1.6.0 | NOK | http://autobuild.buildroot.net/results/5cba23312890c3985552305f9d85cd38270a9578/
Should be fixed by http://patchwork.ozlabs.org/patch/386619/.
> bfin | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/ed812757a2400a6a060944c661fcd85d600c2a7b/
Probably tries to build a shared library.
> arm | make: *** [core-dependencie... | NOK | http://autobuild.buildroot.net/results/a42c4d1abdee3ee28048e68f28781d5914dcd23b/
Peter should move to the autobuild-run script.
> nios2 | minidlna-1.1.4 | NOK | http://autobuild.buildroot.net/results/a2e40c005135be85e6161f7294d749c63a6673e0/
Don't know, to be reproduced/investigated.
> i686 | perl-net-ssleay-1.65 | NOK | http://autobuild.buildroot.net/results/179d10ed4855cb0e357ff50517abc737c9abdce4/
Fran?ois ?
/usr/bin/perl "-Iinc" /usr/share/perl/5.20/ExtUtils/xsubpp -typemap /usr/share/perl/5.20/ExtUtils/typemap -typemap typemap SSLeay.xs > SSLeay.xsc && mv SSLeay.xsc SSLeay.c
make[1]: *** No rule to make target '/home/chroot/media/code/buildroot/autobuilder/instance-1/output/host/usr/i686-buildroot-linux-gnu/sysroot/usr/lib/perl5/5.18.2/i686-linux/CORE/vutil.h', needed by 'SSLeay.o'. Stop.
> arm | php-yaml-1.1.1 | NOK | http://autobuild.buildroot.net/results/c1454491c21c81a2f01b5f21aeff5c39f0a49155/
Issue on Nathaniel autobuilder instance:
gzip: /home/chroot/media/code/buildroot/autobuilder/instance-0/dl/yaml-1.1.1.tgz: not in gzip format
Nathaniel, could you have a look at the yaml-1.1.1.tgz tarball? Also,
look at ftop-1.0.tar.gz, which has a similar issue. It would be good to:
*) Save those tarballs somewhere else so we can study what they look
like and hopefully understand the problem.
*) Then immediately remove them from the instance-<X>/dl/ directory,
so that future builds will not fail due to this.
> bfin | prboom-2.5.0 | NOK | http://autobuild.buildroot.net/results/12776a0122fa992aa23c80c449de3d6962d20bc8/
Static linking issue:
SDLnet.c:(.text+0x14e): warning: gethostbyaddr is obsolescent, use getaddrinfo() instead.
/home/chroot/media/code/buildroot/autobuilder/instance-1/output/host/usr/bfin-buildroot-uclinux-uclibc/sysroot/usr/lib/libSDL_mixer.a(mixer.o): In function `_Mix_LoadWAV_RW':
mixer.c:(.text+0x1128): undefined reference to `_SDL_LoadWAV_RW'
/home/chroot/media/code/buildroot/autobuilder/instance-1/output/host/usr/bfin-buildroot-uclinux-uclibc/sysroot/usr/lib/libSDL_mixer.a(mixer.o): In function `_mix_channels':
mixer.c:(.text+0x15c2): undefined reference to `_SDL_MixAudio'
mixer.c:(.text+0x1646): undefined reference to `_SDL_MixAudio'
/home/chroot/media/code/buildroot/autobuilder/instance-1/output/host/usr/bfin-buildroot-uclinux-uclibc/sysroot/usr/lib/libSDL_mixer.a(wavestream.o): In function `_WAVStream_PlaySome':
wavestream.c:(.text+0x224): undefined reference to `_SDL_MixAudio'
> i686 | python-2.7.8 | NOK | http://autobuild.buildroot.net/results/d526340a1e079e504e4655766d0058317acec1eb/
uClibc bug around setresgid() and al. being redefined. Already reported
upstream.
> mips | samba-3.6.24 | TIM | http://autobuild.buildroot.net/results/9499dbdd4c6c2b1eb6dbe088b986c2ed72ed45c0/
Ignore.
> bfin | ushare-1.1a | NOK | http://autobuild.buildroot.net/results/1c5efa35c3a8082a1a51cf59d5682b21e5e3d932/
Don't know yet.
Checking for libupnp >= 1.4.2 ...
Error, can't find libupnp !
See file "config.log" produced by configure for more details.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-08-29 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-28 Thomas Petazzoni
@ 2014-08-29 7:30 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-08-29 7:30 UTC (permalink / raw)
To: buildroot
Hello,
Yuvaraj, Romain, Samuel, Bernd, see below.
On Fri, 29 Aug 2014 08:30:10 +0200 (CEST), Thomas Petazzoni wrote:
> powerpc | cppcms-1.0.4 | NOK | http://autobuild.buildroot.net/results/b38b30d5a6436c07723ce136a626cab5154cf39a/
error: 'wstring' is not a member of 'std'
To me, this looks like cppcms needs WCHAR support in toolchain, no?
> bfin | directfb-examples-1.6.0 | NOK | http://autobuild.buildroot.net/results/b515eb00f981c494fdbe379cbc8a11c60b247da5/
undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
And many more crazy errors. Don't know what's going on here. Is it
because we're building with gcc a C program linked against a C++
library, and that Blackfin has some specificities here?
Yuvaraj, could you have a look?
> arm | exim-4.83 | NOK | http://autobuild.buildroot.net/results/98a1acb58665e6cd2df354fc63afef1d4606c6e0/
Needs thread.
> microblazeel | gst-ffmpeg-0.10.13 | TIM | http://autobuild.buildroot.net/results/f885e55787e9b966ec67f539f41edb115a2c9e77/
Ignore.
> mipsel | libarchive-3.1.2 | NOK | http://autobuild.buildroot.net/results/b8f7a29787ea1cc5c98e4cbd5f47f257f9b306f2/
/home/buildroot/instance-0/output/host/usr/mipsel-buildroot-linux-uclibc/sysroot/usr/lib/libdl.a(libdl.os): In function `_dl_parse_relocation_information':
libdl.c:(.text+0x146c): undefined reference to `TLS_DTPREL_VALUE'
libdl.c:(.text+0x14ac): undefined reference to `TLS_TPREL_VALUE'
libdl.c:(.text+0x14c8): undefined reference to `TLS_TPREL_VALUE'
libdl.c:(.text+0x1494): undefined reference to `TLS_DTPREL_VALUE'
libdl.c:(.text+0x14d4): undefined reference to `TLS_TPREL_VALUE'
collect2: error: ld returned 1 exit status
Weird. There is already some work being done by Romain Naour on this
package. Maybe you could have a look Romain?
> bfin | libcurl-7.37.1 | NOK | http://autobuild.buildroot.net/results/c37022e334d763bad2a59f7311b93504a569b2dd/
checking for recv... no
configure: error: Unable to link function recv
make: *** [/home/buildroot/instance-1/output/build/libcurl-7.37.1/.stamp_configured] Error 1
make: Leaving directory `/home/buildroot/instance-1/buildroot'
Don't know.
> bfin | libiqrf-v0.1.2 | NOK | http://autobuild.buildroot.net/results/2108f37e4a41af0b527c78e646e82f1cafa0353d/
Samuel: this one is for you. Yet another CMake based package trying to create
a shared library even when told not to do so.
> mipsel | libwebsockets-v1.23-chrome3... | NOK | http://autobuild.buildroot.net/results/0a9f0c3c101550e73f7100f2b88a88c1f2bbad95/
Same problem: purely static build, and the CMake based package tries to
build a shared library. Samuel?
> bfin | ruby-1.9.3-p545 | NOK | http://autobuild.buildroot.net/results/09199826df86b1bebd3c4e5dca03b9d86c0ea495/
> bfin | ruby-1.9.3-p545 | NOK | http://autobuild.buildroot.net/results/1b0e2f5f95889eb26846927da45d128247d0ed89/
> bfin | ruby-1.9.3-p545 | NOK | http://autobuild.buildroot.net/results/ea4b34837e04beb5408871c207b5f9482eafda9b/
Fixed by:
http://git.buildroot.net/buildroot/commit/?id=2b773698820996352274962899790788fc2b3eb5
http://git.buildroot.net/buildroot/commit/?id=53bf889cdca77979814bc6b74170e2f104fc3b70
> bfin | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/695cf7c68ba978052d3b04db129af15c0d68eca6/
bfin-linux-uclibc-g++: /home/test/autobuild/instance-0/output/host/usr/bfin-buildroot-linux-uclibc/sysroot/opt/uClinux/bfin-linux-uclibc/lib/gcc/bfin-linux-uclibc/4.3.5/libstdc++.so: No such file or directory
Don't know. Yuvaraj?
> sh4a | xscreensaver-5.22 | NOK | http://autobuild.buildroot.net/results/e19cbe44035e1620febc194960373c67e3b60ed2/
> mips64el | xscreensaver-5.22 | NOK | http://autobuild.buildroot.net/results/aceb83ff92957accab4e2f64e450b2d2837cb2ba/
Both would be fixed by http://patchwork.ozlabs.org/patch/383576/.
> powerpc | xserver_xorg-server-1.16.0 | NOK | http://autobuild.buildroot.net/results/40c6cce919c9ca08bfc256740f52707dbd67a843/
log.c: In function 'LogInit':
log.c:199:9: error: #pragma GCC diagnostic not allowed inside functions
log.c:201:9: warning: format not a string literal, argument types not checked
log.c:212:9: error: #pragma GCC diagnostic not allowed inside functions
log.c:214:17: warning: format not a string literal, argument types not checked
Bernd, maybe?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-08-26 11:48 ` Vicente Olivert Riera
@ 2014-08-26 12:13 ` Gustavo Zacarias
0 siblings, 0 replies; 416+ messages in thread
From: Gustavo Zacarias @ 2014-08-26 12:13 UTC (permalink / raw)
To: buildroot
On 08/26/2014 08:48 AM, Vicente Olivert Riera wrote:
>> Do i get a beer or what for fixing multiple packages in one shot from a
>> sucky bug/assumption?
>
> It depends. Are you going to the BR meeting in D?sseldorf? :)
Unfortunately no, long distance = steep plane ticket price.
I guess i'll get the 'what' ;)
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-08-26 11:46 ` Gustavo Zacarias
@ 2014-08-26 11:48 ` Vicente Olivert Riera
2014-08-26 12:13 ` Gustavo Zacarias
0 siblings, 1 reply; 416+ messages in thread
From: Vicente Olivert Riera @ 2014-08-26 11:48 UTC (permalink / raw)
To: buildroot
On 08/26/2014 12:46 PM, Gustavo Zacarias wrote:
> On 08/26/2014 08:29 AM, Vicente Olivert Riera wrote:
>
>>> Hi.
>>> It's a conflict between libev and libevent at work here, they both
>>> install /usr/include/event.h hence causing issues.
>>> Isn't that sweet?
>>> I think i've got a solution, i'll send a patch shortly if it pans out.
>>> Regards.
>>>
>>> _______________________________________________
>>> buildroot mailing list
>>> buildroot at busybox.net
>>> http://lists.busybox.net/mailman/listinfo/buildroot
>>>
>>
>> Maybe this is the same problem that is causing tmux to fail:
>>
>> http://autobuild.buildroot.net/results/24f/24f5d0c61b5283fe6ce58b11cb37813ce227fdc8/build-end.log
>>
>>
>> https://sourceforge.net/p/tmux/tickets/152/
>
> Indeed it is and it's fixed by the libev patch i've sent.
Great.
> Do i get a beer or what for fixing multiple packages in one shot from a
> sucky bug/assumption?
It depends. Are you going to the BR meeting in D?sseldorf? :)
> Regards.
>
--
Vincent
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-08-26 11:29 ` Vicente Olivert Riera
@ 2014-08-26 11:46 ` Gustavo Zacarias
2014-08-26 11:48 ` Vicente Olivert Riera
0 siblings, 1 reply; 416+ messages in thread
From: Gustavo Zacarias @ 2014-08-26 11:46 UTC (permalink / raw)
To: buildroot
On 08/26/2014 08:29 AM, Vicente Olivert Riera wrote:
>> Hi.
>> It's a conflict between libev and libevent at work here, they both
>> install /usr/include/event.h hence causing issues.
>> Isn't that sweet?
>> I think i've got a solution, i'll send a patch shortly if it pans out.
>> Regards.
>>
>> _______________________________________________
>> buildroot mailing list
>> buildroot at busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
>>
>
> Maybe this is the same problem that is causing tmux to fail:
>
> http://autobuild.buildroot.net/results/24f/24f5d0c61b5283fe6ce58b11cb37813ce227fdc8/build-end.log
>
>
> https://sourceforge.net/p/tmux/tickets/152/
Indeed it is and it's fixed by the libev patch i've sent.
Do i get a beer or what for fixing multiple packages in one shot from a
sucky bug/assumption?
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-08-26 11:18 ` Gustavo Zacarias
@ 2014-08-26 11:29 ` Vicente Olivert Riera
2014-08-26 11:46 ` Gustavo Zacarias
0 siblings, 1 reply; 416+ messages in thread
From: Vicente Olivert Riera @ 2014-08-26 11:29 UTC (permalink / raw)
To: buildroot
On 08/26/2014 12:18 PM, Gustavo Zacarias wrote:
> On 08/26/2014 04:29 AM, Thomas Petazzoni wrote:
>
>>> powerpc | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/4510fe02ef3497803ed27bf339dca07b3b073c10/
>>
>> src/thrift/async/TEvhttpServer.cpp: In constructor 'apache::thrift::async::TEvhttpServer::RequestContext::RequestContext(evhttp_request*)':
>> src/thrift/async/TEvhttpServer.cpp:102:59: error: 'EVBUFFER_DATA' was not declared in this scope
>> src/thrift/async/TEvhttpServer.cpp:102:117: error: 'EVBUFFER_LENGTH' was not declared in this scope
>> src/thrift/async/TEvhttpServer.cpp: In member function 'void apache::thrift::async::TEvhttpServer::complete(apache::thrift::async::TEvhttpServer::RequestContext*, bool)':
>> src/thrift/async/TEvhttpServer.cpp:142:39: error: 'evbuffer_new' was not declared in this scope
>> src/thrift/async/TEvhttpServer.cpp:150:41: error: 'evbuffer_add' was not declared in this scope
>> src/thrift/async/TEvhttpServer.cpp:159:22: error: 'evbuffer_free' was not declared in this scope
>> make[5]: *** [libthriftnb_la-TEvhttpServer.lo] Error 1
>>
>> Gustavo, maybe?
>
> Hi.
> It's a conflict between libev and libevent at work here, they both
> install /usr/include/event.h hence causing issues.
> Isn't that sweet?
> I think i've got a solution, i'll send a patch shortly if it pans out.
> Regards.
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
Maybe this is the same problem that is causing tmux to fail:
http://autobuild.buildroot.net/results/24f/24f5d0c61b5283fe6ce58b11cb37813ce227fdc8/build-end.log
https://sourceforge.net/p/tmux/tickets/152/
--
Vincent
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-08-26 7:29 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-08-26 7:37 ` Jörg Krause
@ 2014-08-26 11:18 ` Gustavo Zacarias
2014-08-26 11:29 ` Vicente Olivert Riera
1 sibling, 1 reply; 416+ messages in thread
From: Gustavo Zacarias @ 2014-08-26 11:18 UTC (permalink / raw)
To: buildroot
On 08/26/2014 04:29 AM, Thomas Petazzoni wrote:
>> powerpc | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/4510fe02ef3497803ed27bf339dca07b3b073c10/
>
> src/thrift/async/TEvhttpServer.cpp: In constructor 'apache::thrift::async::TEvhttpServer::RequestContext::RequestContext(evhttp_request*)':
> src/thrift/async/TEvhttpServer.cpp:102:59: error: 'EVBUFFER_DATA' was not declared in this scope
> src/thrift/async/TEvhttpServer.cpp:102:117: error: 'EVBUFFER_LENGTH' was not declared in this scope
> src/thrift/async/TEvhttpServer.cpp: In member function 'void apache::thrift::async::TEvhttpServer::complete(apache::thrift::async::TEvhttpServer::RequestContext*, bool)':
> src/thrift/async/TEvhttpServer.cpp:142:39: error: 'evbuffer_new' was not declared in this scope
> src/thrift/async/TEvhttpServer.cpp:150:41: error: 'evbuffer_add' was not declared in this scope
> src/thrift/async/TEvhttpServer.cpp:159:22: error: 'evbuffer_free' was not declared in this scope
> make[5]: *** [libthriftnb_la-TEvhttpServer.lo] Error 1
>
> Gustavo, maybe?
Hi.
It's a conflict between libev and libevent at work here, they both
install /usr/include/event.h hence causing issues.
Isn't that sweet?
I think i've got a solution, i'll send a patch shortly if it pans out.
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-08-26 7:29 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2014-08-26 7:37 ` Jörg Krause
2014-08-26 11:18 ` Gustavo Zacarias
1 sibling, 0 replies; 416+ messages in thread
From: Jörg Krause @ 2014-08-26 7:37 UTC (permalink / raw)
To: buildroot
On 08/26/2014 09:29 AM, Thomas Petazzoni wrote:
>
>> arm | mpd-0.18.12 | NOK | http://autobuild.buildroot.net/results/4924194292a428a295ded2f7aa0b9a3f81ed1b4a/
> checking for OPUS... no
> configure: error: opus decoder plugin: libopus not found
>
> J?rg, Gustavo?
I will check this.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-08-26 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-25 Thomas Petazzoni
@ 2014-08-26 7:29 ` Thomas Petazzoni
2014-08-26 7:37 ` Jörg Krause
2014-08-26 11:18 ` Gustavo Zacarias
0 siblings, 2 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-08-26 7:29 UTC (permalink / raw)
To: buildroot
Hello,
Bernd, J?rg, Gustavo, see below.
On Tue, 26 Aug 2014 08:30:09 +0200 (CEST), Thomas Petazzoni wrote:
> i686 | alsa-lib-1.0.28 | NOK | http://autobuild.buildroot.net/results/f83b65bfc6ea7c7406a02e92afda43e4c5db6e7c/
> x86_64 | alsa-lib-1.0.28 | NOK | http://autobuild.buildroot.net/results/64f418f54885e8b5093dc8949c2d1d1ff3c938ea/
Same uClibc static linking issue around vfork().
> x86_64 | fltk-1.3.2 | NOK | http://autobuild.buildroot.net/results/29e4c52784de56b2e880ee95f0a0f8549bfb1920/
/home/test/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/test/autobuild/instance-1/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/libxcb-render.so.0: undefined reference to `xcb_str_sizeof'
/home/test/autobuild/instance-1/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/libxcb-shm.so.0: undefined reference to `xcb_send_fd'
Anybody doing X stuff to look into this? Bernd maybe?
> arc | geoip-1.6.0 | TIM | http://autobuild.buildroot.net/results/0ebc078fb66a381e3b851fef37c7b48a48fb8b47/
Timeout, don't bother.
> arm | libgcrypt-1.6.1 | NOK | http://autobuild.buildroot.net/results/184eb5f82bbe1d78113499898c1a9e88bb9f2181/
Memory allocation problem on the build server, ignore.
> bfin | libgeotiff-1.3.0 | NOK | http://autobuild.buildroot.net/results/108d618632cc1f941bcba12f76f01c357fc3ef62/
configure: error: You will need to substantially rewrite libxtiff to
build libgeotiff without libtiff
make: *** [/home/test/autobuild/instance-2/output/build/libgeotiff-1.3.0/.stamp_configured] Error 1
make: Leaving directory `/home/test/autobuild/instance-2/buildroot'
Don't know.
> x86_64 | make: *** [core-dependencie... | NOK | http://autobuild.buildroot.net/results/6d723940d1a24e728bfb93d849b792e360fd6815/
> arm | make: *** [core-dependencie... | NOK | http://autobuild.buildroot.net/results/5eae6743dcf33b13807a161f7800d9522726ec1c/
> mips64el | make: *** [core-dependencie... | NOK | http://autobuild.buildroot.net/results/fe2849700379f32eec6ccb48e552ef79fe837a17/
> powerpc | make: *** [core-dependencie... | NOK | http://autobuild.buildroot.net/results/ba358130d9bf2f371edc719f36d3ad5ef882a885/
> x86_64 | make: *** [core-dependencie... | NOK | http://autobuild.buildroot.net/results/dc1ff7ff666c38c5acd62c4b4c6ca58d967ed220/
Ignore those. Richard Braun is setting up a new build server, and there
were some minor issues when setting things up. Richard's server is now
disabled again, we'll see at re-enabling it at some point today.
> arm | mpd-0.18.12 | NOK | http://autobuild.buildroot.net/results/4924194292a428a295ded2f7aa0b9a3f81ed1b4a/
checking for OPUS... no
configure: error: opus decoder plugin: libopus not found
J?rg, Gustavo?
> bfin | opentyrian-2.1.20130907 | NOK | http://autobuild.buildroot.net/results/7a6c9d058367b12edea0df83e02b7bf50521ec9c/
Conflict between uClibc symbols and symbols defined by the program, it seems.
/home/test/autobuild/instance-1/output/host/usr/bfin-buildroot-uclinux-uclibc/sysroot/usr/lib/libc.a(strchrnul.o): In function `*___GI_strchrnul':
/usr/src/packages/BUILD/blackfin-toolchain-uclibc-full-2014R1/uClibc/libc/string/generic/strchrnul.c:33: multiple definition of `_strchrnul'
obj/mingw_fixes.o:src/mingw_fixes.c:(.text+0x0): first defined here
> arm | perl-gd-2.53 | NOK | http://autobuild.buildroot.net/results/a865e4f9a36e3aa6124cbff5a06a5651816f54ca/
> arm | perl-gd-2.53 | NOK | http://autobuild.buildroot.net/results/b7bcac001098355715b675958ba7dbecfb2dbd0d/
Always the same issue, caused by the old host-perl.
> mips64el | python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/a7109a97c1517feb31b6c68d0d10a8d830c62a08/
Failed to build these modules:
_posixsubprocess
Not sure, I need to investigate.
> powerpc | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/4510fe02ef3497803ed27bf339dca07b3b073c10/
src/thrift/async/TEvhttpServer.cpp: In constructor 'apache::thrift::async::TEvhttpServer::RequestContext::RequestContext(evhttp_request*)':
src/thrift/async/TEvhttpServer.cpp:102:59: error: 'EVBUFFER_DATA' was not declared in this scope
src/thrift/async/TEvhttpServer.cpp:102:117: error: 'EVBUFFER_LENGTH' was not declared in this scope
src/thrift/async/TEvhttpServer.cpp: In member function 'void apache::thrift::async::TEvhttpServer::complete(apache::thrift::async::TEvhttpServer::RequestContext*, bool)':
src/thrift/async/TEvhttpServer.cpp:142:39: error: 'evbuffer_new' was not declared in this scope
src/thrift/async/TEvhttpServer.cpp:150:41: error: 'evbuffer_add' was not declared in this scope
src/thrift/async/TEvhttpServer.cpp:159:22: error: 'evbuffer_free' was not declared in this scope
make[5]: *** [libthriftnb_la-TEvhttpServer.lo] Error 1
Gustavo, maybe?
> sh4a | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/3a0c48f65c06f7f19e608d54307c0788a0130589/
Need to disable on SH4, as per yesterday discussion.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-08-13 9:05 ` Luca Ceresoli
2014-08-13 9:06 ` Thomas Petazzoni
@ 2014-08-13 10:31 ` Peter Korsgaard
1 sibling, 0 replies; 416+ messages in thread
From: Peter Korsgaard @ 2014-08-13 10:31 UTC (permalink / raw)
To: buildroot
>>>>> "Luca" == Luca Ceresoli <luca@lucaceresoli.net> writes:
Hi,
> Or look at the config.log files if Peter can provide them. Peter,
> do you still have access to them?
Sorry, I don't.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-08-13 9:05 ` Luca Ceresoli
@ 2014-08-13 9:06 ` Thomas Petazzoni
2014-08-13 10:31 ` Peter Korsgaard
1 sibling, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-08-13 9:06 UTC (permalink / raw)
To: buildroot
Dear Luca Ceresoli,
On Wed, 13 Aug 2014 11:05:23 +0200, Luca Ceresoli wrote:
> > I cannot reproduce these errors - I've used the config in the first
> > build that failed in this way. From what I can see it's failing to pick
> > up libpng, which is listed as a dependency both directly and indirectly
> > through libgd. I can try and screw around with the configure script, but
> > I would need to be able to reproduce it first.
>
> I haven't looked into this, but maybe the configure scripts look
> for the system libpng (in /usr) instead of the libpng in the
> Buildroot output dir?
>
> To check that you may try to uninstall libpng from your host and
> see if the error gets reproduced.
>
> Or look at the config.log files if Peter can provide them. Peter,
> do you still have access to them?
I've reproduced the issue on gcc10, I'll send a patch shortly.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-08-13 8:26 ` Nathaniel Roach
@ 2014-08-13 9:05 ` Luca Ceresoli
2014-08-13 9:06 ` Thomas Petazzoni
2014-08-13 10:31 ` Peter Korsgaard
0 siblings, 2 replies; 416+ messages in thread
From: Luca Ceresoli @ 2014-08-13 9:05 UTC (permalink / raw)
To: buildroot
Dear Nathaniel,
Nathaniel Roach wrote:
> On 13/08/14 16:15, Thomas Petazzoni wrote:
>> Hello,
>>
>> On Wed, 13 Aug 2014 08:30:10 +0200 (CEST), Thomas Petazzoni wrote:
>>
>>> arm | bandwidthd-v2.0.1-auto-r07 | NOK | http://autobuild.buildroot.net/results/024fadb7a8983c0ed35e8a098cfefccd25b3ecd0/
>>> arm | bandwidthd-v2.0.1-auto-r07 | NOK | http://autobuild.buildroot.net/results/b84759b4b2b4473386fb209b6b4d4e18e203ec17/
>>> arm | bandwidthd-v2.0.1-auto-r07 | NOK | http://autobuild.buildroot.net/results/e287acf032330c7b0ef4262e7eb365ca45382221/
>>> arm | bandwidthd-v2.0.1-auto-r07 | NOK | http://autobuild.buildroot.net/results/4ae2406feb33eb81b45bcf87c74f62290bbe00fe/
>>
>> Nathaniel, you're the one who contributed bandwidthd. Can you look at
>> the above build issues?
>
> I cannot reproduce these errors - I've used the config in the first
> build that failed in this way. From what I can see it's failing to pick
> up libpng, which is listed as a dependency both directly and indirectly
> through libgd. I can try and screw around with the configure script, but
> I would need to be able to reproduce it first.
I haven't looked into this, but maybe the configure scripts look
for the system libpng (in /usr) instead of the libpng in the
Buildroot output dir?
To check that you may try to uninstall libpng from your host and
see if the error gets reproduced.
Or look at the config.log files if Peter can provide them. Peter,
do you still have access to them?
--
Luca
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-08-13 8:15 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-08-13 8:26 ` Nathaniel Roach
@ 2014-08-13 8:33 ` yuvaraj.patil at wipro.com
1 sibling, 0 replies; 416+ messages in thread
From: yuvaraj.patil at wipro.com @ 2014-08-13 8:33 UTC (permalink / raw)
To: buildroot
Hello Thomas,
>> bfin | gptfdisk-0.8.6 | NOK | http://autobuild.buildroot.net/results/d06ebe23cfdd1130e68c8e67c7aafee94dc7361d/
> libiconv issue.
I am not able to reproduce this issue ( I cloned the latest buildroot mainline and build).
Thanks
Yuvaraj Patil
-----Original Message-----
From: buildroot-bounces@busybox.net [mailto:buildroot-bounces at busybox.net] On Behalf Of Thomas Petazzoni
Sent: Wednesday, August 13, 2014 1:45 PM
To: buildroot at uclibc.org; Nathaniel Roach; Fran?ois Perrad; Gustavo Zacarias
Subject: [Buildroot] Analysis of build failures
Hello,
On Wed, 13 Aug 2014 08:30:10 +0200 (CEST), Thomas Petazzoni wrote:
> arm | bandwidthd-v2.0.1-auto-r07 | NOK | http://autobuild.buildroot.net/results/024fadb7a8983c0ed35e8a098cfefccd25b3ecd0/
> arm | bandwidthd-v2.0.1-auto-r07 | NOK | http://autobuild.buildroot.net/results/b84759b4b2b4473386fb209b6b4d4e18e203ec17/
> arm | bandwidthd-v2.0.1-auto-r07 | NOK | http://autobuild.buildroot.net/results/e287acf032330c7b0ef4262e7eb365ca45382221/
> arm | bandwidthd-v2.0.1-auto-r07 | NOK | http://autobuild.buildroot.net/results/4ae2406feb33eb81b45bcf87c74f62290bbe00fe/
Nathaniel, you're the one who contributed bandwidthd. Can you look at the above build issues?
> bfin | gptfdisk-0.8.6 | NOK | http://autobuild.buildroot.net/results/d06ebe23cfdd1130e68c8e67c7aafee94dc7361d/
libiconv issue.
> arm | host-python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/df6a24a38daca37bf9c39c7433bf9ccdbb1cd59c/
> arm | host-python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/e9ea4f1ac8c4cac3373265ffe6d02a70103fa061/
> arm | host-python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/991084a6e188acec47b0545475a3010d8a8f6a57/
> sh4 | host-python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/6734897dc8a86a770dcbc8bd9e231c4407b2c3a8/
> powerpc | host-python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/bb48fe8347a86de9d2d59c44d24dc88c87103c81/
> arm | host-python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/08ee72809a4ce2e4b451a299dd24582d05224967/
> microblazeel | host-python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/252a7858a85555e4e276744128aa015cafd7f252/
> powerpc | host-python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/d112a15d70ba0e253e96fe9e11122fbe57b1e365/
Don't bother look at this one: it's /dev/shm not mounted in the autobuilders. I fixed this problem manually some time ago, but the autobuilder server was rebooted a few days ago, and therefore /dev/shm is not mounted. I need to fix my scripts.
> arm | keyutils-1.5.5 | NOK | http://autobuild.buildroot.net/results/d432983faeec51ac59343714178b84f00b11e705/
Tries to build a shared library in a BR2_PREFER_STATIC_LIB=y build.
> sh4a | libarchive-3.1.2 | NOK | http://autobuild.buildroot.net/results/10f5acf7b6aab1d5de6dcd73192ab964b15d7f93/
When linking against libcrypto.a, forgets to pass -ldl.
> bfin | libebml-1.2.2 | NOK | http://autobuild.buildroot.net/results/1c75b276b7ed9683ddf3ec35cc3ccf66f69b00c5/
Tries to build a shared library in a pure static context (bfin-uclinux).
> mipsel | ltrace-0896ce554f80afdcba81... | NOK |
> http://autobuild.buildroot.net/results/09f9b2c8a8f21bfd53628d813b62f01
> 95aa686c6/
Problem known and already reported upstream by Vicente.
> arm | lttng-tools-2.4.1 | NOK | http://autobuild.buildroot.net/results/94fbaeb1cf72671b50f52cf25e7003ed41d070e6/
Known compiler issue, I need to add an exception to the autobuilders.
> arm | perl-gd-2.53 | NOK | http://autobuild.buildroot.net/results/e466773fbfce77ac8e89150b96620607e045cf13/
This has been causing a good number of build issues. Fran?ois, is there something we can do to fix this?
> bfin | procps-ng-3.3.9 | NOK | http://autobuild.buildroot.net/results/f24aa16857e91fb6b03f9ac7ab0442fedcab8546/
Patch sent by Yuvaraj Patil <yuvaraj.patil@wipro.com>.
> nios2 | rtorrent-0.9.3 | NOK | http://autobuild.buildroot.net/results/d27ca54295d5757d7c935a2c3d90c64ed81d6d32/
fallocate64() issue. We need to disable rtorrent on NIOS II for now, it seems.
> bfin | tftpd-5.2 | NOK | http://autobuild.buildroot.net/results/3e16d8c9ae3b77393e082c3dd9b7b3de9aa040c0/
Patch sent by Yuvaraj Patil <yuvaraj.patil@wipro.com>.
> arm | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/4662d63c69d244174b431c2e8615a65e0c7b7828/
Unusual issue, seems really specific to Thrift. Gustavo, maybe?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering http://free-electrons.com _______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-08-13 8:15 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2014-08-13 8:26 ` Nathaniel Roach
2014-08-13 9:05 ` Luca Ceresoli
2014-08-13 8:33 ` yuvaraj.patil at wipro.com
1 sibling, 1 reply; 416+ messages in thread
From: Nathaniel Roach @ 2014-08-13 8:26 UTC (permalink / raw)
To: buildroot
On 13/08/14 16:15, Thomas Petazzoni wrote:
> Hello,
>
> On Wed, 13 Aug 2014 08:30:10 +0200 (CEST), Thomas Petazzoni wrote:
>
>> arm | bandwidthd-v2.0.1-auto-r07 | NOK | http://autobuild.buildroot.net/results/024fadb7a8983c0ed35e8a098cfefccd25b3ecd0/
>> arm | bandwidthd-v2.0.1-auto-r07 | NOK | http://autobuild.buildroot.net/results/b84759b4b2b4473386fb209b6b4d4e18e203ec17/
>> arm | bandwidthd-v2.0.1-auto-r07 | NOK | http://autobuild.buildroot.net/results/e287acf032330c7b0ef4262e7eb365ca45382221/
>> arm | bandwidthd-v2.0.1-auto-r07 | NOK | http://autobuild.buildroot.net/results/4ae2406feb33eb81b45bcf87c74f62290bbe00fe/
>
> Nathaniel, you're the one who contributed bandwidthd. Can you look at
> the above build issues?
I cannot reproduce these errors - I've used the config in the first
build that failed in this way. From what I can see it's failing to pick
up libpng, which is listed as a dependency both directly and indirectly
through libgd. I can try and screw around with the configure script, but
I would need to be able to reproduce it first.
>
> Thanks,
>
> Thomas
>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-08-13 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-12 Thomas Petazzoni
@ 2014-08-13 8:15 ` Thomas Petazzoni
2014-08-13 8:26 ` Nathaniel Roach
2014-08-13 8:33 ` yuvaraj.patil at wipro.com
0 siblings, 2 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-08-13 8:15 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 13 Aug 2014 08:30:10 +0200 (CEST), Thomas Petazzoni wrote:
> arm | bandwidthd-v2.0.1-auto-r07 | NOK | http://autobuild.buildroot.net/results/024fadb7a8983c0ed35e8a098cfefccd25b3ecd0/
> arm | bandwidthd-v2.0.1-auto-r07 | NOK | http://autobuild.buildroot.net/results/b84759b4b2b4473386fb209b6b4d4e18e203ec17/
> arm | bandwidthd-v2.0.1-auto-r07 | NOK | http://autobuild.buildroot.net/results/e287acf032330c7b0ef4262e7eb365ca45382221/
> arm | bandwidthd-v2.0.1-auto-r07 | NOK | http://autobuild.buildroot.net/results/4ae2406feb33eb81b45bcf87c74f62290bbe00fe/
Nathaniel, you're the one who contributed bandwidthd. Can you look at
the above build issues?
> bfin | gptfdisk-0.8.6 | NOK | http://autobuild.buildroot.net/results/d06ebe23cfdd1130e68c8e67c7aafee94dc7361d/
libiconv issue.
> arm | host-python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/df6a24a38daca37bf9c39c7433bf9ccdbb1cd59c/
> arm | host-python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/e9ea4f1ac8c4cac3373265ffe6d02a70103fa061/
> arm | host-python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/991084a6e188acec47b0545475a3010d8a8f6a57/
> sh4 | host-python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/6734897dc8a86a770dcbc8bd9e231c4407b2c3a8/
> powerpc | host-python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/bb48fe8347a86de9d2d59c44d24dc88c87103c81/
> arm | host-python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/08ee72809a4ce2e4b451a299dd24582d05224967/
> microblazeel | host-python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/252a7858a85555e4e276744128aa015cafd7f252/
> powerpc | host-python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/d112a15d70ba0e253e96fe9e11122fbe57b1e365/
Don't bother look at this one: it's /dev/shm not mounted in the
autobuilders. I fixed this problem manually some time ago, but the
autobuilder server was rebooted a few days ago, and therefore /dev/shm
is not mounted. I need to fix my scripts.
> arm | keyutils-1.5.5 | NOK | http://autobuild.buildroot.net/results/d432983faeec51ac59343714178b84f00b11e705/
Tries to build a shared library in a BR2_PREFER_STATIC_LIB=y build.
> sh4a | libarchive-3.1.2 | NOK | http://autobuild.buildroot.net/results/10f5acf7b6aab1d5de6dcd73192ab964b15d7f93/
When linking against libcrypto.a, forgets to pass -ldl.
> bfin | libebml-1.2.2 | NOK | http://autobuild.buildroot.net/results/1c75b276b7ed9683ddf3ec35cc3ccf66f69b00c5/
Tries to build a shared library in a pure static context (bfin-uclinux).
> mipsel | ltrace-0896ce554f80afdcba81... | NOK | http://autobuild.buildroot.net/results/09f9b2c8a8f21bfd53628d813b62f0195aa686c6/
Problem known and already reported upstream by Vicente.
> arm | lttng-tools-2.4.1 | NOK | http://autobuild.buildroot.net/results/94fbaeb1cf72671b50f52cf25e7003ed41d070e6/
Known compiler issue, I need to add an exception to the autobuilders.
> arm | perl-gd-2.53 | NOK | http://autobuild.buildroot.net/results/e466773fbfce77ac8e89150b96620607e045cf13/
This has been causing a good number of build issues. Fran?ois, is there
something we can do to fix this?
> bfin | procps-ng-3.3.9 | NOK | http://autobuild.buildroot.net/results/f24aa16857e91fb6b03f9ac7ab0442fedcab8546/
Patch sent by Yuvaraj Patil <yuvaraj.patil@wipro.com>.
> nios2 | rtorrent-0.9.3 | NOK | http://autobuild.buildroot.net/results/d27ca54295d5757d7c935a2c3d90c64ed81d6d32/
fallocate64() issue. We need to disable rtorrent on NIOS II for now, it
seems.
> bfin | tftpd-5.2 | NOK | http://autobuild.buildroot.net/results/3e16d8c9ae3b77393e082c3dd9b7b3de9aa040c0/
Patch sent by Yuvaraj Patil <yuvaraj.patil@wipro.com>.
> arm | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/4662d63c69d244174b431c2e8615a65e0c7b7828/
Unusual issue, seems really specific to Thrift. Gustavo, maybe?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-06-15 10:42 ` Thomas Petazzoni
@ 2014-06-15 14:11 ` Thomas De Schampheleire
0 siblings, 0 replies; 416+ messages in thread
From: Thomas De Schampheleire @ 2014-06-15 14:11 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Sun, Jun 15, 2014 at 12:42 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Sun, 15 Jun 2014 12:36:44 +0200, Thomas De Schampheleire wrote:
>
>> Could you clarify why we need a timeout in the first place? Have
>> there been occurrences of builds that get stuck (in a loop or
>> otherwise)? According to me, it doesn't matter that a build takes ten
>> hours for a given configuration, as long as it progresses and doesn't
>> get stuck...
>
> The reason a timeout was introduced is because there used to be an old
> PowerPC toolchain in which 'ld' had a bug, and this bug caused ld to
> enter an infinite loop, consuming 100% of the CPU forever, when linking
> a specific piece of code. There have been occurrences where my build
> server has remained stuck for several days in this infinite loop before
> I realized that the builds were no longer occurring, and figured out
> what was going on.
>
> I don't think we still have this toolchain tested in the current
> configurations, but the timeout mechanism has remained in place, and I
> believe it's still possible to have similar issues in the future.
>
If we can agree that the situation is rare, than we could keep things
simple and make the timeout relatively large, say 10 hours. This
reduces the false positives due to big configurations, but still
prevent endless builds. In the good cases, no timeout is effectively
present and all builds can run to completion. In the exceptional bad
case of an endless loop, there is a large penalty of 10 hours (or
whatever the timeout value) but since this should only happen
exceptionally it is acceptable. These situations should be
investigated in detail anyway and resolved shortly after (ideally).
The other solutions you proposed have their value too, but make things
more complex while not really necessary IMO.
Best regards,
Thomas
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-06-15 10:36 ` Thomas De Schampheleire
@ 2014-06-15 10:42 ` Thomas Petazzoni
2014-06-15 14:11 ` Thomas De Schampheleire
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-06-15 10:42 UTC (permalink / raw)
To: buildroot
Dear Thomas De Schampheleire,
On Sun, 15 Jun 2014 12:36:44 +0200, Thomas De Schampheleire wrote:
> Could you clarify why we need a timeout in the first place? Have
> there been occurrences of builds that get stuck (in a loop or
> otherwise)? According to me, it doesn't matter that a build takes ten
> hours for a given configuration, as long as it progresses and doesn't
> get stuck...
The reason a timeout was introduced is because there used to be an old
PowerPC toolchain in which 'ld' had a bug, and this bug caused ld to
enter an infinite loop, consuming 100% of the CPU forever, when linking
a specific piece of code. There have been occurrences where my build
server has remained stuck for several days in this infinite loop before
I realized that the builds were no longer occurring, and figured out
what was going on.
I don't think we still have this toolchain tested in the current
configurations, but the timeout mechanism has remained in place, and I
believe it's still possible to have similar issues in the future.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-06-15 10:20 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2014-06-15 10:36 ` Thomas De Schampheleire
2014-06-15 10:42 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Thomas De Schampheleire @ 2014-06-15 10:36 UTC (permalink / raw)
To: buildroot
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> schreef:
>Hello all,
>
>Over the next few days, I'll try to do a quick analysis of the build
>failures, to let you know which build failures are "real", and which
>build failures are caused by issues in the autobuilder infrastructure.
>
>On Sun, 15 Jun 2014 08:30:14 +0200 (CEST), Thomas Petazzoni wrote:
>
>> powerpc | audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/b62615a2d933f2b69c8b402d0134c72675a7e527/
>
>Still the libstdc++ static linking issue.
>
>> i686 | cairo-1.12.10 | TIM | http://autobuild.buildroot.net/results/211fbc0aee997139a7a9d65b4776e02a5b294b4e/
>
>Timeout on my private server. It seems like this server is by an order
>of magnitude slower than the Free Electrons build server, and that
>therefore the timeout of 4 hours is not appropriate for builds that
>can have up to 30% of the packages enabled. For example, this private
>server needs 20 minutes to build libglib2 (which seems very long, not
>sure what's going on there).
>
>I'm looking for suggestions on this, because I'm sure other people
>testing the autobuild-run script will have similar problems, as they
>will not all have 8 cores monsters with 32 GB of RAM and fast I/O.
>There are two possible directions:
>
> * Make the timeout configurable, so that people can adjust it to their
> configuration to avoid false positives as much as possible.
>
> * Make the timeout a per-package timeout. However, that requires
> having a process running in parallel to the build to monitor the
> progress of the build. Not impossible, but requires a bit of
> additional logic in autobuild-run.
>
> * Make the KCONFIG_PROBABILITY configurable. My statistics lessons are
> way too much in the past, but I'm wondering if having different
> KCONFIG_PROBABILITY in the various builders is not going to make the
> statistic of failed vs. success builds a bit meaningless. If one
> machine runs with a low KCONFIG_PROBABILITY, this machine will do a
> lot of small builds, and small builds have a much higher chance of
> being successful than bigger builds. Therefore, such a machine could
> easily reach a very high success rate of builds, compared to a
> machine running with a higher KCONFIG_PROBABILITY value. Thoughts on
> this? Or people better in statistics than me to confirm or infirm my
> reasoning?
>
Could you clarify why we need a timeout in the first place? Have there been occurrences of builds that get stuck (in a loop or otherwise)?
According to me, it doesn't matter that a build takes ten hours for a given configuration, as long as it progresses and doesn't get stuck...
Best regards,
Thomas
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-06-15 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-06-14 Thomas Petazzoni
@ 2014-06-15 10:20 ` Thomas Petazzoni
2014-06-15 10:36 ` Thomas De Schampheleire
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-06-15 10:20 UTC (permalink / raw)
To: buildroot
Hello all,
Over the next few days, I'll try to do a quick analysis of the build
failures, to let you know which build failures are "real", and which
build failures are caused by issues in the autobuilder infrastructure.
On Sun, 15 Jun 2014 08:30:14 +0200 (CEST), Thomas Petazzoni wrote:
> powerpc | audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/b62615a2d933f2b69c8b402d0134c72675a7e527/
Still the libstdc++ static linking issue.
> i686 | cairo-1.12.10 | TIM | http://autobuild.buildroot.net/results/211fbc0aee997139a7a9d65b4776e02a5b294b4e/
Timeout on my private server. It seems like this server is by an order
of magnitude slower than the Free Electrons build server, and that
therefore the timeout of 4 hours is not appropriate for builds that
can have up to 30% of the packages enabled. For example, this private
server needs 20 minutes to build libglib2 (which seems very long, not
sure what's going on there).
I'm looking for suggestions on this, because I'm sure other people
testing the autobuild-run script will have similar problems, as they
will not all have 8 cores monsters with 32 GB of RAM and fast I/O.
There are two possible directions:
* Make the timeout configurable, so that people can adjust it to their
configuration to avoid false positives as much as possible.
* Make the timeout a per-package timeout. However, that requires
having a process running in parallel to the build to monitor the
progress of the build. Not impossible, but requires a bit of
additional logic in autobuild-run.
* Make the KCONFIG_PROBABILITY configurable. My statistics lessons are
way too much in the past, but I'm wondering if having different
KCONFIG_PROBABILITY in the various builders is not going to make the
statistic of failed vs. success builds a bit meaningless. If one
machine runs with a low KCONFIG_PROBABILITY, this machine will do a
lot of small builds, and small builds have a much higher chance of
being successful than bigger builds. Therefore, such a machine could
easily reach a very high success rate of builds, compared to a
machine running with a higher KCONFIG_PROBABILITY value. Thoughts on
this? Or people better in statistics than me to confirm or infirm my
reasoning?
> microblazeel | dialog-1.2-20140219 | NOK | http://autobuild.buildroot.net/results/5f9957a76381890a5efa5f52900592bf915550ce/
> x86_64 | dialog-1.2-20140219 | NOK | http://autobuild.buildroot.net/results/273539eaf9e930d0230a8c4b11e295733ab4f871/
> arm | dialog-1.2-20140219 | NOK | http://autobuild.buildroot.net/results/128abc06acbf7d4872bbebffd99f97c073237303/
> arm | dialog-1.2-20140219 | NOK | http://autobuild.buildroot.net/results/1bf4342d4aa1d49294a278f25322a00ee0d188ea/
> arm | dialog-1.2-20140219 | NOK | http://autobuild.buildroot.net/results/411f6171e972eab4486143dedbfd078136886ab0/
> arm | dialog-1.2-20140219 | NOK | http://autobuild.buildroot.net/results/365e6d1ef2faef546dd41b5c0a6ab04212b519dd/
> i686 | dialog-1.2-20140219 | NOK | http://autobuild.buildroot.net/results/072cb54fdbc246a97c6cfbf854a6e648779e9755/
> xtensa | dialog-1.2-20140219 | NOK | http://autobuild.buildroot.net/results/875ae36dff9fdd84f71f1177349d7c80adfb3f27/
> powerpc | dialog-1.2-20140219 | NOK | http://autobuild.buildroot.net/results/de6000fbe76fe5e8bd2832f090ddf81c09c9d8d8/
> arm | dialog-1.2-20140219 | NOK | http://autobuild.buildroot.net/results/0dd652d3caa212089caab0f962213d9938d9745e/
This is all fixed by
http://git.buildroot.net/buildroot/commit/?id=9c080f34076cdf48bcf72e1a1fbe2024b47a2694.
> powerpc | eigen-ffa86ffb5570 | NOK | http://autobuild.buildroot.net/results/d7daa7ac359c6bef85ea0c65c5318f3068159010/
Temporary failure of upstream Mercurial server + lack of the tarball on
sources.buildroot.net. I just checked, the upstream Mercurial server
works fine now.
> powerpc | gst1-plugins-good-1.2.4 | NOK | http://autobuild.buildroot.net/results/4f746cb9d8266abea2671718ad0f292763263873/
CC libgstvideo4linux2_la-gstv4l2sink.lo
gstv4l2object.c: In function 'gst_v4l2_object_set_format':
gstv4l2object.c:2384:23: error: 'union <anonymous>' has no member named 'pix_mp'
gstv4l2object.c:2385:24: error: 'union <anonymous>' has no member named 'pix_mp'
pix_mp was added in 2.6.39, and this toolchain uses older kernel
headers. So I propose to package this package depend on kernel headers
greater than 3.0. Even though that's not exactly correct, it's good enough, and
we decided to not have Config.in options for each of the 2.6 kernels. Is that OK ?
> mips64el | host-mysql-5.1.73 | NOK | http://autobuild.buildroot.net/results/cc99d4b8d0d83705071034bc72dd4e2efbb07acf/
Seems like it could be solved by
http://patchwork.ozlabs.org/patch/326425/. I'll try to reproduce in the
autobuilders to be sure.
> microblazeel | make: *** [core-dependencie... | NOK | http://autobuild.buildroot.net/results/30af5cd7f39fb556925321f9ce5c733a6688bc81/
That's an issue with the autobuilder infrastructure, ignore.
> mips64el | make: Leaving directory `/h... | NOK | http://autobuild.buildroot.net/results/16c9d9baf11082e6b7db8bc5076ee7c54ddbd164/
Same, ignore.
> i486 | make: Leaving directory `/h... | NOK | http://autobuild.buildroot.net/results/67f79482f8a80e63aca366df6d3ea232336c9ce1/
That's the same dialog issue, which is already fixed. The "reason" was
mis-detected due to slight variations in the format that caused the
logic on http://autobuild.buildroot.org to not recognized the correct
reason in the log file.
> arm | make[1]: *** [dialog] Error 1 | NOK | http://autobuild.buildroot.net/results/dae1d1cfff19f52ebdbf558b884cbe0a45cf2564/
Same.
> powerpc | make[2]: *** [opt] Terminated | TIM | http://autobuild.buildroot.net/results/b9f67e5b23032eb81be30107fda8104952bf775f/
A timeout on the private server.
> arm | oprofile-0.9.9 | NOK | http://autobuild.buildroot.net/results/549ef23ea1c9daeba8337b45ffabb254321c72e3/
../libutil++/libutil++.a(bfd_support.o): In function `bfd_info::get_synth_symbols()':
bfd_support.cpp:(.text+0x190c): undefined reference to `bfd_elf64_powerpc_vec'
bfd_support.cpp:(.text+0x1910): undefined reference to `bfd_elf64_powerpcle_vec'
collect2: error: ld returned 1 exit status
Looks weird. PowerPC symbols, but we're building for ARM. Why?
> bfin | snmppp-3.3.4 | NOK | http://autobuild.buildroot.net/results/ec2fa986493cf278681e9aa85d80356f9f3f15d1/
I investigated that: it builds fine with the gcc 4.3 Blackfin toolchain
(called stable), but not with the gcc 4.5 Blackfin toolchain (called
experimental). Maybe we should switch to use the gcc 4.3 Blackfin
toolchain by default. But on the other hand, that doesn't allow us to
detect issues and report them to ADI. That being said, when I look at
the toolchain bug tracker of ADI, it looks more like /dev/null that
anything really useful.
Suggestions?
> avr32 | wpa_supplicant-2.2 | NOK | http://autobuild.buildroot.net/results/20908f479b33c1e2952622f5e8ad6b60d58af693/
Baruch has already sent a patch disabling wpa_supplicant to avoid this
problem.
> bfin | xenomai-2.6.3 | NOK | http://autobuild.buildroot.net/results/db4f913a0dc9a0d8875cf3879e350837a73e26aa/
Many "error: inline function 'pthread_atfork' cannot be declared weak"
and similar messages for other functions.
> bfin | zeromq-4.0.4 | NOK | http://autobuild.buildroot.net/results/3af3d41ba5b60f30e3c9e7bcea33f52dc0c89cf2/
Exact same failure as snmpp.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-06-13 15:50 ` Eric Le Bihan
@ 2014-06-13 15:59 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-06-13 15:59 UTC (permalink / raw)
To: buildroot
Dear Eric Le Bihan,
On Fri, 13 Jun 2014 17:50:34 +0200, Eric Le Bihan wrote:
> > Ah, yes, right. Crazy that kernel headers as recent as 3.10 are needed
> > to build systemd...
> Systemd clearly misses some #ifdef's in some places to keep decent
> build requirements...
Yes :-)
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-06-13 15:07 ` Thomas Petazzoni
@ 2014-06-13 15:50 ` Eric Le Bihan
2014-06-13 15:59 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Eric Le Bihan @ 2014-06-13 15:50 UTC (permalink / raw)
To: buildroot
On Fri, Jun 13, 2014 at 05:07:26PM +0200, Thomas Petazzoni wrote:
> Dear Eric Le Bihan,
>
> On Fri, 13 Jun 2014 16:55:17 +0200, Eric Le Bihan wrote:
>
> > > Will be fixed by http://patchwork.ozlabs.org/patch/358913/.
> > This patch will only fix http://autobuild.buildroot.net/results/4b00d517c17cfcd29359e63423f15ac5331096b2/.
> >
> > The error in http://autobuild.buildroot.net/results/33e1447949d13bccc4076b69f902432e2131cc1c/ is:
> >
> > src/libsystemd/sd-rtnl/rtnl-types.c:70:10: error: 'IFLA_VLAN_PROTOCOL'
> > undeclared here (not in a function)
> > [IFLA_VLAN_PROTOCOL] = { .type = NLA_U16 },
> >
> > IFLA_VLAN_PROTOCOL was introduced in Linux 3.10. I'll post a patch updating
> > the kernel headers needs for systemd.
>
> Ah, yes, right. Crazy that kernel headers as recent as 3.10 are needed
> to build systemd...
Systemd clearly misses some #ifdef's in some places to keep decent
build requirements...
Best regards,
ELB
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-06-13 14:55 ` Eric Le Bihan
@ 2014-06-13 15:07 ` Thomas Petazzoni
2014-06-13 15:50 ` Eric Le Bihan
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-06-13 15:07 UTC (permalink / raw)
To: buildroot
Dear Eric Le Bihan,
On Fri, 13 Jun 2014 16:55:17 +0200, Eric Le Bihan wrote:
> > Will be fixed by http://patchwork.ozlabs.org/patch/358913/.
> This patch will only fix http://autobuild.buildroot.net/results/4b00d517c17cfcd29359e63423f15ac5331096b2/.
>
> The error in http://autobuild.buildroot.net/results/33e1447949d13bccc4076b69f902432e2131cc1c/ is:
>
> src/libsystemd/sd-rtnl/rtnl-types.c:70:10: error: 'IFLA_VLAN_PROTOCOL'
> undeclared here (not in a function)
> [IFLA_VLAN_PROTOCOL] = { .type = NLA_U16 },
>
> IFLA_VLAN_PROTOCOL was introduced in Linux 3.10. I'll post a patch updating
> the kernel headers needs for systemd.
Ah, yes, right. Crazy that kernel headers as recent as 3.10 are needed
to build systemd...
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-06-13 9:12 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2014-06-13 14:55 ` Eric Le Bihan
2014-06-13 15:07 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Eric Le Bihan @ 2014-06-13 14:55 UTC (permalink / raw)
To: buildroot
Hi!
On Fri, Jun 13, 2014 at 11:12:16AM +0200, Thomas Petazzoni wrote:
[...]
> On Fri, 13 Jun 2014 08:30:10 +0200 (CEST), Thomas Petazzoni wrote:
> > powerpc | systemd-213 | NOK | http://autobuild.buildroot.net/results/4b00d517c17cfcd29359e63423f15ac5331096b2/
> > i686 | systemd-213 | NOK | http://autobuild.buildroot.net/results/33e1447949d13bccc4076b69f902432e2131cc1c/
>
> Will be fixed by http://patchwork.ozlabs.org/patch/358913/.
This patch will only fix http://autobuild.buildroot.net/results/4b00d517c17cfcd29359e63423f15ac5331096b2/.
The error in http://autobuild.buildroot.net/results/33e1447949d13bccc4076b69f902432e2131cc1c/ is:
src/libsystemd/sd-rtnl/rtnl-types.c:70:10: error: 'IFLA_VLAN_PROTOCOL'
undeclared here (not in a function)
[IFLA_VLAN_PROTOCOL] = { .type = NLA_U16 },
IFLA_VLAN_PROTOCOL was introduced in Linux 3.10. I'll post a patch updating
the kernel headers needs for systemd.
Best regards,
ELB
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-06-13 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-06-12 Thomas Petazzoni
@ 2014-06-13 9:12 ` Thomas Petazzoni
2014-06-13 14:55 ` Eric Le Bihan
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-06-13 9:12 UTC (permalink / raw)
To: buildroot
Hello all,
On Fri, 13 Jun 2014 08:30:10 +0200 (CEST), Thomas Petazzoni wrote:
> Detail of failures
> ===================
>
> x86_64 | cosmo-14.03.04-1 | NOK | http://autobuild.buildroot.net/results/b39d026219e6c9c9accc8d3afc2e34c98ef3ca8c/
> i686 | cosmo-14.03.04-1 | NOK | http://autobuild.buildroot.net/results/44ee587b89f94eb8ed327d608f0b793234d38107/
> arm | cosmo-14.03.04-1 | NOK | http://autobuild.buildroot.net/results/63a5f2e3bdffbe90aef85357d24bfafb6e5bb8ea/
> powerpc | cosmo-14.03.04-1 | NOK | http://autobuild.buildroot.net/results/3b62508f5870a5edf145c223f74f68b42dcd8410/
> arm | cosmo-14.03.04-1 | NOK | http://autobuild.buildroot.net/results/f99b752ab7a85600839cc3a30b92d5001cf14d6c/
> mips64el | cosmo-14.03.04-1 | NOK | http://autobuild.buildroot.net/results/122239aa41a34be7e92b21d1801322e7c5053f66/
> sh4 | cosmo-14.03.04-1 | NOK | http://autobuild.buildroot.net/results/1ca98e95b106a948f1c0d0153a290ae1d9adb76d/
> arm | cosmo-14.03.04-1 | NOK | http://autobuild.buildroot.net/results/330e633ef9b4d7da4789529d97b14fb6a0673604/
Temporarily fixed by
http://git.buildroot.net/buildroot/commit/?id=acaaed7d70b1d624859d04290beff66d680e3ab0.
The problem need to be resolved upstream.
> bfin | gptfdisk-0.8.6 | NOK | http://autobuild.buildroot.net/results/9909d198ce14969d0e9d29a34fcc33f0ef79220d/
Will be fixed by http://patchwork.ozlabs.org/patch/359322/.
> bfin | libcurl-7.37.0 | NOK | http://autobuild.buildroot.net/results/ef95ff4f8c992ee901c676f3ba6e85bb74bc43f8/
Don't know:
checking for SSL_connect in -lssl... no
checking for ssl with RSAglue/rsaref libs in use... checking for SSL_connect in -lssl... (cached) no
no
configure: error: OpenSSL libs and/or directories were not found where specified!
make: *** [/home/test/test/3/output/build/libcurl-7.37.0/.stamp_configured] Error 1
> powerpc | minidlna-1.1.2 | NOK | http://autobuild.buildroot.net/results/7d10e2c13a1caf61b8bd18b85e5e5af50e5e7c48/
Will be fixed by http://patchwork.ozlabs.org/patch/359013/.
> avr32 | nbd-3.8 | NOK | http://autobuild.buildroot.net/results/ab620f1dfd5a47ac3cdc8a1afe1a467263c4e7d7/
Weird symbol redefinition, not sure it's AVR32 specific:
./.libs/libnbdsrv.a(libnbdsrv_la-nbdsrv.o): In function `ntohll':
nbdsrv.c:(.text+0x0): multiple definition of `ntohll'
nbd_server-nbd-server.o:nbd-server.c:(.text+0x0): first defined here
> bfin | popt-1.16 | NOK | http://autobuild.buildroot.net/results/35792bc86ca65fc2ca06db4a16ceef670489e9f7/
Might again be GNU Glob support missing from Blackfin toolchain, to be
verified:
./.libs/libpopt.a(poptconfig.o): In function `_poptGlob.clone.0':
poptconfig.c:(.text+0x36): undefined reference to `_glob_pattern_p'
./.libs/libpopt.a(poptconfig.o): In function `_poptReadConfigFile':
poptconfig.c:(.text+0x2f8): undefined reference to `_glob_pattern_p'
collect2: ld returned 1 exit status
We need help from Blackfin/ADI people here.
> arc | pulseaudio-5.0 | NOK | http://autobuild.buildroot.net/results/8cb5f5258e192feeb896b5c9d4da3f616add8203/
Weird:
checking for ltdl.h... yes
checking for lt_dladvise_init in -lltdl... no
configure: error: Unable to find libltdl version 2. Makes sure you have libtool 2.4 or later installed.
make: *** [/home/test/test/3/output/build/pulseaudio-5.0/.stamp_configured] Error 1
> powerpc | systemd-213 | NOK | http://autobuild.buildroot.net/results/4b00d517c17cfcd29359e63423f15ac5331096b2/
> i686 | systemd-213 | NOK | http://autobuild.buildroot.net/results/33e1447949d13bccc4076b69f902432e2131cc1c/
Will be fixed by http://patchwork.ozlabs.org/patch/358913/.
> bfin | zeromq-4.0.4 | NOK | http://autobuild.buildroot.net/results/74426d3150e9c7a98371d0058d78df7630770026/
/home/test/test/1/output/host/opt/ext-toolchain/bfin-linux-uclibc/bin/../lib/gcc/bfin-linux-uclibc/4.5.3/../../../../bfin-linux-uclibc/bin/ld: remote_lat: hidden symbol `___umulsi3_highpart' in /home/test/test/1/output/host/opt/ext-toolchain/bfin-linux-uclibc/bin/../lib/gcc/bfin-linux-uclibc/4.5.3/libgcc.a(_umulsi3_highpart.o) is referenced by DSO
/home/test/test/1/output/host/opt/ext-toolchain/bfin-linux-uclibc/bin/../lib/gcc/bfin-linux-uclibc/4.5.3/../../../../bfin-linux-uclibc/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
We need help from Blackfin/ADI people here.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-05-09 13:34 ` Ezequiel Garcia
@ 2014-05-09 19:06 ` Frank Bergmann
0 siblings, 0 replies; 416+ messages in thread
From: Frank Bergmann @ 2014-05-09 19:06 UTC (permalink / raw)
To: buildroot
On 09.05.2014 15:34, Ezequiel Garcia wrote:
> On 07 May 09:31 AM, Thomas Petazzoni wrote:
>>> nios2 | fio-fio-2.1.4 | NOK | http://autobuild.buildroot.net/results/9cd30031a40f768f6090cfba44c880fb2406672b/
>>
>> Ezequiel?
>>
>
> fio does a configure-time test to see if fallocate() is there, which passes
> successfully. Then BR builds fio passing LARGE_FILE flags which makes the
> toolchain try fallocate64(), which is not implemented.
>
> However, I'm not sure how to either make the configure-time fallocate test
> fail (so fio knows there's no fallocate), or prevent BR from passing the
> LARGE_FILE flags.
>
> Disable fio for nios2?
Or patch away the fallocate function in the configure script for nios2
like the patch in attachment do ?
With regards,
Frank Bergmann.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-fio-fix-missing-fallocate64.patch
Type: text/x-patch
Size: 2185 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140509/0a686dff/attachment.bin>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-05-07 7:31 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (2 preceding siblings ...)
2014-05-08 23:24 ` Arnout Vandecappelle
@ 2014-05-09 13:34 ` Ezequiel Garcia
2014-05-09 19:06 ` Frank Bergmann
3 siblings, 1 reply; 416+ messages in thread
From: Ezequiel Garcia @ 2014-05-09 13:34 UTC (permalink / raw)
To: buildroot
On 07 May 09:31 AM, Thomas Petazzoni wrote:
> > nios2 | fio-fio-2.1.4 | NOK | http://autobuild.buildroot.net/results/9cd30031a40f768f6090cfba44c880fb2406672b/
>
> Ezequiel?
>
fio does a configure-time test to see if fallocate() is there, which passes
successfully. Then BR builds fio passing LARGE_FILE flags which makes the
toolchain try fallocate64(), which is not implemented.
However, I'm not sure how to either make the configure-time fallocate test
fail (so fio knows there's no fallocate), or prevent BR from passing the
LARGE_FILE flags.
Disable fio for nios2?
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-05-07 7:31 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-05-07 8:04 ` Will Newton
2014-05-07 9:04 ` Peter Seiderer
@ 2014-05-08 23:24 ` Arnout Vandecappelle
2014-05-09 13:34 ` Ezequiel Garcia
3 siblings, 0 replies; 416+ messages in thread
From: Arnout Vandecappelle @ 2014-05-08 23:24 UTC (permalink / raw)
To: buildroot
On 07/05/14 09:31, Thomas Petazzoni wrote:
>> arm | zeromq-4.0.4 | NOK | http://autobuild.buildroot.net/results/7c552e514f8c13ba8cdd420dc5bbf5edac915a83/
> Oh maan, I hate C++ errors. Any C++ person in the place to explain
> what's going on? Might be related to BR2_PREFER_STATIC_LIB.
The issue is that the curve_keygen tool is written in C, but the zeromq library
itself is C++. Therefore, it needs to be linked with libstdc++. With dynamic
linking, the ELF dependencies will take care of that, but with static linking,
it has to be added explicitly. And it looks like libtool doesn't find that
dependency on libstdc++.
Renaming curve_keygen.c to curve_keygen.cpp and adjusting Makefile.am
accordingly solves it, but I'm not sure if that is the best solution...
Oh well, adding LIBS=-lstdc++ works as well...
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-05-07 9:04 ` Peter Seiderer
2014-05-07 9:06 ` Thomas Petazzoni
@ 2014-05-07 13:04 ` Peter Korsgaard
1 sibling, 0 replies; 416+ messages in thread
From: Peter Korsgaard @ 2014-05-07 13:04 UTC (permalink / raw)
To: buildroot
>>>>> "Peter" == Peter Seiderer <ps.report@gmx.net> writes:
> Hello Thomas,
>> Gesendet: Mittwoch, 07. Mai 2014 um 09:31 Uhr
>> Von: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>
>> An: buildroot at uclibc.org, "Ezequiel Garcia" <ezequiel.garcia@free-electrons.com>, "Peter Seiderer" <ps.report@gmx.net>
>> Betreff: Analysis of build failures
>>
>> Hello all,
>>
> [...]
>> > x86_64 | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/992c17e43664e8f2dfdfe711c1b0a43ebc21af90/
>> > mips64el | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/2bbc9606281f4c96a264c5e1daa50f7957315047/
>> > powerpc | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/0162d66ddbfe7f240819eaee9e76bbd0a0ad7e7f/
>> > sh4a | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/d1f2083608540e9b7f778a25d54b94bdb582eca1/
>>
>> Peter (Seiderer), could have a look at these? This issue has been
>> hitting the autobuilders since many days, we really need to get it
>> fixed.
>>
> should be fixed by proposed patch
> http://lists.busybox.net/pipermail/buildroot/2014-April/094830.html
Committed, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-05-07 9:23 ` Thomas De Schampheleire
@ 2014-05-07 9:26 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-05-07 9:26 UTC (permalink / raw)
To: buildroot
Dear Thomas De Schampheleire,
On Wed, 7 May 2014 11:23:05 +0200, Thomas De Schampheleire wrote:
> > Hum, weird. I though it had been committed, but it isn't. And I don't
> > see it in patchwork either. Can you resend it?
>
> It is marked as "Accepted" in patchwork:
> http://patchwork.ozlabs.org/patch/341386/
>
> but indeed does not seem to applied in the tree...
>
> Peter Korsgaard: any idea what went wrong? Could you reapply this patch?
It might have been me who screwed on this. I'm pretty sure this patch
was submitted when I was in charge of the patch merging. I think I did
apply it, but apparently not.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-05-07 9:06 ` Thomas Petazzoni
@ 2014-05-07 9:23 ` Thomas De Schampheleire
2014-05-07 9:26 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Thomas De Schampheleire @ 2014-05-07 9:23 UTC (permalink / raw)
To: buildroot
Hi,
On Wed, May 7, 2014 at 11:06 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Peter Seiderer,
>
> On Wed, 7 May 2014 11:04:04 +0200, Peter Seiderer wrote:
>
>> > > x86_64 | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/992c17e43664e8f2dfdfe711c1b0a43ebc21af90/
>> > > mips64el | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/2bbc9606281f4c96a264c5e1daa50f7957315047/
>> > > powerpc | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/0162d66ddbfe7f240819eaee9e76bbd0a0ad7e7f/
>> > > sh4a | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/d1f2083608540e9b7f778a25d54b94bdb582eca1/
>> >
>> > Peter (Seiderer), could have a look at these? This issue has been
>> > hitting the autobuilders since many days, we really need to get it
>> > fixed.
>> >
>>
>> should be fixed by proposed patch
>> http://lists.busybox.net/pipermail/buildroot/2014-April/094830.html
>
> Hum, weird. I though it had been committed, but it isn't. And I don't
> see it in patchwork either. Can you resend it?
It is marked as "Accepted" in patchwork:
http://patchwork.ozlabs.org/patch/341386/
but indeed does not seem to applied in the tree...
Peter Korsgaard: any idea what went wrong? Could you reapply this patch?
Best regards,
Thomas
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-05-07 9:04 ` Peter Seiderer
@ 2014-05-07 9:06 ` Thomas Petazzoni
2014-05-07 9:23 ` Thomas De Schampheleire
2014-05-07 13:04 ` Peter Korsgaard
1 sibling, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-05-07 9:06 UTC (permalink / raw)
To: buildroot
Dear Peter Seiderer,
On Wed, 7 May 2014 11:04:04 +0200, Peter Seiderer wrote:
> > > x86_64 | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/992c17e43664e8f2dfdfe711c1b0a43ebc21af90/
> > > mips64el | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/2bbc9606281f4c96a264c5e1daa50f7957315047/
> > > powerpc | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/0162d66ddbfe7f240819eaee9e76bbd0a0ad7e7f/
> > > sh4a | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/d1f2083608540e9b7f778a25d54b94bdb582eca1/
> >
> > Peter (Seiderer), could have a look at these? This issue has been
> > hitting the autobuilders since many days, we really need to get it
> > fixed.
> >
>
> should be fixed by proposed patch
> http://lists.busybox.net/pipermail/buildroot/2014-April/094830.html
Hum, weird. I though it had been committed, but it isn't. And I don't
see it in patchwork either. Can you resend it?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-05-07 7:31 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-05-07 8:04 ` Will Newton
@ 2014-05-07 9:04 ` Peter Seiderer
2014-05-07 9:06 ` Thomas Petazzoni
2014-05-07 13:04 ` Peter Korsgaard
2014-05-08 23:24 ` Arnout Vandecappelle
2014-05-09 13:34 ` Ezequiel Garcia
3 siblings, 2 replies; 416+ messages in thread
From: Peter Seiderer @ 2014-05-07 9:04 UTC (permalink / raw)
To: buildroot
Hello Thomas,
> Gesendet: Mittwoch, 07. Mai 2014 um 09:31 Uhr
> Von: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>
> An: buildroot at uclibc.org, "Ezequiel Garcia" <ezequiel.garcia@free-electrons.com>, "Peter Seiderer" <ps.report@gmx.net>
> Betreff: Analysis of build failures
>
> Hello all,
>
[...]
> > x86_64 | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/992c17e43664e8f2dfdfe711c1b0a43ebc21af90/
> > mips64el | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/2bbc9606281f4c96a264c5e1daa50f7957315047/
> > powerpc | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/0162d66ddbfe7f240819eaee9e76bbd0a0ad7e7f/
> > sh4a | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/d1f2083608540e9b7f778a25d54b94bdb582eca1/
>
> Peter (Seiderer), could have a look at these? This issue has been
> hitting the autobuilders since many days, we really need to get it
> fixed.
>
should be fixed by proposed patch
http://lists.busybox.net/pipermail/buildroot/2014-April/094830.html
Regards,
Peter
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-05-07 8:04 ` Will Newton
@ 2014-05-07 8:58 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-05-07 8:58 UTC (permalink / raw)
To: buildroot
Dear Will Newton,
On Wed, 7 May 2014 09:04:11 +0100, Will Newton wrote:
> >> aarch64 | glibc-2.18-svnr23787 | NOK | http://autobuild.buildroot.net/results/bd0aefa1b1efb1a28d2af89a983b389ed2aeeff5/
> >> aarch64 | glibc-2.18-svnr23787 | NOK | http://autobuild.buildroot.net/results/a0679d22dde393a8daa2e109e2438100e36e982d/
> >> aarch64 | glibc-2.18-svnr23787 | NOK | http://autobuild.buildroot.net/results/1b19e911ff26d53708ac107e271d179e0e913735/
> >
> > Ok, on these ones, I have some news. It turns out that I tried to
> > reproduce the build issue on the *new* build server, while in fact the
> > autobuilds were still running on the *old* one. However, I restarted
> > the autobuilds on the new build server, and it has reported new
> > glibc/aarch64 failures... which I'm not able to reproduce.
No: they are the same ld segfault issue. You can access the logs by
using the links above, and read the "build-end.log" file.
I saw your e-mail suggesting that to test a binutils patch. The only
thing that surprises me here is that this issue is 100% reproducible
when executed by the autobuilder script, but does not occur when I do a
separate build (however in the same machine, same chroot as the
autobuilder script).
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-05-07 7:31 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2014-05-07 8:04 ` Will Newton
2014-05-07 8:58 ` Thomas Petazzoni
2014-05-07 9:04 ` Peter Seiderer
` (2 subsequent siblings)
3 siblings, 1 reply; 416+ messages in thread
From: Will Newton @ 2014-05-07 8:04 UTC (permalink / raw)
To: buildroot
On Wed, May 7, 2014 at 8:31 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello all,
>
> On Wed, 7 May 2014 08:30:09 +0200 (CEST), Thomas Petazzoni wrote:
>
>> arm | bustle-0.4.3 | NOK | http://autobuild.buildroot.net/results/400f86cd3c5e418a05089f7a58ecc1cf436ac810/
>
> BR2_PREFER_STATIC_LIB related build failure.
>
>> powerpc | clapack-3.2.1 | NOK | http://autobuild.buildroot.net/results/d1d721fa697956218dfc2c865dfb61911cf2600e/
>> mipsel | clapack-3.2.1 | NOK | http://autobuild.buildroot.net/results/518ed5822cfd88468f5600f3053699e1b06d7245/
>> powerpc | clapack-3.2.1 | NOK | http://autobuild.buildroot.net/results/0d7ea169ab8b2da946ec4444d6e3db1a352c08ff/
>> powerpc | clapack-3.2.1 | NOK | http://autobuild.buildroot.net/results/6e14fa44622e8e4e16cceee591389b07517f6aeb/
>
> Fixed by the patch proposed at http://patchwork.ozlabs.org/patch/346307/.
>
>> i686 | configure: WARNING: unrecog... | NOK | http://autobuild.buildroot.net/results/dab457f00dcf6fdb5a5081291eb9ebaaadbfe7c0/
>
> I think this might be a spurious error: I was doing some maintenance on
> the autobuild server.
>
>> nios2 | fio-fio-2.1.4 | NOK | http://autobuild.buildroot.net/results/9cd30031a40f768f6090cfba44c880fb2406672b/
>
> Ezequiel?
>
>> x86_64 | fltk-1.3.2 | NOK | http://autobuild.buildroot.net/results/2253f1efb8da80f30615535724f6b444a38e7fea/
>
> XCB related issue:
>
> /home/test/test/3/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/libxcb-shm.so.0: undefined reference to `xcb_get_reply_fds'
> /home/test/test/3/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/libxcb-render.so.0: undefined reference to `xcb_str_sizeof'
> /home/test/test/3/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
>
>> aarch64 | glibc-2.18-svnr23787 | NOK | http://autobuild.buildroot.net/results/bd0aefa1b1efb1a28d2af89a983b389ed2aeeff5/
>> aarch64 | glibc-2.18-svnr23787 | NOK | http://autobuild.buildroot.net/results/a0679d22dde393a8daa2e109e2438100e36e982d/
>> aarch64 | glibc-2.18-svnr23787 | NOK | http://autobuild.buildroot.net/results/1b19e911ff26d53708ac107e271d179e0e913735/
>
> Ok, on these ones, I have some news. It turns out that I tried to
> reproduce the build issue on the *new* build server, while in fact the
> autobuilds were still running on the *old* one. However, I restarted
> the autobuilds on the new build server, and it has reported new
> glibc/aarch64 failures... which I'm not able to reproduce.
Are these new failures different from those above? If you have logs I
will happily take a look.
>> arm | lttng-tools-2.4.1 | NOK | http://autobuild.buildroot.net/results/f1982b05693fe3c6939729f7008afdc56a58e7c3/
>> arm | lttng-tools-2.4.1 | NOK | http://autobuild.buildroot.net/results/6e25c8c64756ac6515a91ad4238de977773b67be/
>
> Compiler problem. As soon as 2014.05-rc1 is released, I'll rebuild the
> Buildroot external toolchains, so that they will have the relevant gcc
> fix for this.
>
>> bfin | make: *** [host-gdb-legal-i... | NOK | http://autobuild.buildroot.net/results/753570793be3f35bdf9b344af7252607a82c3b60/
>
> Easy to fix.
>
>> arm | opencv-2.4.2 | NOK | http://autobuild.buildroot.net/results/ee6187d85c84af382e54b0c9c16ee0e8ec45d0a6/
>
> Another compiler issue, but it's with an old Crosstool-NG toolchain.
> With the switch to the new Crosstool-NG toolchains, hopefully, this
> shouldn't happen anymore.
>
>> bfin | popt-1.16 | NOK | http://autobuild.buildroot.net/results/bfcb2ed27debafc584e133f5ae11ad2061ad2b16/
>
> Already fixed.
>
>> x86_64 | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/992c17e43664e8f2dfdfe711c1b0a43ebc21af90/
>> mips64el | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/2bbc9606281f4c96a264c5e1daa50f7957315047/
>> powerpc | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/0162d66ddbfe7f240819eaee9e76bbd0a0ad7e7f/
>> sh4a | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/d1f2083608540e9b7f778a25d54b94bdb582eca1/
>
> Peter (Seiderer), could have a look at these? This issue has been
> hitting the autobuilders since many days, we really need to get it
> fixed.
>
>> arm | zeromq-4.0.4 | NOK | http://autobuild.buildroot.net/results/7c552e514f8c13ba8cdd420dc5bbf5edac915a83/
>
> Oh maan, I hate C++ errors. Any C++ person in the place to explain
> what's going on? Might be related to BR2_PREFER_STATIC_LIB.
>
>> arm | znc-b396cafdb249544164ed029... | NOK | http://autobuild.buildroot.net/results/53e97320fcbad6e51a0bc5183c03a00f86ba86ae/
>
> I have a patch for this one, I hope to send it today.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-05-07 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-05-06 Thomas Petazzoni
@ 2014-05-07 7:31 ` Thomas Petazzoni
2014-05-07 8:04 ` Will Newton
` (3 more replies)
0 siblings, 4 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-05-07 7:31 UTC (permalink / raw)
To: buildroot
Hello all,
On Wed, 7 May 2014 08:30:09 +0200 (CEST), Thomas Petazzoni wrote:
> arm | bustle-0.4.3 | NOK | http://autobuild.buildroot.net/results/400f86cd3c5e418a05089f7a58ecc1cf436ac810/
BR2_PREFER_STATIC_LIB related build failure.
> powerpc | clapack-3.2.1 | NOK | http://autobuild.buildroot.net/results/d1d721fa697956218dfc2c865dfb61911cf2600e/
> mipsel | clapack-3.2.1 | NOK | http://autobuild.buildroot.net/results/518ed5822cfd88468f5600f3053699e1b06d7245/
> powerpc | clapack-3.2.1 | NOK | http://autobuild.buildroot.net/results/0d7ea169ab8b2da946ec4444d6e3db1a352c08ff/
> powerpc | clapack-3.2.1 | NOK | http://autobuild.buildroot.net/results/6e14fa44622e8e4e16cceee591389b07517f6aeb/
Fixed by the patch proposed at http://patchwork.ozlabs.org/patch/346307/.
> i686 | configure: WARNING: unrecog... | NOK | http://autobuild.buildroot.net/results/dab457f00dcf6fdb5a5081291eb9ebaaadbfe7c0/
I think this might be a spurious error: I was doing some maintenance on
the autobuild server.
> nios2 | fio-fio-2.1.4 | NOK | http://autobuild.buildroot.net/results/9cd30031a40f768f6090cfba44c880fb2406672b/
Ezequiel?
> x86_64 | fltk-1.3.2 | NOK | http://autobuild.buildroot.net/results/2253f1efb8da80f30615535724f6b444a38e7fea/
XCB related issue:
/home/test/test/3/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/libxcb-shm.so.0: undefined reference to `xcb_get_reply_fds'
/home/test/test/3/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/libxcb-render.so.0: undefined reference to `xcb_str_sizeof'
/home/test/test/3/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
> aarch64 | glibc-2.18-svnr23787 | NOK | http://autobuild.buildroot.net/results/bd0aefa1b1efb1a28d2af89a983b389ed2aeeff5/
> aarch64 | glibc-2.18-svnr23787 | NOK | http://autobuild.buildroot.net/results/a0679d22dde393a8daa2e109e2438100e36e982d/
> aarch64 | glibc-2.18-svnr23787 | NOK | http://autobuild.buildroot.net/results/1b19e911ff26d53708ac107e271d179e0e913735/
Ok, on these ones, I have some news. It turns out that I tried to
reproduce the build issue on the *new* build server, while in fact the
autobuilds were still running on the *old* one. However, I restarted
the autobuilds on the new build server, and it has reported new
glibc/aarch64 failures... which I'm not able to reproduce.
> arm | lttng-tools-2.4.1 | NOK | http://autobuild.buildroot.net/results/f1982b05693fe3c6939729f7008afdc56a58e7c3/
> arm | lttng-tools-2.4.1 | NOK | http://autobuild.buildroot.net/results/6e25c8c64756ac6515a91ad4238de977773b67be/
Compiler problem. As soon as 2014.05-rc1 is released, I'll rebuild the
Buildroot external toolchains, so that they will have the relevant gcc
fix for this.
> bfin | make: *** [host-gdb-legal-i... | NOK | http://autobuild.buildroot.net/results/753570793be3f35bdf9b344af7252607a82c3b60/
Easy to fix.
> arm | opencv-2.4.2 | NOK | http://autobuild.buildroot.net/results/ee6187d85c84af382e54b0c9c16ee0e8ec45d0a6/
Another compiler issue, but it's with an old Crosstool-NG toolchain.
With the switch to the new Crosstool-NG toolchains, hopefully, this
shouldn't happen anymore.
> bfin | popt-1.16 | NOK | http://autobuild.buildroot.net/results/bfcb2ed27debafc584e133f5ae11ad2061ad2b16/
Already fixed.
> x86_64 | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/992c17e43664e8f2dfdfe711c1b0a43ebc21af90/
> mips64el | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/2bbc9606281f4c96a264c5e1daa50f7957315047/
> powerpc | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/0162d66ddbfe7f240819eaee9e76bbd0a0ad7e7f/
> sh4a | postgresql-9.3.4 | NOK | http://autobuild.buildroot.net/results/d1f2083608540e9b7f778a25d54b94bdb582eca1/
Peter (Seiderer), could have a look at these? This issue has been
hitting the autobuilders since many days, we really need to get it
fixed.
> arm | zeromq-4.0.4 | NOK | http://autobuild.buildroot.net/results/7c552e514f8c13ba8cdd420dc5bbf5edac915a83/
Oh maan, I hate C++ errors. Any C++ person in the place to explain
what's going on? Might be related to BR2_PREFER_STATIC_LIB.
> arm | znc-b396cafdb249544164ed029... | NOK | http://autobuild.buildroot.net/results/53e97320fcbad6e51a0bc5183c03a00f86ba86ae/
I have a patch for this one, I hope to send it today.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-07 8:30 ` Thomas Petazzoni
@ 2014-03-10 21:27 ` Romain Naour
0 siblings, 0 replies; 416+ messages in thread
From: Romain Naour @ 2014-03-10 21:27 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Le 07/03/2014 09:30, Thomas Petazzoni a ?crit :
> Dear Romain Naour,
>
> On Fri, 07 Mar 2014 01:44:15 +0100, Romain Naour wrote:
>
>> It seems that __ELF__ has been removed from gcc
> I don't really the relation between this statement you're making.
>
>> http://gcc.gnu.org/gcc-4.9/changes.html
>> "Support for a number of older systems and recently unmaintained or
>> untested target ports of GCC has been declared obsolete in GCC 4.9"
> And this statement.
I'm sorry, I spoke too hastily...
Curiosity brought me to look at this problem and find where __ELF__ was
defined.
But this is the first time I look at the code of gcc, so I could be wrong.
>> (version 4.9.0)
>> ./microblaze-buildroot-linux-gnu-cpp -dM /dev/null | grep __ELF__
>>
>> (version 4.7.2)
>> (code sourcery toolchain x86)
>> ./i686-pc-linux-gnu-cpp -dM /dev/null | grep __ELF__
>> #define __ELF__ 1
>>
>> (version 4.8.2)
>> (buildroot internal toolchain x86)
>> ./i686-buildroot-linux-gnu-cpp -dM /dev/null | grep __ELF__
>> #define __ELF__ 1
> And a x86 toolchain with gcc 4.9.x ?
(version 4.9.0-20140302)
./i686-buildroot-linux-gnu-cpp -dM /dev/null | grep __ELF__
#define __ELF__ 1
Ok, it'snot a problem related to gcc version...
I found an discussion about missing elfos.h in config.gcc for microblaze :
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01341.html
This header add a macro that define __ELF__ with builtin_define ("__ELF__").
So, I don't know how to solve this problem properly except placing
"builtin_define ("__ELF__")" in gcc/config/microblaze/microblaze-c.c
Really need a gcc/microblaze specialist here...
>> I'll send a patch to remove this test since buildroot does not have
>> support for non ELF system.
> That's not true: we support Blackfin FLAT, which is not an ELF binary
> format.
>
> Thomas
Understood, thank you for your explanation.
Best regards,
Romain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140310/235aca92/attachment.html>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-07 0:44 ` Romain Naour
@ 2014-03-07 8:30 ` Thomas Petazzoni
2014-03-10 21:27 ` Romain Naour
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-03-07 8:30 UTC (permalink / raw)
To: buildroot
Dear Romain Naour,
On Fri, 07 Mar 2014 01:44:15 +0100, Romain Naour wrote:
> It seems that __ELF__ has been removed from gcc
I don't really the relation between this statement you're making.
> http://gcc.gnu.org/gcc-4.9/changes.html
> "Support for a number of older systems and recently unmaintained or
> untested target ports of GCC has been declared obsolete in GCC 4.9"
And this statement.
>
> (version 4.9.0)
> ./microblaze-buildroot-linux-gnu-cpp -dM /dev/null | grep __ELF__
>
> (version 4.7.2)
> (code sourcery toolchain x86)
> ./i686-pc-linux-gnu-cpp -dM /dev/null | grep __ELF__
> #define __ELF__ 1
>
> (version 4.8.2)
> (buildroot internal toolchain x86)
> ./i686-buildroot-linux-gnu-cpp -dM /dev/null | grep __ELF__
> #define __ELF__ 1
And a x86 toolchain with gcc 4.9.x ?
> I'll send a patch to remove this test since buildroot does not have
> support for non ELF system.
That's not true: we support Blackfin FLAT, which is not an ELF binary
format.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-03 12:48 ` Thomas Petazzoni
@ 2014-03-07 0:44 ` Romain Naour
2014-03-07 8:30 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Romain Naour @ 2014-03-07 0:44 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Le 03/03/2014 13:48, Thomas Petazzoni a ?crit :
> Dear Romain Naour,
>
> On Mon, 3 Mar 2014 12:31:45 +0100 (CET), Romain Naour wrote:
>
>> |
>> | > microblaze | gpm-1.20.7 | NOK |
>> | > http://autobuild.buildroot.net/results/e99afadca6de92aad8563006fc7219aa32d77a88/
>> |
>> | Strange:
>> |
>> | /home/test/test/2/output/host/usr/bin/microblaze-buildroot-linux-gnu-gcc
>> | libgpm.so.2 \
>> | -L/home/test/test/2/output/build/gpm-1.20.7/src -o
>> | lib/libgpm.so.2.1.0 lib/liblow.lo lib/libhigh.lo lib/libxtra.lo
>> | lib/report-lib.lo tools.lo -lc
>> | microblaze-buildroot-linux-gnu-gcc: error: libgpm.so.2: No such file
>> | or directory
>> |
>> | Spenser ?
>>
>> It's because __ELF__ is not defined in microblaze toolchain :
>> checking whether system is ELF... no
>>
>> If elf format is not enabled then gpm is build statically.
>> You may have noticed that qpm static build is disabled in gpm.mk because it's broken.
>>
>> I can try to fix gpm's static build.
> Hum, but that's weird because Microblaze definitely uses the ELF binary
> format, supports shared library and has a MMU (at least for the
> Microblaze CPU variants that we support).
>
> So it should be working in shared library mode, I believe.
>
> Thomas
It seems that __ELF__ has been removed from gcc
http://gcc.gnu.org/gcc-4.9/changes.html
"Support for a number of older systems and recently unmaintained or
untested target ports of GCC has been declared obsolete in GCC 4.9"
(version 4.9.0)
./microblaze-buildroot-linux-gnu-cpp -dM /dev/null | grep __ELF__
(version 4.7.2)
(code sourcery toolchain x86)
./i686-pc-linux-gnu-cpp -dM /dev/null | grep __ELF__
#define __ELF__ 1
(version 4.8.2)
(buildroot internal toolchain x86)
./i686-buildroot-linux-gnu-cpp -dM /dev/null | grep __ELF__
#define __ELF__ 1
I'll send a patch to remove this test since buildroot does not have
support for non ELF system.
Best regards,
Romain
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-05 10:27 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-03-05 10:29 ` Alvaro Gamez
@ 2014-03-05 15:01 ` Samuel Martin
1 sibling, 0 replies; 416+ messages in thread
From: Samuel Martin @ 2014-03-05 15:01 UTC (permalink / raw)
To: buildroot
On Wed, Mar 5, 2014 at 11:27 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
[...]
>> arm | gst1-plugins-bad-1.2.3 | NOK | http://autobuild.buildroot.net/results/ac98e35736532c697e1c08e23e1d6800c951ea23/
>> arm | gst1-plugins-bad-1.2.3 | NOK | http://autobuild.buildroot.net/results/d02e1843ef90f4b40c99e3b23eddf376f827d46e/
>> arm | gst1-plugins-bad-1.2.3 | NOK | http://autobuild.buildroot.net/results/51ea53c39e6c067760c2d1e9c0c7b7bfbbe28be8/
>
> OpenCV problem, to be looked at by Samuel I believe:
>
> /home/test/test/3/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/opencv/cv.h:72:37: fatal error: opencv2/legacy/compat.hpp: No such file or directory
Roger that!
I'll look at it soon.
Regards,
--
Samuel
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-05 14:37 ` Alvaro Gamez
@ 2014-03-05 14:42 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-03-05 14:42 UTC (permalink / raw)
To: buildroot
Dear Alvaro Gamez,
On Wed, 5 Mar 2014 15:37:09 +0100, Alvaro Gamez wrote:
> I've discovered there is a race condition on libxmlrpc Makefile set.
> When I sent this patch I tested it on a single core machine, but when
> running on a multicore machine, buildroot has set my jobs level to 4, the
> same as in the build failure above.
>
> So, when invoking make -j 1, libxmlrpc builds fine, but with -j 4 it fails.
>
> Upstream tries to support parallel builds, but it still fails due to this
> reason.
>
> I face two options here: should I repair upstream's set of Makefile's or
> should I patch buildroots' libxmlrpc.mk in order to force linear build? Is
> this even possible, or a good practice, to change BR2_JLEVEL inside
> libxmlrpc.mk to avoid this?
No, but the good way is:
LIBXMLRPC_MAKE = $(MAKE1)
This disables the parallel build specifically for libxmlrpc.
> Anyway, I think I'm going to try and fix libxmlrpc makefiles, for it seems
> to be, although not the fastest approach, the best way for all users of
> libxmlrpc, but I am open to modify buildroots' libxmlrpc.mk in order to fix
> this by changing JLEVEL as soon as possible.
Usually, we do one or the other solution depending on whether the patch
to fix the parallel build problem is complicated or not. If it's not,
and there is a chance to get it merged by upstream, then it's usually
the preferred solution I would say.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-05 10:29 ` Alvaro Gamez
@ 2014-03-05 14:37 ` Alvaro Gamez
2014-03-05 14:42 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Alvaro Gamez @ 2014-03-05 14:37 UTC (permalink / raw)
To: buildroot
Hi all
2014-03-05 11:27 GMT+01:00 Thomas Petazzoni <
thomas.petazzoni@free-electrons.com>:
>
>
> /home/test/test/1/output/host/usr/bin/sh-linux-gnu-gcc -shared
>> -Wl,-soname,libxmlrpc_xmltok.so.3 xmltok.osh xmlrole.osh -o
>> libxmlrpc_xmltok.so.3.25
>> xmltok.osh: file not recognized: File truncated
>> collect2: error: ld returned 1 exit status
>>
>
I've discovered there is a race condition on libxmlrpc Makefile set.
When I sent this patch I tested it on a single core machine, but when
running on a multicore machine, buildroot has set my jobs level to 4, the
same as in the build failure above.
So, when invoking make -j 1, libxmlrpc builds fine, but with -j 4 it fails.
Upstream tries to support parallel builds, but it still fails due to this
reason.
I face two options here: should I repair upstream's set of Makefile's or
should I patch buildroots' libxmlrpc.mk in order to force linear build? Is
this even possible, or a good practice, to change BR2_JLEVEL inside
libxmlrpc.mk to avoid this?
Anyway, I think I'm going to try and fix libxmlrpc makefiles, for it seems
to be, although not the fastest approach, the best way for all users of
libxmlrpc, but I am open to modify buildroots' libxmlrpc.mk in order to fix
this by changing JLEVEL as soon as possible.
Regards
--
?lvaro G?mez Machado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140305/727ed019/attachment.html>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-05 10:10 ` Arnout Vandecappelle
@ 2014-03-05 12:40 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-03-05 12:40 UTC (permalink / raw)
To: buildroot
Dear Arnout Vandecappelle,
On Wed, 05 Mar 2014 11:10:44 +0100, Arnout Vandecappelle wrote:
> > Indeed, DT_RUNPATH would fix the problem, but to me it feels more like
> > a workaround than a real fix, no? Wouldn't the real fix be to ensure
> > that the installation is atomic, i.e either the library is present in
> > $(HOST_DIR)/usr/lib, or it is not? The problem here apparently occurs
> > when Python is executed when the library file already exists in
> > $(HOST_DIR)/usr/lib, but its copy hasn't finished yet.
>
> In this case, that happens to be the problem. But in general, it is
> possible that there is already an old version of the library in
> $(HOST_DIR)/usr/lib, and then that one will be used instead of the newly
> built one. Nothing catastrophic, but still wrong.
Right.
> The thing is, RPATH was just a mistake to begin with: you _always_ want
> LD_LIBRARY_PATH to take precedence over RPATH, otherwise LD_LIBRARY_PATH
> doesn't make much sense. That's why I think that adding
> --enable-new-dtags unconditionally for all builds would be a great idea.
True. So we should add --enable-new-dtags to HOST_LDFLAGS ?
Unfortunately, I'm pretty sure there are many packages that don't honor
HOST_LDFLAGS.
> I just noticed now that the idea of an ld wrapper that adds that option
> would not work in this case anyway, because this is the host ld... Note
> that some distros (I think Gentoo and SUSE at least) patch binutils to
> make the --enable-new-dtags the default, so there you wouldn't even see
> this issue.
Ok, yes, indeed we don't have a wrapper for host ld, and it is
specifically for host binaries that we need to set a RUNPATH.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-05 10:27 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2014-03-05 10:29 ` Alvaro Gamez
2014-03-05 14:37 ` Alvaro Gamez
2014-03-05 15:01 ` Samuel Martin
1 sibling, 1 reply; 416+ messages in thread
From: Alvaro Gamez @ 2014-03-05 10:29 UTC (permalink / raw)
To: buildroot
2014-03-05 11:27 GMT+01:00 Thomas Petazzoni <
thomas.petazzoni@free-electrons.com>:
> > sh4a | libxmlrpc-1.25.26 | NOK |
> http://autobuild.buildroot.net/results/996fc95b302fb6dfc7cd9a468fd395226a36c6c4/
>
> Not sure:
>
> /home/test/test/1/output/host/usr/bin/sh-linux-gnu-gcc -shared
> -Wl,-soname,libxmlrpc_xmltok.so.3 xmltok.osh xmlrole.osh -o
> libxmlrpc_xmltok.so.3.25
> xmltok.osh: file not recognized: File truncated
> collect2: error: ld returned 1 exit status
>
That comes from the recently applied patch I sent.
I'll look at it, it's a bit strange.
--
?lvaro G?mez Machado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140305/61807564/attachment.html>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-05 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-03-04 Thomas Petazzoni
@ 2014-03-05 10:27 ` Thomas Petazzoni
2014-03-05 10:29 ` Alvaro Gamez
2014-03-05 15:01 ` Samuel Martin
0 siblings, 2 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-03-05 10:27 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 5 Mar 2014 08:30:08 +0100 (CET), Thomas Petazzoni wrote:
> x86_64 | <command-line>:0:0: note: t... | TIM | http://autobuild.buildroot.net/results/82e7f26e2e307aeb66a8ff98be3369e04886d226/
Timeout, weird.
> x86_64 | audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/ee48919bb9d0651642b3a1b547cfbd2c5ef2a8dd/
/home/test/test/3/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-buildroot-linux-uclibc/4.7.3/../../../../x86_64-buildroot-linux-uclibc/bin/ld: attempted static link of dynamic object `/home/test/test/3/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-buildroot-linux-uclibc/4.7.3/../../../../x86_64-buildroot-linux-uclibc/lib/../lib64/libstdc++.so'
I think a contributor had a look into this some time ago, and came to
conclusions, but I don't remember, I'd have to dig in the archives :/
> bfin | cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/f1735664c37a72b1b8b137f8bbc6be14624c84e9/
Don't know.
> arm | cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/77f4cb65535033db9d5184b142d96f2a508a7a5c/
> arm | cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/da19c46398ba8a0977058d76fe21bd9968f92ac1/
This problem has been around for weeks. Would it be possible for an
OpenGL person to look into this?
cairo-gl-private.h:255:8: error: unknown type name 'GLchar'
> x86_64 | connman-1.21 | NOK | http://autobuild.buildroot.net/results/5c500167a7277fd3f3cdf02e13749f6e98a0e81e/
Might be a symbol redefinition problem in uClibc, when linking
statically. I remember reading some posts about this on the uClibc
mailing list.
/home/test/test/2/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/usr/lib/libglib-2.0.a(libglib_2_0_la-gstdio.o): In function `g_utime':
gstdio.c:(.text+0x7b): warning: the use of OBSOLESCENT `utime' is discouraged, use `utimes'
/home/test/test/2/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/usr/lib/libpthread.a(lowlevellock.os): In function `__lll_lock_wait_private':
(.text+0x0): multiple definition of `__lll_lock_wait_private'
/home/test/test/2/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/usr/lib/libc.a(libc-lowlevellock.os):(.text+0x0): first defined here
/home/test/test/2/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/usr/lib/libpthread.a(lowlevellock.os): In function `__lll_unlock_wake_private':
(.text+0xa0): multiple definition of `__lll_unlock_wake_private'
/home/test/test/2/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/usr/lib/libc.a(libc-lowlevellock.os):(.text+0x30): first defined here
collect2: ld returned 1 exit status
> bfin | czmq-b5730c5f8290a611fd3b92... | NOK | http://autobuild.buildroot.net/results/99363a20dc25600460bd4cf169d92c922f55a5f6/
> bfin | czmq-b5730c5f8290a611fd3b92... | NOK | http://autobuild.buildroot.net/results/48ca7dbd47d4231b6b98f490f952533caf888861/
> bfin | czmq-b5730c5f8290a611fd3b92... | NOK | http://autobuild.buildroot.net/results/cc9eafd42f1d7887763b912b2ad785635201be3c/
Yesterday evening, I've started looking into this. Here is a summary of
my findings.
So, we're building for Blackfin FLAT, so static only build. ZeroMQ is a
library written in C++, and czmq is a library around it written in C.
The configure script tests whether a simple application that calls
zmq_init() can be linked properly against the ZeroMQ library. This test
is done by compiling the test application using 'gcc', not 'g++'. While
this test works fine in dynamic link mode (because libzmq as a NEEDED
on libstdc++), it fails in static link mode because it links with
-lzmq, but not -lstdc++. A quick test shows that linking against
-lstdc++ would solve the problem.
So there are apparently two issues:
1/ The libzmq.pc file does not have a Libs.private: -lsdtc++
2/ The configure.ac script of czmq does not call pkg-config with the
--static option. Apparently, the logic in pkg.m4 is not even aware
that it should use --static.
I must say I'm not sure how to fix the problem properly.
> microblaze | dmalloc-5.4.3 | NOK | http://autobuild.buildroot.net/results/d8b4f69e5b19a3d9c1b8e4114e686cff7cfeae2f/
To be looked at by Microblaze people:
{standard input}: Assembler messages:
{standard input}:9306: Error: operation combines symbols in different segments
{standard input}:9307: Error: operation combines symbols in different segments
> arm | eudev-1.3 | NOK | http://autobuild.buildroot.net/results/5190f23b84ca9eec49f1071ccfdb3314f6c4ae5b/
> powerpc | eudev-1.3 | NOK | http://autobuild.buildroot.net/results/624ad8ef30318bfb2de0952c5101cfa2b8d94f76/
> mipsel | eudev-1.3 | NOK | http://autobuild.buildroot.net/results/c4e920b16c57e79df979f00cceaea7c0483f043c/
Fixed by:
http://git.buildroot.net/buildroot/commit/?id=d5604d9c3de6cd0b24db1351227b017fd8a8be75
> arm | gst1-plugins-bad-1.2.3 | NOK | http://autobuild.buildroot.net/results/ac98e35736532c697e1c08e23e1d6800c951ea23/
> arm | gst1-plugins-bad-1.2.3 | NOK | http://autobuild.buildroot.net/results/d02e1843ef90f4b40c99e3b23eddf376f827d46e/
> arm | gst1-plugins-bad-1.2.3 | NOK | http://autobuild.buildroot.net/results/51ea53c39e6c067760c2d1e9c0c7b7bfbbe28be8/
OpenCV problem, to be looked at by Samuel I believe:
/home/test/test/3/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/opencv/cv.h:72:37: fatal error: opencv2/legacy/compat.hpp: No such file or directory
> i686 | host-python3-3.4.0rc1 | NOK | http://autobuild.buildroot.net/results/4dab2c72b9583df03db5b065a7f8a7ca0e6d9181/
> i686 | host-python3-3.4.0rc1 | NOK | http://autobuild.buildroot.net/results/ced5ed9ce2f1742560828999eeb6dc8777729d78/
Parallel installation problem.
> i686 | host-scons-2.3.0 | NOK | http://autobuild.buildroot.net/results/a423aa18e25686474633d6420bf701e1fa637bd0/
> powerpc | host-scons-2.3.0 | NOK | http://autobuild.buildroot.net/results/2eb4783dcc3fd990d37f34f2a146a7c025647bec/
The host python3 problem (SCons only works with Python 2).
> sh4 | libsoc-0.6 | NOK | http://autobuild.buildroot.net/results/1f451a338487a2a3c8a8f9b18540d41b90ee5aac/
> i686 | libsoc-0.6 | NOK | http://autobuild.buildroot.net/results/6735751b31dfe8e3ced80c5d18d816772286d4f7/
> arm | libsoc-0.6 | NOK | http://autobuild.buildroot.net/results/578032aac810d04cced1e8fdf0f6f39d20132de8/
> i686 | libsoc-0.6 | NOK | http://autobuild.buildroot.net/results/1888956c040f56b4d6603f2d2f44ccb7614a87de/
Fixed by:
http://git.buildroot.net/buildroot/commit/?id=41711cfdeda6f5fd9b2531f538f3643854d7d3ea
> sh4a | libxmlrpc-1.25.26 | NOK | http://autobuild.buildroot.net/results/996fc95b302fb6dfc7cd9a468fd395226a36c6c4/
Not sure:
/home/test/test/1/output/host/usr/bin/sh-linux-gnu-gcc -shared -Wl,-soname,libxmlrpc_xmltok.so.3 xmltok.osh xmlrole.osh -o libxmlrpc_xmltok.so.3.25
xmltok.osh: file not recognized: File truncated
collect2: error: ld returned 1 exit status
> arm | lvm2-2.02.103 | NOK | http://autobuild.buildroot.net/results/31a4ba00f9628365f080877079ba8d8120f4f23a/
Needs pkg-config.
> arc | mplayer-1.1.1 | NOK | http://autobuild.buildroot.net/results/9a259663b28ae47ed2bfd15f53b0fc44b5853227/
The architecture of your CPU (arc) is not supported by this configure script
It seems nobody has ported MPlayer to your OS or CPU type yet.
> arm | php-5.5.9 | NOK | http://autobuild.buildroot.net/results/c505587a795cd936ce8d5dda4805c0974a96981e/
> arm | php-5.5.9 | NOK | http://autobuild.buildroot.net/results/59ade0d9290cf623b45cd6fe0d0d56f295588ee0/
checking for fork... no
configure: error: pcntl: fork() not supported by this platform
make: *** [/home/test/test/1/output/build/php-5.5.9/.stamp_configured] Error 1
> arm | samba4-4.1.5 | NOK | http://autobuild.buildroot.net/results/8505e0dd5ecda76071f0ea4f7705a105308a1c20/
Fixed by:
http://git.buildroot.net/buildroot/commit/?id=878c04b8ccc399c0d9c09767eda9b129e3b59a53
> i686 | wget-1.15 | NOK | http://autobuild.buildroot.net/results/3abe178c26dc34a4f6a887ed3abbfcaa8990ce6d/
> sh4 | wget-1.15 | NOK | http://autobuild.buildroot.net/results/a685caa6d3e4850a45360dfe733013ba2d53404c/
*** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.17 but the autoconf macros are from gettext version 0.18
> bfin | zeromq-3.2.4 | NOK | http://autobuild.buildroot.net/results/047f2f8ac15592d5f78093249eeed14148de4e5e/
Compiler does not provide the necessary intrinsics.
> avr32 | zeromq-3.2.4 | NOK | http://autobuild.buildroot.net/results/7a0be4da26415b05f3d1c9522da703be408bb5f6/
Not sure :/
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-05 9:04 ` Thomas Petazzoni
@ 2014-03-05 10:10 ` Arnout Vandecappelle
2014-03-05 12:40 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Arnout Vandecappelle @ 2014-03-05 10:10 UTC (permalink / raw)
To: buildroot
On 05/03/14 10:04, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
>
> On Wed, 05 Mar 2014 00:18:37 +0100, Arnout Vandecappelle wrote:
>> On 02/03/14 09:57, Thomas Petazzoni wrote:
>>>> i686 | host-python3-3.4.0rc1 | NOK | http://autobuild.buildroot.net/results/2a62de3247ba5ad273f03d01e690a3eeb11aa7b4/
>>> Parallel installation issue with Python 3. Either we should make Python
>>> 3 entirely use MAKE1, or fix the problem. I have analyzed the problem,
>>> and it is caused by the parallel installation of libpython into the
>>> HOST_DIR and the execution of ./python in the Python source directory.
>>
>> Is that because we export an LD_LIBRARY_PATH that points to the freshly
>> installed libpython? Because I would expect that ./python uses the build
>> directory's libpython, not the installed one...
>>
>> Oh, but it actually does get called with the correct LD_LIBRARY_PATH:
>>
>> LD_LIBRARY_PATH=/home/peko/scratch/build/host-python3-3.4.0rc1:/home/peko/scratch/host/usr/lib:
>> ./python ...
>>
>> The issue is that the executable contains an RPATH pointing to the
>> install location of libpython.so (in $(HOST_DIR)).
>
> Correct. I came to the same conclusion when analyzing the problem the
> other day (but I reported only my findings on IRC, and didn't send a
> summary to the list, my bad).
>
>> When the file doesn't
>> exist yet there, LD_LIBRARY_PATH kicks in and it finds the so file in the
>> build directory. When the file does exist, it can link against it -
>> except when it hasn't been fully written yet.
>>
>> The solution would be if the executable would use RUNPATH instead of
>> RPATH - which according to e.g. [1] is what everybody should do (and I
>> tend to agree). IOW, the option --enable-new-dtags should be passed to
>> the linker ("new" is not really true BTW, the option has existed for
>> since more than 10 years). When we would add a toolchain wrapper for ld,
>> we could add it there.
>>
>> But for the time being, I'll post a patch for python3 (and python, which
>> suffers from the same problem) that adds --enable-new-dtags there.
>
> Indeed, DT_RUNPATH would fix the problem, but to me it feels more like
> a workaround than a real fix, no? Wouldn't the real fix be to ensure
> that the installation is atomic, i.e either the library is present in
> $(HOST_DIR)/usr/lib, or it is not? The problem here apparently occurs
> when Python is executed when the library file already exists in
> $(HOST_DIR)/usr/lib, but its copy hasn't finished yet.
In this case, that happens to be the problem. But in general, it is
possible that there is already an old version of the library in
$(HOST_DIR)/usr/lib, and then that one will be used instead of the newly
built one. Nothing catastrophic, but still wrong.
The thing is, RPATH was just a mistake to begin with: you _always_ want
LD_LIBRARY_PATH to take precedence over RPATH, otherwise LD_LIBRARY_PATH
doesn't make much sense. That's why I think that adding
--enable-new-dtags unconditionally for all builds would be a great idea.
I just noticed now that the idea of an ld wrapper that adds that option
would not work in this case anyway, because this is the host ld... Note
that some distros (I think Gentoo and SUSE at least) patch binutils to
make the --enable-new-dtags the default, so there you wouldn't even see
this issue.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-04 23:18 ` Arnout Vandecappelle
@ 2014-03-05 9:04 ` Thomas Petazzoni
2014-03-05 10:10 ` Arnout Vandecappelle
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-03-05 9:04 UTC (permalink / raw)
To: buildroot
Dear Arnout Vandecappelle,
On Wed, 05 Mar 2014 00:18:37 +0100, Arnout Vandecappelle wrote:
> On 02/03/14 09:57, Thomas Petazzoni wrote:
> >> i686 | host-python3-3.4.0rc1 | NOK | http://autobuild.buildroot.net/results/2a62de3247ba5ad273f03d01e690a3eeb11aa7b4/
> > Parallel installation issue with Python 3. Either we should make Python
> > 3 entirely use MAKE1, or fix the problem. I have analyzed the problem,
> > and it is caused by the parallel installation of libpython into the
> > HOST_DIR and the execution of ./python in the Python source directory.
>
> Is that because we export an LD_LIBRARY_PATH that points to the freshly
> installed libpython? Because I would expect that ./python uses the build
> directory's libpython, not the installed one...
>
> Oh, but it actually does get called with the correct LD_LIBRARY_PATH:
>
> LD_LIBRARY_PATH=/home/peko/scratch/build/host-python3-3.4.0rc1:/home/peko/scratch/host/usr/lib:
> ./python ...
>
> The issue is that the executable contains an RPATH pointing to the
> install location of libpython.so (in $(HOST_DIR)).
Correct. I came to the same conclusion when analyzing the problem the
other day (but I reported only my findings on IRC, and didn't send a
summary to the list, my bad).
> When the file doesn't
> exist yet there, LD_LIBRARY_PATH kicks in and it finds the so file in the
> build directory. When the file does exist, it can link against it -
> except when it hasn't been fully written yet.
>
> The solution would be if the executable would use RUNPATH instead of
> RPATH - which according to e.g. [1] is what everybody should do (and I
> tend to agree). IOW, the option --enable-new-dtags should be passed to
> the linker ("new" is not really true BTW, the option has existed for
> since more than 10 years). When we would add a toolchain wrapper for ld,
> we could add it there.
>
> But for the time being, I'll post a patch for python3 (and python, which
> suffers from the same problem) that adds --enable-new-dtags there.
Indeed, DT_RUNPATH would fix the problem, but to me it feels more like
a workaround than a real fix, no? Wouldn't the real fix be to ensure
that the installation is atomic, i.e either the library is present in
$(HOST_DIR)/usr/lib, or it is not? The problem here apparently occurs
when Python is executed when the library file already exists in
$(HOST_DIR)/usr/lib, but its copy hasn't finished yet.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-02 8:57 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-03-02 9:50 ` Samuel Martin
@ 2014-03-04 23:18 ` Arnout Vandecappelle
2014-03-05 9:04 ` Thomas Petazzoni
1 sibling, 1 reply; 416+ messages in thread
From: Arnout Vandecappelle @ 2014-03-04 23:18 UTC (permalink / raw)
To: buildroot
On 02/03/14 09:57, Thomas Petazzoni wrote:
>> i686 | host-python3-3.4.0rc1 | NOK | http://autobuild.buildroot.net/results/2a62de3247ba5ad273f03d01e690a3eeb11aa7b4/
> Parallel installation issue with Python 3. Either we should make Python
> 3 entirely use MAKE1, or fix the problem. I have analyzed the problem,
> and it is caused by the parallel installation of libpython into the
> HOST_DIR and the execution of ./python in the Python source directory.
Is that because we export an LD_LIBRARY_PATH that points to the freshly
installed libpython? Because I would expect that ./python uses the build
directory's libpython, not the installed one...
Oh, but it actually does get called with the correct LD_LIBRARY_PATH:
LD_LIBRARY_PATH=/home/peko/scratch/build/host-python3-3.4.0rc1:/home/peko/scratch/host/usr/lib:
./python ...
The issue is that the executable contains an RPATH pointing to the
install location of libpython.so (in $(HOST_DIR)). When the file doesn't
exist yet there, LD_LIBRARY_PATH kicks in and it finds the so file in the
build directory. When the file does exist, it can link against it -
except when it hasn't been fully written yet.
The solution would be if the executable would use RUNPATH instead of
RPATH - which according to e.g. [1] is what everybody should do (and I
tend to agree). IOW, the option --enable-new-dtags should be passed to
the linker ("new" is not really true BTW, the option has existed for
since more than 10 years). When we would add a toolchain wrapper for ld,
we could add it there.
But for the time being, I'll post a patch for python3 (and python, which
suffers from the same problem) that adds --enable-new-dtags there.
Regards,
Arnout
[1] http://blog.tremily.us/posts/rpath/
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-03 11:31 ` Romain Naour
@ 2014-03-03 12:48 ` Thomas Petazzoni
2014-03-07 0:44 ` Romain Naour
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-03-03 12:48 UTC (permalink / raw)
To: buildroot
Dear Romain Naour,
On Mon, 3 Mar 2014 12:31:45 +0100 (CET), Romain Naour wrote:
> |
> | > microblaze | gpm-1.20.7 | NOK |
> | > http://autobuild.buildroot.net/results/e99afadca6de92aad8563006fc7219aa32d77a88/
> |
> | Strange:
> |
> | /home/test/test/2/output/host/usr/bin/microblaze-buildroot-linux-gnu-gcc
> | libgpm.so.2 \
> | -L/home/test/test/2/output/build/gpm-1.20.7/src -o
> | lib/libgpm.so.2.1.0 lib/liblow.lo lib/libhigh.lo lib/libxtra.lo
> | lib/report-lib.lo tools.lo -lc
> | microblaze-buildroot-linux-gnu-gcc: error: libgpm.so.2: No such file
> | or directory
> |
> | Spenser ?
>
> It's because __ELF__ is not defined in microblaze toolchain :
> checking whether system is ELF... no
>
> If elf format is not enabled then gpm is build statically.
> You may have noticed that qpm static build is disabled in gpm.mk because it's broken.
>
> I can try to fix gpm's static build.
Hum, but that's weird because Microblaze definitely uses the ELF binary
format, supports shared library and has a MMU (at least for the
Microblaze CPU variants that we support).
So it should be working in shared library mode, I believe.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-03 8:02 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (2 preceding siblings ...)
2014-03-03 11:17 ` Gustavo Zacarias
@ 2014-03-03 11:31 ` Romain Naour
2014-03-03 12:48 ` Thomas Petazzoni
3 siblings, 1 reply; 416+ messages in thread
From: Romain Naour @ 2014-03-03 11:31 UTC (permalink / raw)
To: buildroot
Hi Thomas, All
|
| > microblaze | gpm-1.20.7 | NOK |
| > http://autobuild.buildroot.net/results/e99afadca6de92aad8563006fc7219aa32d77a88/
|
| Strange:
|
| /home/test/test/2/output/host/usr/bin/microblaze-buildroot-linux-gnu-gcc
| libgpm.so.2 \
| -L/home/test/test/2/output/build/gpm-1.20.7/src -o
| lib/libgpm.so.2.1.0 lib/liblow.lo lib/libhigh.lo lib/libxtra.lo
| lib/report-lib.lo tools.lo -lc
| microblaze-buildroot-linux-gnu-gcc: error: libgpm.so.2: No such file
| or directory
|
| Spenser ?
It's because __ELF__ is not defined in microblaze toolchain :
checking whether system is ELF... no
If elf format is not enabled then gpm is build statically.
You may have noticed that qpm static build is disabled in gpm.mk because it's broken.
I can try to fix gpm's static build.
Best regards,
Romain
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-03 8:02 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-03-03 9:10 ` Baruch Siach
2014-03-03 9:38 ` Samuel Martin
@ 2014-03-03 11:17 ` Gustavo Zacarias
2014-03-03 11:31 ` Romain Naour
3 siblings, 0 replies; 416+ messages in thread
From: Gustavo Zacarias @ 2014-03-03 11:17 UTC (permalink / raw)
To: buildroot
On 03/03/2014 05:02 AM, Thomas Petazzoni wrote:
>> powerpc | libnftnl-1.0.0 | NOK | http://autobuild.buildroot.net/results/568d7fd5a6e6cd8a8e23184d7f977ce812b887fd/
>
> Maybe a kernel headers problem. Gustavo ?
Hi.
Definitely.
That toolchain uses 2.6.38-ish kernel headers but include/linux/socket.h
has issues, it doesn't define sa_family_t which vanilla does, hence the
breakage.
We can either disable libnftnl for that toolchain or consider removing
it since it's getting old and there doesn't seem to be any new version
forthcoming for some time now.
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-03 10:19 ` Samuel Martin
@ 2014-03-03 10:27 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-03-03 10:27 UTC (permalink / raw)
To: buildroot
Dear Samuel Martin,
On Mon, 3 Mar 2014 11:19:12 +0100, Samuel Martin wrote:
> > Ok, cool. What approach have you chosen?
>
> I added a variable-knob to the pkg-python infra named
> $(2)_FORCE_HOST_PYTHON (name can be debated later :P) which set the
> proper host python dependency, and call the proper python interpreter
> during build and install steps.
>
> This variable only affects host packages.
>
> If the some configure/build/install commands are overloaded in th *.mk
> file, the right python interpreter should be explicitly called.
> If the package define some tool variable (eg.: SCONS), the variable
> should explicitly called the right python interpreter.
>
> That's roughly the headlines.
Seems like a good approach. I'm a bit worried about Python 3 stuff
which might fall back on using $(HOST_DIR)/usr/bin/python instead of
$(HOST_DIR)/usr/bin/python3, though, but I'm not sure there's much we
can do about it, except getting autobuilder testing, and user testing.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-03 10:05 ` Thomas Petazzoni
@ 2014-03-03 10:19 ` Samuel Martin
2014-03-03 10:27 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Samuel Martin @ 2014-03-03 10:19 UTC (permalink / raw)
To: buildroot
On Mon, Mar 3, 2014 at 11:05 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Samuel Martin,
>
> On Mon, 3 Mar 2014 10:38:19 +0100, Samuel Martin wrote:
>
>> > Problem of host python being Python 3 and not Python 2.
>> [...]
>>
>> I've started looking at this host-python2 thing.
>>
>> So far, I have something working for host-scons, host-python-m2crypto and crda.
>> I still have to look at samba4, and cleanup the patches before
>> submitting them ;)
>
> Ok, cool. What approach have you chosen?
I added a variable-knob to the pkg-python infra named
$(2)_FORCE_HOST_PYTHON (name can be debated later :P) which set the
proper host python dependency, and call the proper python interpreter
during build and install steps.
This variable only affects host packages.
If the some configure/build/install commands are overloaded in th *.mk
file, the right python interpreter should be explicitly called.
If the package define some tool variable (eg.: SCONS), the variable
should explicitly called the right python interpreter.
That's roughly the headlines.
Regards,
--
Samuel
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-03 9:38 ` Samuel Martin
@ 2014-03-03 10:05 ` Thomas Petazzoni
2014-03-03 10:19 ` Samuel Martin
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-03-03 10:05 UTC (permalink / raw)
To: buildroot
Dear Samuel Martin,
On Mon, 3 Mar 2014 10:38:19 +0100, Samuel Martin wrote:
> > Problem of host python being Python 3 and not Python 2.
> [...]
>
> I've started looking at this host-python2 thing.
>
> So far, I have something working for host-scons, host-python-m2crypto and crda.
> I still have to look at samba4, and cleanup the patches before
> submitting them ;)
Ok, cool. What approach have you chosen?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-03 8:02 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-03-03 9:10 ` Baruch Siach
@ 2014-03-03 9:38 ` Samuel Martin
2014-03-03 10:05 ` Thomas Petazzoni
2014-03-03 11:17 ` Gustavo Zacarias
2014-03-03 11:31 ` Romain Naour
3 siblings, 1 reply; 416+ messages in thread
From: Samuel Martin @ 2014-03-03 9:38 UTC (permalink / raw)
To: buildroot
Hi Thomas, all,
On Mon, Mar 3, 2014 at 9:02 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Mon, 3 Mar 2014 08:30:10 +0100 (CET), Thomas Petazzoni wrote:
>
>> mipsel | crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/a1e53d66d3962fd5431e7601937b071a0a3c2084/
>> x86_64 | crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/b363c63b5dda7d55c3bd4c6aedc10666471113ad/
>
> Problem of host python being Python 3 and not Python 2.
>
[...]
>> arm | host-scons-2.3.0 | NOK | http://autobuild.buildroot.net/results/11e6c8c8d79d56ed43daf52e6d6dc80847709926/
>> arm | host-scons-2.3.0 | NOK | http://autobuild.buildroot.net/results/d75722fe096fc1ddbf62a51207b44b3cdbb6fed8/
>> powerpc | host-scons-2.3.0 | NOK | http://autobuild.buildroot.net/results/09a7de5ef086005b2f003ccd58ee1dae268c26a1/
>
> Problem of host python being Python 3 and not Python 2.
[...]
I've started looking at this host-python2 thing.
So far, I have something working for host-scons, host-python-m2crypto and crda.
I still have to look at samba4, and cleanup the patches before
submitting them ;)
Regards,
Samuel
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-03 8:02 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2014-03-03 9:10 ` Baruch Siach
2014-03-03 9:38 ` Samuel Martin
` (2 subsequent siblings)
3 siblings, 0 replies; 416+ messages in thread
From: Baruch Siach @ 2014-03-03 9:10 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Mon, Mar 03, 2014 at 09:02:19AM +0100, Thomas Petazzoni wrote:
> On Mon, 3 Mar 2014 08:30:10 +0100 (CET), Thomas Petazzoni wrote:
>
> > xtensa | wget-1.15 | NOK | http://autobuild.buildroot.net/results/bc20297dad0f0e9b7fa79fe835b9754fbce6dfdf/
>
> spawn_faction_adddup2.c: In function 'posix_spawn_file_actions_adddup2':
> spawn_faction_adddup2.c:50:19: error: 'posix_spawn_file_actions_t' has no member named '_used'
> spawn_faction_adddup2.c:50:42: error: 'posix_spawn_file_actions_t' has no member named '_allocated'
> spawn_faction_adddup2.c:59:24: error: 'posix_spawn_file_actions_t' has no member named '_actions'
> spawn_faction_adddup2.c:59:47: error: 'posix_spawn_file_actions_t' has no member named '_used'
> spawn_faction_adddup2.c:65:19: error: 'posix_spawn_file_actions_t' has no member named '_used'
> make[5]: *** [spawn_faction_adddup2.o] Error 1
>
> Chris, Baruch, Max, an idea?
This is the same problem coreutils had, which was fixed by commit a728e2fe3
(coreutils: fix build against uclibc snapshot). Just sent the same fix for
wget.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-03 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-03-02 Thomas Petazzoni
@ 2014-03-03 8:02 ` Thomas Petazzoni
2014-03-03 9:10 ` Baruch Siach
` (3 more replies)
0 siblings, 4 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-03-03 8:02 UTC (permalink / raw)
To: buildroot
Hello,
On Mon, 3 Mar 2014 08:30:10 +0100 (CET), Thomas Petazzoni wrote:
> mipsel | crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/a1e53d66d3962fd5431e7601937b071a0a3c2084/
> x86_64 | crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/b363c63b5dda7d55c3bd4c6aedc10666471113ad/
Problem of host python being Python 3 and not Python 2.
> bfin | czmq-b5730c5f8290a611fd3b92... | NOK | http://autobuild.buildroot.net/results/8f8b479ac11ed35a7b20d94567bb446044dd02d4/
> bfin | czmq-b5730c5f8290a611fd3b92... | NOK | http://autobuild.buildroot.net/results/ba626190b8019a73ecce74b1eb07eed4ec79ae56/
checking for zmq_init in -lzmq... no
configure: error: cannot link with -lzmq, install libzmq.
> x86_64 | eudev-1.3 | NOK | http://autobuild.buildroot.net/results/3a0238bd1170f2e7d1257e4756553f6e2f4a1268/
Documentation problem:
I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl"
cannot parse http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
> x86_64 | fbgrab-1.2 | NOK | http://autobuild.buildroot.net/results/9e079632a6c0556c96ec8ed7564286aa84044bf7/
Static linking problem.
> microblaze | gpm-1.20.7 | NOK | http://autobuild.buildroot.net/results/e99afadca6de92aad8563006fc7219aa32d77a88/
Strange:
/home/test/test/2/output/host/usr/bin/microblaze-buildroot-linux-gnu-gcc libgpm.so.2 \
-L/home/test/test/2/output/build/gpm-1.20.7/src -o lib/libgpm.so.2.1.0 lib/liblow.lo lib/libhigh.lo lib/libxtra.lo lib/report-lib.lo tools.lo -lc
microblaze-buildroot-linux-gnu-gcc: error: libgpm.so.2: No such file or directory
Spenser ?
> arm | host-scons-2.3.0 | NOK | http://autobuild.buildroot.net/results/11e6c8c8d79d56ed43daf52e6d6dc80847709926/
> arm | host-scons-2.3.0 | NOK | http://autobuild.buildroot.net/results/d75722fe096fc1ddbf62a51207b44b3cdbb6fed8/
> powerpc | host-scons-2.3.0 | NOK | http://autobuild.buildroot.net/results/09a7de5ef086005b2f003ccd58ee1dae268c26a1/
Problem of host python being Python 3 and not Python 2.
> xtensa | kmod-16 | NOK | http://autobuild.buildroot.net/results/9fb1a008e5fa13425ab9fba0d497cf877ef90457/
> xtensa | kmod-16 | NOK | http://autobuild.buildroot.net/results/97d4c96d6f6cdc1ed4007456f4ab70be9dfa41b5/
The xtensa binutils crash when building kmod-16. Chris, Baruch, Max ?
> bfin | lftp-4.4.15 | NOK | http://autobuild.buildroot.net/results/321a6eedd2c79ce45c047cd8ebddb67124da092c/
Fixed by:
http://git.buildroot.net/buildroot/commit/?id=5970e883419a55f25ea900d776287ae6ea34b62e
> powerpc | libnftnl-1.0.0 | NOK | http://autobuild.buildroot.net/results/568d7fd5a6e6cd8a8e23184d7f977ce812b887fd/
Maybe a kernel headers problem. Gustavo ?
> bfin | libwebsockets-v1.22-chrome2... | NOK | http://autobuild.buildroot.net/results/97e21513dba6aae5b2e2721c9218589dbc75d702/
Should add a MMU dependency:
daemonize.c: In function 'lws_daemonize':
daemonize.c:138: error: implicit declaration of function 'fork'
> arm | lvm2-2.02.103 | NOK | http://autobuild.buildroot.net/results/b780582f8a1f3ac9886d4b23375d8a6a704d25a2/
> i686 | lvm2-2.02.103 | NOK | http://autobuild.buildroot.net/results/a2e39cb626143c2d029ea3687891eab68ca0bde3/
Fixed by:
http://git.buildroot.net/buildroot/commit/?id=fb36a82a745e93afc92bb5aff29daea8daecb6d3
> mips64el | make: *** [systemd-legal-in... | NOK | http://autobuild.buildroot.net/results/e6c4dc22c014e62ce35273945a2a2307315ec3f7/
Fixed by:
http://git.buildroot.net/buildroot/commit/?id=1862463829e8194ed768ca8cb3a4f4664b35d8bc
> x86_64 | parted-3.1 | NOK | http://autobuild.buildroot.net/results/dc0592af4930b3631cc82bd0f510ee23466b3723/
> arm | parted-3.1 | NOK | http://autobuild.buildroot.net/results/e9a576e2154f56c2f6b0f9ec017f04e085557a52/
> sh4 | parted-3.1 | NOK | http://autobuild.buildroot.net/results/650960214be2b00ca7f028e31a36d74f3917454c/
Fixed by:
http://git.buildroot.net/buildroot/commit/?id=8d89fd2b7c09af47f2d1b81cfa4de45a421d8a83
> bfin | sane-backends-1.0.22 | NOK | http://autobuild.buildroot.net/results/5efcb8d898df0e798cc19eaf28a670356fc4e049/
pixma_mp750.c: In function 'mp750_scan':
pixma_mp750.c:624: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
Sonic, Aaron? This triggers an internal compiler error in the Blackfin official toolchain.
> microblaze | systemd-207 | NOK | http://autobuild.buildroot.net/results/91010b43e63b82e050046b8f10c2c42f31a8a620/
Fixed by:
http://git.buildroot.net/buildroot/commit/?id=f07c6c483c7d8f4718c82e91ff1c9d41a43f02e0
> i686 | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/accfb42f28c4701207df412eb6059a34997b02dd/
> arm | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/e11e28c29808202363961dfca01e9c19f5fb3eaf/
> i686 | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/0494eff48f4b55fef42f0713668dd2ac83822043/
Ignore, those were due to incorrect toolchain configurations following
the addition of the kernel headers dependency mechanism.
> xtensa | wget-1.15 | NOK | http://autobuild.buildroot.net/results/bc20297dad0f0e9b7fa79fe835b9754fbce6dfdf/
spawn_faction_adddup2.c: In function 'posix_spawn_file_actions_adddup2':
spawn_faction_adddup2.c:50:19: error: 'posix_spawn_file_actions_t' has no member named '_used'
spawn_faction_adddup2.c:50:42: error: 'posix_spawn_file_actions_t' has no member named '_allocated'
spawn_faction_adddup2.c:59:24: error: 'posix_spawn_file_actions_t' has no member named '_actions'
spawn_faction_adddup2.c:59:47: error: 'posix_spawn_file_actions_t' has no member named '_used'
spawn_faction_adddup2.c:65:19: error: 'posix_spawn_file_actions_t' has no member named '_used'
make[5]: *** [spawn_faction_adddup2.o] Error 1
Chris, Baruch, Max, an idea?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-02 9:50 ` Samuel Martin
@ 2014-03-02 10:08 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-03-02 10:08 UTC (permalink / raw)
To: buildroot
Dear Samuel Martin,
On Sun, 2 Mar 2014 10:50:41 +0100, Samuel Martin wrote:
> host-python and host-python3 are exclusive at the kconfig level
Hum? There are no Kconfig options for host-python and host-python3.
It's the target Pythons that are mutually exclusive at the Kconfig
level. And since each target Python depends on the same version of
host-pythonX, this is what brings host-python3 when target python3 is
selected.
> the make target one, right or am I missing something?
> AFAICS the only overlapping thing between the 2 host package is the
> $(HOST_DIR)/usr/bin/python symlink.
>
> So, we could imagine building host-python and host-python3 in the same build.
> In such a case, the tricky point becomes the
> $(HOST_DIR)/usr/bin/python symlink management:
> - host-python should not install the symlink if python3 is enabled;
> - host-python3 should deactivate the symlink installation when python
> is enabled.
> Then, the SCONS variable should explicity refer to
> "$(HOST_DIR)/usr/bin/python2 $(HOST_DIR)/usr/bin/scons"
> So, we could be able to build host-python (for host-scons) even if
> python3 is enabled.
You're missing something: the host-scons package is using the
host-python-package infrastructure. And this infrastructure uses the
host Python version of the selected target Python. This is where the
core of the problem is. We would need a way to tell the
host-python-package infrastructure to make a package depend on
host-python instead of host-python3, even if the selected target Python
is Python 3.
> > * Make the three target packages that actually need host-scons
> > "depends on !BR2_PACKAGE_PYTHON3". This is a bit ugly, but the next
> > version of SCons is supposed to support Python 3, so we could
> > consider it as a temporary solution.
>
> I've just checked out scons repository and it cannot be bootstraped
> with python3 :'(
See the Scons homepage:
"""
SCons release 2.3.0 now available from the download page at
SourceForge. This release adds new features, and fixes and improves a
number of issues. This will be the last release to support Python
versions earlier than 2.7, as we begin to move toward supporting Python
3.
"""
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-02 8:57 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2014-03-02 9:50 ` Samuel Martin
2014-03-02 10:08 ` Thomas Petazzoni
2014-03-04 23:18 ` Arnout Vandecappelle
1 sibling, 1 reply; 416+ messages in thread
From: Samuel Martin @ 2014-03-02 9:50 UTC (permalink / raw)
To: buildroot
Thomas, all,
On Sun, Mar 2, 2014 at 9:57 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
[...]
>> arm | host-scons-2.3.0 | NOK | http://autobuild.buildroot.net/results/1ee0d18f2a9e45b94e4db04fd5c54e6f7994b1be/
>> powerpc | host-scons-2.3.0 | NOK | http://autobuild.buildroot.net/results/d1421f2063ecfea9c4110414f481f779defa8ad5/
>
> Scons is not compatible with Python 3. But host-scons is not a target
> package, it's a host package, so we cannot add a Python 3 related
> dependency to it. So the two solutions that I see are:
>
> * Change our host-python and host-python3 packages so that they are
> not exclusive from each other, and then find a way for host-scons to
> express the fact that it really needs host-python, and not the
> host-python version matching the selected target python version.
> Note that achieving this might be difficult.
host-python and host-python3 are exclusive at the kconfig level, not
the make target one, right or am I missing something?
AFAICS the only overlapping thing between the 2 host package is the
$(HOST_DIR)/usr/bin/python symlink.
So, we could imagine building host-python and host-python3 in the same build.
In such a case, the tricky point becomes the
$(HOST_DIR)/usr/bin/python symlink management:
- host-python should not install the symlink if python3 is enabled;
- host-python3 should deactivate the symlink installation when python
is enabled.
Then, the SCONS variable should explicity refer to
"$(HOST_DIR)/usr/bin/python2 $(HOST_DIR)/usr/bin/scons"
So, we could be able to build host-python (for host-scons) even if
python3 is enabled.
host-python is the only package providing python2 stuff we would allow
to build when python3 is enabled.
For other packages, it should not change anything since the
$(HOST_DIR)/usr/bin/python symlink still reflects the configuration
(ie. its points to python3 if python3 is enabled, to python if
python(2) is enabled).
For example, crda needs host-python-m2crypto. Since there is no change
in the buildroot configuration (ie. the BR2_PACKAGE_PYTHON and
BR2_PACKAGE_PYTHON3 will still have the right value) and
$(HOST_DIR)/usr/bin/python still reflect this configuration,
host-python-m2crypto should still be built against the right python
version.
Of course, if we choose this way, it requires tests.
Comments?
>
> * Make the three target packages that actually need host-scons
> "depends on !BR2_PACKAGE_PYTHON3". This is a bit ugly, but the next
> version of SCons is supposed to support Python 3, so we could
> consider it as a temporary solution.
I've just checked out scons repository and it cannot be bootstraped
with python3 :'(
>
> Suggestions?
See above ;)
Regards,
--
Samuel
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-03-02 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-03-01 Thomas Petazzoni
@ 2014-03-02 8:57 ` Thomas Petazzoni
2014-03-02 9:50 ` Samuel Martin
2014-03-04 23:18 ` Arnout Vandecappelle
0 siblings, 2 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-03-02 8:57 UTC (permalink / raw)
To: buildroot
Hello all,
On Sun, 2 Mar 2014 08:30:07 +0100 (CET), Thomas Petazzoni wrote:
> i686 | bash-4.3 | NOK | http://autobuild.buildroot.net/results/44a962623be757143a3d6d37fc6cd14964094f79/
> i686 | bash-4.3 | NOK | http://autobuild.buildroot.net/results/9c16032f9630e09e3709a69ced6716de725c153d/
> x86_64 | bash-4.3 | NOK | http://autobuild.buildroot.net/results/6902eee5e39d9fd79b1e78ccd54382299f1b25ea/F
Fixed by
http://git.buildroot.net/buildroot/commit/?id=7a95111e48f5fe387f592463effa233834c6fda1
> bfin | cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/c421cde66d8d2d9bdf9ecbe531fb15b86f85d909/
To be fixed.
> powerpc | crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/87bfdc235ee441153c36489a0a1ec97266899d5a/
> powerpc | crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/d442f571f14758a4bdf7d694cecd5a34116be40a/
Issue when host-python3 is built before crda. The easiest solution is
probably to make the crda Python script Python 3 compatible and submit
the patch upstream.
> bfin | fbgrab-1.2 | NOK | http://autobuild.buildroot.net/results/b87b9397f4bf22579e7fca9763c9f099bb63bd8f/
Missing -l flags?
> i686 | host-python-setuptools-2.1.2 | NOK | http://autobuild.buildroot.net/results/f22ffbf62d4bc8a1f910269e06636181c324644f/
> powerpc | host-python-setuptools-2.1.2 | NOK | http://autobuild.buildroot.net/results/5e6f3c45dd480ef2bed8515d6a48579642e28274/
> i686 | host-python-setuptools-2.1.2 | NOK | http://autobuild.buildroot.net/results/aa6334d89d47d91fdb696d9248036ec27b4b752a/
> i686 | host-python-setuptools-2.1.2 | NOK | http://autobuild.buildroot.net/results/95d0e3656d539258bffa9ca3637d98bc48876a40/
> i686 | host-python-setuptools-2.1.2 | NOK | http://autobuild.buildroot.net/results/177f027edd981ed2ec081d93a15993e51f408620/
> i686 | host-python-setuptools-2.1.2 | NOK | http://autobuild.buildroot.net/results/87909291c77a45b1fbe99f641ea8f7d4b8b50e13/
> powerpc | host-python-setuptools-2.1.2 | NOK | http://autobuild.buildroot.net/results/4952e3a5bd6bac437b8b382dfa18f52eb17505da/
> arm | host-python-setuptools-2.1.2 | NOK | http://autobuild.buildroot.net/results/b622fc14776f5a6c26ff0d1fb882f4ae6cccc5d8/
> i686 | host-python-setuptools-2.1.2 | NOK | http://autobuild.buildroot.net/results/91df531bb3bb57f9b562ed358d6e4a7a970d5e8a/
> powerpc | host-python-setuptools-2.1.2 | NOK | http://autobuild.buildroot.net/results/5deb94ab960aa2f4428f7e9d2d5315ba79116ce1/
> i686 | host-python-setuptools-2.1.2 | NOK | http://autobuild.buildroot.net/results/11725dbff02b07096552a8c0f85d90d969a31fc9/
> powerpc | host-python-setuptools-2.1.2 | NOK | http://autobuild.buildroot.net/results/1b4713983e9148408081ee432717cb9f6afa5ac9/
> arm | host-python-setuptools-2.1.2 | NOK | http://autobuild.buildroot.net/results/b8a4c5dce70d6215945293cd6fd28282c3896a78/
> i686 | host-python-setuptools-2.1.2 | NOK | http://autobuild.buildroot.net/results/de0d965f2e1d6e70b234c2708d558273291f3a5f/
> powerpc | host-python-setuptools-2.1.2 | NOK | http://autobuild.buildroot.net/results/05c721a141e698d0df49b2867a218d31e7acb311/
> i686 | host-python-setuptools-2.1.2 | NOK | http://autobuild.buildroot.net/results/b01f64c75e71fb4e5282f690ee76a2a49842e889/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=bec21dcfa7042d1f7065cf467c4f9c777f0fd072
> i686 | host-python3-3.4.0rc1 | NOK | http://autobuild.buildroot.net/results/2a62de3247ba5ad273f03d01e690a3eeb11aa7b4/
Parallel installation issue with Python 3. Either we should make Python
3 entirely use MAKE1, or fix the problem. I have analyzed the problem,
and it is caused by the parallel installation of libpython into the
HOST_DIR and the execution of ./python in the Python source directory.
> arm | host-scons-2.3.0 | NOK | http://autobuild.buildroot.net/results/1ee0d18f2a9e45b94e4db04fd5c54e6f7994b1be/
> powerpc | host-scons-2.3.0 | NOK | http://autobuild.buildroot.net/results/d1421f2063ecfea9c4110414f481f779defa8ad5/
Scons is not compatible with Python 3. But host-scons is not a target
package, it's a host package, so we cannot add a Python 3 related
dependency to it. So the two solutions that I see are:
* Change our host-python and host-python3 packages so that they are
not exclusive from each other, and then find a way for host-scons to
express the fact that it really needs host-python, and not the
host-python version matching the selected target python version.
Note that achieving this might be difficult.
* Make the three target packages that actually need host-scons
"depends on !BR2_PACKAGE_PYTHON3". This is a bit ugly, but the next
version of SCons is supposed to support Python 3, so we could
consider it as a temporary solution.
Suggestions?
> i686 | libmicrohttpd-0.9.34 | NOK | http://autobuild.buildroot.net/results/edb1b5ee1ffaa6a495b4d7c2976f618c8331b5d2/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=25c438bce1c02775f2c23d8878ab71c3022b0c95
> powerpc | libnftnl-1.0.0 | NOK | http://autobuild.buildroot.net/results/c13ef3757b90838549d6f396155a20890d163ff9/
Probably needs some kernel headers dependency. To be checked in detail.
Any taker?
> nios2 | libsigsegv-2.10 | NOK | http://autobuild.buildroot.net/results/82dac744ce01c9ebb8c769aea02bf29bc7494aa6/
Needs a small patch to support NIOS 2. The only information needed is
to know whether the stack grows upward or downward on the architecture.
> arm | lvm2-2.02.103 | NOK | http://autobuild.buildroot.net/results/dd5ceda4e3778a763d26b8a81a08391f13f02307/
> powerpc | lvm2-2.02.103 | NOK | http://autobuild.buildroot.net/results/d6f4d388c62ec2137560aabbff46c4a30c584e18/
> mips | lvm2-2.02.103 | NOK | http://autobuild.buildroot.net/results/bc9b84964667fd37155df97c35252d6b73be724f/
> microblaze | lvm2-2.02.103 | NOK | http://autobuild.buildroot.net/results/affded5ab5590e6f7313c59f511b81c1bb645c92/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=fb36a82a745e93afc92bb5aff29daea8daecb6d3.
> arm | mplayer-1.1.1 | NOK | http://autobuild.buildroot.net/results/ee409788bbf44434a53c14ede7928367ba8e1c85/
ARM floating point issue.
> arm | parted-3.1 | NOK | http://autobuild.buildroot.net/results/87ee883d745fafd88fa446244cfe69659ff06f3c/
> arm | parted-3.1 | NOK | http://autobuild.buildroot.net/results/1e90929bfaf617381d490dc0b99f333968624ce7/
> arm | parted-3.1 | NOK | http://autobuild.buildroot.net/results/c4cb972758a58c4b62e600c14936af4fd559295b/
> i686 | parted-3.1 | NOK | http://autobuild.buildroot.net/results/4b5f5dc38a08f622992ea22fd58c1d82b80890c8/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=8d89fd2b7c09af47f2d1b81cfa4de45a421d8a83.
> bfin | pciutils-3.2.1 | NOK | http://autobuild.buildroot.net/results/f5c6d4453d546001423244476adf2c6f40411e2c/
Blackfin specific issue related to the usage of _ as prefix for
assembly symbols.
> i686 | php-gnupg-1.3.3 | NOK | http://autobuild.buildroot.net/results/e3b2d68b22224fcda95174bd64803a58aae1606a/
> powerpc | php-gnupg-1.3.3 | NOK | http://autobuild.buildroot.net/results/fe26034ee29c7334d09cba8a80ae5bfd2787a552/
> i686 | php-gnupg-1.3.3 | NOK | http://autobuild.buildroot.net/results/df9f7c7c30d9cdba65b4f5c6d46c8aa91de4179a/
> powerpc | php-gnupg-1.3.3 | NOK | http://autobuild.buildroot.net/results/efbce29a2fa1d8561c10613d2145b9b382ddc83c/
> powerpc | php-gnupg-1.3.3 | NOK | http://autobuild.buildroot.net/results/757fb0b12af12de4f128d9c503d45b20776c2313/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=1188fcf1667ac316ea9df024b9346415a05b90db.
> arm | python-pyasn-0.17 | NOK | http://autobuild.buildroot.net/results/3c968459f6cc020a3c6bc77f49245d69ed92df20/
> arm | python-pyasn-0.17 | NOK | http://autobuild.buildroot.net/results/e009a9a5f8a311b5fcb41212d517a2d52ff2db9d/
> arm | python-pyasn-0.17 | NOK | http://autobuild.buildroot.net/results/c11893d19f5614236f1d30a5fca781b94d2f9f80/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=e025e49100565617715e0de986ba670532098b14.
> bfin | zeromq-3.2.4 | NOK | http://autobuild.buildroot.net/results/59182657d03ca48dc46c96d4ff14667324f4e4f6/
Compiler does not provide the right compiler intrinsics. We should
check if more recent versions of gcc do not provide the necessary
intrinsics.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-24 21:18 ` Ezequiel García
@ 2014-02-26 21:10 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-26 21:10 UTC (permalink / raw)
To: buildroot
Dear Ezequiel Garc?a,
On Mon, 24 Feb 2014 18:18:35 -0300, Ezequiel Garc?a wrote:
> > The _gp problem seems to be occurring for a bunch of other packages. We
> > should contact the Sourcery CodeBench people about this, I believe.
> > Someone to take the lead on this?
>
> Altera provided the names of the people working on this (and also
> suggested they might not reply to private mails). Let me find some
> time to prepare a mail for them.
Good. Please keep us informed of the outcome of these discussions.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-21 9:08 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (5 preceding siblings ...)
2014-02-22 21:54 ` Ryan Barnett
@ 2014-02-26 11:06 ` Vicente Olivert Riera
6 siblings, 0 replies; 416+ messages in thread
From: Vicente Olivert Riera @ 2014-02-26 11:06 UTC (permalink / raw)
To: buildroot
On 02/21/2014 09:08 AM, Thomas Petazzoni wrote:
>> mips | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/95cac37ef8f035c024ebcd808367739c29875f30/
>
> /home/test/test/3/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-linux-gnu/4.7.3/../../../../mips-linux-gnu/bin/ld: ./.libs/libvlc_srtp.a(libvlc_srtp_la-srtp.o): relocation R_MIPS_26 against `div' can not be used when making a shared object; recompile with -fPIC
> ./.libs/libvlc_srtp.a(libvlc_srtp_la-srtp.o): could not read symbols: Bad value
> collect2: error: ld returned 1 exit status
>
> We have the same problem on x86-64: some vlc library is apparently not
> build with -fPIC. Could someone look into this?
>
> It has caused the last 3 build failures of vlc on mips:
>
> http://autobuild.buildroot.org/?reason=vlc-2.1.2&arch=mips&step=3
>
> and the four last build failures of vlc on x86-64:
>
> http://autobuild.buildroot.org/results/a53/a53ea017ec92150c7d37c0da0ca9a8dac75f460e/build-end.log
After compiling libgcrypt with -fPIC, the error has changed to this one:
/home/test/test/3/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-linux-gnu/4.7.3/../../../../mips-linux-gnu/bin/ld:
./.libs/libunzip.a(unzip.o): relocation R_MIPS_26 against `a local
symbol' can not be used when making a shared object; recompile with -fPIC
I don't know if this is an improvement or not, and I don't know what to
do next :/
Maybe someone else has more ideas.
--
Vincent
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-23 10:00 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (3 preceding siblings ...)
2014-02-24 10:12 ` Vicente Olivert Riera
@ 2014-02-25 21:08 ` Samuel Martin
4 siblings, 0 replies; 416+ messages in thread
From: Samuel Martin @ 2014-02-25 21:08 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Sun, Feb 23, 2014 at 11:00 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
[...]
>> x86_64 | lua-ev-458165bdfe0c6eadc788... | NOK | http://autobuild.buildroot.net/results/41c8bb9cf91a86908a150dae27726136cb56f5b7/
>
> Samuel, Fran?ois, you discussed this problem recently. Can you come up
> with a patch that solves it?
I cannot reproduce this build failure. :(
Could you re-run the build (maybe on the autobuilder itself) and
provide the lua-ev configure/build log with "V=1"?
Regards,
--
Samuel
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-24 21:16 ` Thomas Petazzoni
@ 2014-02-24 21:18 ` Ezequiel García
2014-02-26 21:10 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Ezequiel García @ 2014-02-24 21:18 UTC (permalink / raw)
To: buildroot
On 24 February 2014 18:16, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Ezequiel Garc?a,
>
> On Sun, 23 Feb 2014 20:46:37 -0300, Ezequiel Garc?a wrote:
>> On 23 February 2014 07:00, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com> wrote:
>> >
>> >> nios2 | minidlna-1.1.1 | NOK | http://autobuild.buildroot.net/results/2e6fa6e4891b5cc4c75943130158aa24fa77f26e/
>> >
>> > configure: error: Could not find libavformat - part of ffmpeg
>> > make: *** [/home/test/test/3/output/build/minidlna-1.1.1/.stamp_configured] Error 1
>> >
>> > Ezequiel?
>> >
>>
>> Already discussed here: http://patchwork.ozlabs.org/patch/312275/
>>
>> Since it seems a compiler bug, all we can do for now is disable minidlna
>> for nios2 with a note about a compiler's bug.
>
> The _gp problem seems to be occurring for a bunch of other packages. We
> should contact the Sourcery CodeBench people about this, I believe.
> Someone to take the lead on this?
>
Altera provided the names of the people working on this (and also
suggested they might not reply to private mails). Let me find some
time to prepare a mail for them.
--
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-23 23:46 ` Ezequiel García
@ 2014-02-24 21:16 ` Thomas Petazzoni
2014-02-24 21:18 ` Ezequiel García
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-24 21:16 UTC (permalink / raw)
To: buildroot
Dear Ezequiel Garc?a,
On Sun, 23 Feb 2014 20:46:37 -0300, Ezequiel Garc?a wrote:
> On 23 February 2014 07:00, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> >
> >> nios2 | minidlna-1.1.1 | NOK | http://autobuild.buildroot.net/results/2e6fa6e4891b5cc4c75943130158aa24fa77f26e/
> >
> > configure: error: Could not find libavformat - part of ffmpeg
> > make: *** [/home/test/test/3/output/build/minidlna-1.1.1/.stamp_configured] Error 1
> >
> > Ezequiel?
> >
>
> Already discussed here: http://patchwork.ozlabs.org/patch/312275/
>
> Since it seems a compiler bug, all we can do for now is disable minidlna
> for nios2 with a note about a compiler's bug.
The _gp problem seems to be occurring for a bunch of other packages. We
should contact the Sourcery CodeBench people about this, I believe.
Someone to take the lead on this?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-24 10:12 ` Vicente Olivert Riera
@ 2014-02-24 10:30 ` Vicente Olivert Riera
0 siblings, 0 replies; 416+ messages in thread
From: Vicente Olivert Riera @ 2014-02-24 10:30 UTC (permalink / raw)
To: buildroot
On 02/24/2014 10:12 AM, Vicente Olivert Riera wrote:
> On 02/23/2014 10:00 AM, Thomas Petazzoni wrote:
>>> mips64el | ltp-testsuite-20130904 | NOK |
>>> http://autobuild.buildroot.net/results/f9b3780c712ba7e3cbb871dcfd5123340be688b3/
>>>
>>
>> Cannot work in master, it needs the version bump in next. Should we
>> disable ltp-testsuite build on mips64el in master?
>
> Disabling this package for the new release is the best solution. If we
> know that it will fail then it has no sense to keep it enabled.
>
Anyway..., this is not a problem of MIPS. This is a problem with this
package and glibc >= 2.18. Here is the commit which fixed the problem
upstream:
https://github.com/linux-test-project/ltp/commit/5811a1d7f007b2683c72d8315df0e0cd1c67a1b4
--
Vincent
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-23 10:00 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (2 preceding siblings ...)
2014-02-23 23:46 ` Ezequiel García
@ 2014-02-24 10:12 ` Vicente Olivert Riera
2014-02-24 10:30 ` Vicente Olivert Riera
2014-02-25 21:08 ` Samuel Martin
4 siblings, 1 reply; 416+ messages in thread
From: Vicente Olivert Riera @ 2014-02-24 10:12 UTC (permalink / raw)
To: buildroot
On 02/23/2014 10:00 AM, Thomas Petazzoni wrote:
>> mips64el | ltp-testsuite-20130904 | NOK | http://autobuild.buildroot.net/results/f9b3780c712ba7e3cbb871dcfd5123340be688b3/
>
> Cannot work in master, it needs the version bump in next. Should we
> disable ltp-testsuite build on mips64el in master?
Disabling this package for the new release is the best solution. If we
know that it will fail then it has no sense to keep it enabled.
--
Vincent
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-22 21:54 ` Ryan Barnett
@ 2014-02-24 9:47 ` Vicente Olivert Riera
0 siblings, 0 replies; 416+ messages in thread
From: Vicente Olivert Riera @ 2014-02-24 9:47 UTC (permalink / raw)
To: buildroot
On 02/22/2014 09:54 PM, Ryan Barnett wrote:
> Thomas and Vicente,
>
> On Fri, Feb 21, 2014 at 10:08 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>
>>> mipsel | rt-tests-0.83 | NOK | http://autobuild.buildroot.net/results/c76e6f8b2d7fc29abc2f4dcae962b60cf91a8e0c/
>>
>> Usual rt-tests failure on mipsel, fixed by a bump of rt-tests, but
>> which was committed to next.
>
> rt-tests was not bumped on next but rather ltp-testsuite was to fix an
> issue. However, Vicente submitted a patch to uclibc that will add for
> _tid specifically targeted for this package. Is this something that
> could be backported to our uclibc version?
>
> Specifically the commit is as follows:
>
> http://git.uclibc.org/uClibc/commit/?id=b4e6e61e2f7c6fb4bf59f66efaa74591a2112912
>
> Another option to fix the rt-tests-0.83 failures is to disable
> rt-tests when uclibc for mipsel is used.
>
> This is what I found when I was investigating a recent rt-tests-0.83
> autobuilder failure. I will not have time backport Vicente's patch but
> I may have time to submit a patch to disable this package in the way
> that is described above.
>
> Thanks,
> -Ryan
>
If we decide to not add more uClibc patches on BR, then I think we
should disable this package for uClibc + mips. Is useless to always have
an autobuild failure that you already know where the problem is but you
are not going to fix it. FIx it or disable that package. This autobuild
failure is just more nonsense flood.
--
Vincent
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-23 10:00 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-02-23 10:16 ` Thomas De Schampheleire
2014-02-23 15:45 ` Peter Korsgaard
@ 2014-02-23 23:46 ` Ezequiel García
2014-02-24 21:16 ` Thomas Petazzoni
2014-02-24 10:12 ` Vicente Olivert Riera
2014-02-25 21:08 ` Samuel Martin
4 siblings, 1 reply; 416+ messages in thread
From: Ezequiel García @ 2014-02-23 23:46 UTC (permalink / raw)
To: buildroot
On 23 February 2014 07:00, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
>> nios2 | minidlna-1.1.1 | NOK | http://autobuild.buildroot.net/results/2e6fa6e4891b5cc4c75943130158aa24fa77f26e/
>
> configure: error: Could not find libavformat - part of ffmpeg
> make: *** [/home/test/test/3/output/build/minidlna-1.1.1/.stamp_configured] Error 1
>
> Ezequiel?
>
Already discussed here: http://patchwork.ozlabs.org/patch/312275/
Since it seems a compiler bug, all we can do for now is disable minidlna
for nios2 with a note about a compiler's bug.
--
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-23 10:00 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-02-23 10:16 ` Thomas De Schampheleire
@ 2014-02-23 15:45 ` Peter Korsgaard
2014-02-23 23:46 ` Ezequiel García
` (2 subsequent siblings)
4 siblings, 0 replies; 416+ messages in thread
From: Peter Korsgaard @ 2014-02-23 15:45 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> avr32 | gst1-libav-1.2.2 | NOK | http://autobuild.buildroot.net/results/d727c0f61b84acee08d2262691e07f9839235f54/
> Don't know. Any idea?
Presumably avr32 has some relocation limitations like we've seen on mips
xtensaand arc, maybe there's a magic gcc argument to make it use a
different type?
>> mipsel | rt-tests-0.83 | NOK | http://autobuild.buildroot.net/results/074265602bec4aba6c82d1aee389045e8ad33d4b/
> Ryan Barnett has sent a patch to fix this. Peter, can you commit
> http://patchwork.ozlabs.org/patch/323254/ and
> http://patchwork.ozlabs.org/patch/323255/.
Will do.
>> bfin | sdl-1.2.15 | NOK | http://autobuild.buildroot.net/results/9c893390fb4ca5630f03387adc918c8a3d80c912/
>> nios2 | sdl-1.2.15 | NOK | http://autobuild.buildroot.net/results/543b4135c7996133f32e82d72d6f2969622f8617/
> Both fixed by http://patchwork.ozlabs.org/patch/323145/. Peter can you
> commit this patch?
I've already cherry picked the similar patch from next yesterday.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-23 10:16 ` Thomas De Schampheleire
@ 2014-02-23 10:56 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-23 10:56 UTC (permalink / raw)
To: buildroot
Dear Thomas De Schampheleire,
On Sun, 23 Feb 2014 11:16:58 +0100, Thomas De Schampheleire wrote:
> >
> >> powerpc | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/3ce992a663ddf1030a987bb778f8275a8e5fdef0/
> >
> > To be investigated.
> >
>
> My proposal would be to disable webkit on powerpc. As I wrote in the
> previous analysis mail, there is already an upstream bug report for
> this, without a lot of feedback. If someone wants to have webkit on
> powerpc, he/she should take the matter upstream.
>
> If you agree, I can send a patch for it...
I'm fine with this solution.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-23 10:00 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2014-02-23 10:16 ` Thomas De Schampheleire
2014-02-23 10:56 ` Thomas Petazzoni
2014-02-23 15:45 ` Peter Korsgaard
` (3 subsequent siblings)
4 siblings, 1 reply; 416+ messages in thread
From: Thomas De Schampheleire @ 2014-02-23 10:16 UTC (permalink / raw)
To: buildroot
>
>> powerpc | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/3ce992a663ddf1030a987bb778f8275a8e5fdef0/
>
> To be investigated.
>
My proposal would be to disable webkit on powerpc. As I wrote in the
previous analysis mail, there is already an upstream bug report for
this, without a lot of feedback. If someone wants to have webkit on
powerpc, he/she should take the matter upstream.
If you agree, I can send a patch for it...
Best regards,
Thomas
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-23 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-22 Thomas Petazzoni
@ 2014-02-23 10:00 ` Thomas Petazzoni
2014-02-23 10:16 ` Thomas De Schampheleire
` (4 more replies)
0 siblings, 5 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-23 10:00 UTC (permalink / raw)
To: buildroot
Hello all,
On Sun, 23 Feb 2014 08:30:09 +0100 (CET), Thomas Petazzoni wrote:
> bfin | alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/051645bb07daab81241a378a8cc426d617b98a64/
> bfin | alsa-utils-1.0.26 | NOK | http://autobuild.buildroot.net/results/03885497b519c17338e8f53194ea1b425fbab4d8/
This is being taken care of by Thomas De Schampheleire.
> bfin | cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/93a97f90345d193b52035b2dc7559a306e11098e/
> bfin | cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/3ee23ac4cbfd02555185689486dea5b103b05294/
I'll try to have a look today at these.
> bfin | e2fsprogs-1.42.9 | NOK | http://autobuild.buildroot.net/results/ee2c1568d16ac040011dd4d6d8b543ff9e9e2622/
Ditto.
> avr32 | gst1-libav-1.2.2 | NOK | http://autobuild.buildroot.net/results/d727c0f61b84acee08d2262691e07f9839235f54/
Don't know. Any idea?
> avr32 | iputils-s20121011 | NOK | http://autobuild.buildroot.net/results/4a5ba3987ceaadc385a8e77acf8aa0c598811b22/
> avr32 | iputils-s20121011 | NOK | http://autobuild.buildroot.net/results/a96ae6bca11375ed872da48bbae4e923e0fba4e5/
> avr32 | iputils-s20121011 | NOK | http://autobuild.buildroot.net/results/d6768cc732353f1d53ed1ae3e9c8102abb9db0fa/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=50c33ad125e84f6df485b85ef10c9dd6b73ae7ea.
> bfin | libcec-libcec-2.1.1 | NOK | http://autobuild.buildroot.net/results/670ce46627daaa4ae9ecdb8ffb6f97d0574354d4/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=ff6000507ae32006f1da8c3510bc3d48fbe7ccae
> mips64el | ltp-testsuite-20130904 | NOK | http://autobuild.buildroot.net/results/f9b3780c712ba7e3cbb871dcfd5123340be688b3/
Cannot work in master, it needs the version bump in next. Should we
disable ltp-testsuite build on mips64el in master?
> x86_64 | lua-ev-458165bdfe0c6eadc788... | NOK | http://autobuild.buildroot.net/results/41c8bb9cf91a86908a150dae27726136cb56f5b7/
Samuel, Fran?ois, you discussed this problem recently. Can you come up
with a patch that solves it?
> nios2 | minidlna-1.1.1 | NOK | http://autobuild.buildroot.net/results/2e6fa6e4891b5cc4c75943130158aa24fa77f26e/
configure: error: Could not find libavformat - part of ffmpeg
make: *** [/home/test/test/3/output/build/minidlna-1.1.1/.stamp_configured] Error 1
Ezequiel?
> arm | opencv-2.4.2 | NOK | http://autobuild.buildroot.net/results/71e4c8118871ec220f1b1a420eae4cfd74ac148f/
smooth.cpp:525:1: internal compiler error: in vect_transform_stmt, at tree-vect-stmts.c:5468
This is with a fairly old Crosstool-NG toolchain. We should ignore
this, I believe.
> microblaze | pixman-0.30.0 | NOK | http://autobuild.buildroot.net/results/8064092cdbac85fbf4322429d29d5d11dc51860f/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=a9baea4345625f6f00fc59395faec83e08346015.
> mipsel | rt-tests-0.83 | NOK | http://autobuild.buildroot.net/results/074265602bec4aba6c82d1aee389045e8ad33d4b/
Ryan Barnett has sent a patch to fix this. Peter, can you commit
http://patchwork.ozlabs.org/patch/323254/ and
http://patchwork.ozlabs.org/patch/323255/.
> mips64el | sawman-1.6.3 | NOK | http://autobuild.buildroot.net/results/19bfe0d39e457fd260b73928331721f57555fc84/
> mips64el | sawman-1.6.3 | NOK | http://autobuild.buildroot.net/results/1dffadaed95ad328e464ec08440d5a28de6e8b47/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=0a2850104bd1b3e9e7011e8dd7767eff158b835e.
> bfin | sdl-1.2.15 | NOK | http://autobuild.buildroot.net/results/9c893390fb4ca5630f03387adc918c8a3d80c912/
> nios2 | sdl-1.2.15 | NOK | http://autobuild.buildroot.net/results/543b4135c7996133f32e82d72d6f2969622f8617/
Both fixed by http://patchwork.ozlabs.org/patch/323145/. Peter can you
commit this patch?
> aarch64 | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/64c4f405c7bd72e5e9dc8fc0823677b79e476e8e/
> x86_64 | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/8726be7b5432dbab0b0ca5a0c0e5152a66c45171/
> x86_64 | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/b319c6722395a99f98790e6c4582dc872d7ef0d9/
Weird problems :)
> powerpc | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/3ce992a663ddf1030a987bb778f8275a8e5fdef0/
To be investigated.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-21 9:08 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (4 preceding siblings ...)
2014-02-21 13:54 ` Vicente Olivert Riera
@ 2014-02-22 21:54 ` Ryan Barnett
2014-02-24 9:47 ` Vicente Olivert Riera
2014-02-26 11:06 ` Vicente Olivert Riera
6 siblings, 1 reply; 416+ messages in thread
From: Ryan Barnett @ 2014-02-22 21:54 UTC (permalink / raw)
To: buildroot
Thomas and Vicente,
On Fri, Feb 21, 2014 at 10:08 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>> mipsel | rt-tests-0.83 | NOK | http://autobuild.buildroot.net/results/c76e6f8b2d7fc29abc2f4dcae962b60cf91a8e0c/
>
> Usual rt-tests failure on mipsel, fixed by a bump of rt-tests, but
> which was committed to next.
rt-tests was not bumped on next but rather ltp-testsuite was to fix an
issue. However, Vicente submitted a patch to uclibc that will add for
_tid specifically targeted for this package. Is this something that
could be backported to our uclibc version?
Specifically the commit is as follows:
http://git.uclibc.org/uClibc/commit/?id=b4e6e61e2f7c6fb4bf59f66efaa74591a2112912
Another option to fix the rt-tests-0.83 failures is to disable
rt-tests when uclibc for mipsel is used.
This is what I found when I was investigating a recent rt-tests-0.83
autobuilder failure. I will not have time backport Vicente's patch but
I may have time to submit a patch to disable this package in the way
that is described above.
Thanks,
-Ryan
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-21 9:08 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (3 preceding siblings ...)
2014-02-21 9:50 ` Thomas De Schampheleire
@ 2014-02-21 13:54 ` Vicente Olivert Riera
2014-02-22 21:54 ` Ryan Barnett
2014-02-26 11:06 ` Vicente Olivert Riera
6 siblings, 0 replies; 416+ messages in thread
From: Vicente Olivert Riera @ 2014-02-21 13:54 UTC (permalink / raw)
To: buildroot
On 02/21/2014 09:08 AM, Thomas Petazzoni wrote:
>> mips | matchbox-lib-1.9 | NOK | http://autobuild.buildroot.net/results/e4d510ab6ba69f95401e3120ab90ccdff22deb91/
>
> mbpixbuf.c:127:3: error: unknown type name 'jmp_buf'
>
> Vicente maybe?
>
Patches sent.
--
Vincent
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-21 9:08 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (2 preceding siblings ...)
2014-02-21 9:49 ` Anton Kolesov
@ 2014-02-21 9:50 ` Thomas De Schampheleire
2014-02-21 13:54 ` Vicente Olivert Riera
` (2 subsequent siblings)
6 siblings, 0 replies; 416+ messages in thread
From: Thomas De Schampheleire @ 2014-02-21 9:50 UTC (permalink / raw)
To: buildroot
On Fri, Feb 21, 2014 at 10:08 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
[..]
>
>> powerpc | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/c1ffdd6fd0a7d352faddbe58a81b66c22bbf7bbf/
>
> Architecture support problem.
>
> ./Source/JavaScriptCore/assembler/MacroAssembler.h:62:2: error: #error "The MacroAssembler is not supported on this platform."
>
Last release cycle I looked into this, found an existing bug report,
and added onto it, but without a lot of success:
https://bugs.webkit.org/show_bug.cgi?id=113638
I managed to fix one part of the problem, but bumped into another one.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-21 9:08 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-02-21 9:24 ` Peter Korsgaard
2014-02-21 9:46 ` Frank Bergmann
@ 2014-02-21 9:49 ` Anton Kolesov
2014-02-21 9:50 ` Thomas De Schampheleire
` (3 subsequent siblings)
6 siblings, 0 replies; 416+ messages in thread
From: Anton Kolesov @ 2014-02-21 9:49 UTC (permalink / raw)
To: buildroot
Hi Thomas,
>
> > arc | ruby-1.9.3-p484 | NOK |
> http://autobuild.buildroot.net/results/c3d235d4c42f6b256cf3bba7140dae5c7
> bd4d2fd/
>
> compiling parser.c
> {standard input}: Assembler messages:
> {standard input}:2581: Error: operand out of range (524 is not between -512
> and 511)
> {standard input}:2585: Error: operand out of range (516 is not between -512
> and 511)
> {standard input}:2856: Error: operand out of range (512 is not between -512
> and 511)
>
> Compiler problem on ARC. Maybe fixed by the bump of the ARC toolchain
> in next. Anton, can you confirm?
>
Yes, I've just run with "next" and ruby builds successfully.
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-21 9:08 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-02-21 9:24 ` Peter Korsgaard
@ 2014-02-21 9:46 ` Frank Bergmann
2014-02-21 9:49 ` Anton Kolesov
` (4 subsequent siblings)
6 siblings, 0 replies; 416+ messages in thread
From: Frank Bergmann @ 2014-02-21 9:46 UTC (permalink / raw)
To: buildroot
Hello,
On 21.02.2014 10:08, Thomas Petazzoni wrote:
> Hello all,
>
> On Fri, 21 Feb 2014 08:30:08 +0100 (CET), Thomas Petazzoni wrote:
>
>> nios2 | e2fsprogs-1.42.9 | NOK | http://autobuild.buildroot.net/results/480d1337de3467520d629fa8bdee57436337ce05/
>
> Fixed by
> http://lists.busybox.net/pipermail/buildroot/2014-February/089981.html
> and
> http://lists.busybox.net/pipermail/buildroot/2014-February/089982.html,
> but I must say I don't necessarily understand the problem.
A short C-program test.c:
#ifndef _GNU_SOURCE
#define _GNU_SOURCE
#endif
#include <fcntl.h>
int main(int argc, char **argv) {
return fallocate(0, 0, 0, 0);
}
That makes no sense but compiles without errors:
$> nios2-linux-gnu-gcc test.c
$> ls
a.out test.c
But when I provide _FILE_OFFSET_BITS=64 the library uses fallocate64
instead of fallocate:
$> nios2-linux-gnu-gcc -D_FILE_OFFSET_BITS=64 test.c
/tmp/ccQbizFP.o: In function `main':
test.c:(.text+0x30): undefined reference to `fallocate64'
collect2: error: ld returned 1 exit status
Regards,
Frank.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-21 9:08 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2014-02-21 9:24 ` Peter Korsgaard
2014-02-21 9:46 ` Frank Bergmann
` (5 subsequent siblings)
6 siblings, 0 replies; 416+ messages in thread
From: Peter Korsgaard @ 2014-02-21 9:24 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> sh4a | dropbear-2014.63 | NOK | http://autobuild.buildroot.net/results/294f462fd585b405fc3067967f9508202bb76230/
> Download problem. Peter, can you put the tarball on
> sources.buildroot.net?
I did already yesterday evening. The mirror script runs every 30
minutes, so normally sources.buildroot.net should have the tarballs
pretty much right away, but the script got broken by the recent
BUILDROOT_DL_DIR -> BR2_DL_DIR change and I hadn't noticed it.
Fixed now.
>> avr32 | gpsd-b4c32aa40cff1b4e1041d5... | NOK | http://autobuild.buildroot.net/results/ee2ec848e893f08fa80caf99a67e68b73b6400e8/
> driver_nmea2000.c: In function 'nmea2000_open':
> driver_nmea2000.c:1607: error: 'PF_CAN' undeclared (first use in this function)
> driver_nmea2000.c:1607: error: (Each undeclared identifier is reported only once
> driver_nmea2000.c:1607: error: for each function it appears in.)
> driver_nmea2000.c:1636: error: 'AF_CAN' undeclared (first use in this function)
> Smells like a too old kernel header problem, but it uses an AVR32
> toolchain built by Buildroot 2014.02-rc1, so I would suppose the kernel
> headers are quite recent?
PF_CAN comes from uClibc (bits/socket.h), and 0.9.31 didn't have
PF_CAN. Either we should mark this as !avr32 or backport the uClibc
change:
http://git.buildroot.net/uClibc/commit/?id=6f810c757e5b14a97f
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-21 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-20 Thomas Petazzoni
@ 2014-02-21 9:08 ` Thomas Petazzoni
2014-02-21 9:24 ` Peter Korsgaard
` (6 more replies)
0 siblings, 7 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-21 9:08 UTC (permalink / raw)
To: buildroot
Hello all,
On Fri, 21 Feb 2014 08:30:08 +0100 (CET), Thomas Petazzoni wrote:
> bfin | cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/cf6d6b0c794e254676903f86d96d11d107c79283/
cairo-test-runner.c: In function 'is_running_under_debugger':
cairo-test-runner.c:168: error: implicit declaration of function 'getppid'
cairo-test-runner.c:168: warning: nested extern declaration of 'getppid'
cairo-test-runner.c:169: error: implicit declaration of function 'readlink'
cairo-test-runner.c:169: warning: nested extern declaration of 'readlink'
Needs investigation.
> i686 | coreutils-8.21 | NOK | http://autobuild.buildroot.net/results/bd4cc779b46e3837e3d6c43c97eaf42fdfc3a288/
Fixed by http://git.buildroot.net/buildroot/commit/?id=0cb2b158d4650ab0f0648056c212686d026997ae.
> avr32 | cups-1.3.11 | NOK | http://autobuild.buildroot.net/results/61dc8c841b878abe60fffa7e686e15e362fa908b/
Looks like a problem linking with zlib or something like that. Not sure
if it's AVR32 specific or not:
../cups/libcups.a(file.o): In function `cups_compress':
/home/test/test/2/output/build/cups-1.3.11/cups/file.c:271: undefined reference to `crc32'
/home/test/test/2/output/build/cups-1.3.11/cups/file.c:271: undefined reference to `deflate'
> bfin | dhcpcd-6.1.0 | NOK | http://autobuild.buildroot.net/results/51249e8d3487e17bb6a60a99dcbd461f7b591eac/
Just sent a patch to fix this.
> sh4a | dropbear-2014.63 | NOK | http://autobuild.buildroot.net/results/294f462fd585b405fc3067967f9508202bb76230/
Download problem. Peter, can you put the tarball on
sources.buildroot.net?
> nios2 | e2fsprogs-1.42.9 | NOK | http://autobuild.buildroot.net/results/480d1337de3467520d629fa8bdee57436337ce05/
Fixed by
http://lists.busybox.net/pipermail/buildroot/2014-February/089981.html
and
http://lists.busybox.net/pipermail/buildroot/2014-February/089982.html,
but I must say I don't necessarily understand the problem.
> bfin | gpm-1.20.7 | NOK | http://autobuild.buildroot.net/results/b2beb4876fba22f139df9c336ff0fae77354721b/
gpm uses fork(), cannot work on !MMU. Patch sent.
> avr32 | gpsd-b4c32aa40cff1b4e1041d5... | NOK | http://autobuild.buildroot.net/results/ee2ec848e893f08fa80caf99a67e68b73b6400e8/
driver_nmea2000.c: In function 'nmea2000_open':
driver_nmea2000.c:1607: error: 'PF_CAN' undeclared (first use in this function)
driver_nmea2000.c:1607: error: (Each undeclared identifier is reported only once
driver_nmea2000.c:1607: error: for each function it appears in.)
driver_nmea2000.c:1636: error: 'AF_CAN' undeclared (first use in this function)
Smells like a too old kernel header problem, but it uses an AVR32
toolchain built by Buildroot 2014.02-rc1, so I would suppose the kernel
headers are quite recent?
> nios2 | host-gdb-7.5.1 | NOK | http://autobuild.buildroot.net/results/df09e1fe301480b599be777bf26874d66a152810/
Fixed by http://git.buildroot.net/buildroot/commit/?id=faed40cf1dd378e764c8c202f9e4652ff845b148.
> bfin | icu-51.2 | NOK | http://autobuild.buildroot.net/results/b415fed7fae4012bad7d8b53a481bd71bdab716f/
> bfin | icu-51.2 | NOK | http://autobuild.buildroot.net/results/ce09a82e33663902c063bfb23a7dafe4067d4e46/
Both fixed by
http://git.buildroot.net/buildroot/commit/?id=8797a8cb587634c907321ab6aa50ba5400392739.
> powerpc | libnftnl-1.0.0 | NOK | http://autobuild.buildroot.net/results/5a25499020b8e933a8c1d9381aecbce0ac74dddc/
In file included from common.c:10:0:
/home/test/test/1/output/host/usr/powerpc-buildroot-linux-gnu/sysroot/usr/include/linux/netlink.h:31:2: error: expected specifier-qualifier-list before 'sa_family_t'
make[3]: *** [common.lo] Error 1
Smells like a kernel headers problem.
> aarch64 | libv4l-0.8.9 | NOK | http://autobuild.buildroot.net/results/9994201ccccdd36349bad75c001810785c3b09b1/
> aarch64 | libv4l-0.8.9 | NOK | http://autobuild.buildroot.net/results/ed66792e332ee0256a17f98cbe21dfcfe6e8743b/
Both fixed by
http://git.buildroot.net/buildroot/commit/?id=045651e253be4ec20abbff0cd2678b88509cbb20.
> mips | matchbox-lib-1.9 | NOK | http://autobuild.buildroot.net/results/e4d510ab6ba69f95401e3120ab90ccdff22deb91/
mbpixbuf.c:127:3: error: unknown type name 'jmp_buf'
Vicente maybe?
> arm | mplayer-1.1.1 | NOK | http://autobuild.buildroot.net/results/aa95d19fa5fdddd4e6ac5ae5f079396ffd7b70a9/
ARM floating point issue.
{standard input}: Assembler messages:
{standard input}:3784: Error: selected FPU does not support instruction -- `vmul.f32 q0,q0,q1'
{standard input}:3869: Error: selected processor does not support ARM mode `veor q0,q0,q2'
{standard input}:3870: Error: selected FPU does not support instruction -- `vmul.f32 q0,q0,q1'
{standard input}:3931: Error: selected FPU does not support instruction -- `vmul.f32 d0,d0,d1'
{standard input}:4001: Error: selected processor does not support ARM mode `veor d0,d0,d2'
{standard input}:4002: Error: selected FPU does not support instruction -- `vmul.f32 d0,d0,d1'
> mipsel | rt-tests-0.83 | NOK | http://autobuild.buildroot.net/results/c76e6f8b2d7fc29abc2f4dcae962b60cf91a8e0c/
Usual rt-tests failure on mipsel, fixed by a bump of rt-tests, but
which was committed to next.
> arc | ruby-1.9.3-p484 | NOK | http://autobuild.buildroot.net/results/c3d235d4c42f6b256cf3bba7140dae5c7bd4d2fd/
compiling parser.c
{standard input}: Assembler messages:
{standard input}:2581: Error: operand out of range (524 is not between -512 and 511)
{standard input}:2585: Error: operand out of range (516 is not between -512 and 511)
{standard input}:2856: Error: operand out of range (512 is not between -512 and 511)
Compiler problem on ARC. Maybe fixed by the bump of the ARC toolchain
in next. Anton, can you confirm?
> avr32 | samba-3.6.22 | NOK | http://autobuild.buildroot.net/results/bbf179eb809c5515fbf7bb0ab54c1d02fc6e71c7/
/home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/avr32-buildroot-linux-uclibc/4.2.2/crtbegin.o:(.fini+0x0): relocation truncated to fit: R_AVR32_GOT18SW against `__do_global_dtors_aux'
/home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/avr32-buildroot-linux-uclibc/4.2.2/crtbegin.o:(.init+0x0): relocation truncated to fit: R_AVR32_GOT18SW against `frame_dummy'
Weird problem. Maybe a binary that is too big for AVR32 ? Samba creates
really huge binaries. Should we simply disable samba on avr32
altogether? Or is it a specific configuration of Samba that doesn't
build?
> mips | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/95cac37ef8f035c024ebcd808367739c29875f30/
/home/test/test/3/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-linux-gnu/4.7.3/../../../../mips-linux-gnu/bin/ld: ./.libs/libvlc_srtp.a(libvlc_srtp_la-srtp.o): relocation R_MIPS_26 against `div' can not be used when making a shared object; recompile with -fPIC
./.libs/libvlc_srtp.a(libvlc_srtp_la-srtp.o): could not read symbols: Bad value
collect2: error: ld returned 1 exit status
We have the same problem on x86-64: some vlc library is apparently not
build with -fPIC. Could someone look into this?
It has caused the last 3 build failures of vlc on mips:
http://autobuild.buildroot.org/?reason=vlc-2.1.2&arch=mips&step=3
and the four last build failures of vlc on x86-64:
http://autobuild.buildroot.org/results/a53/a53ea017ec92150c7d37c0da0ca9a8dac75f460e/build-end.log
> powerpc | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/c1ffdd6fd0a7d352faddbe58a81b66c22bbf7bbf/
Architecture support problem.
./Source/JavaScriptCore/assembler/MacroAssembler.h:62:2: error: #error "The MacroAssembler is not supported on this platform."
> bfin | zeromq-3.2.4 | NOK | http://autobuild.buildroot.net/results/f234ca1dace003be0dc3e331589eb448170d6ad1/
Missing atomic builtins?
../src/.libs/libzmq.so: warning: the use of OBSOLESCENT `tempnam' is discouraged, use `mkstemp'
/home/test/test/1/output/host/usr/bfin-buildroot-linux-uclibc/sysroot/usr/lib/libpgm.so: warning: gethostbyaddr is obsolescent, use getaddrinfo() instead.
/home/test/test/1/output/host/usr/bfin-buildroot-linux-uclibc/sysroot/usr/lib/libpgm.so: undefined reference to `___sync_add_and_fetch_2'
/home/test/test/1/output/host/usr/bfin-buildroot-linux-uclibc/sysroot/usr/lib/libpgm.so: undefined reference to `___sync_fetch_and_add_2'
> powerpc | zeromq-3.2.4 | NOK | http://autobuild.buildroot.net/results/c077d0782fd2791e295a8abf9464c9933a16a52f/
Static linking issue:
/home/test/test/3/output/host/usr/lib/gcc/powerpc-buildroot-linux-uclibc/4.7.3/../../../../powerpc-buildroot-linux-uclibc/bin/ld: attempted static link of dynamic object `/home/test/test/3/output/host/usr/powerpc-buildroot-linux-uclibc/lib/libstdc++.so'
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-17 15:40 ` Vicente Olivert Riera
2014-02-17 15:44 ` Markos Chandras
@ 2014-02-17 16:09 ` Thomas Petazzoni
1 sibling, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-17 16:09 UTC (permalink / raw)
To: buildroot
Dear Vicente Olivert Riera,
On Mon, 17 Feb 2014 15:40:32 +0000, Vicente Olivert Riera wrote:
> > You'll find below a quick analysis of the build failures. If you are in
> > Cc, it means that there is a question for you below, or a request to
> > help debugging a specific problem. Thanks!
> >
> > On Fri, 7 Feb 2014 08:30:09 +0100 (CET), Thomas Petazzoni wrote:
>
> >> mipsel | alsa-utils-1.0.26 | NOK | http://autobuild.buildroot.net/results/05d3186bcb74c905bbc689859522b88db78c2f68/
> >
> > /home/test/test/3/output/host/opt/ext-toolchain/bin/../lib/gcc/mipsel-buildroot-linux-uclibc/4.7.3/../../../../mipsel-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.21 assertion fail elfxx-mips.c:3416
> > /home/test/test/3/output/host/usr/mipsel-buildroot-linux-uclibc/sysroot/usr/lib/libasound.a(rawmidi_symbols.o):(.data.rel+0x4): undefined reference to `_snd_module_rawmidi_virt'
> >
> > Looks like a MIPS toolchain problem, maybe? The toolchain used is a
> > Buildroot toolchain built with Buildroot 2013.11. If the problem no
> > longer occurs with the internal toolchain backend, then it will be
> > fixed once I rebuild the external Buildroot toolchains of the Buildroot
> > (when -rc1 is released). Vicente, can you test if this works with the
> > internal toolchain?
>
> No, it doesn't work. There is the same problem with the internal
> toolchain, but only fails when BR2_PREFER_STATIC_LIB is selected.
To be investigated, then :-)
> >> nios2 | ltp-testsuite-20130904 | NOK | http://autobuild.buildroot.net/results/9aca518bf53aea62bc4bb437976f0223113c26ce/
> >
> > Would be good to see if the bump of ltp-testsuite proposed by Vicente
> > fixes this problem. Peter, can you apply
> > http://patchwork.ozlabs.org/patch/317112/ ?
>
> I have received an email from Peter saying "Committed to next, thanks."
> What that means? To next what?
When -rc1 of version N is released, we no longer commit "big changes"
to the master branch, as we have entered the "bug fixing period", until
the final release of version N to take place.
But during that time, we do not want to completely stop the merging of
the "big changes", so Peter opens up a branch, called "next", whose
starting point is the -rc1 of version N. And the contents of this
branch will be merged into master as soon as the final release of
version N is done, which means that the changes merged in the
next branch will be part release N+1.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-17 15:44 ` Markos Chandras
@ 2014-02-17 15:45 ` Vicente Olivert Riera
0 siblings, 0 replies; 416+ messages in thread
From: Vicente Olivert Riera @ 2014-02-17 15:45 UTC (permalink / raw)
To: buildroot
On 02/17/2014 03:44 PM, Markos Chandras wrote:
> On 02/17/2014 03:40 PM, Vicente Olivert Riera wrote:
>> On 02/07/2014 12:53 PM, Thomas Petazzoni wrote:
>>> Hello all,
>>>
>>> You'll find below a quick analysis of the build failures. If you are in
>>> Cc, it means that there is a question for you below, or a request to
>>> help debugging a specific problem. Thanks!
>>>
>>> On Fri, 7 Feb 2014 08:30:09 +0100 (CET), Thomas Petazzoni wrote:
>>
>>>> mipsel | alsa-utils-1.0.26 | NOK |
>>>> http://autobuild.buildroot.net/results/05d3186bcb74c905bbc689859522b88db78c2f68/
>>>>
>>>>
>>>
>>> /home/test/test/3/output/host/opt/ext-toolchain/bin/../lib/gcc/mipsel-buildroot-linux-uclibc/4.7.3/../../../../mipsel-buildroot-linux-uclibc/bin/ld:
>>>
>>> BFD (GNU Binutils) 2.21 assertion fail elfxx-mips.c:3416
>>> /home/test/test/3/output/host/usr/mipsel-buildroot-linux-uclibc/sysroot/usr/lib/libasound.a(rawmidi_symbols.o):(.data.rel+0x4):
>>>
>>> undefined reference to `_snd_module_rawmidi_virt'
>>>
>>> Looks like a MIPS toolchain problem, maybe? The toolchain used is a
>>> Buildroot toolchain built with Buildroot 2013.11. If the problem no
>>> longer occurs with the internal toolchain backend, then it will be
>>> fixed once I rebuild the external Buildroot toolchains of the Buildroot
>>> (when -rc1 is released). Vicente, can you test if this works with the
>>> internal toolchain?
>>
>> No, it doesn't work. There is the same problem with the internal
>> toolchain, but only fails when BR2_PREFER_STATIC_LIB is selected.
>>
>>>> nios2 | ltp-testsuite-20130904 | NOK |
>>>> http://autobuild.buildroot.net/results/9aca518bf53aea62bc4bb437976f0223113c26ce/
>>>>
>>>>
>>>
>>> Would be good to see if the bump of ltp-testsuite proposed by Vicente
>>> fixes this problem. Peter, can you apply
>>> http://patchwork.ozlabs.org/patch/317112/ ?
>>
>> I have received an email from Peter saying "Committed to next, thanks."
>> What that means? To next what?
>>
> The -next branch
>
> http://git.buildroot.org/buildroot/log/?h=next
>
> Whenever a release is approaching, after -rc1, a -next branch is created
> for fixes that will be included *after* the release. In other words,
> anything in -next will not be part of the release. Once a release is
> done, the -next branch is merged back to master, and development is
> moving forward as usual.
>
Oh, I see... Thanks!
--
Vincent
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-17 15:40 ` Vicente Olivert Riera
@ 2014-02-17 15:44 ` Markos Chandras
2014-02-17 15:45 ` Vicente Olivert Riera
2014-02-17 16:09 ` Thomas Petazzoni
1 sibling, 1 reply; 416+ messages in thread
From: Markos Chandras @ 2014-02-17 15:44 UTC (permalink / raw)
To: buildroot
On 02/17/2014 03:40 PM, Vicente Olivert Riera wrote:
> On 02/07/2014 12:53 PM, Thomas Petazzoni wrote:
>> Hello all,
>>
>> You'll find below a quick analysis of the build failures. If you are in
>> Cc, it means that there is a question for you below, or a request to
>> help debugging a specific problem. Thanks!
>>
>> On Fri, 7 Feb 2014 08:30:09 +0100 (CET), Thomas Petazzoni wrote:
>
>>> mipsel | alsa-utils-1.0.26 | NOK |
>>> http://autobuild.buildroot.net/results/05d3186bcb74c905bbc689859522b88db78c2f68/
>>>
>>
>> /home/test/test/3/output/host/opt/ext-toolchain/bin/../lib/gcc/mipsel-buildroot-linux-uclibc/4.7.3/../../../../mipsel-buildroot-linux-uclibc/bin/ld:
>> BFD (GNU Binutils) 2.21 assertion fail elfxx-mips.c:3416
>> /home/test/test/3/output/host/usr/mipsel-buildroot-linux-uclibc/sysroot/usr/lib/libasound.a(rawmidi_symbols.o):(.data.rel+0x4):
>> undefined reference to `_snd_module_rawmidi_virt'
>>
>> Looks like a MIPS toolchain problem, maybe? The toolchain used is a
>> Buildroot toolchain built with Buildroot 2013.11. If the problem no
>> longer occurs with the internal toolchain backend, then it will be
>> fixed once I rebuild the external Buildroot toolchains of the Buildroot
>> (when -rc1 is released). Vicente, can you test if this works with the
>> internal toolchain?
>
> No, it doesn't work. There is the same problem with the internal
> toolchain, but only fails when BR2_PREFER_STATIC_LIB is selected.
>
>>> nios2 | ltp-testsuite-20130904 | NOK |
>>> http://autobuild.buildroot.net/results/9aca518bf53aea62bc4bb437976f0223113c26ce/
>>>
>>
>> Would be good to see if the bump of ltp-testsuite proposed by Vicente
>> fixes this problem. Peter, can you apply
>> http://patchwork.ozlabs.org/patch/317112/ ?
>
> I have received an email from Peter saying "Committed to next, thanks."
> What that means? To next what?
>
The -next branch
http://git.buildroot.org/buildroot/log/?h=next
Whenever a release is approaching, after -rc1, a -next branch is created
for fixes that will be included *after* the release. In other words,
anything in -next will not be part of the release. Once a release is
done, the -next branch is merged back to master, and development is
moving forward as usual.
--
markos
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-07 12:53 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (5 preceding siblings ...)
2014-02-07 19:03 ` Spenser Gilliland
@ 2014-02-17 15:40 ` Vicente Olivert Riera
2014-02-17 15:44 ` Markos Chandras
2014-02-17 16:09 ` Thomas Petazzoni
6 siblings, 2 replies; 416+ messages in thread
From: Vicente Olivert Riera @ 2014-02-17 15:40 UTC (permalink / raw)
To: buildroot
On 02/07/2014 12:53 PM, Thomas Petazzoni wrote:
> Hello all,
>
> You'll find below a quick analysis of the build failures. If you are in
> Cc, it means that there is a question for you below, or a request to
> help debugging a specific problem. Thanks!
>
> On Fri, 7 Feb 2014 08:30:09 +0100 (CET), Thomas Petazzoni wrote:
>> mipsel | alsa-utils-1.0.26 | NOK | http://autobuild.buildroot.net/results/05d3186bcb74c905bbc689859522b88db78c2f68/
>
> /home/test/test/3/output/host/opt/ext-toolchain/bin/../lib/gcc/mipsel-buildroot-linux-uclibc/4.7.3/../../../../mipsel-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.21 assertion fail elfxx-mips.c:3416
> /home/test/test/3/output/host/usr/mipsel-buildroot-linux-uclibc/sysroot/usr/lib/libasound.a(rawmidi_symbols.o):(.data.rel+0x4): undefined reference to `_snd_module_rawmidi_virt'
>
> Looks like a MIPS toolchain problem, maybe? The toolchain used is a
> Buildroot toolchain built with Buildroot 2013.11. If the problem no
> longer occurs with the internal toolchain backend, then it will be
> fixed once I rebuild the external Buildroot toolchains of the Buildroot
> (when -rc1 is released). Vicente, can you test if this works with the
> internal toolchain?
No, it doesn't work. There is the same problem with the internal
toolchain, but only fails when BR2_PREFER_STATIC_LIB is selected.
>> nios2 | ltp-testsuite-20130904 | NOK | http://autobuild.buildroot.net/results/9aca518bf53aea62bc4bb437976f0223113c26ce/
>
> Would be good to see if the bump of ltp-testsuite proposed by Vicente
> fixes this problem. Peter, can you apply
> http://patchwork.ozlabs.org/patch/317112/ ?
I have received an email from Peter saying "Committed to next, thanks."
What that means? To next what?
--
Vincent
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-14 9:12 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (3 preceding siblings ...)
2014-02-15 21:31 ` Baruch Siach
@ 2014-02-16 0:00 ` Romain Naour
4 siblings, 0 replies; 416+ messages in thread
From: Romain Naour @ 2014-02-16 0:00 UTC (permalink / raw)
To: buildroot
Hi Thomas, All,
>> i686 | imagemagick-6.8.8-4 | NOK | http://autobuild.buildroot.net/results/a9d35975c7699515350eb307712cd69b6d48e418/
> Not enough backlog to see what the error is, unfortunately.
>
>
It is impossible to disable documentation in Imagemagick because all
options like --disable-gtk-doc, --disable-doc, --disable-docs and
--disable-documentation are not handled by configure script.
It will be easier to understand what happens when the build fails if we
remove hard coded documentation from Makefiles.
I just sent a patch for this.
Best regards,
Romain Naour
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-14 9:12 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (2 preceding siblings ...)
2014-02-14 13:15 ` Ezequiel García
@ 2014-02-15 21:31 ` Baruch Siach
2014-02-16 0:00 ` Romain Naour
4 siblings, 0 replies; 416+ messages in thread
From: Baruch Siach @ 2014-02-15 21:31 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Fri, Feb 14, 2014 at 10:12:41AM +0100, Thomas Petazzoni wrote:
> > xtensa | kmod-16 | NOK | http://autobuild.buildroot.net/results/ba205bcbb6898bee78f610883f3837930eda262c/
>
> Binutils internal error. Baruch ?
Xtensa Toolchain issues are out of scope for me at the moment I'm afraid.
Sorry.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-14 13:15 ` Ezequiel García
2014-02-15 7:27 ` Frank Bergmann
@ 2014-02-15 17:29 ` Frank Bergmann
1 sibling, 0 replies; 416+ messages in thread
From: Frank Bergmann @ 2014-02-15 17:29 UTC (permalink / raw)
To: buildroot
Hello,
On 14.02.2014 14:15, Ezequiel Garc?a wrote:
>>> nios2 | e2fsprogs-1.42.9 | NOK | http://autobuild.buildroot.net/results/70a47bd7392560cbc1c64769c8357c0b4c91ca3b/
>>
>> Another missing syscall on NIOS II ? Ezequiel ?
>>
>> ../lib/libext2fs.so: undefined reference to `fallocate64'
>> collect2: error: ld returned 1 exit status
>>
>
> Ah, yes. We have lots of packages failing with this issue. I think
> it's some issue
> with the toolchain. fallocate64 is not a system call (only fallocate
> exists, AFAICS),
> so this should be some libc issue.
>
> Anybody knows better? Who implements fallocate64? What can we do to fix this
> in Buildroot (using an external toolchain)?
No, sorry. But after dig a little bit:
e2fsprogs using
_FILE_OFFSET_BITS=64
while compiling the source. In this case the fallocate system call will
be silently replaced by fallocate64 (see:
https://lists.debian.org/debian-glibc/2010/02/msg00088.html). But
fallocate64 is unfortunately not available on nios2 toolchain at the moment.
The only solution that works appears to be completely disable the
fallocate system call(s) by providing
ac_cv_func_fallocate=no
to the configure script. The effect in e2fsprogs will be that
unix_discard() in ext2fs/unix_io.c will return with the "UNIMPLEMENTED"
return code. I'm not sure for the moment if the whole packages or only a
couple of functions gets unusable with this.
With regards,
Frank Bergmann.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-14 13:15 ` Ezequiel García
@ 2014-02-15 7:27 ` Frank Bergmann
2014-02-15 17:29 ` Frank Bergmann
1 sibling, 0 replies; 416+ messages in thread
From: Frank Bergmann @ 2014-02-15 7:27 UTC (permalink / raw)
To: buildroot
Hello,
On 14.02.2014 14:15, Ezequiel Garc?a wrote:
> On 14 February 2014 06:12, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>>> nios2 | crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/780c3388e408ae6479e824711b1c02fdbd34bef4/
>>
>> No idea what this error means. Ezequiel ?
>>
>> /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/crt1.o: undefined reference to symbol '_gp'
>> /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: note: '_gp' is defined in DSO /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/libgpg-error.so.0 so try adding it to the linker command line
>>
>
> As Peter said, some issue with the compiler. This is too much for me :-)
What about the hint the linker gives in the line after the error ?
Link the binary with the additional LDFLAG '-lgpg-error' build the
binary (but I have not run-time tested the result). This is also the
advise from libgcrypt:
$> libgcrypt-config --libs
-lgcrypt -ldl -lgpg-error
I guess this is an unlucky accident: libgpg-error exports a
symbol/function named '_gp' that could lead one to think it's about the
global pointer from the nios2.
> Adding nios2 support in the internal toolchain is on my (increasingly
> long) TODO list.
That's fine. Is there a public repository for early testing ?
With regards,
Frank Bergmann.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-14 17:05 ` Anton Kolesov
@ 2014-02-14 17:42 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-14 17:42 UTC (permalink / raw)
To: buildroot
Dear Anton Kolesov,
On Fri, 14 Feb 2014 17:05:24 +0000, Anton Kolesov wrote:
> I would say that I would prefer to keep current state, because currently master points to our released versions, which are pretty much of a known entity for us, even if with some known failures. Latest commits haven?t been completely tested, so while they fix some bugs, they might introduce some new undiscovered troubles as well, so I don't feel safe about pointing to them in the buildroot release.
Ok, no problem!
> Since it is a problem of our tools, I can volunteer to prepare patches that disable reverse dependencies of libxml for ARC in master, though you still will have to apply them :)
>
> I will ask our team opinion on this as well. And let me know if you are ok if I we just disable failing packages in master.
I believe it's ok to disable failing packages in master, except when
they have too many reverse dependencies and that we know the problem
will be fixed soon. For such cases, I can simply add an exception to
the autobuilder script.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-14 15:19 ` Thomas Petazzoni
@ 2014-02-14 17:05 ` Anton Kolesov
2014-02-14 17:42 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Anton Kolesov @ 2014-02-14 17:05 UTC (permalink / raw)
To: buildroot
Hi Thomas and Peter,
> >
> > As I said on IRC, if we think arc will be in a better state with those
> > bumps cherry picked to master instead, then that's fine for me as well.
>
> Anton, what is your confidence with this bump of the toolchain
> components? Should we merge it for 2014.02 ?
>
I would say that I would prefer to keep current state, because currently master points to our released versions, which are pretty much of a known entity for us, even if with some known failures. Latest commits haven?t been completely tested, so while they fix some bugs, they might introduce some new undiscovered troubles as well, so I don't feel safe about pointing to them in the buildroot release.
Since it is a problem of our tools, I can volunteer to prepare patches that disable reverse dependencies of libxml for ARC in master, though you still will have to apply them :)
I will ask our team opinion on this as well. And let me know if you are ok if I we just disable failing packages in master.
Anton
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-14 14:42 ` Peter Korsgaard
@ 2014-02-14 15:19 ` Thomas Petazzoni
2014-02-14 17:05 ` Anton Kolesov
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-14 15:19 UTC (permalink / raw)
To: buildroot
Dear Peter Korsgaard,
On Fri, 14 Feb 2014 15:42:16 +0100, Peter Korsgaard wrote:
> > Argh. So libxml2 doesn't build at all on master. This is pretty
> > annoying, because this package has a fairly large number of reverse
> > dependencies, so marking all of them "depends on !BR2_arc" to avoid
> > build problems occurring on master is going to be annoying.
>
> > I was discussing this morning with better whether he should have merged
>
> s/better/Peter/ ;)
Oops, sorry!
Fortunately I have this automatic thing "Dear <foo>", which gets your
name right whenever I reply to you :-)
> > your ARC toolchain components bump to master instead of next. He merged
> > in next to be on the safe side, but the consequence is that we have a
> > good number of packages that don't build for ARC in master, causing
> > autobuilder failures, that we know are solved in next.
>
> > Oh well, I guess it's just a matter of waiting for the release at the
> > end of the month, and get next merged into master.
>
> As I said on IRC, if we think arc will be in a better state with those
> bumps cherry picked to master instead, then that's fine for me as well.
Anton, what is your confidence with this bump of the toolchain
components? Should we merge it for 2014.02 ?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-14 14:13 ` Thomas Petazzoni
@ 2014-02-14 14:42 ` Peter Korsgaard
2014-02-14 15:19 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Peter Korsgaard @ 2014-02-14 14:42 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> Yes, it passes for me with the "next" branch.
> Argh. So libxml2 doesn't build at all on master. This is pretty
> annoying, because this package has a fairly large number of reverse
> dependencies, so marking all of them "depends on !BR2_arc" to avoid
> build problems occurring on master is going to be annoying.
> I was discussing this morning with better whether he should have merged
s/better/Peter/ ;)
> your ARC toolchain components bump to master instead of next. He merged
> in next to be on the safe side, but the consequence is that we have a
> good number of packages that don't build for ARC in master, causing
> autobuilder failures, that we know are solved in next.
> Oh well, I guess it's just a matter of waiting for the release at the
> end of the month, and get next merged into master.
As I said on IRC, if we think arc will be in a better state with those
bumps cherry picked to master instead, then that's fine for me as well.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-14 10:23 ` Anton Kolesov
@ 2014-02-14 14:13 ` Thomas Petazzoni
2014-02-14 14:42 ` Peter Korsgaard
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-14 14:13 UTC (permalink / raw)
To: buildroot
Dear Anton Kolesov,
On Fri, 14 Feb 2014 10:23:00 +0000, Anton Kolesov wrote:
> > > arc | imagemagick-6.8.8-4 | NOK |
> > http://autobuild.buildroot.net/results/97ec0c366c24bd03fe4c26851e8729a4d
> > 8eaf4d0/
> >
> > Internal compiler error. Anton, would you mind checking if your recent
> > bump of the ARC toolchain components solves this compiler problem?
>
> No, that hasn't fixed yet. I've opened bug report for this error, but no ETA. Should I disable affected packages for ARC until solution will be ready?
Yes, please.
> > > arc | libxml2-2.9.1 | NOK |
> > http://autobuild.buildroot.net/results/4abdea83c6915aa02b6dc55c9a9dd964
> > ba70ac4b/
> >
> > Another internal compiler error. Anton, same thing, is that fixed by your
> > recent bump?
>
> Yes, it passes for me with the "next" branch.
Argh. So libxml2 doesn't build at all on master. This is pretty
annoying, because this package has a fairly large number of reverse
dependencies, so marking all of them "depends on !BR2_arc" to avoid
build problems occurring on master is going to be annoying.
I was discussing this morning with better whether he should have merged
your ARC toolchain components bump to master instead of next. He merged
in next to be on the safe side, but the consequence is that we have a
good number of packages that don't build for ARC in master, causing
autobuilder failures, that we know are solved in next.
Oh well, I guess it's just a matter of waiting for the release at the
end of the month, and get next merged into master.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-14 9:12 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-02-14 10:23 ` Anton Kolesov
2014-02-14 11:29 ` Peter Korsgaard
@ 2014-02-14 13:15 ` Ezequiel García
2014-02-15 7:27 ` Frank Bergmann
2014-02-15 17:29 ` Frank Bergmann
2014-02-15 21:31 ` Baruch Siach
2014-02-16 0:00 ` Romain Naour
4 siblings, 2 replies; 416+ messages in thread
From: Ezequiel García @ 2014-02-14 13:15 UTC (permalink / raw)
To: buildroot
On 14 February 2014 06:12, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>> nios2 | crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/780c3388e408ae6479e824711b1c02fdbd34bef4/
>
> No idea what this error means. Ezequiel ?
>
> /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/crt1.o: undefined reference to symbol '_gp'
> /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: note: '_gp' is defined in DSO /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/libgpg-error.so.0 so try adding it to the linker command line
>
As Peter said, some issue with the compiler. This is too much for me :-)
Adding nios2 support in the internal toolchain is on my (increasingly
long) TODO list.
>> nios2 | e2fsprogs-1.42.9 | NOK | http://autobuild.buildroot.net/results/70a47bd7392560cbc1c64769c8357c0b4c91ca3b/
>
> Another missing syscall on NIOS II ? Ezequiel ?
>
> ../lib/libext2fs.so: undefined reference to `fallocate64'
> collect2: error: ld returned 1 exit status
>
Ah, yes. We have lots of packages failing with this issue. I think
it's some issue
with the toolchain. fallocate64 is not a system call (only fallocate
exists, AFAICS),
so this should be some libc issue.
Anybody knows better? Who implements fallocate64? What can we do to fix this
in Buildroot (using an external toolchain)?
>> nios2 | libnetfilter_queue-1.0.2 | NOK | http://autobuild.buildroot.net/results/3d77c91847a099b2498030505b91f3f84c81df18/
>
> Issue with kernel headers ?
>
> /home/test/test/1/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/libnfnetlink/linux_nfnetlink.h:6:6: error: nested redefinition of 'enum nfnetlink_groups'
> /home/test/test/1/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/libnfnetlink/linux_nfnetlink.h:6:6: error: redeclaration of 'enum nfnetlink_groups'
>
The kernel headers exported by CodeSourcery toolchain seem to be copied
using some braindead cp-like copy, instead of using "make headers_install".
The latter does some modification to the headers. The dhcp package also fails
because of this.
Let's put this on top of my nios2 TODO list. Can we apply the header
sanitize in Buildroot,
when we install the Sourcery toolchain?
--
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-14 9:12 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-02-14 10:23 ` Anton Kolesov
@ 2014-02-14 11:29 ` Peter Korsgaard
2014-02-14 13:15 ` Ezequiel García
` (2 subsequent siblings)
4 siblings, 0 replies; 416+ messages in thread
From: Peter Korsgaard @ 2014-02-14 11:29 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> nios2 | crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/780c3388e408ae6479e824711b1c02fdbd34bef4/
> No idea what this error means. Ezequiel ?
> /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/crt1.o: undefined reference to symbol '_gp'
> /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: note: '_gp' is defined in DSO /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/libgpg-error.so.0 so try adding it to the linker command line
If I remember correctly, _gp is a magic linker symbol on mips/nios. When
we discussed it last time I brought up this link:
https://lists.debian.org/debian-mips/2013/06/msg00041.html
>> x86_64 | gst1-libav-1.2.2 | NOK | http://autobuild.buildroot.net/results/2d83f38b4a6cb2a1a47c78306da7773270ce698e/
> Weird:
> /home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-unknown-linux-uclibc/4.6.3/../../../../x86_64-unknown-linux-uclibc/bin/ld: ../../gst-libs/ext/libav/libavcodec/libavcodec.a(lpc.o): relocation R_X86_64_PC32 against symbol `ff_pd_1' can not be used when making a shared object; recompile with -fPIC
> But the build is not a static library build.
But it uses a static (embedded) copy of libav, perhaps that one isn't
built with -fPIC?
>> powerpc | tstools-1_11 | NOK | http://autobuild.buildroot.net/results/b92b707ec32bf6f9a0c5834fd68d81d76d1a6365/
> Weird messages:
> Assembler messages:
> Fatal error: can't create obj/esfilter.o: No such file or directory
> Parallel build issue?
Sounds like it.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-14 9:12 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2014-02-14 10:23 ` Anton Kolesov
2014-02-14 14:13 ` Thomas Petazzoni
2014-02-14 11:29 ` Peter Korsgaard
` (3 subsequent siblings)
4 siblings, 1 reply; 416+ messages in thread
From: Anton Kolesov @ 2014-02-14 10:23 UTC (permalink / raw)
To: buildroot
Hi Thomas,
>
> > arc | imagemagick-6.8.8-4 | NOK |
> http://autobuild.buildroot.net/results/97ec0c366c24bd03fe4c26851e8729a4d
> 8eaf4d0/
>
> Internal compiler error. Anton, would you mind checking if your recent
> bump of the ARC toolchain components solves this compiler problem?
No, that hasn't fixed yet. I've opened bug report for this error, but no ETA. Should I disable affected packages for ARC until solution will be ready?
> > arc | libxml2-2.9.1 | NOK |
> http://autobuild.buildroot.net/results/4abdea83c6915aa02b6dc55c9a9dd964
> ba70ac4b/
>
> Another internal compiler error. Anton, same thing, is that fixed by your
> recent bump?
Yes, it passes for me with the "next" branch.
Anton
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-14 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-13 Thomas Petazzoni
@ 2014-02-14 9:12 ` Thomas Petazzoni
2014-02-14 10:23 ` Anton Kolesov
` (4 more replies)
0 siblings, 5 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-14 9:12 UTC (permalink / raw)
To: buildroot
Hello,
Aaron, Ezequiel, Spenser, Anton, Baruch and Gustavo, there are
questions for you below. Please read on ! :-)
On Fri, 14 Feb 2014 08:30:08 +0100 (CET), Thomas Petazzoni wrote:
> bfin | cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/899395ce00ba54f19fd1f8ebaf1ea7a15e3d98dc/
> bfin | cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/0fcb07e9efbef5881c986199e2c1358d7fd9cffa/
cairo-test-runner.c: In function 'is_running_under_debugger':
cairo-test-runner.c:168: error: implicit declaration of function 'getppid'
cairo-test-runner.c:168: warning: nested extern declaration of 'getppid'
cairo-test-runner.c:169: error: implicit declaration of function 'readlink'
cairo-test-runner.c:169: warning: nested extern declaration of 'readlink'
This problem has been here for a while. Aaron, as the Blackfin person,
can you have a look into this and sent a patch to fix the problem? Thanks!
> nios2 | crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/780c3388e408ae6479e824711b1c02fdbd34bef4/
No idea what this error means. Ezequiel ?
/home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/crt1.o: undefined reference to symbol '_gp'
/home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: note: '_gp' is defined in DSO /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/libgpg-error.so.0 so try adding it to the linker command line
> microblaze | dropwatch-1.4 | NOK | http://autobuild.buildroot.net/results/916eec6a8853c49eab5b7806edcc0add06b8168f/
Spenser, can you have a look at this one?
/home/test/test/2/output/host/usr/bin/microblaze-buildroot-linux-gnu-gcc -g -o dropwatch main.o lookup.o lookup_bfd.o lookup_kas.o -lbfd -liberty -lreadline -lnl-3 -lnl-genl-3 -lpthread -lncurses -lm
/home/test/test/2/output/host/usr/lib/gcc/microblaze-buildroot-linux-gnu/4.9.0/../../../../microblaze-buildroot-linux-gnu/bin/ld: cannot find -liberty
> nios2 | e2fsprogs-1.42.9 | NOK | http://autobuild.buildroot.net/results/70a47bd7392560cbc1c64769c8357c0b4c91ca3b/
Another missing syscall on NIOS II ? Ezequiel ?
../lib/libext2fs.so: undefined reference to `fallocate64'
collect2: error: ld returned 1 exit status
> x86_64 | gst1-libav-1.2.2 | NOK | http://autobuild.buildroot.net/results/2d83f38b4a6cb2a1a47c78306da7773270ce698e/
Weird:
/home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-unknown-linux-uclibc/4.6.3/../../../../x86_64-unknown-linux-uclibc/bin/ld: ../../gst-libs/ext/libav/libavcodec/libavcodec.a(lpc.o): relocation R_X86_64_PC32 against symbol `ff_pd_1' can not be used when making a shared object; recompile with -fPIC
But the build is not a static library build.
> powerpc | host-libeet-1.7.7 | NOK | http://autobuild.buildroot.net/results/e3581e4a17e2c577458f5481b391f548b7fcdf69/
Spurious failure, the build machine was too heavily loaded.
> i686 | host-libxslt-1.1.28 | NOK | http://autobuild.buildroot.net/results/784b3989fab4007d6d077fba9a9078cf337ce002/
CCLD testThreads
/home/peko/scratch/host/usr/lib/libxml2.so: undefined reference to `lzma_code at XZ_5.0'
/home/peko/scratch/host/usr/lib/libxml2.so: undefined reference to `lzma_auto_decoder at XZ_5.0'
/home/peko/scratch/host/usr/lib/libxml2.so: undefined reference to `lzma_end at XZ_5.0'
/home/peko/scratch/host/usr/lib/libxml2.so: undefined reference to `lzma_properties_decode at XZ_5.0'
collect2: error: ld returned 1 exit status
I find it rather weird that this doesn't happen more often...
> i686 | imagemagick-6.8.8-4 | NOK | http://autobuild.buildroot.net/results/a9d35975c7699515350eb307712cd69b6d48e418/
Not enough backlog to see what the error is, unfortunately.
> arc | imagemagick-6.8.8-4 | NOK | http://autobuild.buildroot.net/results/97ec0c366c24bd03fe4c26851e8729a4d8eaf4d0/
Internal compiler error. Anton, would you mind checking if your recent
bump of the ARC toolchain components solves this compiler problem?
> xtensa | kmod-16 | NOK | http://autobuild.buildroot.net/results/ba205bcbb6898bee78f610883f3837930eda262c/
Binutils internal error. Baruch ?
> nios2 | libnetfilter_queue-1.0.2 | NOK | http://autobuild.buildroot.net/results/3d77c91847a099b2498030505b91f3f84c81df18/
Issue with kernel headers ?
/home/test/test/1/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/libnfnetlink/linux_nfnetlink.h:6:6: error: nested redefinition of 'enum nfnetlink_groups'
/home/test/test/1/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/libnfnetlink/linux_nfnetlink.h:6:6: error: redeclaration of 'enum nfnetlink_groups'
> arc | libxml2-2.9.1 | NOK | http://autobuild.buildroot.net/results/4abdea83c6915aa02b6dc55c9a9dd964ba70ac4b/
Another internal compiler error. Anton, same thing, is that fixed by your recent bump?
> mips64el | ltp-testsuite-20130904 | NOK | http://autobuild.buildroot.net/results/f6aa04e2b904b1aae3b68b2ffbb1b8edb6f4929a/
This one is fixed by
http://git.buildroot.net/buildroot/commit/?h=next&id=898e54bd783280ee1ffb6aeeb523c9fb8c31641a,
but unfortunately Peter only merged it in the next branch, so we still
have the build problem on master.
> powerpc | mmc-utils-11f2ceabc4ad3f0dd... | NOK | http://autobuild.buildroot.net/results/79e24d5ada564e664f32041cc71a1aeac0d9d5cd/
> powerpc | mmc-utils-11f2ceabc4ad3f0dd... | NOK | http://autobuild.buildroot.net/results/b23f295008a834bbb37b6ea5c99842409b652bc9/
Too old kernel headers;
> microblaze | pixman-0.30.0 | NOK | http://autobuild.buildroot.net/results/3becd76e2a7c3cf843d43ea9f1713fd536888cd7/
> microblaze | pixman-0.30.0 | NOK | http://autobuild.buildroot.net/results/2b1feb18dc415c69aae6de9d558e527faae7b246/
utils.c:779:21: error: 'FE_DIVBYZERO' undeclared (first use in this function)
feenableexcept (FE_DIVBYZERO);
Spenser ? :-)
> bfin | popt-1.16 | NOK | http://autobuild.buildroot.net/results/8d3ee14585f54c6946b449854df9f06ea7746e8e/
Maybe the blackfin uClibc lacks _glob_pattern_p ? Aaron ?
./.libs/libpopt.so: undefined reference to `_glob_pattern_p'
> powerpc | python-2.7.3 | NOK | http://autobuild.buildroot.net/results/64ed5890d4d03399eb549cba4aa3e65afd3b005f/
./Modules/posixmodule.c: In function '_pystat_fromstructstat':
./Modules/posixmodule.c:1356:22: error: 'struct stat' has no member named 'st_birthtime'
Weird: it wants to use st_birthtime, even though this field doesn't
exist under Linux, and Python has a configure test that checks whether
it exists or not, and the code is properly conditionally compiled.
> xtensa | qt5base-5.2.0 | NOK | http://autobuild.buildroot.net/results/70b77e7a5b292e3fcbcf8cab4651c48220f2bd17/
Needs NPTL. Fixed by my series about NPTL support.
> nios2 | samba-3.6.22 | NOK | http://autobuild.buildroot.net/results/bc674e494c24155800583dde5dfda0709709becb/
Wooo, lots of errors. Relocation truncated to fit (maybe the binary is
too large), and missing fallocate64.
> x86_64 | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/eb6317433b89d3ad2a70b39a186ee223bc3f4a41/
> x86_64 | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/d439787cb8b3ee3e001dfd24e93351201a1387ce/
> x86_64 | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/c397677e2332c9a39950ea840333fc05d04c2e68/
uint64_t type problem. Gustavo, can you have a look?
> powerpc | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/a659d7ede91bb13904c360fe8c8f316b7011918b/
Something for me to look at, it seems.
> powerpc | tstools-1_11 | NOK | http://autobuild.buildroot.net/results/b92b707ec32bf6f9a0c5834fd68d81d76d1a6365/
Weird messages:
Assembler messages:
Fatal error: can't create obj/esfilter.o: No such file or directory
Parallel build issue?
> arm | tvheadend-c7d0335eb10d02b78... | NOK | http://autobuild.buildroot.net/results/4df8cd85e0287910567df81c0394b2914570e98a/
src/input/mpegts/dvb_support.c:415:25: error: 'SYS_TURBO' undeclared here (not in a function)
{ "TURBO", SYS_TURBO }
Too old kernel headers.
> bfin | udev-182 | NOK | http://autobuild.buildroot.net/results/386be48be71ede6e06ea5547e37a1b6448f5fba2/
udev needs fork().
> sh4a | unknown | TIM | http://autobuild.buildroot.net/results/52bc9c4c2dfc0bd37f7170b98a2201ed853bad74/
> sh4a | unknown | TIM | http://autobuild.buildroot.net/results/899155257298dbc85c1681f900ddd042ead98412/
> sh4a | unknown | TIM | http://autobuild.buildroot.net/results/b908769c1291da8f758a44b04d36dbc415400b39/
Those ones should be fixed now, they were caused by issues in the
autobuilder script.
> x86_64 | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/a53ea017ec92150c7d37c0da0ca9a8dac75f460e/
/home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../i686-pc-linux-gnu/bin/ld: ./.libs/libvlc_srtp.a(libvlc_srtp_la-srtp.o): relocation R_X86_64_PC32 against undefined symbol `gcry_md_reset@@GCRYPT_1.2' can not be used when making a shared object; recompile with -fPIC
/home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../i686-pc-linux-gnu/bin/ld: final link failed: Bad value
> powerpc | w_scan-20130331 | NOK | http://autobuild.buildroot.net/results/6e7c691099a8f3eef4fc84860ceb1a94f25873eb/
Too old kernel headers.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-13 21:17 ` Romain Naour
@ 2014-02-13 21:59 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-13 21:59 UTC (permalink / raw)
To: buildroot
Dear Romain Naour,
On Thu, 13 Feb 2014 22:17:15 +0100, Romain Naour wrote:
> Thanks for testing and for the log.
>
> Ok, I'll send a patch to disable parallel builds.
It'd be nicer to actually understand the parallel build problem and fix
it :-)
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-13 18:54 ` Thomas Petazzoni
@ 2014-02-13 21:17 ` Romain Naour
2014-02-13 21:59 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Romain Naour @ 2014-02-13 21:17 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Le 13/02/2014 19:54, Thomas Petazzoni a ?crit :
> Hello,
>
> On Thu, 13 Feb 2014 12:29:42 +0100, Thomas Petazzoni wrote:
>
>>> I don't think it's related but libhal.h is present on the autobuilder's log
>>> "checking for libhal.h... yes"
>>>
>>> Maybe add --without-hal in nut.mk ?
>> That would certainly be a good idea, but I have a successful build with
>> the configuration of the autobuilder. So I'm suspecting a parallel
>> build problem maybe, but so far I've attempted maybe builds of nut, and
>> none of them failed. I've started a loop that builds nut repeatedly and
>> aborts if the build has failed. Hopefully the issue will pop up.
> The issue popped up. Not exactly the same, but another case of invalid
> stuff being present in an header file. So it really looks like a
> parallel build issue.
>
> Thomas
Thanks for testing and for the log.
Ok, I'll send a patch to disable parallel builds.
Best regards,
Romain
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-13 11:29 ` Thomas Petazzoni
@ 2014-02-13 18:54 ` Thomas Petazzoni
2014-02-13 21:17 ` Romain Naour
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-13 18:54 UTC (permalink / raw)
To: buildroot
Hello,
On Thu, 13 Feb 2014 12:29:42 +0100, Thomas Petazzoni wrote:
> > I don't think it's related but libhal.h is present on the autobuilder's log
> > "checking for libhal.h... yes"
> >
> > Maybe add --without-hal in nut.mk ?
>
> That would certainly be a good idea, but I have a successful build with
> the configuration of the autobuilder. So I'm suspecting a parallel
> build problem maybe, but so far I've attempted maybe builds of nut, and
> none of them failed. I've started a loop that builds nut repeatedly and
> aborts if the build has failed. Hopefully the issue will pop up.
The issue popped up. Not exactly the same, but another case of invalid
stuff being present in an header file. So it really looks like a
parallel build issue.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-12 20:58 ` Romain Naour
@ 2014-02-13 11:29 ` Thomas Petazzoni
2014-02-13 18:54 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-13 11:29 UTC (permalink / raw)
To: buildroot
Dear Romain Naour,
On Wed, 12 Feb 2014 21:58:28 +0100, Romain Naour wrote:
> I also tried to reproduce this build failure recently, but nut builds
> fine for me too.
> Have you found somethingon gcc10 ?
No, I've tried to reproduce it, but the exact configuration that caused
the build failure in the autobuilders doesn't fail for me.
> I don't think it's related but libhal.h is present on the autobuilder's log
> "checking for libhal.h... yes"
>
> Maybe add --without-hal in nut.mk ?
That would certainly be a good idea, but I have a successful build with
the configuration of the autobuilder. So I'm suspecting a parallel
build problem maybe, but so far I've attempted maybe builds of nut, and
none of them failed. I've started a loop that builds nut repeatedly and
aborts if the build has failed. Hopefully the issue will pop up.
> Can you provide a complete build log with configure step ?
Sure, see the attached log file.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logfile2
Type: application/octet-stream
Size: 303269 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140213/58e5cdb5/attachment-0001.obj>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-12 8:06 ` Thomas Petazzoni
@ 2014-02-12 20:58 ` Romain Naour
2014-02-13 11:29 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Romain Naour @ 2014-02-12 20:58 UTC (permalink / raw)
To: buildroot
Hi Tomas, Yann,
>>>> arm | nut-2.6.5 | NOK | http://autobuild.buildroot.net/results/0ddd856bcbec2db0500791fd428ba053d6e4fa1b/
>>> libusb compatibility issue?
>>>
>>> scan_usb.c:34:29: error: unknown type name 'usb_dev_handle'
>>> scan_usb.c:38:41: error: unknown type name 'usb_dev_handle'
>>> scan_usb.c:41:1: error: unknown type name 'usb_dev_handle'
>>> scan_usb.c:41:48: warning: 'struct usb_device' declared inside parameter list [enabled by default]
>>> scan_usb.c:41:48: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
>>> scan_usb.c: In function 'nutscan_load_usb_library':
>>> scan_usb.c:67:22: error: 'nut_usb_close' undeclared (first use in this function)
>> I tried to reproduce it here, but it builds fine (in a squeeze-32
>> chroot, with almost nothing installed except the Buildroot
>> dependencies).
> Error occurred on gcc10, where tests are not running in a clean chroot,
> but in an environment with lots of headers/libraries installed. I'll do
> a test build on gcc10, to see what host stuff causes this mis-detection.
>
> Thanks!
>
> Thomas
I also tried to reproduce this build failure recently, but nut builds
fine for me too.
Have you found somethingon gcc10 ?
I don't think it's related but libhal.h is present on the autobuilder's log
"checking for libhal.h... yes"
Maybe add --without-hal in nut.mk ?
Can you provide a complete build log with configure step ?
I hope it can help...
Best regards,
Romain Naour
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140212/c05c4aa9/attachment.html>
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-12 8:32 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (2 preceding siblings ...)
2014-02-12 11:25 ` Samuel Martin
@ 2014-02-12 17:52 ` Yann E. MORIN
3 siblings, 0 replies; 416+ messages in thread
From: Yann E. MORIN @ 2014-02-12 17:52 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2014-02-12 09:32 +0100, Thomas Petazzoni spake thusly:
> As usual, analysis of yesterday build failures.
> > arm | qtuio-abe4973ff60654aad9df7... | NOK | http://autobuild.buildroot.net/results/9b57f76672c8d0a74980cb1de32661761b666ce7/
>
> /home/test/test/1/output/host/usr/bin/arm-unknown-linux-gnueabi-g++ -L/home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib -lGAL -lEGL -Wl,-O1 -o pinchzoom graphicsview.o main.o mouse.o moc_graphicsview.o moc_mouse.o qrc_mice.o -L/home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib -L../../lib -lqTUIO -lQtGui -L/home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot//usr/lib -ldirectfb -lfusion -L/home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib -ldirect -lEGL -lQtNetwork -lQtCore -lpthread
> /home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.6.4/../../../../arm-unknown-linux-gnueabi/bin/ld: warning: libXdamage.so.1, needed by /home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGAL.so, not found (try using -rpath or -rpath-link)
> /home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.6.4/../../../../arm-unknown-linux-gnueabi/bin/ld: warning: libXfixes.so.3, needed by /home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGAL.so, not found (try using -rpath or -rpath-link)
> /home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.6.4/../../../../arm-unknown-linux-gnueabi/bin/ld: warning: libXext.so.6, needed by /home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGAL.so, not found (try using -rpath or -rpath-link)
> /home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.6.4/../../../../arm-unknown-linux-gnueabi/bin/ld: warning: libX11.so.6, needed by /home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGAL.so, not found (try using -rpath or -rpath-link)
I already looked at that one, and the situatioon is strange:
- libGAL is provided by gpu-viv-bin-mx6q
- Xorg is not selected, so gpu-viv-bin-mx6q should install the 'fb'
version of the lib, which does not have those X11 dependencies
- on the other hand, the X11 version of libGAL does have a dependency
on two of the X11 libs, so it looks it was the one installed
So I tried rebuilding it here, and the build was sucessful:
- the installed libGAL is the 'fb' one
- qtuio build OK
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] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-12 12:44 ` Thomas De Schampheleire
@ 2014-02-12 12:47 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-12 12:47 UTC (permalink / raw)
To: buildroot
Dear Thomas De Schampheleire,
On Wed, 12 Feb 2014 13:44:05 +0100, Thomas De Schampheleire wrote:
> In alsa-utils, configure.in contains the following line:
> AM_PATH_ALSA(1.0.24)
>
> This macro is defined in aclocal.m4, and I want to change that,
> because this is where the -ldl is added unconditionally.
>
> So, if aclocal uses configure.in to generate aclocal.m4, the real
> definition of AM_PATH_ALSA must be somewhere else (outside the
> alsa-utils sources).
>
> So how to change the AM_PATH_ALSA ?
AM_PATH_ALSA is defined in the alsa-lib source code, utils/alsa.m4. So
when we install alsa-lib, it should also install alsa.m4
in $(STAGING_DIR)/usr/share/aclocal, so that when the autoreconf of
alsa-utils is done, it finds it.
BTW, what about joining #buildroot on IRC to do live discussion ? :-)
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-12 12:31 ` Thomas Petazzoni
@ 2014-02-12 12:44 ` Thomas De Schampheleire
2014-02-12 12:47 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Thomas De Schampheleire @ 2014-02-12 12:44 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Wed, Feb 12, 2014 at 1:31 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Wed, 12 Feb 2014 13:29:35 +0100, Thomas De Schampheleire wrote:
>
>> I found this snippet:
>> AC_CHECK_LIB(c, dlopen, LIBDL="", [AC_CHECK_LIB(dl, dlopen, LIBDL="-ldl")])
>>
>> which would be used as follows in aclocal.m4:
>> -ALSA_LIBS="$ALSA_LIBS -lasound -lm -ldl -lpthread"
>> +ALSA_LIBS="$ALSA_LIBS -lasound -lm $LIBDL -lpthread"
>>
>> but aclocal.m4 seems to be regenerated with autoreconf. How can you
>> make changes in that file?
>
> You don't make changes to aclocal.m4.
>
>> I tried adding an m4 file in the m4 subdirectory, adding it to the Makefile.am.
>> But how to regenerate aclocal.m4?
>
> By running the aclocal tool.
>
> From man aclocal:
>
> """
> Generate 'aclocal.m4' by scanning 'configure.ac' or 'configure.in
> """
In alsa-utils, configure.in contains the following line:
AM_PATH_ALSA(1.0.24)
This macro is defined in aclocal.m4, and I want to change that,
because this is where the -ldl is added unconditionally.
So, if aclocal uses configure.in to generate aclocal.m4, the real
definition of AM_PATH_ALSA must be somewhere else (outside the
alsa-utils sources).
So how to change the AM_PATH_ALSA ?
Thanks,
Thomas
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-12 12:29 ` Thomas De Schampheleire
@ 2014-02-12 12:31 ` Thomas Petazzoni
2014-02-12 12:44 ` Thomas De Schampheleire
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-12 12:31 UTC (permalink / raw)
To: buildroot
Dear Thomas De Schampheleire,
On Wed, 12 Feb 2014 13:29:35 +0100, Thomas De Schampheleire wrote:
> I found this snippet:
> AC_CHECK_LIB(c, dlopen, LIBDL="", [AC_CHECK_LIB(dl, dlopen, LIBDL="-ldl")])
>
> which would be used as follows in aclocal.m4:
> -ALSA_LIBS="$ALSA_LIBS -lasound -lm -ldl -lpthread"
> +ALSA_LIBS="$ALSA_LIBS -lasound -lm $LIBDL -lpthread"
>
> but aclocal.m4 seems to be regenerated with autoreconf. How can you
> make changes in that file?
You don't make changes to aclocal.m4.
> I tried adding an m4 file in the m4 subdirectory, adding it to the Makefile.am.
> But how to regenerate aclocal.m4?
By running the aclocal tool.
From man aclocal:
"""
Generate 'aclocal.m4' by scanning 'configure.ac' or 'configure.in
"""
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-12 11:39 ` Thomas De Schampheleire
@ 2014-02-12 12:29 ` Thomas De Schampheleire
2014-02-12 12:31 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Thomas De Schampheleire @ 2014-02-12 12:29 UTC (permalink / raw)
To: buildroot
Hi,
On Wed, Feb 12, 2014 at 12:39 PM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
[..]
>
> With the alsa-lib patch applied, this is the next problem in
> alsa-utils (Blackfin FLAT config):
> checking for ALSA CFLAGS...
> checking for ALSA LDFLAGS... -lasound -lm -ldl -lpthread
> checking for libasound headers version >= 1.0.24... found.
> checking for snd_ctl_open in -lasound... no
> configure: error: No linkable libasound was found.
> make: *** [/home/tdescham/repo/contrib/buildroot-alsa/output/build/alsa-utils-1.0.26/.stamp_configured]
> Error 1
>
>
> which is apparently the same problem as reported with bug #5774 (Not
> able to build ALSA-Utils for static build)
>
> The config.log says:
> configure:7019: checking for ALSA CFLAGS
> configure:7025: result:
> configure:7028: checking for ALSA LDFLAGS
> configure:7037: result: -lasound -lm -ldl -lpthread
> configure:7042: checking for libasound headers version >= 1.0.24
> configure:7104:
> /home/tdescham/repo/contrib/buildroot-alsa/output/host/usr/bin/bfin-uclinux-gcc
> -c -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> -pipe -Os -Wl,-elf2flt -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> -D_FILE_OFFSET_BITS=64 conftest.c >&5
> configure:7104: $? = 0
> configure:7105: result: found.
> configure:7124: checking for snd_ctl_open in -lasound
> configure:7149:
> /home/tdescham/repo/contrib/buildroot-alsa/output/host/usr/bin/bfin-uclinux-gcc
> -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> -D_FILE_OFFSET_BITS=64 -pipe -Os -Wl,-elf2flt -D_LARGEFILE_SOURCE
> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -elf2flt --static
> conftest.c -lasound -lasound -lm -ldl -lpthread >&5
> /home/tdescham/repo/contrib/buildroot-alsa/output/host/usr/bfin-buildroot-uclinux-uclibc/sysroot/usr/lib/libasound.a(pcm_dmix.o):
> In function `_snd_pcm_dmix_start_timer':
> pcm_dmix.c:(.text+0x53a): warning:
> /home/tdescham/repo/contrib/buildroot-alsa/output/host/opt/ext-toolchain/bfin-uclinux/bfin-uclinux/bin/ld.real:
> cannot find -ldl
> collect2: ld returned 1 exit status
>
>
> The relevant autoconf macro is AM_PATH_ALSA, defined in
> output/build/alsa-utils-1.0.26/aclocal.m4.
> However, what is the right solution?
> I assume we need to add a check to verify whether libdl is needed, correct?
> Any autoconf wizzkids in the house?
I found this snippet:
AC_CHECK_LIB(c, dlopen, LIBDL="", [AC_CHECK_LIB(dl, dlopen, LIBDL="-ldl")])
which would be used as follows in aclocal.m4:
-ALSA_LIBS="$ALSA_LIBS -lasound -lm -ldl -lpthread"
+ALSA_LIBS="$ALSA_LIBS -lasound -lm $LIBDL -lpthread"
but aclocal.m4 seems to be regenerated with autoreconf. How can you
make changes in that file?
I tried adding an m4 file in the m4 subdirectory, adding it to the Makefile.am.
But how to regenerate aclocal.m4?
Thanks,
Thomas
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-12 9:50 ` Thomas De Schampheleire
@ 2014-02-12 11:39 ` Thomas De Schampheleire
2014-02-12 12:29 ` Thomas De Schampheleire
0 siblings, 1 reply; 416+ messages in thread
From: Thomas De Schampheleire @ 2014-02-12 11:39 UTC (permalink / raw)
To: buildroot
Hi,
On Wed, Feb 12, 2014 at 10:50 AM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> Hi Thomas,
>
> On Wed, Feb 12, 2014 at 10:47 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> [..]
>>>
>>> Note that there is a related bug:
>>> https://bugs.busybox.net/show_bug.cgi?id=5774
>>> Not able to build ALSA-Utils for static build
>>>
>>> which does not yet have a patch it seems.
>>
>> Huh, it does have a patch!
>>
>
> I was too hasty. It does indeed have a patch, but I don't think it's a
> good patch. It disables -ldl unconditionally, so this will (untested)
> break alsa-lib on shared library builds, right?
>
>>> I tried reproducing it but
>>> couldn't, but then again, the bug report does not really provide a lot
>>> of info about the configuration.
>>
>> You need to build for blackfin FLAT to reproduce the problem. Is this
>> what you tested? Of course, if you try to reproduce the alsa-utils
>> problem, you will first fall into the alsa-lib problem :)
>
> Ok, thanks.
With the alsa-lib patch applied, this is the next problem in
alsa-utils (Blackfin FLAT config):
checking for ALSA CFLAGS...
checking for ALSA LDFLAGS... -lasound -lm -ldl -lpthread
checking for libasound headers version >= 1.0.24... found.
checking for snd_ctl_open in -lasound... no
configure: error: No linkable libasound was found.
make: *** [/home/tdescham/repo/contrib/buildroot-alsa/output/build/alsa-utils-1.0.26/.stamp_configured]
Error 1
which is apparently the same problem as reported with bug #5774 (Not
able to build ALSA-Utils for static build)
The config.log says:
configure:7019: checking for ALSA CFLAGS
configure:7025: result:
configure:7028: checking for ALSA LDFLAGS
configure:7037: result: -lasound -lm -ldl -lpthread
configure:7042: checking for libasound headers version >= 1.0.24
configure:7104:
/home/tdescham/repo/contrib/buildroot-alsa/output/host/usr/bin/bfin-uclinux-gcc
-c -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-pipe -Os -Wl,-elf2flt -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 conftest.c >&5
configure:7104: $? = 0
configure:7105: result: found.
configure:7124: checking for snd_ctl_open in -lasound
configure:7149:
/home/tdescham/repo/contrib/buildroot-alsa/output/host/usr/bin/bfin-uclinux-gcc
-o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -pipe -Os -Wl,-elf2flt -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -elf2flt --static
conftest.c -lasound -lasound -lm -ldl -lpthread >&5
/home/tdescham/repo/contrib/buildroot-alsa/output/host/usr/bfin-buildroot-uclinux-uclibc/sysroot/usr/lib/libasound.a(pcm_dmix.o):
In function `_snd_pcm_dmix_start_timer':
pcm_dmix.c:(.text+0x53a): warning:
/home/tdescham/repo/contrib/buildroot-alsa/output/host/opt/ext-toolchain/bfin-uclinux/bfin-uclinux/bin/ld.real:
cannot find -ldl
collect2: ld returned 1 exit status
The relevant autoconf macro is AM_PATH_ALSA, defined in
output/build/alsa-utils-1.0.26/aclocal.m4.
However, what is the right solution?
I assume we need to add a check to verify whether libdl is needed, correct?
Any autoconf wizzkids in the house?
Thanks,
Thomas
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-12 8:32 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-02-12 9:21 ` Peter Korsgaard
2014-02-12 9:41 ` Thomas De Schampheleire
@ 2014-02-12 11:25 ` Samuel Martin
2014-02-12 17:52 ` Yann E. MORIN
3 siblings, 0 replies; 416+ messages in thread
From: Samuel Martin @ 2014-02-12 11:25 UTC (permalink / raw)
To: buildroot
Thomas, all,
On Wed, Feb 12, 2014 at 9:32 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> As usual, analysis of yesterday build failures.
>
> On Wed, 12 Feb 2014 08:30:07 +0100 (CET), Thomas Petazzoni wrote:
[...]
>> i686 | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/39c77ffb5a5599d0b09422433c747b2bac185c4f/
>
> CXX libopencv_example_plugin_la-opencv_example.lo
> opencv_example.cpp:42:33: fatal error: opencv2/core/core_c.h: No such file or directory
I'll look into this.
Regards,
--
Samuel
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-12 9:52 ` Peter Korsgaard
@ 2014-02-12 10:15 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-12 10:15 UTC (permalink / raw)
To: buildroot
Dear Peter Korsgaard,
On Wed, 12 Feb 2014 10:52:19 +0100, Peter Korsgaard wrote:
> >> But orc is a JIT code generator, and from the source code it seems it
> >> only handles ARM/PowerPC/x86.
>
> > True. Odd that their configure script doesn't bail out after checking
> > the target architecture.
>
> > Things worth mentioning:
>
> > * They have a newer 0.4.17 version that has MIPS support, as well as
> > PowerPC64 support.
>
> Ehh, we currently use 0.4.18 (which doesn't seem to match their git tree
> and doesn't have a RELEASE file)?
Ah, I was looking in my dl directory, and it only had 0.4.16. Seems
like I haven't built something with Orc since a while :)
> > * Their README suggest a way of reducing the size of the library that
> > we are not using:
>
> > """
> > A: For embedded users, the --enable-backend configure option can
> > be used to disable irrelvant targets. Compiled with only one target
> > (SSE), the library size is about 150 kB uncompressed, or 48 kB
> > compressed. The goal was to keep the uncompressed size under
> > about 100 kB (but that failed!). A typical build with all targets
> > and the full ABI is around 350 kB.
> > """
>
> Ahh yes, that could be good to use.
Indeed.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-12 9:45 ` Thomas Petazzoni
@ 2014-02-12 9:52 ` Peter Korsgaard
2014-02-12 10:15 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Peter Korsgaard @ 2014-02-12 9:52 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> But orc is a JIT code generator, and from the source code it seems it
>> only handles ARM/PowerPC/x86.
> True. Odd that their configure script doesn't bail out after checking
> the target architecture.
> Things worth mentioning:
> * They have a newer 0.4.17 version that has MIPS support, as well as
> PowerPC64 support.
Ehh, we currently use 0.4.18 (which doesn't seem to match their git tree
and doesn't have a RELEASE file)?
> * Their README suggest a way of reducing the size of the library that
> we are not using:
> """
> A: For embedded users, the --enable-backend configure option can
> be used to disable irrelvant targets. Compiled with only one target
> (SSE), the library size is about 150 kB uncompressed, or 48 kB
> compressed. The goal was to keep the uncompressed size under
> about 100 kB (but that failed!). A typical build with all targets
> and the full ABI is around 350 kB.
> """
Ahh yes, that could be good to use.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-12 9:47 ` Thomas Petazzoni
@ 2014-02-12 9:50 ` Thomas De Schampheleire
2014-02-12 11:39 ` Thomas De Schampheleire
0 siblings, 1 reply; 416+ messages in thread
From: Thomas De Schampheleire @ 2014-02-12 9:50 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Wed, Feb 12, 2014 at 10:47 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
[..]
>>
>> Note that there is a related bug:
>> https://bugs.busybox.net/show_bug.cgi?id=5774
>> Not able to build ALSA-Utils for static build
>>
>> which does not yet have a patch it seems.
>
> Huh, it does have a patch!
>
I was too hasty. It does indeed have a patch, but I don't think it's a
good patch. It disables -ldl unconditionally, so this will (untested)
break alsa-lib on shared library builds, right?
>> I tried reproducing it but
>> couldn't, but then again, the bug report does not really provide a lot
>> of info about the configuration.
>
> You need to build for blackfin FLAT to reproduce the problem. Is this
> what you tested? Of course, if you try to reproduce the alsa-utils
> problem, you will first fall into the alsa-lib problem :)
Ok, thanks.
Best regards,
Thomas
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-12 9:41 ` Thomas De Schampheleire
@ 2014-02-12 9:47 ` Thomas Petazzoni
2014-02-12 9:50 ` Thomas De Schampheleire
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-12 9:47 UTC (permalink / raw)
To: buildroot
Dear Thomas De Schampheleire,
On Wed, 12 Feb 2014 10:41:52 +0100, Thomas De Schampheleire wrote:
> On Wed, Feb 12, 2014 at 9:32 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> [..]
> >
> >> bfin | alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/7069e1f43cbed745d65f7dd9904a3fff034530ac/
> >
> > Fixed by http://patchwork.ozlabs.org/patch/293833/. I'll try to give a
> > test to this patch today, and send my tested by.
>
> I'm assuming this will also fix bug #5768:
> https://bugs.busybox.net/show_bug.cgi?id=5768
> "Not able to build ALSA-Lib for static build"
Yes, it will fix this bug.
>
> Note that there is a related bug:
> https://bugs.busybox.net/show_bug.cgi?id=5774
> Not able to build ALSA-Utils for static build
>
> which does not yet have a patch it seems.
Huh, it does have a patch!
> I tried reproducing it but
> couldn't, but then again, the bug report does not really provide a lot
> of info about the configuration.
You need to build for blackfin FLAT to reproduce the problem. Is this
what you tested? Of course, if you try to reproduce the alsa-utils
problem, you will first fall into the alsa-lib problem :)
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-12 9:39 ` Peter Korsgaard
@ 2014-02-12 9:45 ` Thomas Petazzoni
2014-02-12 9:52 ` Peter Korsgaard
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-12 9:45 UTC (permalink / raw)
To: buildroot
Dear Peter Korsgaard,
On Wed, 12 Feb 2014 10:39:16 +0100, Peter Korsgaard wrote:
> > case "${host_os}" in
> > nobody_is_using_this_currently)
> > AC_DEFINE(HAVE_CODEMEM_MALLOC, 1, [Use malloc to allocate code for execution])
> > ;;
> > mingw*|pw32*|cygwin*)
> > AC_DEFINE(HAVE_CODEMEM_VIRTUALALLOC, 1, [Use VirtualAlloc to allocate code for execution])
> > ;;
> > linux*|darwin*|solaris*|netbsd*|freebsd*|openbsd*|kfreebsd*|dragonfly*|gnu*)
> > AC_DEFINE(HAVE_CODEMEM_MMAP, 1, [Use mmap to allocate code for execution])
> > ;;
> > *)
> > AC_ERROR([no code allocation backend])
> > ;;
> > esac
>
> > So when the host is uclinux (such as on !MMU platforms), nothing
> > matches. Which seems to match the fact that it needs a proper mmap() to
> > operate. So I believe it's really a "depends BR2_USE_MMU" that we need
> > here.
>
> But orc is a JIT code generator, and from the source code it seems it
> only handles ARM/PowerPC/x86.
True. Odd that their configure script doesn't bail out after checking
the target architecture.
Things worth mentioning:
* They have a newer 0.4.17 version that has MIPS support, as well as
PowerPC64 support.
* Their README suggest a way of reducing the size of the library that
we are not using:
"""
A: For embedded users, the --enable-backend configure option can
be used to disable irrelvant targets. Compiled with only one target
(SSE), the library size is about 150 kB uncompressed, or 48 kB
compressed. The goal was to keep the uncompressed size under
about 100 kB (but that failed!). A typical build with all targets
and the full ABI is around 350 kB.
"""
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-12 8:32 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-02-12 9:21 ` Peter Korsgaard
@ 2014-02-12 9:41 ` Thomas De Schampheleire
2014-02-12 9:47 ` Thomas Petazzoni
2014-02-12 11:25 ` Samuel Martin
2014-02-12 17:52 ` Yann E. MORIN
3 siblings, 1 reply; 416+ messages in thread
From: Thomas De Schampheleire @ 2014-02-12 9:41 UTC (permalink / raw)
To: buildroot
Hi,
On Wed, Feb 12, 2014 at 9:32 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
[..]
>
>> bfin | alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/7069e1f43cbed745d65f7dd9904a3fff034530ac/
>
> Fixed by http://patchwork.ozlabs.org/patch/293833/. I'll try to give a
> test to this patch today, and send my tested by.
>
I'm assuming this will also fix bug #5768:
https://bugs.busybox.net/show_bug.cgi?id=5768
"Not able to build ALSA-Lib for static build"
Note that there is a related bug:
https://bugs.busybox.net/show_bug.cgi?id=5774
Not able to build ALSA-Utils for static build
which does not yet have a patch it seems. I tried reproducing it but
couldn't, but then again, the bug report does not really provide a lot
of info about the configuration.
Best regards,
thomas
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-12 9:29 ` Thomas Petazzoni
@ 2014-02-12 9:39 ` Peter Korsgaard
2014-02-12 9:45 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Peter Korsgaard @ 2014-02-12 9:39 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> > Ah, yes. I have the beginning of a patch that bumps libv4l, which
>> > solves this problem. But it is not a straightforward bump since libv4l
>> > has changed quite a bit (more tools available, for example).
>>
>> Nice, care to send a patch? I had a quick look at updating it (and
>> probably renaming to v4l-utils) last week as I could use some of the new
>> features, but ran out of time.
> Yeah, just need a bit of time. Many patch sets in progress at the same
> time :)
Ok, no problem.
>> > What should we do in the mean time?
>>
>> If you say just mark it as !BR2_aarch64 for 2014.02.
Ehh, I naturally meant 'I would say' ;)
>> >> bfin | orc-0.4.18 | NOK | http://autobuild.buildroot.net/results/dd64c2aed5291b6c083f061709d6179150440a7e/
>>
>> > configure: error: no code allocation backend
>> > make: *** [/home/test/test/3/output/build/orc-0.4.18/.stamp_configured] Error 1
>>
>> Looks like it should be !BR2_bfin.
> Not sure if it's BR2_bfin or !MMU. What we have is:
> case "${host_os}" in
> nobody_is_using_this_currently)
> AC_DEFINE(HAVE_CODEMEM_MALLOC, 1, [Use malloc to allocate code for execution])
> ;;
> mingw*|pw32*|cygwin*)
> AC_DEFINE(HAVE_CODEMEM_VIRTUALALLOC, 1, [Use VirtualAlloc to allocate code for execution])
> ;;
> linux*|darwin*|solaris*|netbsd*|freebsd*|openbsd*|kfreebsd*|dragonfly*|gnu*)
> AC_DEFINE(HAVE_CODEMEM_MMAP, 1, [Use mmap to allocate code for execution])
> ;;
> *)
> AC_ERROR([no code allocation backend])
> ;;
> esac
> So when the host is uclinux (such as on !MMU platforms), nothing
> matches. Which seems to match the fact that it needs a proper mmap() to
> operate. So I believe it's really a "depends BR2_USE_MMU" that we need
> here.
But orc is a JIT code generator, and from the source code it seems it
only handles ARM/PowerPC/x86.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-12 9:21 ` Peter Korsgaard
@ 2014-02-12 9:29 ` Thomas Petazzoni
2014-02-12 9:39 ` Peter Korsgaard
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-12 9:29 UTC (permalink / raw)
To: buildroot
Dear Peter Korsgaard,
On Wed, 12 Feb 2014 10:21:55 +0100, Peter Korsgaard wrote:
> >> aarch64 | libv4l-0.8.9 | NOK | http://autobuild.buildroot.net/results/6635f7149cd0f5192d49276b2cc3edc5be3b5868/
>
> > Ah, yes. I have the beginning of a patch that bumps libv4l, which
> > solves this problem. But it is not a straightforward bump since libv4l
> > has changed quite a bit (more tools available, for example).
>
> Nice, care to send a patch? I had a quick look at updating it (and
> probably renaming to v4l-utils) last week as I could use some of the new
> features, but ran out of time.
Yeah, just need a bit of time. Many patch sets in progress at the same
time :)
> > What should we do in the mean time?
>
> If you say just mark it as !BR2_aarch64 for 2014.02.
Ok, will send a patch.
> >> bfin | orc-0.4.18 | NOK | http://autobuild.buildroot.net/results/dd64c2aed5291b6c083f061709d6179150440a7e/
>
> > configure: error: no code allocation backend
> > make: *** [/home/test/test/3/output/build/orc-0.4.18/.stamp_configured] Error 1
>
> Looks like it should be !BR2_bfin.
Not sure if it's BR2_bfin or !MMU. What we have is:
case "${host_os}" in
nobody_is_using_this_currently)
AC_DEFINE(HAVE_CODEMEM_MALLOC, 1, [Use malloc to allocate code for execution])
;;
mingw*|pw32*|cygwin*)
AC_DEFINE(HAVE_CODEMEM_VIRTUALALLOC, 1, [Use VirtualAlloc to allocate code for execution])
;;
linux*|darwin*|solaris*|netbsd*|freebsd*|openbsd*|kfreebsd*|dragonfly*|gnu*)
AC_DEFINE(HAVE_CODEMEM_MMAP, 1, [Use mmap to allocate code for execution])
;;
*)
AC_ERROR([no code allocation backend])
;;
esac
So when the host is uclinux (such as on !MMU platforms), nothing
matches. Which seems to match the fact that it needs a proper mmap() to
operate. So I believe it's really a "depends BR2_USE_MMU" that we need
here.
> >> x86_64 | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/23caf6deef3cbd8fd6b150e133d493d26d16d80b/
>
> > Same as yesterday:
>
> > /home/test/test/2/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/usr/include/boost/cstdint.hpp:314:42: error: typedef boost::ulong_long_type boost::uint64_t
> > src/thrift/transport/TSSLSocket.cpp:351:1: error: 'uint64_t' does not name a type
>
> Boost version compatibility issue?
Don't know :)
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-12 8:32 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2014-02-12 9:21 ` Peter Korsgaard
2014-02-12 9:29 ` Thomas Petazzoni
2014-02-12 9:41 ` Thomas De Schampheleire
` (2 subsequent siblings)
3 siblings, 1 reply; 416+ messages in thread
From: Peter Korsgaard @ 2014-02-12 9:21 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> bfin | boost-1.55.0 | NOK | http://autobuild.buildroot.net/results/17dd7946631354d59336259d5f31aa899e3599b8/
> Some part of boost needs fork(). But we probably shouldn't disable
> boost as a whole, only the specific modules that cannot work on !MMU
> systems.
> ./boost/test/impl/debug.ipp: In function 'bool
> boost::debug::attach_debugger(bool)': ./boost/test/impl/debug.ipp:868:
> error: 'fork' was not declared in this scope
Fixed.
>> aarch64 | libv4l-0.8.9 | NOK | http://autobuild.buildroot.net/results/6635f7149cd0f5192d49276b2cc3edc5be3b5868/
> Ah, yes. I have the beginning of a patch that bumps libv4l, which
> solves this problem. But it is not a straightforward bump since libv4l
> has changed quite a bit (more tools available, for example).
Nice, care to send a patch? I had a quick look at updating it (and
probably renaming to v4l-utils) last week as I could use some of the new
features, but ran out of time.
> What should we do in the mean time?
If you say just mark it as !BR2_aarch64 for 2014.02.
>> bfin | orc-0.4.18 | NOK | http://autobuild.buildroot.net/results/dd64c2aed5291b6c083f061709d6179150440a7e/
> configure: error: no code allocation backend
> make: *** [/home/test/test/3/output/build/orc-0.4.18/.stamp_configured] Error 1
Looks like it should be !BR2_bfin.
>> x86_64 | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/23caf6deef3cbd8fd6b150e133d493d26d16d80b/
> Same as yesterday:
> /home/test/test/2/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/usr/include/boost/cstdint.hpp:314:42: error: typedef boost::ulong_long_type boost::uint64_t
> src/thrift/transport/TSSLSocket.cpp:351:1: error: 'uint64_t' does not name a type
Boost version compatibility issue?
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-12 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-11 Thomas Petazzoni
@ 2014-02-12 8:32 ` Thomas Petazzoni
2014-02-12 9:21 ` Peter Korsgaard
` (3 more replies)
0 siblings, 4 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-12 8:32 UTC (permalink / raw)
To: buildroot
Hello,
As usual, analysis of yesterday build failures.
On Wed, 12 Feb 2014 08:30:07 +0100 (CET), Thomas Petazzoni wrote:
> avr32 | aiccu-20070115 | NOK | http://autobuild.buildroot.net/results/aeeaaf1f22d655eb918a492d430f5cce37b8a201/
../common/resolver.o: In function `getrrs':
resolver.c:(.text+0x46): undefined reference to `__dn_skipname'
collect2: ld returned 1 exit status
Might be something missing in uClibc 0.9.31 used by AVR32, so we would
have to disable this package on avr32 if that's the case.
> bfin | alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/7069e1f43cbed745d65f7dd9904a3fff034530ac/
Fixed by http://patchwork.ozlabs.org/patch/293833/. I'll try to give a
test to this patch today, and send my tested by.
> avr32 | audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/595a83e6f1df0f0c0294d31ccb3857206c0da47a/
/home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/avr32-buildroot-linux-uclibc/4.2.2/../../../../avr32-buildroot-linux-uclibc/bin/ld: attempted static link of dynamic object `/home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/avr32-buildroot-linux-uclibc/4.2.2/../../../../avr32-buildroot-linux-uclibc/lib/libstdc++.so'
collect2: ld returned 1 exit status
Probably the C++ static linking issue. Since -rc1 has been released, I
will rebuild all the Buildroot external toolchains.
> bfin | boost-1.55.0 | NOK | http://autobuild.buildroot.net/results/17dd7946631354d59336259d5f31aa899e3599b8/
Some part of boost needs fork(). But we probably shouldn't disable
boost as a whole, only the specific modules that cannot work on !MMU
systems.
./boost/test/impl/debug.ipp: In function 'bool
boost::debug::attach_debugger(bool)': ./boost/test/impl/debug.ipp:868:
error: 'fork' was not declared in this scope
> aarch64 | coreutils-8.21 | NOK | http://autobuild.buildroot.net/results/c57f89ffa732e2bfbb6ebf9af9de5bac3cbc197f/
Compiler problem:
CC src/groups.o
{standard input}: Assembler messages:
{standard input}:378: Error: operand 3 should be an integer register -- `adc x11,x10,0'
{standard input}:382: Error: operand 3 should be an integer register -- `adc x2,x11,0'
{standard input}:400: Error: operand 3 should be an integer register -- `adc x4,x2,0'
> bfin | czmq-b5730c5f8290a611fd3b92... | NOK | http://autobuild.buildroot.net/results/1ae0fee94f2161ce20ba6efdccf7fb90ddbfcb1b/
checking for zmq_init in -lzmq... no
configure: error: cannot link with -lzmq, install libzmq.
> microblaze | dropwatch-1.4 | NOK | http://autobuild.buildroot.net/results/0365f1e36a91f64e5c67eb1d4872ec57269ddd8f/
/home/test/test/3/output/host/usr/bin/microblaze-buildroot-linux-gnu-gcc -g -o dropwatch main.o lookup.o lookup_bfd.o lookup_kas.o -lbfd -liberty -lreadline -lnl-3 -lnl-genl-3 -lpthread -lncurses -lm
/home/test/test/3/output/host/usr/lib/gcc/microblaze-buildroot-linux-gnu/4.9.0/../../../../microblaze-buildroot-linux-gnu/bin/ld: cannot find -liberty
collect2: error: ld returned 1 exit status
> bfin | elfutils-0.155 | NOK | http://autobuild.buildroot.net/results/4c38d5c29d3c338e84c7c3720f89b0b81ab629ac/
{standard input}: Assembler messages:
{standard input}:4: Error: syntax error. Input text was _compat.elfutils_0.122.dwarf_bitsize.
{standard input}:4: Error:
make[4]: *** [dwarf_bitsize.os] Error 1
> powerpc | enlightenment-0.17.3 | NOK | http://autobuild.buildroot.net/results/314694709b3a2d812c18acc70e374b3bc2fbedbd/
CC enlightenment_start-e_start_main.o
e_start_main.c: In function 'main':
e_start_main.c:478:42: error: 'PT_GETSIGINFO' undeclared (first use in this function)
e_start_main.c:478:42: note: each undeclared identifier is reported only once for each function it appears in
make[5]: *** [enlightenment_start-e_start_main.o] Error 1
> bfin | imlib2-1.4.5 | NOK | http://autobuild.buildroot.net/results/567beac5f5d0c19620a6e770d2b9302bed481332/
checking whether to enable tiff support... yes
checking for TIFFReadScanline in -ltiff... no
checking for TIFFReadScanline in -ltiff... (cached) no
checking for TIFFReadScanline in -ltiff34... no
configure: error: TIFF support was requested but system does not support it
make: *** [/home/test/test/2/output/build/imlib2-1.4.5/.stamp_configured] Error 1
> arm | iozone-3_414 | NOK | http://autobuild.buildroot.net/results/2a33d2c7535a9d867d76dd5cf05e1bcc3f5cdc38/
iozone needs threads, fixed.
> bfin | libevas-1.7.7 | NOK | http://autobuild.buildroot.net/results/ad90baa5e07569308a7e2b2510b67c5b2a563b44/
uClibc configuration problem?
/home/test/test/2/output/host/usr/bfin-buildroot-uclinux-uclibc/sysroot/usr/lib/libeina.a(eina_file.o): In function `_eina_file_map_all':
eina_file.c:(.text+0x6aa): undefined reference to `_madvise'
/home/test/test/2/output/host/usr/bfin-buildroot-uclinux-uclibc/sysroot/usr/lib/libeina.a(eina_file.o): In function `_eina_file_map_new':
eina_file.c:(.text+0x7fc): undefined reference to `_madvise'
collect2: ld returned 1 exit status
> powerpc | libnftnl-1.0.0 | NOK | http://autobuild.buildroot.net/results/8be92ceb7e93332b218d3090b1b4fbf64e7af887/
> powerpc | libnftnl-1.0.0 | NOK | http://autobuild.buildroot.net/results/9a5c30cccf7b7e1c68a384fa5c49e4009d50400e/
In file included from common.c:10:0:
/home/test/test/3/output/host/usr/powerpc-buildroot-linux-gnu/sysroot/usr/include/linux/netlink.h:31:2: error: expected specifier-qualifier-list before 'sa_family_t'
> aarch64 | libv4l-0.8.9 | NOK | http://autobuild.buildroot.net/results/6635f7149cd0f5192d49276b2cc3edc5be3b5868/
Ah, yes. I have the beginning of a patch that bumps libv4l, which
solves this problem. But it is not a straightforward bump since libv4l
has changed quite a bit (more tools available, for example).
What should we do in the mean time?
> xtensa | lvm2-2.02.103 | NOK | http://autobuild.buildroot.net/results/2c6b9fdfffe81042d7606893d1ff006f9e6c4296/
/home/test/test/3/output/host/usr/lib/gcc/xtensa-buildroot-linux-uclibc/4.7.3/../../../../xtensa-buildroot-linux-uclibc/bin/ld: cannot find -ldevmapper
> xtensa | mplayer-1.1.1 | NOK | http://autobuild.buildroot.net/results/68bb764e5b34a2862537c3bd4b57ef5af529f0a3/
Compiler problem:
CC libavcodec/vp56.o
{standard input}: Assembler messages:
{standard input}:70614: Error: operand 1 of 'j' has out of range value '155096'
{standard input}:71047: Error: operand 1 of 'j' has out of range value '154068'
{standard input}:129895: Error: operand 1 of 'j' has out of range value '4294812257'
{standard input}:129905: Error: operand 1 of 'j' has out of range value '4294813285'
> arm | mplayer-1.1.1 | NOK | http://autobuild.buildroot.net/results/ed28908a93362d76fc720cf67f6c530eed8d855b/
ARM/floating point issue:
CC libavformat/avc.o
{standard input}: Assembler messages:
{standard input}:3921: Error: selected processor does not support ARM mode `vmov d0,r7,r8'
{standard input}:3923: Error: selected processor does not support ARM mode `vld1.32 {d2[],d3[]},[r2,:32]'
{standard input}:3924: Error: selected processor does not support ARM mode `vmov d1,r0,r1'
{standard input}:3925: Error: selected processor does not support ARM mode `vmul.f32 q0,q0,q1'
{standard input}:3926: Error: selected processor does not support ARM mode `vst1.32 {q0},[r3,:128]!'
> arm | ne10-88c18f02199947b2c8b577... | NOK | http://autobuild.buildroot.net/results/4d12fc71a775b0f81afeae1fa5317c0cb319185f/
ARM/neon issue
> bfin | orc-0.4.18 | NOK | http://autobuild.buildroot.net/results/dd64c2aed5291b6c083f061709d6179150440a7e/
configure: error: no code allocation backend
make: *** [/home/test/test/3/output/build/orc-0.4.18/.stamp_configured] Error 1
> arm | qtuio-abe4973ff60654aad9df7... | NOK | http://autobuild.buildroot.net/results/9b57f76672c8d0a74980cb1de32661761b666ce7/
/home/test/test/1/output/host/usr/bin/arm-unknown-linux-gnueabi-g++ -L/home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib -lGAL -lEGL -Wl,-O1 -o pinchzoom graphicsview.o main.o mouse.o moc_graphicsview.o moc_mouse.o qrc_mice.o -L/home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib -L../../lib -lqTUIO -lQtGui -L/home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot//usr/lib -ldirectfb -lfusion -L/home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib -ldirect -lEGL -lQtNetwork -lQtCore -lpthread
/home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.6.4/../../../../arm-unknown-linux-gnueabi/bin/ld: warning: libXdamage.so.1, needed by /home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGAL.so, not found (try using -rpath or -rpath-link)
/home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.6.4/../../../../arm-unknown-linux-gnueabi/bin/ld: warning: libXfixes.so.3, needed by /home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGAL.so, not found (try using -rpath or -rpath-link)
/home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.6.4/../../../../arm-unknown-linux-gnueabi/bin/ld: warning: libXext.so.6, needed by /home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGAL.so, not found (try using -rpath or -rpath-link)
/home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.6.4/../../../../arm-unknown-linux-gnueabi/bin/ld: warning: libX11.so.6, needed by /home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGAL.so, not found (try using -rpath or -rpath-link)
> x86_64 | sdl-1.2.15 | NOK | http://autobuild.buildroot.net/results/451521367a12cc4eda823526ec1e25580d4a2cc6/
Already fixed, by Maxime Hadjinlian.
> x86_64 | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/23caf6deef3cbd8fd6b150e133d493d26d16d80b/
Same as yesterday:
/home/test/test/2/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/usr/include/boost/cstdint.hpp:314:42: error: typedef boost::ulong_long_type boost::uint64_t
src/thrift/transport/TSSLSocket.cpp:351:1: error: 'uint64_t' does not name a type
> arm | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/656cddb6f22360808fbe39a9d112a06b87ad313a/
I will have a look into this.
> nios2 | unknown | TIM | http://autobuild.buildroot.net/results/fe79fe617e7bb8c7fabcbaefac883604bbb49d80/
Might be an issue in my autobuilder infra.
> i686 | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/39c77ffb5a5599d0b09422433c747b2bac185c4f/
CXX libopencv_example_plugin_la-opencv_example.lo
opencv_example.cpp:42:33: fatal error: opencv2/core/core_c.h: No such file or directory
> mips | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/05bc24c48da6ccd9cccb90689b7457b973278f9d/
/home/test/test/3/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-linux-gnu/4.7.3/../../../../mips-linux-gnu/bin/ld: ./.libs/libvlc_srtp.a(libvlc_srtp_la-srtp.o): relocation R_MIPS_26 against `div' can not be used when making a shared object; recompile with -fPIC
./.libs/libvlc_srtp.a(libvlc_srtp_la-srtp.o): could not read symbols: Bad value
> microblaze | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/67d14aaaf6b4c04225a457676c8ff7b125f6b692/
misc/objects.c: In function 'vlc_object_release':
misc/objects.c:531:1: internal compiler error: in merge_overlapping_regs, at regrename.c:295
}
We probably want to disable vlc on Microblaze for now, and add a
bugzilla entry to track this.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-12 8:05 ` Thomas Petazzoni
@ 2014-02-12 8:11 ` Baruch Siach
0 siblings, 0 replies; 416+ messages in thread
From: Baruch Siach @ 2014-02-12 8:11 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Wed, Feb 12, 2014 at 09:05:04AM +0100, Thomas Petazzoni wrote:
> On Tue, 11 Feb 2014 19:37:24 +0200, Baruch Siach wrote:
>
> > On Tue, Feb 11, 2014 at 10:10:15AM +0100, Thomas Petazzoni wrote:
> > > > xtensa | coreutils-8.21 | NOK | http://autobuild.buildroot.net/results/246b3778a1a646afd1c8b9c17b4579fb5a27120e/
> > >
> > > lib/spawn_faction_adddup2.c: In function 'posix_spawn_file_actions_adddup2':
> > > lib/spawn_faction_adddup2.c:50:19: error: 'posix_spawn_file_actions_t' has no member named '_used'
> > > lib/spawn_faction_adddup2.c:50:42: error: 'posix_spawn_file_actions_t' has no member named '_allocated'
> > >
> > > uClibc problem?
> >
> > Yes and no. uClibc (snapshot only) implements POSIX spawn, but unlike glibc,
> > requires -lrt. coreutils configure script (actually gnulib) fails to detect
> > the -lrt dependency. The next coreutils version (2.23) fixes avoids the
> > problem by not using this gnulib module. I tried applying this fix, but it
> > triggers a reconf and a fresh gnulib download from git, followed by a
> > different build failure. Instead I added a patch fixing gnulib -lrt dependency
> > detection.
>
> Ok, thanks!
>
> However, you mention the next coreutils version as being 2.23, but the
> latest version available today is 8.21. Aren't you confusing util-linux
> version numbers with coreutils version numbers here? Or did I miss
> something?
Yes, you're right. The next coreutils version is 8.23. The latest version as
of today is 8.22, though, released on December, 13. I did the same mistake in
the patch description. I'll send a fix for that shortly.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-11 18:01 ` Yann E. MORIN
@ 2014-02-12 8:06 ` Thomas Petazzoni
2014-02-12 20:58 ` Romain Naour
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-12 8:06 UTC (permalink / raw)
To: buildroot
Dear Yann E. MORIN,
On Tue, 11 Feb 2014 19:01:23 +0100, Yann E. MORIN wrote:
> On 2014-02-11 10:10 +0100, Thomas Petazzoni spake thusly:
> > On Tue, 11 Feb 2014 08:30:08 +0100 (CET), Thomas Petazzoni wrote:
> [--SNIP--]
> > > avr32 | elfutils-0.155 | NOK | http://autobuild.buildroot.net/results/7bf7f9c786a3199e29d0dc38c4878cb6bf9c26dc/
> >
> > ../libdwfl/libdwfl_pic.a(find-debuginfo.os): In function `find_debuginfo_in_path':
> > find-debuginfo.c:(.text+0x3e6): undefined reference to `canonicalize_file_name'
> > ../libdwfl/libdwfl_pic.a(dwfl_build_id_find_elf.os): In function `__libdwfl_open_by_build_id':
> > dwfl_build_id_find_elf.c:(.text+0x1a8): undefined reference to `canonicalize_file_name'
>
> I already looked at that one: the toolchain is using uClibc 0.9.31, and
> canonicalize_file_name is missing in that version (it only appeared in
> 0.9.32, IIRC).
So we need:
# canonicalize_file_name() not available on uClibc 0.9.31, used
# only for AVR32
depends on !BR2_avr32
> > > arm | nut-2.6.5 | NOK | http://autobuild.buildroot.net/results/0ddd856bcbec2db0500791fd428ba053d6e4fa1b/
> >
> > libusb compatibility issue?
> >
> > scan_usb.c:34:29: error: unknown type name 'usb_dev_handle'
> > scan_usb.c:38:41: error: unknown type name 'usb_dev_handle'
> > scan_usb.c:41:1: error: unknown type name 'usb_dev_handle'
> > scan_usb.c:41:48: warning: 'struct usb_device' declared inside parameter list [enabled by default]
> > scan_usb.c:41:48: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
> > scan_usb.c: In function 'nutscan_load_usb_library':
> > scan_usb.c:67:22: error: 'nut_usb_close' undeclared (first use in this function)
>
> I tried to reproduce it here, but it builds fine (in a squeeze-32
> chroot, with almost nothing installed except the Buildroot
> dependencies).
Error occurred on gcc10, where tests are not running in a clean chroot,
but in an environment with lots of headers/libraries installed. I'll do
a test build on gcc10, to see what host stuff causes this mis-detection.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-11 17:37 ` Baruch Siach
@ 2014-02-12 8:05 ` Thomas Petazzoni
2014-02-12 8:11 ` Baruch Siach
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-12 8:05 UTC (permalink / raw)
To: buildroot
Dear Baruch Siach,
On Tue, 11 Feb 2014 19:37:24 +0200, Baruch Siach wrote:
> On Tue, Feb 11, 2014 at 10:10:15AM +0100, Thomas Petazzoni wrote:
> > > xtensa | coreutils-8.21 | NOK | http://autobuild.buildroot.net/results/246b3778a1a646afd1c8b9c17b4579fb5a27120e/
> >
> > lib/spawn_faction_adddup2.c: In function 'posix_spawn_file_actions_adddup2':
> > lib/spawn_faction_adddup2.c:50:19: error: 'posix_spawn_file_actions_t' has no member named '_used'
> > lib/spawn_faction_adddup2.c:50:42: error: 'posix_spawn_file_actions_t' has no member named '_allocated'
> >
> > uClibc problem?
>
> Yes and no. uClibc (snapshot only) implements POSIX spawn, but unlike glibc,
> requires -lrt. coreutils configure script (actually gnulib) fails to detect
> the -lrt dependency. The next coreutils version (2.23) fixes avoids the
> problem by not using this gnulib module. I tried applying this fix, but it
> triggers a reconf and a fresh gnulib download from git, followed by a
> different build failure. Instead I added a patch fixing gnulib -lrt dependency
> detection.
Ok, thanks!
However, you mention the next coreutils version as being 2.23, but the
latest version available today is 8.21. Aren't you confusing util-linux
version numbers with coreutils version numbers here? Or did I miss
something?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-11 9:10 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-02-11 17:37 ` Baruch Siach
@ 2014-02-11 18:01 ` Yann E. MORIN
2014-02-12 8:06 ` Thomas Petazzoni
1 sibling, 1 reply; 416+ messages in thread
From: Yann E. MORIN @ 2014-02-11 18:01 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2014-02-11 10:10 +0100, Thomas Petazzoni spake thusly:
> On Tue, 11 Feb 2014 08:30:08 +0100 (CET), Thomas Petazzoni wrote:
[--SNIP--]
> > avr32 | elfutils-0.155 | NOK | http://autobuild.buildroot.net/results/7bf7f9c786a3199e29d0dc38c4878cb6bf9c26dc/
>
> ../libdwfl/libdwfl_pic.a(find-debuginfo.os): In function `find_debuginfo_in_path':
> find-debuginfo.c:(.text+0x3e6): undefined reference to `canonicalize_file_name'
> ../libdwfl/libdwfl_pic.a(dwfl_build_id_find_elf.os): In function `__libdwfl_open_by_build_id':
> dwfl_build_id_find_elf.c:(.text+0x1a8): undefined reference to `canonicalize_file_name'
I already looked at that one: the toolchain is using uClibc 0.9.31, and
canonicalize_file_name is missing in that version (it only appeared in
0.9.32, IIRC).
> > arm | nut-2.6.5 | NOK | http://autobuild.buildroot.net/results/0ddd856bcbec2db0500791fd428ba053d6e4fa1b/
>
> libusb compatibility issue?
>
> scan_usb.c:34:29: error: unknown type name 'usb_dev_handle'
> scan_usb.c:38:41: error: unknown type name 'usb_dev_handle'
> scan_usb.c:41:1: error: unknown type name 'usb_dev_handle'
> scan_usb.c:41:48: warning: 'struct usb_device' declared inside parameter list [enabled by default]
> scan_usb.c:41:48: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
> scan_usb.c: In function 'nutscan_load_usb_library':
> scan_usb.c:67:22: error: 'nut_usb_close' undeclared (first use in this function)
I tried to reproduce it here, but it builds fine (in a squeeze-32
chroot, with almost nothing installed except the Buildroot
dependencies).
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] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-11 9:10 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2014-02-11 17:37 ` Baruch Siach
2014-02-12 8:05 ` Thomas Petazzoni
2014-02-11 18:01 ` Yann E. MORIN
1 sibling, 1 reply; 416+ messages in thread
From: Baruch Siach @ 2014-02-11 17:37 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Tue, Feb 11, 2014 at 10:10:15AM +0100, Thomas Petazzoni wrote:
> > xtensa | coreutils-8.21 | NOK | http://autobuild.buildroot.net/results/246b3778a1a646afd1c8b9c17b4579fb5a27120e/
>
> lib/spawn_faction_adddup2.c: In function 'posix_spawn_file_actions_adddup2':
> lib/spawn_faction_adddup2.c:50:19: error: 'posix_spawn_file_actions_t' has no member named '_used'
> lib/spawn_faction_adddup2.c:50:42: error: 'posix_spawn_file_actions_t' has no member named '_allocated'
>
> uClibc problem?
Yes and no. uClibc (snapshot only) implements POSIX spawn, but unlike glibc,
requires -lrt. coreutils configure script (actually gnulib) fails to detect
the -lrt dependency. The next coreutils version (2.23) fixes avoids the
problem by not using this gnulib module. I tried applying this fix, but it
triggers a reconf and a fresh gnulib download from git, followed by a
different build failure. Instead I added a patch fixing gnulib -lrt dependency
detection.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-11 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-10 Thomas Petazzoni
@ 2014-02-11 9:10 ` Thomas Petazzoni
2014-02-11 17:37 ` Baruch Siach
2014-02-11 18:01 ` Yann E. MORIN
0 siblings, 2 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-11 9:10 UTC (permalink / raw)
To: buildroot
Hello,
On Tue, 11 Feb 2014 08:30:08 +0100 (CET), Thomas Petazzoni wrote:
> Build statistics for 2014-02-10
> ===============================
>
> success : 72
> failures : 22
Wow, only 22 failures yesterday, and amongst them we have 7 failures
that are not Buildroot's fault. So it's really 15 failures. Let's look
at them.
> mips | ^[[8G^[(0^[[0m^[[30m^[[47m^[(0^[[0... | NOK | http://autobuild.buildroot.net/results/f3fd767dccd8c993ec68d75c7be8a16ada5d2f08/
Ignore. Probably caused by me killing the autobuilder jobs to get them
restarted after the BUILDROOT_DL_DIR -> BR2_DL_DIR issue.
> xtensa | audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/8717968dfeeedf429cd188fa53d6c90bce621490/
C++ static linking problem, but not caused by a broken external
toolchain, since I only use the internal toolchain backend for xtensa.
> xtensa | coreutils-8.21 | NOK | http://autobuild.buildroot.net/results/246b3778a1a646afd1c8b9c17b4579fb5a27120e/
lib/spawn_faction_adddup2.c: In function 'posix_spawn_file_actions_adddup2':
lib/spawn_faction_adddup2.c:50:19: error: 'posix_spawn_file_actions_t' has no member named '_used'
lib/spawn_faction_adddup2.c:50:42: error: 'posix_spawn_file_actions_t' has no member named '_allocated'
uClibc problem?
> avr32 | elfutils-0.155 | NOK | http://autobuild.buildroot.net/results/7bf7f9c786a3199e29d0dc38c4878cb6bf9c26dc/
../libdwfl/libdwfl_pic.a(find-debuginfo.os): In function `find_debuginfo_in_path':
find-debuginfo.c:(.text+0x3e6): undefined reference to `canonicalize_file_name'
../libdwfl/libdwfl_pic.a(dwfl_build_id_find_elf.os): In function `__libdwfl_open_by_build_id':
dwfl_build_id_find_elf.c:(.text+0x1a8): undefined reference to `canonicalize_file_name'
> xtensa | gd-2.0.35 | NOK | http://autobuild.buildroot.net/results/ce20e355db99303365bc6b4cfab92c3c4329b2fd/
Static linking problem with pthread?
./.libs/libgd.a(gdft.o):(.literal+0x6c): undefined reference to `pthread_mutex_lock'
./.libs/libgd.a(gdft.o):(.literal+0x74): undefined reference to `pthread_mutex_unlock'
./.libs/libgd.a(gdft.o):(.literal+0x78): undefined reference to `pthread_mutex_destroy'
./.libs/libgd.a(gdft.o):(.literal+0x88): undefined reference to `pthread_mutex_init'
> x86_64 | gst-ffmpeg-0.10.13 | NOK | http://autobuild.buildroot.net/results/acfb07943b417461b1d1efd96f796293d7c95300/
Not sure.
*** Warning: Linking the shared library libgstffmpeg.la against the
*** static library ../../gst-libs/ext/libav/libavutil/libavutil.a is not portable!
/home/test/test/3/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-unknown-linux-uclibc/4.6.3/../../../../x86_64-unknown-linux-uclibc/bin/ld: ../../gst-libs/ext/libav/libavcodec/libavcodec.a(lpc_mmx.o): relocation R_X86_64_PC32 against symbol `ff_pd_1' can not be used when making a shared object; recompile with -fPIC
/home/test/test/3/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-unknown-linux-uclibc/4.6.3/../../../../x86_64-unknown-linux-uclibc/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make[4]: *** [libgstffmpeg.la] Error 1
> bfin | icu-51.2 | NOK | http://autobuild.buildroot.net/results/7f7ce4711cfb3659a1b5deecf6705a90713b864e/
*** ERROR - configure could not detect your platform
*** see the readme.html
*** or, try copying icu/source/config/mh-linux to mh-unknown
*** and editing it.
Some Blackfin person should look into this.
> arm | libevas-1.7.7 | NOK | http://autobuild.buildroot.net/results/d15f4a5e92ef3e0e868cbcfcef6b8e4440eae306/
Evas/OpenGL/GLX issue:
evas_x_main.c: In function 'eng_window_new':
evas_x_main.c:306:14: warning: implicit declaration of function 'glXMakeContextCurrent' [-Wimplicit-function-declaration]
evas_x_main.c: In function 'eng_window_free':
evas_x_main.c:477:4: warning: implicit declaration of function 'glXDestroyWindow' [-Wimplicit-function-declaration]
evas_x_main.c: In function 'eng_best_visual_get':
evas_x_main.c:698:34: error: 'GLX_DRAWABLE_TYPE' undeclared (first use in this function)
evas_x_main.c:698:34: note: each undeclared identifier is reported only once for each function it appears in
evas_x_main.c:699:34: error: 'GLX_WINDOW_BIT' undeclared (first use in this function)
evas_x_main.c:710:39: error: 'GLX_RENDER_TYPE' undeclared (first use in this function)
evas_x_main.c:711:39: error: 'GLX_RGBA_BIT' undeclared (first use in this function)
evas_x_main.c:728:34: error: 'GLX_TRANSPARENT_TYPE' undeclared (first use in this function)
evas_x_main.c:729:34: error: 'GLX_NONE' undeclared (first use in this function)
evas_x_main.c:732:14: warning: implicit declaration of function 'glXChooseFBConfig' [-Wimplicit-function-declaration]
evas_x_main.c:732:22: warning: assignment makes pointer from integer without a cast [enabled by default]
evas_x_main.c:745:19: warning: implicit declaration of function 'glXGetVisualFromFBConfig' [-Wimplicit-function-declaration]
evas_x_main.c:745:27: warning: assignment makes pointer from integer without a cast [enabled by default]
> mips | Makefile.legacy:12: *** "Yo... | NOK | http://autobuild.buildroot.net/results/0a5362e6687c2c62ecd36b118bde0b512a2b39c1/
> mips | Makefile.legacy:12: *** "Yo... | NOK | http://autobuild.buildroot.net/results/768f6bd5f5adb0d8d1da9387d6551b58384cd36e/
> powerpc | Makefile.legacy:12: *** "Yo... | NOK | http://autobuild.buildroot.net/results/d990d5d0c941c13a54df60267d841e301cba6dd0/
> powerpc | Makefile.legacy:12: *** "Yo... | NOK | http://autobuild.buildroot.net/results/980eb9a3d98fa8c64fadf890f01f0dfb332a1fc8/
> x86_64 | Makefile.legacy:12: *** "Yo... | NOK | http://autobuild.buildroot.net/results/cfd41ff7265d088026b1cbc85733fb992c0e593e/
> x86_64 | Makefile.legacy:12: *** "Yo... | NOK | http://autobuild.buildroot.net/results/e3bcc49fa603d985465d01877eaf7744f14213dd/
Not sure how this is possible, I believe those are just left-overs from
the BUILDROOT_DL_DIR -> BR2_DL_DIR migration, and the build jobs I killed.
> arm | minidlna-1.1.1 | NOK | http://autobuild.buildroot.net/results/5510343f964a637f722e4275a4e55034c332b1c3/
The tool to generate .po files was not here?
rm -f da.gmo && : -c --statistics --verbose -o da.gmo da.po
rm -f es.gmo && : -c --statistics --verbose -o es.gmo es.po
rm -f fr.gmo && : -c --statistics --verbose -o fr.gmo fr.po
rm -f de.gmo && : -c --statistics --verbose -o de.gmo de.po
mv: mv: mv: mv: cannot stat `t-fr.gmo'cannot stat `t-da.gmo'cannot stat `t-de.gmo'cannot stat `t-es.gmo': No such file or directory
: No such file or directory
: No such file or directory: No such file or directory
> powerpc | mmc-utils-11f2ceabc4ad3f0dd... | NOK | http://autobuild.buildroot.net/results/75bbfa4a5a1139957cde03c39179f1389813784b/
Kernel headers problem:
In file included from mmc_cmds.c:30:0:
mmc.h:18:29: fatal error: linux/mmc/ioctl.h: No such file or directory
compilation terminated.
> arm | nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/e4066efae55f84e9270ae7139760de2ab32ca967/
C++/static problem, external Buildroot toolchain. Will be fixed once I
rebuild the toolchain (Peter, please release -rc1 !).
> arm | nut-2.6.5 | NOK | http://autobuild.buildroot.net/results/0ddd856bcbec2db0500791fd428ba053d6e4fa1b/
libusb compatibility issue?
scan_usb.c:34:29: error: unknown type name 'usb_dev_handle'
scan_usb.c:38:41: error: unknown type name 'usb_dev_handle'
scan_usb.c:41:1: error: unknown type name 'usb_dev_handle'
scan_usb.c:41:48: warning: 'struct usb_device' declared inside parameter list [enabled by default]
scan_usb.c:41:48: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
scan_usb.c: In function 'nutscan_load_usb_library':
scan_usb.c:67:22: error: 'nut_usb_close' undeclared (first use in this function)
> bfin | rpcbind-0.2.0 | NOK | http://autobuild.buildroot.net/results/d7c788749b54275154cc3934a7a32385cd72be61/
rpcbind needs MMU, I've sent a patch to disallow rpcbind on !MMU
platforms.
> powerpc | systemd-44 | NOK | http://autobuild.buildroot.net/results/cb22f21cae34e40eea4704029706fe6688550384/
I will try to send a patch for this one.
> x86_64 | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/95b0f70e36a0063601d5c8d719f749902bac7ef3/
In file included from /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-buildroot-linux-uclibc/4.7.3/include/stdint.h:3:0,
from /home/test/test/2/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/usr/include/netinet/in.h:24,
from /home/test/test/2/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/usr/include/arpa/inet.h:23,
from src/thrift/transport/TSSLSocket.cpp:25:
/home/test/test/2/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/usr/include/stdint.h:58:27: error: candidates are: typedef long unsigned int uint64_t
In file included from /home/test/test/2/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/usr/include/boost/numeric/conversion/numeric_cast_traits.hpp:27:0,
from /home/test/test/2/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/usr/include/boost/numeric/conversion/cast.hpp:34,
from /home/test/test/2/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/usr/include/boost/lexical_cast.hpp:159,
from src/thrift/transport/TSSLSocket.cpp:31:
/home/test/test/2/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/usr/include/boost/cstdint.hpp:314:42: error: typedef boost::ulong_long_type boost::uint64_t
src/thrift/transport/TSSLSocket.cpp:351:1: error: 'uint64_t' does not name a type
> x86_64 | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/b0d3c997d6ae8bbdb606c0a24bac9287dd17ce69/
Not sure what happened here. Maybe a spurious failure caused by me
killing build jobs.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-07 13:25 ` Gustavo Zacarias
2014-02-07 19:18 ` Arnout Vandecappelle
@ 2014-02-08 21:43 ` Peter Korsgaard
1 sibling, 0 replies; 416+ messages in thread
From: Peter Korsgaard @ 2014-02-08 21:43 UTC (permalink / raw)
To: buildroot
>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:
Hi,
>> Missing setns() on CodeSourcery toolchain. Since util-linux is really
>> needed for many packages, it would be good to find a fix that doesn't
>> involve disabling util-linux completely.
>>
>> checking for syscall setns... no
>> configure: WARNING: Unable to detect syscall setns.
>> configure: error: nsenter selected but setns syscall not found
>> make: *** [/home/test/test/3/output/build/util-linux-2.23.2/.stamp_configured] Error 1
>>
>> Gustavo, an idea?
> Yes, blame commit 9f91d79601da42516752318beecfd080dc05aac9
> Before it was an option util-linux decided if it was appropiate to build
> it according to setns() being available, now we may be forcing it when
> the syscall may simply be unavailable (like this toolchain).
> We can do a ton of toolchain kludges or just revert, i'd prefer the
> second option since it's not like a super-common command (actually most
> distros don't have it yet because it's pretty new for util-linux).
> Regards.
Hmm, looking closer at the issue I think I agree. Without the explicit
option nsenter automatically gets built if possible. Nsenter is very
small compared to the rest of util-linux (~20KB), and people can always
remove it in a post-build script if they really care.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-07 19:03 ` Spenser Gilliland
@ 2014-02-08 11:40 ` Romain Naour
0 siblings, 0 replies; 416+ messages in thread
From: Romain Naour @ 2014-02-08 11:40 UTC (permalink / raw)
To: buildroot
Hi Spenser, all
>>> microblaze | gpm-1.20.7 | NOK | http://autobuild.buildroot.net/results/5915af9e00fc29e48764778916ea6f806d6dceb8/
>> Not sure what's going on:
>>
>> /home/test/test/3/output/host/usr/bin/microblaze-buildroot-linux-gnu-gcc libgpm.so.2 \
>> -L/home/test/test/3/output/build/gpm-1.20.7/src -o lib/libgpm.so.2.1.0 lib/liblow.lo lib/libhigh.lo lib/libxtra.lo lib/report-lib.lo tools.lo -lc
>> microblaze-buildroot-linux-gnu-gcc: error: libgpm.so.2: No such file or directory
> Me neither. I'll try replicating it then take a look.
>
>
It seems to related to the toolchain where __ELF__ is not defined.
checking whether system is ELF... no
Then shared lib libgpm.so.2 is not build but still used in Makefile's
target all...
I'm not sure about the right solution here but force the ELF format in
gpm.mk fixe the build.
GPM_CONF_OPT += itz_cv_sys_elf=yes
Best regards,
Romain Naour
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-07 13:25 ` Gustavo Zacarias
@ 2014-02-07 19:18 ` Arnout Vandecappelle
2014-02-08 21:43 ` Peter Korsgaard
1 sibling, 0 replies; 416+ messages in thread
From: Arnout Vandecappelle @ 2014-02-07 19:18 UTC (permalink / raw)
To: buildroot
On 07/02/14 14:25, Gustavo Zacarias wrote:
[snip]
>>> >> powerpc | util-linux-2.23.2 | NOK | http://autobuild.buildroot.net/results/399e62acf2c452653cb2ee9ca150a0cfe7e33326/
>> >
>> > Missing setns() on CodeSourcery toolchain. Since util-linux is really
>> > needed for many packages, it would be good to find a fix that doesn't
>> > involve disabling util-linux completely.
>> >
>> > checking for syscall setns... no
>> > configure: WARNING: Unable to detect syscall setns.
>> > configure: error: nsenter selected but setns syscall not found
>> > make: *** [/home/test/test/3/output/build/util-linux-2.23.2/.stamp_configured] Error 1
>> >
>> > Gustavo, an idea?
> Yes, blame commit 9f91d79601da42516752318beecfd080dc05aac9
> Before it was an option util-linux decided if it was appropiate to build
> it according to setns() being available, now we may be forcing it when
> the syscall may simply be unavailable (like this toolchain).
> We can do a ton of toolchain kludges or just revert, i'd prefer the
> second option since it's not like a super-common command (actually most
> distros don't have it yet because it's pretty new for util-linux).
Then instead, mark it as BROKEN with an explanatory comment, so it is
still lying around in case someone needs it.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-07 12:53 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (4 preceding siblings ...)
2014-02-07 18:53 ` Yann E. MORIN
@ 2014-02-07 19:03 ` Spenser Gilliland
2014-02-08 11:40 ` Romain Naour
2014-02-17 15:40 ` Vicente Olivert Riera
6 siblings, 1 reply; 416+ messages in thread
From: Spenser Gilliland @ 2014-02-07 19:03 UTC (permalink / raw)
To: buildroot
Thomas,
On Fri, Feb 7, 2014 at 6:53 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello all,
>
> You'll find below a quick analysis of the build failures. If you are in
> Cc, it means that there is a question for you below, or a request to
> help debugging a specific problem. Thanks!
>
> On Fri, 7 Feb 2014 08:30:09 +0100 (CET), Thomas Petazzoni wrote:
>
>> Detail of failures
>> ===================
>>
>> bfin | alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/b25590e19d0e638dcbb2855a84e82ea7b2703460/
>
> There is a patch pending that fixes this issue:
> http://patchwork.ozlabs.org/patch/293833/. Maybe we should merge it?
>
>> mipsel | alsa-utils-1.0.26 | NOK | http://autobuild.buildroot.net/results/05d3186bcb74c905bbc689859522b88db78c2f68/
>
> /home/test/test/3/output/host/opt/ext-toolchain/bin/../lib/gcc/mipsel-buildroot-linux-uclibc/4.7.3/../../../../mipsel-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.21 assertion fail elfxx-mips.c:3416
> /home/test/test/3/output/host/usr/mipsel-buildroot-linux-uclibc/sysroot/usr/lib/libasound.a(rawmidi_symbols.o):(.data.rel+0x4): undefined reference to `_snd_module_rawmidi_virt'
>
> Looks like a MIPS toolchain problem, maybe? The toolchain used is a
> Buildroot toolchain built with Buildroot 2013.11. If the problem no
> longer occurs with the internal toolchain backend, then it will be
> fixed once I rebuild the external Buildroot toolchains of the Buildroot
> (when -rc1 is released). Vicente, can you test if this works with the
> internal toolchain?
>
>> bfin | cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/1f79be918cebc29c306db6444908b20c6ada5683/
>> bfin | cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/91310c4da3541b9b8b447f0876d1deff2fadc19c/
>
> Unknown problem while building cairo tests:
>
> cairo-test-runner.c: In function 'is_running_under_debugger':
> cairo-test-runner.c:168: error: implicit declaration of function 'getppid'
> cairo-test-runner.c:168: warning: nested extern declaration of 'getppid'
> cairo-test-runner.c:169: error: implicit declaration of function 'readlink'
> cairo-test-runner.c:169: warning: nested extern declaration of 'readlink'
> make[5]: *** [cairo_test_suite-cairo-test-runner.o] Error 1
>
> Maybe disabling the cairo tests is sufficient.
>
>> arc | dmraid-1.0.0.rc15 | NOK | http://autobuild.buildroot.net/results/ef6a0e2d382ae202bb8f0e9fc9f5e48c90119faf/
>
> Internal compiler error. Ryan has sent a patch to disable the dmraid
> build on ARC for now, but it would be good if the ARC team could have a
> look at this. Cc'ing Anton.
>
>> bfin | e2fsprogs-1.42.9 | NOK | http://autobuild.buildroot.net/results/284f2a161d110d4c561cf89c052ce531b4edc173/
>
> Not sure what's going on:
>
> checking for blkid_get_cache in -lblkid... no
> configure: error: external blkid library not found
> make: *** [/home/test/test/1/output/build/e2fsprogs-1.42.9/.stamp_configured] Error 1
>
>> avr32 | elfutils-0.155 | NOK | http://autobuild.buildroot.net/results/7bb5b317dd35d8b3dd2fc9a777a5d65bd143348c/
>
> ../libdwfl/libdwfl_pic.a(find-debuginfo.os): In function `find_debuginfo_in_path':
> find-debuginfo.c:(.text+0x3e6): undefined reference to `canonicalize_file_name'
> ../libdwfl/libdwfl_pic.a(dwfl_build_id_find_elf.os): In function `__libdwfl_open_by_build_id':
> dwfl_build_id_find_elf.c:(.text+0x1a8): undefined reference to `canonicalize_file_name'
> collect2: ld returned 1 exit status
>
> Might be due to a too old uClibc on AVR32 ?
>
>> microblaze | gdb-7.5.1 | NOK | http://autobuild.buildroot.net/results/1996d259baffdfed52a56b93c67904df97fe5c53/
>
> Download error. Spenser, can you have a look?
I'm aware of the problem. I'm working with the maintainer to try to
create some git tags, so that the gc doesn't remove our commits. (the
way he creates the tags is kinda odd and is why theissue is created.)
>> microblaze | gpm-1.20.7 | NOK | http://autobuild.buildroot.net/results/5915af9e00fc29e48764778916ea6f806d6dceb8/
>
> Not sure what's going on:
>
> /home/test/test/3/output/host/usr/bin/microblaze-buildroot-linux-gnu-gcc libgpm.so.2 \
> -L/home/test/test/3/output/build/gpm-1.20.7/src -o lib/libgpm.so.2.1.0 lib/liblow.lo lib/libhigh.lo lib/libxtra.lo lib/report-lib.lo tools.lo -lc
> microblaze-buildroot-linux-gnu-gcc: error: libgpm.so.2: No such file or directory
Me neither. I'll try replicating it then take a look.
>> microblaze | gpsd-b4c32aa40cff1b4e1041d5... | NOK | http://autobuild.buildroot.net/results/42da870722f24e4202d8265597771a0449e74cfd/
>
> Internal compiler error. Ryan has sent a patch to disable the gpsd
> build on Microblaze for now, but it would be good to report the problem
> to Xilinx, or bump the toolchain component versions as needed.
I'll resubmit the patches which move us to a tagged version of the
microblaze compiler. Maybe it's fixed there.
>> bfin | libeet-1.7.7 | NOK | http://autobuild.buildroot.net/results/3eaa07dc462b5ffa34ccf527dc921d3ad5a2c4f8/
>
> uClibc lacks _madvise ?
>
> CCLD eet
> /home/test/test/3/output/host/usr/bfin-buildroot-linux-uclibc/sysroot/usr/lib/libeina.so: undefined reference to `_madvise'
> collect2: ld returned 1 exit status
>
>> arm | libevas-1.7.7 | NOK | http://autobuild.buildroot.net/results/ca25323567324fb9082e3c0f318ea8b961fad3d8/
>
> Don't know:
>
> CC evas_cache2.lo
> evas_cache2.c: In function '_evas_cache_image_entry_delete':
> evas_cache2.c:176:17: error: 'Image_Entry_Flags' has no member named 'delete_me'
> evas_cache2.c:181:18: error: 'Image_Entry_Flags' has no member named 'delete_me'
> evas_cache2.c: In function '_evas_cache2_image_preloaded_cb':
> evas_cache2.c:296:13: error: 'Image_Entry_Flags' has no member named 'preload_done'
> evas_cache2.c:303:23: error: 'Image_Entry_Flags' has no member named 'delete_me'
> evas_cache2.c:308:17: error: 'Image_Entry_Flags' has no member named 'delete_me'
> evas_cache2.c: In function '_evas_cache2_image_entry_preload_add':
> evas_cache2.c:317:17: error: 'Image_Entry_Flags' has no member named 'preload_done'
> make[5]: *** [evas_cache2.lo] Error 1
>
>> arc | libpfm4-4.3.0 | NOK | http://autobuild.buildroot.net/results/59cefaba9d382f0de17b5dccb2d88fc74d36f520/
>
> task.c: In function 'read_groups':
> task.c:110:5: error: format '%zd' expects argument of type 'signed size_t', but argument 4 has type 'ssize_t' [-Werror=format=]
> evt, new_sz, ret);
> ^
> cc1: all warnings being treated as errors
> make[2]: *** [task.o] Error 1
>
> -> We should build this package without treating warning as error.
>
>> nios2 | ltp-testsuite-20130904 | NOK | http://autobuild.buildroot.net/results/9aca518bf53aea62bc4bb437976f0223113c26ce/
>
> Would be good to see if the bump of ltp-testsuite proposed by Vicente
> fixes this problem. Peter, can you apply
> http://patchwork.ozlabs.org/patch/317112/ ?
>
>> nios2 | lxc-0.9.0 | NOK | http://autobuild.buildroot.net/results/f592a011321429426be81bd1ecf664ad9a2c0161/
>
> Duplicate declaration of setns() :
>
> attach.c:54:12: error: static declaration of 'setns' follows non-static declaration
> In file included from /home/test/test/1/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/sched.h:42:0,
> from namespace.h:27,
> from attach.c:43:
> /home/test/test/1/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/bits/sched.h:92:12: note: previous declaration of 'setns' was here
> make[4]: *** [liblxc_so-attach.o] Error 1
>
> Ezequiel ?
>
>> powerpc | mmc-utils-11f2ceabc4ad3f0dd... | NOK | http://autobuild.buildroot.net/results/6d97daa1754aa4380b2fae23698da24a9790b61e/
>> arm | mmc-utils-11f2ceabc4ad3f0dd... | NOK | http://autobuild.buildroot.net/results/828c7a686736710c4fcb152230d0fa6b5f4d6ad3/
>
> Already fixed by Ryan.
>
>> arm | mpd-0.18.7 | NOK | http://autobuild.buildroot.net/results/a46b4c97fe126b23a96051a8bf1243a7f4935434/
>> arm | mpd-0.18.7 | NOK | http://autobuild.buildroot.net/results/ac2d0808752ef5e31dc7121b9f00e1968e8a3621/
>> arm | mpd-0.18.7 | NOK | http://autobuild.buildroot.net/results/232dfa5c786b0423dde4fdb3166fdd8e746bb34b/
>> i686 | mpd-0.18.7 | NOK | http://autobuild.buildroot.net/results/799f24846ba800500243bb69e85a1d6b10960ef3/
>> arm | mpd-0.18.7 | NOK | http://autobuild.buildroot.net/results/77f1b0d537d6d2aa1eea066d15f46fc492ff160d/
>
> Linking problem against libvorbis. To be investigated. Gustavo ?
>
>> arm | mplayer-1.1.1 | NOK | http://autobuild.buildroot.net/results/a2da603abd4ce895c2515e687882c63774c20749/
>
> ARM/floating point problem:
>
> {standard input}: Assembler messages:
> {standard input}:3921: Error: selected processor does not support ARM mode `vmov d0,r7,r8'
> {standard input}:3923: Error: selected processor does not support ARM mode `vld1.32 {d2[],d3[]},[r2,:32]'
> {standard input}:3924: Error: selected processor does not support ARM mode `vmov d1,r0,r1'
> {standard input}:3925: Error: selected processor does not support ARM mode `vmul.f32 q0,q0,q1'
> {standard input}:3926: Error: selected processor does not support ARM mode `vst1.32 {q0},[r3,:128]!'
>
>> arm | nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/f9863fc6b285c76cb3c9926f96b970b98d3203fa/
>
> Static link problem with libstdc++, will be fixed once I rebuild the
> Buildroot external toolchains when 2014.02-rc1 is released.
>
>> mipsel | open2300-12 | NOK | http://autobuild.buildroot.net/results/a57b67bc905a3381cf6f1f86d7af588aecacac60/
>> x86_64 | open2300-12 | NOK | http://autobuild.buildroot.net/results/8108d1b8c524c415a4101f527aa34d8db9df5aa8/
>> avr32 | open2300-12 | NOK | http://autobuild.buildroot.net/results/514f7fe52b17e28966e95adb1e0b13de12f2488b/
>
> Fixed by the patch from Samuel Martin.
>
>> arm | pango-1.28.4 | NOK | http://autobuild.buildroot.net/results/3605675ef8dd03362670ba33ef003b15326bd440/
>
> Link problem:
>
> CCLD pango-view
> /home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.8.1/../../../../arm-none-linux-gnueabi/bin/ld: warning: libXdamage.so.1, needed by /home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGAL.so, not found (try using -rpath or -rpath-link)
> /home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.8.1/../../../../arm-none-linux-gnueabi/bin/ld: warning: libXfixes.so.3, needed by /home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGAL.so, not found (try using -rpath or -rpath-link)
> /home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.8.1/../../../../arm-none-linux-gnueabi/bin/ld: warning: libXext.so.6, needed by /home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGAL.so, not found (try using -rpath or -rpath-link)
> /home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.8.1/../../../../arm-none-linux-gnueabi/bin/ld: warning: libX11.so.6, needed by /home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGAL.so, not found (try using -rpath or -rpath-link)
> /home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGAL.so: undefined reference to `XWidthOfScreen'
> /home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGAL.so: undefined reference to `_XReply'
>
>> mips | sane-backends-1.0.22 | NOK | http://autobuild.buildroot.net/results/7552c9c4106dc5dda8a54178d2ce0dccb40267e0/
>> x86_64 | sane-backends-1.0.22 | NOK | http://autobuild.buildroot.net/results/b241b930f109f68bec3e250e583a934e6d32b565/
>> aarch64 | sane-backends-1.0.22 | NOK | http://autobuild.buildroot.net/results/dfeda680f6f2b44487cd0f79a47b79a6eff9108e/
>> powerpc | sane-backends-1.0.22 | NOK | http://autobuild.buildroot.net/results/7b2924aecdfd6220caf523765693fd8fe3bd3853/
>
> Download problems, fixed by removing the invalid tarball on the autobuilders.
>
>> sh4a | unknown | TIM | http://autobuild.buildroot.net/results/463f2d7d4becda8338a806597094204dde8adf36/
>
> To be ignored.
>
>> powerpc | util-linux-2.23.2 | NOK | http://autobuild.buildroot.net/results/399e62acf2c452653cb2ee9ca150a0cfe7e33326/
>
> Missing setns() on CodeSourcery toolchain. Since util-linux is really
> needed for many packages, it would be good to find a fix that doesn't
> involve disabling util-linux completely.
>
> checking for syscall setns... no
> configure: WARNING: Unable to detect syscall setns.
> configure: error: nsenter selected but setns syscall not found
> make: *** [/home/test/test/3/output/build/util-linux-2.23.2/.stamp_configured] Error 1
>
> Gustavo, an idea?
>
>> powerpc | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/a9fbda1006db0ebd8961ee582151aaae7d7e8fe6/
>> arm | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/b5972ecad4e5004dc23a2366066ce45346994f58/
>> powerpc | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/d41d2f36a4384289e300a3cf91d51960df9fab00/
>
> The first two ones are related to live555 missing:
>
> checking for LIVE555... no
> configure: WARNING: Package live555 was not found in the pkg-config search path.
> Perhaps you should add the directory containing `live555.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'live555' found.
> checking for live555 version 1324598400 or later... no
> configure: WARNING: live555 is missing or its installed version is too old:
>
> The last one is a little more weird:
>
> CC libvmem_plugin_la-vmem.lo
> In file included from sdl.c:31:0:
> ../../config.h:733:0: warning: "_REENTRANT" redefined
> <command-line>:0:0: note: this is the location of the previous definition
> sdl.c:45:4: error: #error Xlib required due to XInitThreads
> In file included from sdl.c:47:0:
> ../../include/vlc_xlib.h:26:23: fatal error: X11/Xlib.h: No such file or directory
> compilation terminated.
>
> Simon, maybe?
>
>> arm | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/47a6a7f419dc76a0a3864304e7335b59a0c89b4a/
>
> Some Javascript JIT stuff should be disabled on ARMv4.
>
>> powerpc | weston-1.4.0 | NOK | http://autobuild.buildroot.net/results/aa54b1aaf0ac89531d7a1e7dd3900b35605ae3f5/
>
> CC weston-data-device.o
> launcher-util.c: In function 'setup_tty':
> launcher-util.c:334:38: error: 'K_OFF' undeclared (first use in this function)
> launcher-util.c:334:38: note: each undeclared identifier is reported only once for each function it appears in
> make[4]: *** [libsession_helper_la-launcher-util.lo] Error 1
>
> Yann ?
>
>> powerpc | zmqpp-36413487f05b165dfc82a... | NOK | http://autobuild.buildroot.net/results/fd296ba75a767556fd1a39c5552a6e00cb59d867/
>
> Weird C++ error:
>
> src/zmqpp/message.cpp:437:38: instantiated from here
> src/zmqpp/frame.hpp:52:2: error: 'zmqpp::frame::frame(const zmqpp::frame&)' is private
> /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/powerpc-linux-gnu/4.5.2/../../../../powerpc-linux-gnu/include/c++/4.5.2/bits/stl_construct.h:80:7: error: within this context
> src/zmqpp/frame.hpp:52:2: error: deleted function 'zmqpp::frame::frame(const zmqpp::frame&)'
> /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/powerpc-linux-gnu/4.5.2/../../../../powerpc-linux-gnu/include/c++/4.5.2/bits/stl_construct.h:80:7: error: used here
> make[1]: *** [build/obj/zmqpp/message.o] Error 1
>
> Simon, Alexander ?
>
> Thanks for your help!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
--
Spenser Gilliland
Computer Engineer
Doctoral Candidate
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-07 12:53 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (3 preceding siblings ...)
2014-02-07 14:53 ` Ezequiel García
@ 2014-02-07 18:53 ` Yann E. MORIN
2014-02-07 19:03 ` Spenser Gilliland
2014-02-17 15:40 ` Vicente Olivert Riera
6 siblings, 0 replies; 416+ messages in thread
From: Yann E. MORIN @ 2014-02-07 18:53 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2014-02-07 13:53 +0100, Thomas Petazzoni spake thusly:
> > powerpc | weston-1.4.0 | NOK | http://autobuild.buildroot.net/results/aa54b1aaf0ac89531d7a1e7dd3900b35605ae3f5/
>
> CC weston-data-device.o
> launcher-util.c: In function 'setup_tty':
> launcher-util.c:334:38: error: 'K_OFF' undeclared (first use in this function)
> launcher-util.c:334:38: note: each undeclared identifier is reported only once for each function it appears in
> make[4]: *** [libsession_helper_la-launcher-util.lo] Error 1
Too old toolchain.
The K_OFF define was introduced with:
2011-02-04 9fc3de9c: vt: Add virtual console keyboard mode OFF
which ended up in the 2.6.39 release.
But the freescale-2011.03-38-powerpc-linux-gnu-i686-pc-linux-gnu
toolchain uses headers from the 2.6.38 Linux kernel, and thus is
missing this define.
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] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-07 13:01 ` Thomas De Schampheleire
2014-02-07 13:33 ` Thomas Petazzoni
@ 2014-02-07 18:40 ` Yann E. MORIN
1 sibling, 0 replies; 416+ messages in thread
From: Yann E. MORIN @ 2014-02-07 18:40 UTC (permalink / raw)
To: buildroot
Thomas?, All,
On 2014-02-07 14:01 +0100, Thomas De Schampheleire spake thusly:
> On Fri, Feb 7, 2014 at 1:53 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > Hello all,
> >
> > You'll find below a quick analysis of the build failures. If you are in
> > Cc, it means that there is a question for you below, or a request to
> > help debugging a specific problem. Thanks!
> >
>
> It seems almost all of your CC:s were removed, only Yann is still present.
I guess it's because of the settings of the list. By default, the option
"Avoid duplicate copies of messages?" is set to "yes", which means mailman
drops the Cc: fields which are subscribed to the list.
It keeps me in Cc: because I explcitly set this option to "no".
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] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-07 15:14 ` Thomas Petazzoni
@ 2014-02-07 15:19 ` Ezequiel García
0 siblings, 0 replies; 416+ messages in thread
From: Ezequiel García @ 2014-02-07 15:19 UTC (permalink / raw)
To: buildroot
On 7 February 2014 12:14, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Ezequiel Garc?a,
>
> On Fri, 7 Feb 2014 13:07:22 -0200, Ezequiel Garc?a wrote:
>
>> Old nios2 kernel ports does not have setns system call. I've confirmed
>> at least v3.7 (the one I use on production stuff) lacks setns. Latest
>> v3.12 (development kernel) *does* support setns.
>>
>> I guess the toolchain people just set it to be unimplemented.
>>
>> Want a patch masking lxc package on nios2?
>
> If indeed most nios2 kernels do not support the setns system call,
> that's probably the best solution. Moreover, I would say it's fairly
> unlikely that people would use nios2 to do Linux Containers, no?
>
You can bet on that any day.
> Be sure to indicate above the dependency why it was added:
>
> # nios2 kernels do not provide the setns syscall
> depends on !BR2_nios2
>
> Thanks!
>
Sure.
--
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-07 15:07 ` Ezequiel García
2014-02-07 15:14 ` Thomas Petazzoni
@ 2014-02-07 15:18 ` Peter Korsgaard
1 sibling, 0 replies; 416+ messages in thread
From: Peter Korsgaard @ 2014-02-07 15:18 UTC (permalink / raw)
To: buildroot
>>>>> "Ezequiel" == Ezequiel Garc?a <ezequiel@vanguardiasur.com.ar> writes:
Hi,
> I guess the toolchain people just set it to be unimplemented.
> Want a patch masking lxc package on nios2?
yes please.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-07 15:07 ` Ezequiel García
@ 2014-02-07 15:14 ` Thomas Petazzoni
2014-02-07 15:19 ` Ezequiel García
2014-02-07 15:18 ` Peter Korsgaard
1 sibling, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-07 15:14 UTC (permalink / raw)
To: buildroot
Dear Ezequiel Garc?a,
On Fri, 7 Feb 2014 13:07:22 -0200, Ezequiel Garc?a wrote:
> Old nios2 kernel ports does not have setns system call. I've confirmed
> at least v3.7 (the one I use on production stuff) lacks setns. Latest
> v3.12 (development kernel) *does* support setns.
>
> I guess the toolchain people just set it to be unimplemented.
>
> Want a patch masking lxc package on nios2?
If indeed most nios2 kernels do not support the setns system call,
that's probably the best solution. Moreover, I would say it's fairly
unlikely that people would use nios2 to do Linux Containers, no?
Be sure to indicate above the dependency why it was added:
# nios2 kernels do not provide the setns syscall
depends on !BR2_nios2
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-07 14:55 ` Thomas Petazzoni
@ 2014-02-07 15:07 ` Ezequiel García
2014-02-07 15:14 ` Thomas Petazzoni
2014-02-07 15:18 ` Peter Korsgaard
0 siblings, 2 replies; 416+ messages in thread
From: Ezequiel García @ 2014-02-07 15:07 UTC (permalink / raw)
To: buildroot
On 7 February 2014 11:55, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
[..]
>
> Have a look at config.log to see why it fails to detect that setns() is
> available.
>
Thanks for the tip:
| /* The GNU C library defines this for functions which it implements
| to always fail with ENOSYS. Some functions are actually named
| something starting with __ and the normal name is an alias. */
| #if defined __stub_setns || defined __stub___setns
| choke me
| #endif
Old nios2 kernel ports does not have setns system call. I've confirmed
at least v3.7 (the one I use on production stuff) lacks setns. Latest
v3.12 (development kernel) *does* support setns.
I guess the toolchain people just set it to be unimplemented.
Want a patch masking lxc package on nios2?
--
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-07 14:53 ` Ezequiel García
@ 2014-02-07 14:55 ` Thomas Petazzoni
2014-02-07 15:07 ` Ezequiel García
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-07 14:55 UTC (permalink / raw)
To: buildroot
Dear Ezequiel Garc?a,
On Fri, 7 Feb 2014 12:53:17 -0200, Ezequiel Garc?a wrote:
> I guess setns is getting problematic today. Problem is this chunk of lxc's code:
>
> #ifndef HAVE_SETNS
> static int setns(int fd, int nstype)
> {
> #ifdef __NR_setns
> return syscall(__NR_setns, fd, nstype);
> #else
> errno = ENOSYS;
> return -1;
> #endif
> }
> #endif
>
> We need a way to set HAVE_SETNS. I've found a similar fix here:
>
> http://buildroot-busybox.2317881.n4.nabble.com/git-commit-iproute2-fix-build-with-toolchains-providing-setns-2-td33940.html
>
> I'll see if I can find a suitable fix for lxc. Help is welcome though.
The lxc configure script has a check for setns() :
AC_CHECK_FUNCS([setns pivot_root sethostname unshare])
so if setns() is available, it should set HAVE_SETNS in config.h.
Have a look at config.log to see why it fails to detect that setns() is
available.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-07 12:53 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (2 preceding siblings ...)
2014-02-07 14:00 ` Anton Kolesov
@ 2014-02-07 14:53 ` Ezequiel García
2014-02-07 14:55 ` Thomas Petazzoni
2014-02-07 18:53 ` Yann E. MORIN
` (2 subsequent siblings)
6 siblings, 1 reply; 416+ messages in thread
From: Ezequiel García @ 2014-02-07 14:53 UTC (permalink / raw)
To: buildroot
On 7 February 2014 09:53, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
[..]
>
>> nios2 | lxc-0.9.0 | NOK | http://autobuild.buildroot.net/results/f592a011321429426be81bd1ecf664ad9a2c0161/
>
> Duplicate declaration of setns() :
>
> attach.c:54:12: error: static declaration of 'setns' follows non-static declaration
> In file included from /home/test/test/1/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/sched.h:42:0,
> from namespace.h:27,
> from attach.c:43:
> /home/test/test/1/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/bits/sched.h:92:12: note: previous declaration of 'setns' was here
> make[4]: *** [liblxc_so-attach.o] Error 1
>
> Ezequiel ?
>
I guess setns is getting problematic today. Problem is this chunk of lxc's code:
#ifndef HAVE_SETNS
static int setns(int fd, int nstype)
{
#ifdef __NR_setns
return syscall(__NR_setns, fd, nstype);
#else
errno = ENOSYS;
return -1;
#endif
}
#endif
We need a way to set HAVE_SETNS. I've found a similar fix here:
http://buildroot-busybox.2317881.n4.nabble.com/git-commit-iproute2-fix-build-with-toolchains-providing-setns-2-td33940.html
I'll see if I can find a suitable fix for lxc. Help is welcome though.
--
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-07 12:53 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-02-07 13:01 ` Thomas De Schampheleire
2014-02-07 13:25 ` Gustavo Zacarias
@ 2014-02-07 14:00 ` Anton Kolesov
2014-02-07 14:53 ` Ezequiel García
` (3 subsequent siblings)
6 siblings, 0 replies; 416+ messages in thread
From: Anton Kolesov @ 2014-02-07 14:00 UTC (permalink / raw)
To: buildroot
Hi Thomas,
>
> > arc | dmraid-1.0.0.rc15 | NOK |
> http://autobuild.buildroot.net/results/ef6a0e2d382ae202bb8f0e9fc9f5e48c9
> 0119faf/
>
> Internal compiler error. Ryan has sent a patch to disable the dmraid
> build on ARC for now, but it would be good if the ARC team could have a
> look at this. Cc'ing Anton.
We have two compiler patches internally which resolve several failures in autobuild. I'm waiting for compiler engineer to merge those patches into main branch, so I can update commit referenced in Buildroot. I expect this to happen next week.
>
> > arc | libpfm4-4.3.0 | NOK |
> http://autobuild.buildroot.net/results/59cefaba9d382f0de17b5dccb2d88fc74
> d36f520/
>
> task.c: In function 'read_groups':
> task.c:110:5: error: format '%zd' expects argument of type 'signed size_t', but
> argument 4 has type 'ssize_t' [-Werror=format=]
> evt, new_sz, ret);
> ^
> cc1: all warnings being treated as errors
> make[2]: *** [task.o] Error 1
>
> -> We should build this package without treating warning as error.
However variables of type "signed size_t" cannot be declared (at least for ARC) so there is a misinformation from GCC, and on the same test case GCC for x86_64 doesn't emit a warning at all, while ARC emits. Both GCC's are version 4.8. So it seems to be something ARC-specific. I've filed an internal bug report to investigate. Though I also have no objections if this package will be compiled without -Werror.
Anton Kolesov
>
> Thanks for your help!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-07 13:01 ` Thomas De Schampheleire
@ 2014-02-07 13:33 ` Thomas Petazzoni
2014-02-07 18:40 ` Yann E. MORIN
1 sibling, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-07 13:33 UTC (permalink / raw)
To: buildroot
Dear Thomas De Schampheleire,
On Fri, 7 Feb 2014 14:01:10 +0100, Thomas De Schampheleire wrote:
> > You'll find below a quick analysis of the build failures. If you are in
> > Cc, it means that there is a question for you below, or a request to
> > help debugging a specific problem. Thanks!
>
> It seems almost all of your CC:s were removed, only Yann is still present.
> Try using the To: field? This is what I've done successfully for the
> patchwork cleanup mails.
I hate this mailing list software that trims the Cc list. This is
annoying and useless...
I'll try to use To: next time.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-07 12:53 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-02-07 13:01 ` Thomas De Schampheleire
@ 2014-02-07 13:25 ` Gustavo Zacarias
2014-02-07 19:18 ` Arnout Vandecappelle
2014-02-08 21:43 ` Peter Korsgaard
2014-02-07 14:00 ` Anton Kolesov
` (4 subsequent siblings)
6 siblings, 2 replies; 416+ messages in thread
From: Gustavo Zacarias @ 2014-02-07 13:25 UTC (permalink / raw)
To: buildroot
On 02/07/2014 09:53 AM, Thomas Petazzoni wrote:
> Hello all,
>
> You'll find below a quick analysis of the build failures. If you are in
> Cc, it means that there is a question for you below, or a request to
> help debugging a specific problem. Thanks!
>
> On Fri, 7 Feb 2014 08:30:09 +0100 (CET), Thomas Petazzoni wrote:
>
>> Detail of failures
>> ===================
>>
>> bfin | alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/b25590e19d0e638dcbb2855a84e82ea7b2703460/
>
> There is a patch pending that fixes this issue:
> http://patchwork.ozlabs.org/patch/293833/. Maybe we should merge it?
Alsa upstream didn't respond to Sonic's patch.
At the time i thought it could be made somewhat nicer without the dl
dummy defines by #ifdef'ing out the RTLD usage, but waited on upstream
to chime in and well... nothing happened :)
>> arm | mpd-0.18.7 | NOK | http://autobuild.buildroot.net/results/a46b4c97fe126b23a96051a8bf1243a7f4935434/
>> arm | mpd-0.18.7 | NOK | http://autobuild.buildroot.net/results/ac2d0808752ef5e31dc7121b9f00e1968e8a3621/
>> arm | mpd-0.18.7 | NOK | http://autobuild.buildroot.net/results/232dfa5c786b0423dde4fdb3166fdd8e746bb34b/
>> i686 | mpd-0.18.7 | NOK | http://autobuild.buildroot.net/results/799f24846ba800500243bb69e85a1d6b10960ef3/
>> arm | mpd-0.18.7 | NOK | http://autobuild.buildroot.net/results/77f1b0d537d6d2aa1eea066d15f46fc492ff160d/
>
> Linking problem against libvorbis. To be investigated. Gustavo ?
mpd 0.18 introduced the vorbis encoder option, which is an automatic
option as most. If vorbis (decoder) is not enabled and the library is
present vorbis encoder is automatically enabled, but mpd doesn't do the
libvorbis magic as it should thus failing.
Easy fix forcibly disabling all of the vorbis bits in the package, patch
sent.
>> powerpc | util-linux-2.23.2 | NOK | http://autobuild.buildroot.net/results/399e62acf2c452653cb2ee9ca150a0cfe7e33326/
>
> Missing setns() on CodeSourcery toolchain. Since util-linux is really
> needed for many packages, it would be good to find a fix that doesn't
> involve disabling util-linux completely.
>
> checking for syscall setns... no
> configure: WARNING: Unable to detect syscall setns.
> configure: error: nsenter selected but setns syscall not found
> make: *** [/home/test/test/3/output/build/util-linux-2.23.2/.stamp_configured] Error 1
>
> Gustavo, an idea?
Yes, blame commit 9f91d79601da42516752318beecfd080dc05aac9
Before it was an option util-linux decided if it was appropiate to build
it according to setns() being available, now we may be forcing it when
the syscall may simply be unavailable (like this toolchain).
We can do a ton of toolchain kludges or just revert, i'd prefer the
second option since it's not like a super-common command (actually most
distros don't have it yet because it's pretty new for util-linux).
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-07 12:53 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2014-02-07 13:01 ` Thomas De Schampheleire
2014-02-07 13:33 ` Thomas Petazzoni
2014-02-07 18:40 ` Yann E. MORIN
2014-02-07 13:25 ` Gustavo Zacarias
` (5 subsequent siblings)
6 siblings, 2 replies; 416+ messages in thread
From: Thomas De Schampheleire @ 2014-02-07 13:01 UTC (permalink / raw)
To: buildroot
Thomas,
On Fri, Feb 7, 2014 at 1:53 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello all,
>
> You'll find below a quick analysis of the build failures. If you are in
> Cc, it means that there is a question for you below, or a request to
> help debugging a specific problem. Thanks!
>
It seems almost all of your CC:s were removed, only Yann is still present.
Try using the To: field? This is what I've done successfully for the
patchwork cleanup mails.
Thanks,
Thomas
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2014-02-07 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-06 Thomas Petazzoni
@ 2014-02-07 12:53 ` Thomas Petazzoni
2014-02-07 13:01 ` Thomas De Schampheleire
` (6 more replies)
0 siblings, 7 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2014-02-07 12:53 UTC (permalink / raw)
To: buildroot
Hello all,
You'll find below a quick analysis of the build failures. If you are in
Cc, it means that there is a question for you below, or a request to
help debugging a specific problem. Thanks!
On Fri, 7 Feb 2014 08:30:09 +0100 (CET), Thomas Petazzoni wrote:
> Detail of failures
> ===================
>
> bfin | alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/b25590e19d0e638dcbb2855a84e82ea7b2703460/
There is a patch pending that fixes this issue:
http://patchwork.ozlabs.org/patch/293833/. Maybe we should merge it?
> mipsel | alsa-utils-1.0.26 | NOK | http://autobuild.buildroot.net/results/05d3186bcb74c905bbc689859522b88db78c2f68/
/home/test/test/3/output/host/opt/ext-toolchain/bin/../lib/gcc/mipsel-buildroot-linux-uclibc/4.7.3/../../../../mipsel-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.21 assertion fail elfxx-mips.c:3416
/home/test/test/3/output/host/usr/mipsel-buildroot-linux-uclibc/sysroot/usr/lib/libasound.a(rawmidi_symbols.o):(.data.rel+0x4): undefined reference to `_snd_module_rawmidi_virt'
Looks like a MIPS toolchain problem, maybe? The toolchain used is a
Buildroot toolchain built with Buildroot 2013.11. If the problem no
longer occurs with the internal toolchain backend, then it will be
fixed once I rebuild the external Buildroot toolchains of the Buildroot
(when -rc1 is released). Vicente, can you test if this works with the
internal toolchain?
> bfin | cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/1f79be918cebc29c306db6444908b20c6ada5683/
> bfin | cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/91310c4da3541b9b8b447f0876d1deff2fadc19c/
Unknown problem while building cairo tests:
cairo-test-runner.c: In function 'is_running_under_debugger':
cairo-test-runner.c:168: error: implicit declaration of function 'getppid'
cairo-test-runner.c:168: warning: nested extern declaration of 'getppid'
cairo-test-runner.c:169: error: implicit declaration of function 'readlink'
cairo-test-runner.c:169: warning: nested extern declaration of 'readlink'
make[5]: *** [cairo_test_suite-cairo-test-runner.o] Error 1
Maybe disabling the cairo tests is sufficient.
> arc | dmraid-1.0.0.rc15 | NOK | http://autobuild.buildroot.net/results/ef6a0e2d382ae202bb8f0e9fc9f5e48c90119faf/
Internal compiler error. Ryan has sent a patch to disable the dmraid
build on ARC for now, but it would be good if the ARC team could have a
look at this. Cc'ing Anton.
> bfin | e2fsprogs-1.42.9 | NOK | http://autobuild.buildroot.net/results/284f2a161d110d4c561cf89c052ce531b4edc173/
Not sure what's going on:
checking for blkid_get_cache in -lblkid... no
configure: error: external blkid library not found
make: *** [/home/test/test/1/output/build/e2fsprogs-1.42.9/.stamp_configured] Error 1
> avr32 | elfutils-0.155 | NOK | http://autobuild.buildroot.net/results/7bb5b317dd35d8b3dd2fc9a777a5d65bd143348c/
../libdwfl/libdwfl_pic.a(find-debuginfo.os): In function `find_debuginfo_in_path':
find-debuginfo.c:(.text+0x3e6): undefined reference to `canonicalize_file_name'
../libdwfl/libdwfl_pic.a(dwfl_build_id_find_elf.os): In function `__libdwfl_open_by_build_id':
dwfl_build_id_find_elf.c:(.text+0x1a8): undefined reference to `canonicalize_file_name'
collect2: ld returned 1 exit status
Might be due to a too old uClibc on AVR32 ?
> microblaze | gdb-7.5.1 | NOK | http://autobuild.buildroot.net/results/1996d259baffdfed52a56b93c67904df97fe5c53/
Download error. Spenser, can you have a look?
> microblaze | gpm-1.20.7 | NOK | http://autobuild.buildroot.net/results/5915af9e00fc29e48764778916ea6f806d6dceb8/
Not sure what's going on:
/home/test/test/3/output/host/usr/bin/microblaze-buildroot-linux-gnu-gcc libgpm.so.2 \
-L/home/test/test/3/output/build/gpm-1.20.7/src -o lib/libgpm.so.2.1.0 lib/liblow.lo lib/libhigh.lo lib/libxtra.lo lib/report-lib.lo tools.lo -lc
microblaze-buildroot-linux-gnu-gcc: error: libgpm.so.2: No such file or directory
> microblaze | gpsd-b4c32aa40cff1b4e1041d5... | NOK | http://autobuild.buildroot.net/results/42da870722f24e4202d8265597771a0449e74cfd/
Internal compiler error. Ryan has sent a patch to disable the gpsd
build on Microblaze for now, but it would be good to report the problem
to Xilinx, or bump the toolchain component versions as needed.
> bfin | libeet-1.7.7 | NOK | http://autobuild.buildroot.net/results/3eaa07dc462b5ffa34ccf527dc921d3ad5a2c4f8/
uClibc lacks _madvise ?
CCLD eet
/home/test/test/3/output/host/usr/bfin-buildroot-linux-uclibc/sysroot/usr/lib/libeina.so: undefined reference to `_madvise'
collect2: ld returned 1 exit status
> arm | libevas-1.7.7 | NOK | http://autobuild.buildroot.net/results/ca25323567324fb9082e3c0f318ea8b961fad3d8/
Don't know:
CC evas_cache2.lo
evas_cache2.c: In function '_evas_cache_image_entry_delete':
evas_cache2.c:176:17: error: 'Image_Entry_Flags' has no member named 'delete_me'
evas_cache2.c:181:18: error: 'Image_Entry_Flags' has no member named 'delete_me'
evas_cache2.c: In function '_evas_cache2_image_preloaded_cb':
evas_cache2.c:296:13: error: 'Image_Entry_Flags' has no member named 'preload_done'
evas_cache2.c:303:23: error: 'Image_Entry_Flags' has no member named 'delete_me'
evas_cache2.c:308:17: error: 'Image_Entry_Flags' has no member named 'delete_me'
evas_cache2.c: In function '_evas_cache2_image_entry_preload_add':
evas_cache2.c:317:17: error: 'Image_Entry_Flags' has no member named 'preload_done'
make[5]: *** [evas_cache2.lo] Error 1
> arc | libpfm4-4.3.0 | NOK | http://autobuild.buildroot.net/results/59cefaba9d382f0de17b5dccb2d88fc74d36f520/
task.c: In function 'read_groups':
task.c:110:5: error: format '%zd' expects argument of type 'signed size_t', but argument 4 has type 'ssize_t' [-Werror=format=]
evt, new_sz, ret);
^
cc1: all warnings being treated as errors
make[2]: *** [task.o] Error 1
-> We should build this package without treating warning as error.
> nios2 | ltp-testsuite-20130904 | NOK | http://autobuild.buildroot.net/results/9aca518bf53aea62bc4bb437976f0223113c26ce/
Would be good to see if the bump of ltp-testsuite proposed by Vicente
fixes this problem. Peter, can you apply
http://patchwork.ozlabs.org/patch/317112/ ?
> nios2 | lxc-0.9.0 | NOK | http://autobuild.buildroot.net/results/f592a011321429426be81bd1ecf664ad9a2c0161/
Duplicate declaration of setns() :
attach.c:54:12: error: static declaration of 'setns' follows non-static declaration
In file included from /home/test/test/1/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/sched.h:42:0,
from namespace.h:27,
from attach.c:43:
/home/test/test/1/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/bits/sched.h:92:12: note: previous declaration of 'setns' was here
make[4]: *** [liblxc_so-attach.o] Error 1
Ezequiel ?
> powerpc | mmc-utils-11f2ceabc4ad3f0dd... | NOK | http://autobuild.buildroot.net/results/6d97daa1754aa4380b2fae23698da24a9790b61e/
> arm | mmc-utils-11f2ceabc4ad3f0dd... | NOK | http://autobuild.buildroot.net/results/828c7a686736710c4fcb152230d0fa6b5f4d6ad3/
Already fixed by Ryan.
> arm | mpd-0.18.7 | NOK | http://autobuild.buildroot.net/results/a46b4c97fe126b23a96051a8bf1243a7f4935434/
> arm | mpd-0.18.7 | NOK | http://autobuild.buildroot.net/results/ac2d0808752ef5e31dc7121b9f00e1968e8a3621/
> arm | mpd-0.18.7 | NOK | http://autobuild.buildroot.net/results/232dfa5c786b0423dde4fdb3166fdd8e746bb34b/
> i686 | mpd-0.18.7 | NOK | http://autobuild.buildroot.net/results/799f24846ba800500243bb69e85a1d6b10960ef3/
> arm | mpd-0.18.7 | NOK | http://autobuild.buildroot.net/results/77f1b0d537d6d2aa1eea066d15f46fc492ff160d/
Linking problem against libvorbis. To be investigated. Gustavo ?
> arm | mplayer-1.1.1 | NOK | http://autobuild.buildroot.net/results/a2da603abd4ce895c2515e687882c63774c20749/
ARM/floating point problem:
{standard input}: Assembler messages:
{standard input}:3921: Error: selected processor does not support ARM mode `vmov d0,r7,r8'
{standard input}:3923: Error: selected processor does not support ARM mode `vld1.32 {d2[],d3[]},[r2,:32]'
{standard input}:3924: Error: selected processor does not support ARM mode `vmov d1,r0,r1'
{standard input}:3925: Error: selected processor does not support ARM mode `vmul.f32 q0,q0,q1'
{standard input}:3926: Error: selected processor does not support ARM mode `vst1.32 {q0},[r3,:128]!'
> arm | nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/f9863fc6b285c76cb3c9926f96b970b98d3203fa/
Static link problem with libstdc++, will be fixed once I rebuild the
Buildroot external toolchains when 2014.02-rc1 is released.
> mipsel | open2300-12 | NOK | http://autobuild.buildroot.net/results/a57b67bc905a3381cf6f1f86d7af588aecacac60/
> x86_64 | open2300-12 | NOK | http://autobuild.buildroot.net/results/8108d1b8c524c415a4101f527aa34d8db9df5aa8/
> avr32 | open2300-12 | NOK | http://autobuild.buildroot.net/results/514f7fe52b17e28966e95adb1e0b13de12f2488b/
Fixed by the patch from Samuel Martin.
> arm | pango-1.28.4 | NOK | http://autobuild.buildroot.net/results/3605675ef8dd03362670ba33ef003b15326bd440/
Link problem:
CCLD pango-view
/home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.8.1/../../../../arm-none-linux-gnueabi/bin/ld: warning: libXdamage.so.1, needed by /home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGAL.so, not found (try using -rpath or -rpath-link)
/home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.8.1/../../../../arm-none-linux-gnueabi/bin/ld: warning: libXfixes.so.3, needed by /home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGAL.so, not found (try using -rpath or -rpath-link)
/home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.8.1/../../../../arm-none-linux-gnueabi/bin/ld: warning: libXext.so.6, needed by /home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGAL.so, not found (try using -rpath or -rpath-link)
/home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.8.1/../../../../arm-none-linux-gnueabi/bin/ld: warning: libX11.so.6, needed by /home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGAL.so, not found (try using -rpath or -rpath-link)
/home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGAL.so: undefined reference to `XWidthOfScreen'
/home/test/test/1/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGAL.so: undefined reference to `_XReply'
> mips | sane-backends-1.0.22 | NOK | http://autobuild.buildroot.net/results/7552c9c4106dc5dda8a54178d2ce0dccb40267e0/
> x86_64 | sane-backends-1.0.22 | NOK | http://autobuild.buildroot.net/results/b241b930f109f68bec3e250e583a934e6d32b565/
> aarch64 | sane-backends-1.0.22 | NOK | http://autobuild.buildroot.net/results/dfeda680f6f2b44487cd0f79a47b79a6eff9108e/
> powerpc | sane-backends-1.0.22 | NOK | http://autobuild.buildroot.net/results/7b2924aecdfd6220caf523765693fd8fe3bd3853/
Download problems, fixed by removing the invalid tarball on the autobuilders.
> sh4a | unknown | TIM | http://autobuild.buildroot.net/results/463f2d7d4becda8338a806597094204dde8adf36/
To be ignored.
> powerpc | util-linux-2.23.2 | NOK | http://autobuild.buildroot.net/results/399e62acf2c452653cb2ee9ca150a0cfe7e33326/
Missing setns() on CodeSourcery toolchain. Since util-linux is really
needed for many packages, it would be good to find a fix that doesn't
involve disabling util-linux completely.
checking for syscall setns... no
configure: WARNING: Unable to detect syscall setns.
configure: error: nsenter selected but setns syscall not found
make: *** [/home/test/test/3/output/build/util-linux-2.23.2/.stamp_configured] Error 1
Gustavo, an idea?
> powerpc | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/a9fbda1006db0ebd8961ee582151aaae7d7e8fe6/
> arm | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/b5972ecad4e5004dc23a2366066ce45346994f58/
> powerpc | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/d41d2f36a4384289e300a3cf91d51960df9fab00/
The first two ones are related to live555 missing:
checking for LIVE555... no
configure: WARNING: Package live555 was not found in the pkg-config search path.
Perhaps you should add the directory containing `live555.pc'
to the PKG_CONFIG_PATH environment variable
No package 'live555' found.
checking for live555 version 1324598400 or later... no
configure: WARNING: live555 is missing or its installed version is too old:
The last one is a little more weird:
CC libvmem_plugin_la-vmem.lo
In file included from sdl.c:31:0:
../../config.h:733:0: warning: "_REENTRANT" redefined
<command-line>:0:0: note: this is the location of the previous definition
sdl.c:45:4: error: #error Xlib required due to XInitThreads
In file included from sdl.c:47:0:
../../include/vlc_xlib.h:26:23: fatal error: X11/Xlib.h: No such file or directory
compilation terminated.
Simon, maybe?
> arm | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/47a6a7f419dc76a0a3864304e7335b59a0c89b4a/
Some Javascript JIT stuff should be disabled on ARMv4.
> powerpc | weston-1.4.0 | NOK | http://autobuild.buildroot.net/results/aa54b1aaf0ac89531d7a1e7dd3900b35605ae3f5/
CC weston-data-device.o
launcher-util.c: In function 'setup_tty':
launcher-util.c:334:38: error: 'K_OFF' undeclared (first use in this function)
launcher-util.c:334:38: note: each undeclared identifier is reported only once for each function it appears in
make[4]: *** [libsession_helper_la-launcher-util.lo] Error 1
Yann ?
> powerpc | zmqpp-36413487f05b165dfc82a... | NOK | http://autobuild.buildroot.net/results/fd296ba75a767556fd1a39c5552a6e00cb59d867/
Weird C++ error:
src/zmqpp/message.cpp:437:38: instantiated from here
src/zmqpp/frame.hpp:52:2: error: 'zmqpp::frame::frame(const zmqpp::frame&)' is private
/home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/powerpc-linux-gnu/4.5.2/../../../../powerpc-linux-gnu/include/c++/4.5.2/bits/stl_construct.h:80:7: error: within this context
src/zmqpp/frame.hpp:52:2: error: deleted function 'zmqpp::frame::frame(const zmqpp::frame&)'
/home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/powerpc-linux-gnu/4.5.2/../../../../powerpc-linux-gnu/include/c++/4.5.2/bits/stl_construct.h:80:7: error: used here
make[1]: *** [build/obj/zmqpp/message.o] Error 1
Simon, Alexander ?
Thanks for your help!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-22 9:15 ` Fabio Porcedda
@ 2013-11-29 10:25 ` Fabio Porcedda
0 siblings, 0 replies; 416+ messages in thread
From: Fabio Porcedda @ 2013-11-29 10:25 UTC (permalink / raw)
To: buildroot
On Fri, Nov 22, 2013 at 10:15 AM, Fabio Porcedda
<fabio.porcedda@gmail.com> wrote:
> Hi Thomas,
>
> On Fri, Nov 22, 2013 at 9:14 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Hello,
>>
>> On Fri, 22 Nov 2013 08:30:02 +0100 (CET), Thomas Petazzoni wrote:
>> ...
>>> arm | lvm2-2.02.103 | NOK | http://autobuild.buildroot.net/results/b0b386969459dda9c294f1ccb4927ca225fa6bdd/
>>
>> Missing dependency?
>>
>> /home/test/test/1/output/host/usr/bin/arm-linux-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pipe -Os -fPIC -O2 --static -O2 -L../libdm -L../lib -L../libdaemon/client -L../libdm \
>> -o dmsetup dmsetup.o -ldevmapper
>> /home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.7.3/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: cannot find -ldevmapper
>>
>> ...
>
> I will try to look into this.
The problem is still present on the master branch.
The minimal defconfig to reproduce the problem is:
BR2_PREFER_STATIC_LIB=y
BR2_TOOLCHAIN_BUILDROOT_LARGEFILE=y
BR2_PACKAGE_LVM2=y
The problem is related to "BR2_PREFER_STATIC_LIB=y" without that
option it builds fine.
Updating it to the latest available git version does not fix the issue.
I will try to investigate further.
Regards
--
Fabio Porcedda
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-29 8:51 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2013-11-29 9:00 ` Peter Korsgaard
@ 2013-11-29 10:04 ` Gustavo Zacarias
1 sibling, 0 replies; 416+ messages in thread
From: Gustavo Zacarias @ 2013-11-29 10:04 UTC (permalink / raw)
To: buildroot
On 11/29/2013 05:51 AM, Thomas Petazzoni wrote:
>> bfin | hostapd-2.0 | NOK | http://autobuild.buildroot.net/results/d4a9f44effeb08eda6c4b32764274ae81d185d5e/
>
> Missing pthread in the link command line?
>
> /home/test/test/1/output/host/usr/bfin-buildroot-uclinux-uclibc/sysroot/usr/lib/libnl-3.a(cache_mngt.o): In function `_nl_cache_mngt_unprovide':
> cache_mngt.c:(.text+0x6e): undefined reference to `_pthread_rwlock_wrlock'
> cache_mngt.c:(.text+0x10a): undefined reference to `_pthread_rwlock_unlock'
libnl doesn't account for pthread usage in its PC files.
I'll take a look.
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-29 8:51 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2013-11-29 9:00 ` Peter Korsgaard
2013-11-29 10:04 ` Gustavo Zacarias
1 sibling, 0 replies; 416+ messages in thread
From: Peter Korsgaard @ 2013-11-29 9:00 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> Hello,
> This is probably the last day (or last two days) to fix more
> autobuilder failures.
Thanks for the overview.
>> arm | qt-4.8.5 | NOK | http://autobuild.buildroot.net/results/efe26c54361094fb1e201da6915900cd9b24d596/
> The EGL functionality test failed!
> EGL is required for OpenGL ES to manage contexts & surfaces.
> You might need to modify the include and library search paths by editing
> QMAKE_INCDIR_EGL, QMAKE_LIBDIR_EGL and QMAKE_LIBS_EGL in
> /scratch/peko/build/qt-4.8.5/mkspecs/qws/linux-arm-g++.
> make: *** [/scratch/peko/build/qt-4.8.5/.stamp_configured] Error 1
> OpenGL implementation is the RPi one.
I'm taking a look.
>> arm | zeromq-3.2.4 | NOK | http://autobuild.buildroot.net/results/7cf107566da47670bc8ef6d16c5e1bb7bcccef3e/
> Build machine issue?
I think so too.
> CXX libzmq_la-encoder.lo
> /scratch/peko/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.7.3/cc1plus: error while loading shared libraries: libc.so.6: failed to map segment from shared object: Cannot allocate memory
> make[3]: *** [libzmq_la-decoder.lo] Error 1
> make[3]: *** Waiting for unfinished jobs....
I don't recall it triggering before atleast.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-29 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2013-11-28 Thomas Petazzoni
@ 2013-11-29 8:51 ` Thomas Petazzoni
2013-11-29 9:00 ` Peter Korsgaard
2013-11-29 10:04 ` Gustavo Zacarias
0 siblings, 2 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2013-11-29 8:51 UTC (permalink / raw)
To: buildroot
Hello,
This is probably the last day (or last two days) to fix more
autobuilder failures.
On Fri, 29 Nov 2013 08:30:03 +0100 (CET), Thomas Petazzoni wrote:
> bfin | alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/637e19310ab85c1982319a0f60e9f5643fc3ff1e/
alsa-lib need dynamic library loading, this is being handled by the
Blackfin people, if I remember correctly.
> arm | bluez_utils-4.101 | NOK | http://autobuild.buildroot.net/results/260cac5c54e03224fe90f4c5828b97748903eb10/
Not sure what's going on here:
/home/test/test/1/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libc.a(jmp-unwind.os): In function `_longjmp_unwind':
jmp-unwind.c:(.text+0x24): dangerous relocation: unsupported relocation
collect2: ld returned 1 exit status
> sh4 | cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/a1ac6bb5d6f38c37c18df5ede67abd562b004073/
Don't know:
In file included from cairo-xlib-private.h:41:0,
from cairo-xlib-display.c:40:
cairo-xlib-xrender-private.h:102:16: error: redefinition of 'struct _XLinearGradient'
In file included from cairo-xlib-xrender.h:45:0,
from cairo-xlib-xrender-private.h:53,
from cairo-xlib-private.h:41,
from cairo-xlib-display.c:40:
/home/test/test/1/output/host/usr/sh4-buildroot-linux-uclibc/sysroot/usr/include/X11/extensions/Xrender.h:186:16: note: originally defined here
In file included from cairo-xlib-private.h:41:0,
from cairo-xlib-display.c:40:
cairo-xlib-xrender-private.h:105:3: error: conflicting types for 'XLinearGradient'
> bfin | directfb-1.6.3 | NOK | http://autobuild.buildroot.net/results/8aa814b0eab38809b5614578f18359588db78ffa/
DirectFB using the dynamic library loader. I had a quick look at that
one yesterday, and it seems like DirectFB has some conditionals to not
use dynamic library loading when not available, but it doesn't seem to
work completely:
In file included from ../../../../../lib/direct/os/types.h:43,
from ../../../../../lib/direct/os/clock.h:32,
from ../../../../../lib/direct/clock.h:32,
from clock.c:34:
../../../../../lib/direct/os/linux/glibc/types.h:110:19: error: dlfcn.h: No such file or directory
> bfin | dtc-e4b497f367a3b2ae99cc520... | NOK | http://autobuild.buildroot.net/results/5b6dd72f2599ef073a834359326af36350d9c09b/
libfdt cannot build as a static library, I believe.
> bfin | hostapd-2.0 | NOK | http://autobuild.buildroot.net/results/d4a9f44effeb08eda6c4b32764274ae81d185d5e/
Missing pthread in the link command line?
/home/test/test/1/output/host/usr/bfin-buildroot-uclinux-uclibc/sysroot/usr/lib/libnl-3.a(cache_mngt.o): In function `_nl_cache_mngt_unprovide':
cache_mngt.c:(.text+0x6e): undefined reference to `_pthread_rwlock_wrlock'
cache_mngt.c:(.text+0x10a): undefined reference to `_pthread_rwlock_unlock'
> avr32 | libev-4.11 | NOK | http://autobuild.buildroot.net/results/38704a4362ab6c3458c45603975b274937059fa9/
Simon has already sent a fix for that one: missing propagation of libev
architecture dependencies.
> arm | libevas-1.7.7 | NOK | http://autobuild.buildroot.net/results/15cfb974e428b20ba230321cd8b59a82308785af/
This one is already being discussed on the list, and has been reported
upstream I believe:
CC evas_cache2.lo
evas_cache2.c: In function '_evas_cache_image_entry_delete':
evas_cache2.c:176:17: error: 'Image_Entry_Flags' has no member named 'delete_me'
evas_cache2.c:181:18: error: 'Image_Entry_Flags' has no member named 'delete_me'
evas_cache2.c: In function '_evas_cache2_image_preloaded_cb':
evas_cache2.c:296:13: error: 'Image_Entry_Flags' has no member named 'preload_done'
evas_cache2.c:303:23: error: 'Image_Entry_Flags' has no member named 'delete_me'
evas_cache2.c:308:17: error: 'Image_Entry_Flags' has no member named 'delete_me'
evas_cache2.c: In function '_evas_cache2_image_entry_preload_add':
evas_cache2.c:317:17: error: 'Image_Entry_Flags' has no member named 'preload_done'
make[5]: *** [evas_cache2.lo] Error 1
> xtensa | libnspr-4.9.6 | NOK | http://autobuild.buildroot.net/results/250339438786d77e757759c7da76df944d8fd560/
Fixed by http://git.buildroot.net/buildroot/commit/?id=354cab0ee8c7c7813d7c7d69d5a699f234443c0b.
> arm | libnspr-4.9.6 | NOK | http://autobuild.buildroot.net/results/b4b69cb385551b912894b8b81c8d9e8d689c75fe/
That's a Thumb2/sysroot issue I have investigated already, I have some
ideas to fix it, but it's not that simple.
> xtensa | libnspr-4.9.6 | NOK | http://autobuild.buildroot.net/results/165b1c2f96c60f88890e6e7d85f7b5875f0cb788/
Same as before, fixed by
http://git.buildroot.net/buildroot/commit/?id=354cab0ee8c7c7813d7c7d69d5a699f234443c0b.
> avr32 | libpfm4-4.3.0 | NOK | http://autobuild.buildroot.net/results/a4a1d1f936d8414acb297c7619e224b9f05d6c36/
> avr32 | libpfm4-4.3.0 | NOK | http://autobuild.buildroot.net/results/38fa81315be448c409b9af29f92621fcf5676f71/
Missing syscalls. Probably we want to disable libpfm4 on AVR32,
especially since it's only used to build OProfile on PowerPC.
> nios2 | mplayer-1.1.1 | NOK | http://autobuild.buildroot.net/results/0ae3a53a1a6e870ee1bf2a902a400893339777df/
Fixed by http://git.buildroot.net/buildroot/commit/?id=9402eef6e24b51da750f0852e16cd92ffc65f2a7.
> microblaze | openssl-1.0.1e | NOK | http://autobuild.buildroot.net/results/e0ef522ac074f6f5601d23d380aa94489ca1f4ef/
Will be fixed after the release by bumping the compiler.
> arm | qt-4.8.5 | NOK | http://autobuild.buildroot.net/results/efe26c54361094fb1e201da6915900cd9b24d596/
The EGL functionality test failed!
EGL is required for OpenGL ES to manage contexts & surfaces.
You might need to modify the include and library search paths by editing
QMAKE_INCDIR_EGL, QMAKE_LIBDIR_EGL and QMAKE_LIBS_EGL in
/scratch/peko/build/qt-4.8.5/mkspecs/qws/linux-arm-g++.
make: *** [/scratch/peko/build/qt-4.8.5/.stamp_configured] Error 1
OpenGL implementation is the RPi one.
> arm | qt5declarative-5.1.1 | NOK | http://autobuild.buildroot.net/results/c30a078c646af0839039fa71e0bd1d7114970b0b/
The locale issue, with the weird usage of target headers when building
host tools.
> arc | ruby-1.9.3-p484 | NOK | http://autobuild.buildroot.net/results/a1fd72919035a6dc38c68831c899cf3464fa2cc7/
Compiler issue, will be fixed after the release by bumping the compiler.
> mips64el | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/1895d54e75cd7864ed4adf17b9ce6f09589738cc/
> arm | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/36c4148cc9649c44057b2d0b2b0168692ef530ea/
> aarch64 | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/d34c7429f60a28f4b2dc7ce1783ce2a6a36fe4cd/
Autobuilder scripts issue, please ignore.
> bfin | xlib_libX11-1.5.0 | NOK | http://autobuild.buildroot.net/results/d5f6e444f630a2ba612fb234496872a1e2e714a4/
CrGlCur.c:43:19: error: dlfcn.h: No such file or directory
CrGlCur.c: In function 'open_library':
CrGlCur.c:74: warning: implicit declaration of function 'dlopen'
CrGlCur.c:74: warning: nested extern declaration of 'dlopen'
CrGlCur.c:74: error: 'RTLD_LAZY' undeclared (first use in this function)
CrGlCur.c:74: error: (Each undeclared identifier is reported only once
CrGlCur.c:74: error: for each function it appears in.)
> arm | zeromq-3.2.4 | NOK | http://autobuild.buildroot.net/results/7cf107566da47670bc8ef6d16c5e1bb7bcccef3e/
Build machine issue?
CXX libzmq_la-encoder.lo
/scratch/peko/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.7.3/cc1plus: error while loading shared libraries: libc.so.6: failed to map segment from shared object: Cannot allocate memory
make[3]: *** [libzmq_la-decoder.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
Is that reproducible?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-22 12:13 ` Thomas Petazzoni
@ 2013-11-23 23:07 ` Arnout Vandecappelle
0 siblings, 0 replies; 416+ messages in thread
From: Arnout Vandecappelle @ 2013-11-23 23:07 UTC (permalink / raw)
To: buildroot
On 22/11/13 13:13, Thomas Petazzoni wrote:
> Dear Fatih A??c?,
>
> On Fri, 22 Nov 2013 13:58:29 +0200, Fatih A??c? wrote:
>> On Friday 22 November 2013 10:14:11 Thomas Petazzoni wrote:
>>>> arm | qt5declarative-5.1.1 | NOK |
>>>> http://autobuild.buildroot.net/results/82bb89d5b29dc6bd40f840bc04845b6c87
>>>> 157985/
>>>
>>> Weird thing. It's having problems when building things for the host...
>>> but it uses target headers when building for the host. Someone needs to
>>> look closely into this. Fatih ? :-)
>>
>> All those headers belong to Qt. Qt does not install headers into host prefix.
>> This might be intentional. It doesn't sound like a problem to me.
>
> It does to me. Headers correspond to libraries. And therefore, headers
> installed in $(STAGING_DIR) match libraries installed in
> $(STAGING_DIR), and so built for the target. Including headers from
> $(STAGING_DIR) to build native tools seems wrong.
And just to prove that point: when the staging dir is removed from the
include path, that file compiles fine. That is, after symlinking the
QtCore directory to somewhere else in the include path, otherwise the Qt
includes can't be found. Another solution is to replace the -I with
-idirafter, so the system includes come first.
The reason that the staging dir has to be included is because that's
the only place where you can find the core Qt libraries.
The funny thing is that Qt is smart enough to link with the libraries
in host/usr/lib and install the executables in host/usr/bin...
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-22 16:01 ` Arnout Vandecappelle
@ 2013-11-22 16:03 ` Thomas De Schampheleire
0 siblings, 0 replies; 416+ messages in thread
From: Thomas De Schampheleire @ 2013-11-22 16:03 UTC (permalink / raw)
To: buildroot
On Fri, Nov 22, 2013 at 5:01 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 22/11/13 13:59, Thomas De Schampheleire wrote:
>>
>> Hi,
>>
>> On Fri, Nov 22, 2013 at 11:42 AM, Thomas De Schampheleire
>> <patrickdepinguin@gmail.com> wrote:
>>>
>>> Hi Thomas,
>>>
>>> Thanks for the analysis!
>>>
>>> On Fri, Nov 22, 2013 at 9:14 AM, Thomas Petazzoni
>>> <thomas.petazzoni@free-electrons.com> wrote:
>>> [..]
>>>>>
>>>>> mips64el | rpm-5.2.0 | NOK |
>>>>> http://autobuild.buildroot.net/results/bcff4b81bfbb1191f97317b0945c74d948c9774b/
>>>>
>>>>
>>>> checking whether to build with BeeCrypt library... no
>>>> configure: error: mandatory BeeCrypt library not found
>>>> make: *** [/home/test/test/3/output/build/rpm-5.2.0/.stamp_configured]
>>>> Error 1
>>>>
>>>> rpm has a dependency on beecrypt, so normally it should have been built
>>>> before. Seems like rpm isn't "seeing" that beecrypt is around :-)
>>>
>>>
>>> I will look into this...
>>
>>
>> The problem is that rpm uses beecrypt, and beecrypt depends on openmp
>> (libgomp), but the test in rpm does not include -lgomp.
>>
>> I found a few references to this problem in older threads:
>> http://lists.busybox.net/pipermail/buildroot/2012-October/059839.html
>> http://lists.busybox.net/pipermail/buildroot/2012-November/061560.html
>>
>> From these threads, there is a suggestion to disable openmp in
>> beecrypt (from you, ThomasP, actually). I haven't tried it yet, but it
>> sounds like this would solve the above autobuild problem.
>>
>> Any input on this?
>
>
> I completely agree with the idea. Should be a matter of adding
> --disable-openmp to BEECRYPT_CONF_OPT.
>
I tried that and it works fine.
However, in the mean time Vicente sent another proposal (see other
thread), but I conclude from the threads above that it is not the
right patch...
Best regards,
Thomas
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-22 12:59 ` Thomas De Schampheleire
@ 2013-11-22 16:01 ` Arnout Vandecappelle
2013-11-22 16:03 ` Thomas De Schampheleire
0 siblings, 1 reply; 416+ messages in thread
From: Arnout Vandecappelle @ 2013-11-22 16:01 UTC (permalink / raw)
To: buildroot
On 22/11/13 13:59, Thomas De Schampheleire wrote:
> Hi,
>
> On Fri, Nov 22, 2013 at 11:42 AM, Thomas De Schampheleire
> <patrickdepinguin@gmail.com> wrote:
>> Hi Thomas,
>>
>> Thanks for the analysis!
>>
>> On Fri, Nov 22, 2013 at 9:14 AM, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com> wrote:
>> [..]
>>>> mips64el | rpm-5.2.0 | NOK | http://autobuild.buildroot.net/results/bcff4b81bfbb1191f97317b0945c74d948c9774b/
>>>
>>> checking whether to build with BeeCrypt library... no
>>> configure: error: mandatory BeeCrypt library not found
>>> make: *** [/home/test/test/3/output/build/rpm-5.2.0/.stamp_configured] Error 1
>>>
>>> rpm has a dependency on beecrypt, so normally it should have been built
>>> before. Seems like rpm isn't "seeing" that beecrypt is around :-)
>>
>> I will look into this...
>
> The problem is that rpm uses beecrypt, and beecrypt depends on openmp
> (libgomp), but the test in rpm does not include -lgomp.
>
> I found a few references to this problem in older threads:
> http://lists.busybox.net/pipermail/buildroot/2012-October/059839.html
> http://lists.busybox.net/pipermail/buildroot/2012-November/061560.html
>
> From these threads, there is a suggestion to disable openmp in
> beecrypt (from you, ThomasP, actually). I haven't tried it yet, but it
> sounds like this would solve the above autobuild problem.
>
> Any input on this?
I completely agree with the idea. Should be a matter of adding
--disable-openmp to BEECRYPT_CONF_OPT.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-22 8:14 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (3 preceding siblings ...)
2013-11-22 11:58 ` Fatih Aşıcı
@ 2013-11-22 15:20 ` Peter Korsgaard
4 siblings, 0 replies; 416+ messages in thread
From: Peter Korsgaard @ 2013-11-22 15:20 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> A patch has been sent by Thomas DS to make libglib and all its reverse
> dependencies not available on !MMU. I believe it's the good way to go
> for now, until we have a proper patch to make libglib2 usable on !MMU
> systems. Peter, can you merge http://patchwork.ozlabs.org/patch/292839/ ?
Done.
>> avr32 | libroxml-2.2.3 | NOK | http://autobuild.buildroot.net/results/e22d94fca3eabb4e54d82af04319f17ad8e10c20/
> Simon Dawson has already sent a patch to fix this:
> http://patchwork.ozlabs.org/patch/293203/. Peter, can you merge this.
Done.
>> arm | libvncserver-0.9.9 | NOK | http://autobuild.buildroot.net/results/c3082693fe0da0c54d4bbf950dd6d74e1395c1d9/
> libvncserver needs thread support.
Ahh, I already tried fixing that in:
commit b6ee44b6d497f412b5b6c6223462a8a687c82af7
Author: Peter Korsgaard <peter@korsgaard.com>
Date: Wed Nov 13 09:07:41 2013 +0100
libvncserver: fix build without pthread
Fixes http://autobuild.buildroot.net/results/761/7618028d0781269d2f6f0a14d814da456f207475/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
But the openssl support in libvncclient apparently doesn't look at that
option. I'll take a closer look.
>> mips64el | qt-4.8.5 | NOK | http://autobuild.buildroot.net/results/fd7e7e53290f235b540ed5f3c784e2584fdb41e0/
> There is no support for mips64 in QtScript, which uses JavaScriptCore.
> Options are:
> * Disable the possibility of enabling QtScript on mips64el/mips64
> * Adapt the patch that was done for webkit-gtk to allow
> mips64el/mips64 usage: http://patches.openembedded.org/patch/51625/
The first approach seems simples/safest for 2013.11.
>> arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/1ec3664f28492bf3da53dcbe8ceeb165bce8df6d/
> Patch has been sent to fix this:
> http://patchwork.ozlabs.org/patch/293270/. To be applied.
Done.
>> mips64el | tinymembench-v0.2 | NOK | http://autobuild.buildroot.net/results/bab68bcf8714f215ac0b0c2546fa06608377fbb0/
> Fixed by http://patchwork.ozlabs.org/patch/293207/.
Done.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-22 10:42 ` Thomas De Schampheleire
@ 2013-11-22 12:59 ` Thomas De Schampheleire
2013-11-22 16:01 ` Arnout Vandecappelle
0 siblings, 1 reply; 416+ messages in thread
From: Thomas De Schampheleire @ 2013-11-22 12:59 UTC (permalink / raw)
To: buildroot
Hi,
On Fri, Nov 22, 2013 at 11:42 AM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> Hi Thomas,
>
> Thanks for the analysis!
>
> On Fri, Nov 22, 2013 at 9:14 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> [..]
>>> mips64el | rpm-5.2.0 | NOK | http://autobuild.buildroot.net/results/bcff4b81bfbb1191f97317b0945c74d948c9774b/
>>
>> checking whether to build with BeeCrypt library... no
>> configure: error: mandatory BeeCrypt library not found
>> make: *** [/home/test/test/3/output/build/rpm-5.2.0/.stamp_configured] Error 1
>>
>> rpm has a dependency on beecrypt, so normally it should have been built
>> before. Seems like rpm isn't "seeing" that beecrypt is around :-)
>
> I will look into this...
The problem is that rpm uses beecrypt, and beecrypt depends on openmp
(libgomp), but the test in rpm does not include -lgomp.
I found a few references to this problem in older threads:
http://lists.busybox.net/pipermail/buildroot/2012-October/059839.html
http://lists.busybox.net/pipermail/buildroot/2012-November/061560.html
From these threads, there is a suggestion to disable openmp in
beecrypt (from you, ThomasP, actually). I haven't tried it yet, but it
sounds like this would solve the above autobuild problem.
Any input on this?
Thanks,
Thomas
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-22 11:58 ` Fatih Aşıcı
@ 2013-11-22 12:13 ` Thomas Petazzoni
2013-11-23 23:07 ` Arnout Vandecappelle
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2013-11-22 12:13 UTC (permalink / raw)
To: buildroot
Dear Fatih A??c?,
On Fri, 22 Nov 2013 13:58:29 +0200, Fatih A??c? wrote:
> On Friday 22 November 2013 10:14:11 Thomas Petazzoni wrote:
> > > arm | qt5declarative-5.1.1 | NOK |
> > >http://autobuild.buildroot.net/results/82bb89d5b29dc6bd40f840bc04845b6c87
> > >157985/
> >
> > Weird thing. It's having problems when building things for the host...
> > but it uses target headers when building for the host. Someone needs to
> > look closely into this. Fatih ? :-)
>
> All those headers belong to Qt. Qt does not install headers into host prefix.
> This might be intentional. It doesn't sound like a problem to me.
It does to me. Headers correspond to libraries. And therefore, headers
installed in $(STAGING_DIR) match libraries installed in
$(STAGING_DIR), and so built for the target. Including headers from
$(STAGING_DIR) to build native tools seems wrong.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-22 8:14 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (2 preceding siblings ...)
2013-11-22 11:56 ` Thomas Petazzoni
@ 2013-11-22 11:58 ` Fatih Aşıcı
2013-11-22 12:13 ` Thomas Petazzoni
2013-11-22 15:20 ` Peter Korsgaard
4 siblings, 1 reply; 416+ messages in thread
From: Fatih Aşıcı @ 2013-11-22 11:58 UTC (permalink / raw)
To: buildroot
On Friday 22 November 2013 10:14:11 Thomas Petazzoni wrote:
> > arm | qt5declarative-5.1.1 | NOK |
> >http://autobuild.buildroot.net/results/82bb89d5b29dc6bd40f840bc04845b6c87
> >157985/
>
> Weird thing. It's having problems when building things for the host...
> but it uses target headers when building for the host. Someone needs to
> look closely into this. Fatih ? :-)
All those headers belong to Qt. Qt does not install headers into host prefix.
This might be intentional. It doesn't sound like a problem to me.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-22 8:14 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2013-11-22 9:15 ` Fabio Porcedda
2013-11-22 10:42 ` Thomas De Schampheleire
@ 2013-11-22 11:56 ` Thomas Petazzoni
2013-11-22 11:58 ` Fatih Aşıcı
2013-11-22 15:20 ` Peter Korsgaard
4 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2013-11-22 11:56 UTC (permalink / raw)
To: buildroot
Dear Thomas Petazzoni,
On Fri, 22 Nov 2013 09:14:11 +0100, Thomas Petazzoni wrote:
> On Fri, 22 Nov 2013 08:30:02 +0100 (CET), Thomas Petazzoni wrote:
>
> > mipsel | alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/417dac44eb077079f16a039881a45fa1b1782497/
> > mipsel | apr-1.4.8 | NOK | http://autobuild.buildroot.net/results/20926ed11e7d86cd6c54700eb609b3fa1740b8a7/
> > mipsel | attr-2.4.47 | NOK | http://autobuild.buildroot.net/results/03e5b85c71e5b624e42245f04d305042ec9136fa/
> > mipsel | bootutils-1.0.0 | NOK | http://autobuild.buildroot.net/results/a51b3723f176a98abff809313a5f863e2539e103/
>
> Those four ones are the same:
>
> configure: error: C compiler cannot create executables
>
> probably a toolchain configuration problem, I need to look into this.
Caused by the deprecation of mips 1, 2, 3 and 4. The toolchain used was
built for mips4, so when linked against code for mips32, it doesn't
work (because apparently, mips32 code isn't compatible with mips4 code).
So I've started rebuilding the set of toolchains on top of 2013.11-rc2,
by replacing the mips4 toolchain by a mips32 toolchain.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-22 8:14 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2013-11-22 9:15 ` Fabio Porcedda
@ 2013-11-22 10:42 ` Thomas De Schampheleire
2013-11-22 12:59 ` Thomas De Schampheleire
2013-11-22 11:56 ` Thomas Petazzoni
` (2 subsequent siblings)
4 siblings, 1 reply; 416+ messages in thread
From: Thomas De Schampheleire @ 2013-11-22 10:42 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Thanks for the analysis!
On Fri, Nov 22, 2013 at 9:14 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
[..]
>> mips64el | rpm-5.2.0 | NOK | http://autobuild.buildroot.net/results/bcff4b81bfbb1191f97317b0945c74d948c9774b/
>
> checking whether to build with BeeCrypt library... no
> configure: error: mandatory BeeCrypt library not found
> make: *** [/home/test/test/3/output/build/rpm-5.2.0/.stamp_configured] Error 1
>
> rpm has a dependency on beecrypt, so normally it should have been built
> before. Seems like rpm isn't "seeing" that beecrypt is around :-)
I will look into this...
Best regards,
Thomas
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-22 8:14 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2013-11-22 9:15 ` Fabio Porcedda
2013-11-29 10:25 ` Fabio Porcedda
2013-11-22 10:42 ` Thomas De Schampheleire
` (3 subsequent siblings)
4 siblings, 1 reply; 416+ messages in thread
From: Fabio Porcedda @ 2013-11-22 9:15 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Fri, Nov 22, 2013 at 9:14 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Fri, 22 Nov 2013 08:30:02 +0100 (CET), Thomas Petazzoni wrote:
> ...
>> arm | lvm2-2.02.103 | NOK | http://autobuild.buildroot.net/results/b0b386969459dda9c294f1ccb4927ca225fa6bdd/
>
> Missing dependency?
>
> /home/test/test/1/output/host/usr/bin/arm-linux-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pipe -Os -fPIC -O2 --static -O2 -L../libdm -L../lib -L../libdaemon/client -L../libdm \
> -o dmsetup dmsetup.o -ldevmapper
> /home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.7.3/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: cannot find -ldevmapper
>
> ...
I will try to look into this.
Best regards
--
Fabio Porcedda
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-22 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2013-11-21 Thomas Petazzoni
@ 2013-11-22 8:14 ` Thomas Petazzoni
2013-11-22 9:15 ` Fabio Porcedda
` (4 more replies)
0 siblings, 5 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2013-11-22 8:14 UTC (permalink / raw)
To: buildroot
Hello,
On Fri, 22 Nov 2013 08:30:02 +0100 (CET), Thomas Petazzoni wrote:
> mipsel | alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/417dac44eb077079f16a039881a45fa1b1782497/
> mipsel | apr-1.4.8 | NOK | http://autobuild.buildroot.net/results/20926ed11e7d86cd6c54700eb609b3fa1740b8a7/
> mipsel | attr-2.4.47 | NOK | http://autobuild.buildroot.net/results/03e5b85c71e5b624e42245f04d305042ec9136fa/
> mipsel | bootutils-1.0.0 | NOK | http://autobuild.buildroot.net/results/a51b3723f176a98abff809313a5f863e2539e103/
Those four ones are the same:
configure: error: C compiler cannot create executables
probably a toolchain configuration problem, I need to look into this.
> bfin | icu-51.2 | NOK | http://autobuild.buildroot.net/results/fc643356587aaed0c3e7c2205dad0c40f02eede1/
I believe the problem here is that Blackfin needs a "_" to be prefixed
on assembly symbols, compared to the corresponding C symbol.
> xtensa | iozone-3_414 | NOK | http://autobuild.buildroot.net/results/04896be35649215d8141cb737185c0c10ad11d12/
iozone_linux-noaio.o:(.literal+0xfec): undefined reference to `pthread_setaffinity_np'
> xtensa | kmod-15 | NOK | http://autobuild.buildroot.net/results/622d25321d76f505de6aef4e33d0e421ba701de5/
/home/test/test/2/output/host/usr/lib/gcc/xtensa-buildroot-linux-uclibc/4.7.3/../../../../xtensa-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.22 internal error, aborting at elf32-xtensa.c line 3374 in elf_xtensa_finish_dynamic_sections
-> seems like an update to Xtensa binutils is needed.
> avr32 | libcap-ng-0.7.3 | NOK | http://autobuild.buildroot.net/results/73c7c211a51c312bbe4eb6a540f3ad9c92c79ebe/
TLS not available on AVR32, discussion on-going on how to solve this.
> microblaze | libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/2cd1b11c43655cfd3bcbe8f6e127ea5e4a607e9d/
> microblaze | libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/bcbc99ec7987fe10d4e752eb96840a7ec1be2744/
Missing compiler intrinsics. There are patches from Spenser to add
internal toolchain support for Microblaze, so that we can remove the
broken external toolchains.
> bfin | libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/d5c743294314584473cdd6098ebcfae42971803c/
A patch has been sent by Thomas DS to make libglib and all its reverse
dependencies not available on !MMU. I believe it's the good way to go
for now, until we have a proper patch to make libglib2 usable on !MMU
systems. Peter, can you merge http://patchwork.ozlabs.org/patch/292839/ ?
> avr32 | libroxml-2.2.3 | NOK | http://autobuild.buildroot.net/results/e22d94fca3eabb4e54d82af04319f17ad8e10c20/
Simon Dawson has already sent a patch to fix this:
http://patchwork.ozlabs.org/patch/293203/. Peter, can you merge this.
> arm | libvncserver-0.9.9 | NOK | http://autobuild.buildroot.net/results/c3082693fe0da0c54d4bbf950dd6d74e1395c1d9/
libvncserver needs thread support.
> arm | lvm2-2.02.103 | NOK | http://autobuild.buildroot.net/results/b0b386969459dda9c294f1ccb4927ca225fa6bdd/
Missing dependency?
/home/test/test/1/output/host/usr/bin/arm-linux-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pipe -Os -fPIC -O2 --static -O2 -L../libdm -L../lib -L../libdaemon/client -L../libdm \
-o dmsetup dmsetup.o -ldevmapper
/home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.7.3/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: cannot find -ldevmapper
> bfin | mdadm-3.2.6 | NOK | http://autobuild.buildroot.net/results/52cc56df2aa278d92141918de74833d7e4fd3d47/
Needs MMU. Gustavo has sent a patch,
http://patchwork.ozlabs.org/patch/293083/.
> aarch64 | ola-0.8.32 | NOK | http://autobuild.buildroot.net/results/5967dfd4bd7c2b68e2911a98b9b84c8fe7adf0aa/
I've sent two patches to fix this:
http://patchwork.ozlabs.org/patch/293258/ and
http://patchwork.ozlabs.org/patch/293259/.
> arm | omniorb-4.1.6 | NOK | http://autobuild.buildroot.net/results/dfc083bff04eba68456edd359424293842b6f42d/
Thread support needed, patch at
http://patchwork.ozlabs.org/patch/293205/.
> microblaze | openssl-1.0.1e | NOK | http://autobuild.buildroot.net/results/2299063bb4e84833ee3edccec960d551b5fcdfe5/
Needs the internal toolchain backend support for Microblaze.
> mips64el | qt-4.8.5 | NOK | http://autobuild.buildroot.net/results/fd7e7e53290f235b540ed5f3c784e2584fdb41e0/
There is no support for mips64 in QtScript, which uses JavaScriptCore.
Options are:
* Disable the possibility of enabling QtScript on mips64el/mips64
* Adapt the patch that was done for webkit-gtk to allow
mips64el/mips64 usage: http://patches.openembedded.org/patch/51625/
> arm | qt5declarative-5.1.1 | NOK | http://autobuild.buildroot.net/results/82bb89d5b29dc6bd40f840bc04845b6c87157985/
Weird thing. It's having problems when building things for the host...
but it uses target headers when building for the host. Someone needs to
look closely into this. Fatih ? :-)
> mips64el | rpm-5.2.0 | NOK | http://autobuild.buildroot.net/results/bcff4b81bfbb1191f97317b0945c74d948c9774b/
checking whether to build with BeeCrypt library... no
configure: error: mandatory BeeCrypt library not found
make: *** [/home/test/test/3/output/build/rpm-5.2.0/.stamp_configured] Error 1
rpm has a dependency on beecrypt, so normally it should have been built
before. Seems like rpm isn't "seeing" that beecrypt is around :-)
> arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/1ec3664f28492bf3da53dcbe8ceeb165bce8df6d/
Patch has been sent to fix this:
http://patchwork.ozlabs.org/patch/293270/. To be applied.
> arm | sdl_ttf-2.0.11 | NOK | http://autobuild.buildroot.net/results/f4ad0468f17520a645f029878876a972421a87b4/
OpenGL/libraries problem.
linux-gnueabi/sysroot/usr/lib
/home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.3/../../../../arm-none-linux-gnueabi/bin/ld: warning: libXdamage.so.1, needed by /home/test/test/2/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGL.so, not found (try using -rpath or -rpath-link)
/home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.3/../../../../arm-none-linux-gnueabi/bin/ld: warning: libXfixes.so.3, needed by /home/test/test/2/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGL.so, not found (try using -rpath or -rpath-link)
/home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.3/../../../../arm-none-linux-gnueabi/bin/ld: warning: libXext.so.6, needed by /home/test/test/2/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGL.so, not found (try using -rpath or -rpath-link)
/home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.3/../../../../arm-none-linux-gnueabi/bin/ld: warning: libX11.so.6, needed by /home/test/test/2/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib/libGL.so, not found (try using -rpath or -rpath-link)
> arc | sqlite-3080002 | NOK | http://autobuild.buildroot.net/results/4f09bbb3cf646e7e45c86d43a50b440245e136e2/
ARC compiler problem. Fixed by the bump of the toolchain components for
ARC (patches already submitted by Mischa).
> mips64el | tinymembench-v0.2 | NOK | http://autobuild.buildroot.net/results/bab68bcf8714f215ac0b0c2546fa06608377fbb0/
Fixed by http://patchwork.ozlabs.org/patch/293207/.
> powerpc | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/8fb291915b3ce5dc955f5e7e60eea2a4a6202143/
> arm | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/cc4c41b99005c82e546a9e2916df97180be32b2b/
These are autobuilder script issues. Don't take them into account (even
though I indeed need to find a solution for these).
> powerpc | w_scan-20130331 | NOK | http://autobuild.buildroot.net/results/7ac90c6087640585a9afb0e31ad9e690eded89f5/
Too old kernel headers, but the toolchain is the latest PowerPC
toolchain from CodeSourcery.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-11 10:09 ` Thomas Petazzoni
@ 2013-11-11 12:26 ` Fatih Aşıcı
2013-11-11 9:30 ` Gustavo Zacarias
0 siblings, 1 reply; 416+ messages in thread
From: Fatih Aşıcı @ 2013-11-11 12:26 UTC (permalink / raw)
To: buildroot
On Monday 11 November 2013 12:09:06 Thomas Petazzoni wrote:
> Dear Fatih A??c?,
>
> On Mon, 11 Nov 2013 11:14:51 +0200, Fatih A??c? wrote:
> > > http://autobuild.buildroot.net/results/555278227680e90737e6dbe0a6dcc0
> > > 35507150aa/build-end.log (sqlite problem)
> >
> > Needs posix_fallocate() which is not available in the test toolchain.
>
> Except that posix_fallocate() is not available in uClibc. It is indeed
> available in the internal toolchain backend, due to a patch that we
> have added, but we cannot assume it will be available in external
> uClibc toolchains that may not have the same of patches applied.
>
> Moreover, the sqlite3.c code in Qt seems to have some code to handle
> the absence of posix_fallocate():
>
> #if defined(HAVE_POSIX_FALLOCATE) && HAVE_POSIX_FALLOCATE
> { "fallocate", (sqlite3_syscall_ptr)posix_fallocate, 0 },
> #else
> { "fallocate", (sqlite3_syscall_ptr)0, 0 },
> #endif
>
> It would be nice to have a look at why HAVE_POSIX_FALLOCATE is defined
> even though posix_fallocate() is not available.
Probably the following change will fix it:
--- a/src/3rdparty/sqlite/sqlite3.c
+++ b/src/3rdparty/sqlite/sqlite3.c
@@ -22938,7 +22938,8 @@ SQLITE_PRIVATE const char *sqlite3OpcodeName(int i){
/* Use posix_fallocate() if it is available
*/
#if !defined(HAVE_POSIX_FALLOCATE) \
- && (_XOPEN_SOURCE >= 600 || _POSIX_C_SOURCE >= 200112L)
+ && (_XOPEN_SOURCE >= 600 || _POSIX_C_SOURCE >= 200112L) \
+ && !defined(__UCLIBC__)
# define HAVE_POSIX_FALLOCATE 1
#endif
sqlite3's own build system (which is not available in qt) checks if
posix_fallocate() is available. I wonder if there is a special reason for
providing an option to use the built-in sqlite.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-11 11:25 ` Ezequiel García
2013-11-11 11:27 ` Peter Korsgaard
@ 2013-11-11 11:45 ` Thomas Petazzoni
1 sibling, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2013-11-11 11:45 UTC (permalink / raw)
To: buildroot
Dear Ezequiel Garc?a,
On Mon, 11 Nov 2013 09:25:03 -0200, Ezequiel Garc?a wrote:
> On 9 November 2013 15:15, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>
> >
> >> nios2 | libnspr-4.9.6 | NOK | http://autobuild.buildroot.net/results/8c01fdaac7afa00bd1117c79ae047344242d1463/
> >> nios2 | libnspr-4.9.6 | NOK | http://autobuild.buildroot.net/results/a418145d72e92f64956518bb2786e33dadd08a86/
> >
> > NIOS2 support missing in libnspr. Ezequiel, can you look into this?
> > Normally, adding an architecture support in libnspr is really easy, so
> > adding a patch to libnspr should be feasible.
>
> Right. Would you accept a "builds-only" patch for it?
> I'm not familiar with libnspr and it seems it's only loosely used
> through libnss in BR.
I'm personally fine with that, especially since I don't believe the
patch is going to be really big or strange.
Maybe you can even submit the patch upstream? Upstream seems to be
active, latest release is from the end of september.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-11 11:25 ` Ezequiel García
@ 2013-11-11 11:27 ` Peter Korsgaard
2013-11-11 11:45 ` Thomas Petazzoni
1 sibling, 0 replies; 416+ messages in thread
From: Peter Korsgaard @ 2013-11-11 11:27 UTC (permalink / raw)
To: buildroot
>>>>> "Ezequiel" == Ezequiel Garc?a <ezequiel@vanguardiasur.com.ar> writes:
Hi,
>> NIOS2 support missing in libnspr. Ezequiel, can you look into this?
>> Normally, adding an architecture support in libnspr is really easy, so
>> adding a patch to libnspr should be feasible.
>>
> Right. Would you accept a "builds-only" patch for it?
> I'm not familiar with libnspr and it seems it's only loosely used
> through libnss in BR.
Yes. Even if you cannot do any runtime tests, it will most likely be OK
and is in any case a step forward compared to a build failure.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-09 18:15 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (7 preceding siblings ...)
2013-11-11 10:01 ` Will Newton
@ 2013-11-11 11:25 ` Ezequiel García
2013-11-11 11:27 ` Peter Korsgaard
2013-11-11 11:45 ` Thomas Petazzoni
8 siblings, 2 replies; 416+ messages in thread
From: Ezequiel García @ 2013-11-11 11:25 UTC (permalink / raw)
To: buildroot
Thomas,
On 9 November 2013 15:15, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
>> nios2 | libnspr-4.9.6 | NOK | http://autobuild.buildroot.net/results/8c01fdaac7afa00bd1117c79ae047344242d1463/
>> nios2 | libnspr-4.9.6 | NOK | http://autobuild.buildroot.net/results/a418145d72e92f64956518bb2786e33dadd08a86/
>
> NIOS2 support missing in libnspr. Ezequiel, can you look into this?
> Normally, adding an architecture support in libnspr is really easy, so
> adding a patch to libnspr should be feasible.
>
Right. Would you accept a "builds-only" patch for it?
I'm not familiar with libnspr and it seems it's only loosely used
through libnss in BR.
--
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-11 10:25 ` Will Newton
@ 2013-11-11 10:43 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2013-11-11 10:43 UTC (permalink / raw)
To: buildroot
Dear Will Newton,
On Mon, 11 Nov 2013 10:25:27 +0000, Will Newton wrote:
> Yes, Thumb-2. Only those crazy microcontroller guys care about Thumb-1. ;-)
>
> ARM ARM A8.8.203 is the relevant page, Thumb-2 cannot store pc/r15
> directly. It should be possible to use a temporary to achieve the same
> effect but it would need thorough testing.
So I guess we need to disable valgrind on Thumb-2, or make it build
with ARM instructions even on Thumb-2 builds. Or bump Valgrind and see
if the new version is fixed for Thumb-2.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-11 10:20 ` Baruch Siach
@ 2013-11-11 10:39 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2013-11-11 10:39 UTC (permalink / raw)
To: buildroot
Dear Baruch Siach,
On Mon, 11 Nov 2013 12:20:50 +0200, Baruch Siach wrote:
> > > Why do we need binutils on target?
> >
> > $ git grep "select BR2_PACKAGE_BINUTILS"
> > package/dropwatch/Config.in: select BR2_PACKAGE_BINUTILS
> > package/oprofile/Config.in: select BR2_PACKAGE_BINUTILS
> >
> > So we need it for dropwatch and oprofile. In fact, what is needed is
> > not the full binutils (i.e the binutils programs), but the libbfd
> > library which is part of the binutils tarball.
>
> This is strange. More than half of xtensa autobuilds used to fail on target
> binutils before Chris' obstack fix. Does this mean that all failing configs
> had dropwatch or oprofile enabled?
Or that they had BR2_PACKAGE_BINUTILS enabled itself. So I took my poor
SQL knowledge and came up with the following query to answer your
question:
select results.id,status,builddate,identifier,arch,reason,results_config.name,results_config.value
from results
inner join results_config on results.id=results_config.resultid
where
results.arch='xtensa' and
results.reason like 'binutils%' and
results.builddate >= '2013-10-01' and
(results_config.name='BR2_PACKAGE_BINUTILS' or results_config.name='BR2_PACKAGE_DROPWATCH' or results_config.name='BR2_PACKAGE_OPROFILE');
which gives the list of xtensa build results that failed on binutils,
since October 1st, and for each of those builds, give the value of the
binutils, dropwatch and oprofile options. So in the below table, you
have 3 consecutive lines for a given build, each of those 3 lines
corresponding to dropwatch,oprofile and binutils. As you can see, for
each of those builds, BR2_PACKAGE_BINUTILS was always set to 'y', and
sometimes either or both of oprofile and dropwatch were also enabled.
I kind of like the type of questions I can now answer by having the
full set of config options for each build part of the SQL database :-)
+-------+--------+---------------------+------------------------------------------+--------+-----------------+-----------------------+-------+
| id | status | builddate | identifier | arch | reason | name | value |
+-------+--------+---------------------+------------------------------------------+--------+-----------------+-----------------------+-------+
| 71059 | 1 | 2013-10-01 20:48:10 | 0cd166469449b2fa224277a1be6997af8ff2488d | xtensa | binutils-2.21.1 | BR2_PACKAGE_DROPWATCH | |
| 71059 | 1 | 2013-10-01 20:48:10 | 0cd166469449b2fa224277a1be6997af8ff2488d | xtensa | binutils-2.21.1 | BR2_PACKAGE_OPROFILE | y |
| 71059 | 1 | 2013-10-01 20:48:10 | 0cd166469449b2fa224277a1be6997af8ff2488d | xtensa | binutils-2.21.1 | BR2_PACKAGE_BINUTILS | y |
| 71076 | 1 | 2013-10-01 23:09:35 | 2cfd80795aa9c7556e572f8d344c4f512c80f232 | xtensa | binutils-2.21.1 | BR2_PACKAGE_DROPWATCH | |
| 71076 | 1 | 2013-10-01 23:09:35 | 2cfd80795aa9c7556e572f8d344c4f512c80f232 | xtensa | binutils-2.21.1 | BR2_PACKAGE_OPROFILE | y |
| 71076 | 1 | 2013-10-01 23:09:35 | 2cfd80795aa9c7556e572f8d344c4f512c80f232 | xtensa | binutils-2.21.1 | BR2_PACKAGE_BINUTILS | y |
| 71161 | 1 | 2013-10-02 19:13:40 | 8244788b518211947cd850e97ab80c43426a07a3 | xtensa | binutils-2.21.1 | BR2_PACKAGE_DROPWATCH | |
| 71161 | 1 | 2013-10-02 19:13:40 | 8244788b518211947cd850e97ab80c43426a07a3 | xtensa | binutils-2.21.1 | BR2_PACKAGE_OPROFILE | y |
| 71161 | 1 | 2013-10-02 19:13:40 | 8244788b518211947cd850e97ab80c43426a07a3 | xtensa | binutils-2.21.1 | BR2_PACKAGE_BINUTILS | y |
| 71218 | 1 | 2013-10-03 03:40:15 | 6c0cb311739fb0ea3b835c946090296bf3c8eb5f | xtensa | binutils-2.21.1 | BR2_PACKAGE_DROPWATCH | |
| 71218 | 1 | 2013-10-03 03:40:15 | 6c0cb311739fb0ea3b835c946090296bf3c8eb5f | xtensa | binutils-2.21.1 | BR2_PACKAGE_OPROFILE | y |
| 71218 | 1 | 2013-10-03 03:40:15 | 6c0cb311739fb0ea3b835c946090296bf3c8eb5f | xtensa | binutils-2.21.1 | BR2_PACKAGE_BINUTILS | y |
| 71494 | 1 | 2013-10-05 02:37:45 | cdd334ae490646c6367315668fff68feee03a4a2 | xtensa | binutils-2.21.1 | BR2_PACKAGE_DROPWATCH | y |
| 71494 | 1 | 2013-10-05 02:37:45 | cdd334ae490646c6367315668fff68feee03a4a2 | xtensa | binutils-2.21.1 | BR2_PACKAGE_OPROFILE | |
| 71494 | 1 | 2013-10-05 02:37:45 | cdd334ae490646c6367315668fff68feee03a4a2 | xtensa | binutils-2.21.1 | BR2_PACKAGE_BINUTILS | y |
| 71534 | 1 | 2013-10-05 10:12:54 | 9d6f624cd22fcf2cf113dfd3a3097c88f5e77612 | xtensa | binutils-2.21.1 | BR2_PACKAGE_DROPWATCH | |
| 71534 | 1 | 2013-10-05 10:12:54 | 9d6f624cd22fcf2cf113dfd3a3097c88f5e77612 | xtensa | binutils-2.21.1 | BR2_PACKAGE_OPROFILE | y |
| 71534 | 1 | 2013-10-05 10:12:54 | 9d6f624cd22fcf2cf113dfd3a3097c88f5e77612 | xtensa | binutils-2.21.1 | BR2_PACKAGE_BINUTILS | y |
| 71606 | 1 | 2013-10-05 20:32:09 | 436f1f897efb09bfc910b88b7396deaa9c67e158 | xtensa | binutils-2.21.1 | BR2_PACKAGE_DROPWATCH | y |
| 71606 | 1 | 2013-10-05 20:32:09 | 436f1f897efb09bfc910b88b7396deaa9c67e158 | xtensa | binutils-2.21.1 | BR2_PACKAGE_OPROFILE | |
| 71606 | 1 | 2013-10-05 20:32:09 | 436f1f897efb09bfc910b88b7396deaa9c67e158 | xtensa | binutils-2.21.1 | BR2_PACKAGE_BINUTILS | y |
| 71831 | 1 | 2013-10-07 16:06:10 | a6f8c67f60b13bab89c8bd2ca88d3407eead2b61 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 71831 | 1 | 2013-10-07 16:06:10 | a6f8c67f60b13bab89c8bd2ca88d3407eead2b61 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 71831 | 1 | 2013-10-07 16:06:10 | a6f8c67f60b13bab89c8bd2ca88d3407eead2b61 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 71926 | 1 | 2013-10-08 09:12:43 | b46524626cab681167253d68c45f0eed091a347c | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 71926 | 1 | 2013-10-08 09:12:43 | b46524626cab681167253d68c45f0eed091a347c | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 71926 | 1 | 2013-10-08 09:12:43 | b46524626cab681167253d68c45f0eed091a347c | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 72116 | 1 | 2013-10-09 14:52:26 | 98f65001a4a1dc1382630c232ffb43514f7482c5 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 72116 | 1 | 2013-10-09 14:52:26 | 98f65001a4a1dc1382630c232ffb43514f7482c5 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 72116 | 1 | 2013-10-09 14:52:26 | 98f65001a4a1dc1382630c232ffb43514f7482c5 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 72123 | 1 | 2013-10-09 15:40:15 | 45d1546b5dab74dc9e9a52d6c9ad1f3f2957eae4 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 72123 | 1 | 2013-10-09 15:40:15 | 45d1546b5dab74dc9e9a52d6c9ad1f3f2957eae4 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | y |
| 72123 | 1 | 2013-10-09 15:40:15 | 45d1546b5dab74dc9e9a52d6c9ad1f3f2957eae4 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 72140 | 1 | 2013-10-09 18:32:06 | d90aa26a8ac309694f5dbf3fc546f6d6c9af434c | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 72140 | 1 | 2013-10-09 18:32:06 | d90aa26a8ac309694f5dbf3fc546f6d6c9af434c | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 72140 | 1 | 2013-10-09 18:32:06 | d90aa26a8ac309694f5dbf3fc546f6d6c9af434c | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 72148 | 1 | 2013-10-09 19:15:32 | f31b2093399685498ee92873517bfa65ea366860 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | y |
| 72148 | 1 | 2013-10-09 19:15:32 | f31b2093399685498ee92873517bfa65ea366860 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 72148 | 1 | 2013-10-09 19:15:32 | f31b2093399685498ee92873517bfa65ea366860 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 72295 | 1 | 2013-10-10 21:50:50 | 38a1dea49373fd4f4da95621f716f8c9324e0d0c | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 72295 | 1 | 2013-10-10 21:50:50 | 38a1dea49373fd4f4da95621f716f8c9324e0d0c | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | y |
| 72295 | 1 | 2013-10-10 21:50:50 | 38a1dea49373fd4f4da95621f716f8c9324e0d0c | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 72404 | 1 | 2013-10-11 18:52:26 | 6d5754d10af24d8e9528878548be1d4f25a1f730 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 72404 | 1 | 2013-10-11 18:52:26 | 6d5754d10af24d8e9528878548be1d4f25a1f730 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 72404 | 1 | 2013-10-11 18:52:26 | 6d5754d10af24d8e9528878548be1d4f25a1f730 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 72540 | 1 | 2013-10-12 18:07:08 | bf8614dbfd930f0fd1678cf97da8cd125b0502c6 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 72540 | 1 | 2013-10-12 18:07:08 | bf8614dbfd930f0fd1678cf97da8cd125b0502c6 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | y |
| 72540 | 1 | 2013-10-12 18:07:08 | bf8614dbfd930f0fd1678cf97da8cd125b0502c6 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 72691 | 1 | 2013-10-13 19:50:44 | d3ce520b2ee273c7dde62ec8527ba9ac9ed11a9e | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | y |
| 72691 | 1 | 2013-10-13 19:50:44 | d3ce520b2ee273c7dde62ec8527ba9ac9ed11a9e | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | y |
| 72691 | 1 | 2013-10-13 19:50:44 | d3ce520b2ee273c7dde62ec8527ba9ac9ed11a9e | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 72889 | 1 | 2013-10-15 00:03:02 | 02c9b14ab7cd784fb09b9bc02ade6238b3761588 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 72889 | 1 | 2013-10-15 00:03:02 | 02c9b14ab7cd784fb09b9bc02ade6238b3761588 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | y |
| 72889 | 1 | 2013-10-15 00:03:02 | 02c9b14ab7cd784fb09b9bc02ade6238b3761588 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 72944 | 1 | 2013-10-15 12:30:11 | 8c20156bb4d8be909ae1367e1e8e043867d477ae | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | y |
| 72944 | 1 | 2013-10-15 12:30:11 | 8c20156bb4d8be909ae1367e1e8e043867d477ae | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 72944 | 1 | 2013-10-15 12:30:11 | 8c20156bb4d8be909ae1367e1e8e043867d477ae | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 72990 | 1 | 2013-10-15 18:36:49 | 1fa265c9cdda8c79cf3ccf9fa9ca6cfaff160bd8 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | y |
| 72990 | 1 | 2013-10-15 18:36:49 | 1fa265c9cdda8c79cf3ccf9fa9ca6cfaff160bd8 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 72990 | 1 | 2013-10-15 18:36:49 | 1fa265c9cdda8c79cf3ccf9fa9ca6cfaff160bd8 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 73068 | 1 | 2013-10-16 11:21:00 | 52b30beeec9af53dcaee98c1e6ab430b8328f7a3 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | y |
| 73068 | 1 | 2013-10-16 11:21:00 | 52b30beeec9af53dcaee98c1e6ab430b8328f7a3 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | y |
| 73068 | 1 | 2013-10-16 11:21:00 | 52b30beeec9af53dcaee98c1e6ab430b8328f7a3 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 73157 | 1 | 2013-10-16 21:39:23 | 3af486e2291d5f18ce6c22404a1f7e1e6d8546a1 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 73157 | 1 | 2013-10-16 21:39:23 | 3af486e2291d5f18ce6c22404a1f7e1e6d8546a1 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | y |
| 73157 | 1 | 2013-10-16 21:39:23 | 3af486e2291d5f18ce6c22404a1f7e1e6d8546a1 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 73248 | 1 | 2013-10-17 10:41:08 | cfbbae2f39385582fcd4dcf3d7a6f8d065208ff3 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 73248 | 1 | 2013-10-17 10:41:08 | cfbbae2f39385582fcd4dcf3d7a6f8d065208ff3 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | y |
| 73248 | 1 | 2013-10-17 10:41:08 | cfbbae2f39385582fcd4dcf3d7a6f8d065208ff3 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 73490 | 1 | 2013-10-18 20:35:00 | 63a8f4d34ef97a7ac1ec0fce4d6425827f4de5fd | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | y |
| 73490 | 1 | 2013-10-18 20:35:00 | 63a8f4d34ef97a7ac1ec0fce4d6425827f4de5fd | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 73490 | 1 | 2013-10-18 20:35:00 | 63a8f4d34ef97a7ac1ec0fce4d6425827f4de5fd | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 73566 | 1 | 2013-10-19 06:34:07 | df47ef18beab5ea00d880ef25922e688fe93ca88 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | y |
| 73566 | 1 | 2013-10-19 06:34:07 | df47ef18beab5ea00d880ef25922e688fe93ca88 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 73566 | 1 | 2013-10-19 06:34:07 | df47ef18beab5ea00d880ef25922e688fe93ca88 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 73697 | 1 | 2013-10-20 03:52:11 | 615495c9a3d55e2c3f46d3cc86678453ecd95ec6 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 73697 | 1 | 2013-10-20 03:52:11 | 615495c9a3d55e2c3f46d3cc86678453ecd95ec6 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | y |
| 73697 | 1 | 2013-10-20 03:52:11 | 615495c9a3d55e2c3f46d3cc86678453ecd95ec6 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 73732 | 1 | 2013-10-20 09:11:20 | 4a73f7380d493359ca1593a5c6a5cc8d11fb7cf7 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 73732 | 1 | 2013-10-20 09:11:20 | 4a73f7380d493359ca1593a5c6a5cc8d11fb7cf7 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 73732 | 1 | 2013-10-20 09:11:20 | 4a73f7380d493359ca1593a5c6a5cc8d11fb7cf7 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 73812 | 1 | 2013-10-20 21:59:28 | 1fefa8b4fc1dc22e3667b25b0d93d3f30424629f | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 73812 | 1 | 2013-10-20 21:59:28 | 1fefa8b4fc1dc22e3667b25b0d93d3f30424629f | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | y |
| 73812 | 1 | 2013-10-20 21:59:28 | 1fefa8b4fc1dc22e3667b25b0d93d3f30424629f | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 73979 | 1 | 2013-10-22 01:58:24 | 3318ee1e074b9e9fca9e2815e220313cc9a00021 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 73979 | 1 | 2013-10-22 01:58:24 | 3318ee1e074b9e9fca9e2815e220313cc9a00021 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | y |
| 73979 | 1 | 2013-10-22 01:58:24 | 3318ee1e074b9e9fca9e2815e220313cc9a00021 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 74121 | 1 | 2013-10-22 23:34:05 | c9581efea42eb4a6d14952d616ae2cf049c3ed47 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 74121 | 1 | 2013-10-22 23:34:05 | c9581efea42eb4a6d14952d616ae2cf049c3ed47 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 74121 | 1 | 2013-10-22 23:34:05 | c9581efea42eb4a6d14952d616ae2cf049c3ed47 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 74141 | 1 | 2013-10-23 04:03:55 | fdc5d439987d988cb14f58726443f2bb41d0b1cb | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | y |
| 74141 | 1 | 2013-10-23 04:03:55 | fdc5d439987d988cb14f58726443f2bb41d0b1cb | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 74141 | 1 | 2013-10-23 04:03:55 | fdc5d439987d988cb14f58726443f2bb41d0b1cb | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 74322 | 1 | 2013-10-24 13:02:54 | 7b0798f139e81b054e72c08cc16ff337bbe36a2b | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 74322 | 1 | 2013-10-24 13:02:54 | 7b0798f139e81b054e72c08cc16ff337bbe36a2b | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 74322 | 1 | 2013-10-24 13:02:54 | 7b0798f139e81b054e72c08cc16ff337bbe36a2b | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 74386 | 1 | 2013-10-24 22:30:39 | 7806239e9e9161f03d3e658dcf18090b21eb8e65 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 74386 | 1 | 2013-10-24 22:30:39 | 7806239e9e9161f03d3e658dcf18090b21eb8e65 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | y |
| 74386 | 1 | 2013-10-24 22:30:39 | 7806239e9e9161f03d3e658dcf18090b21eb8e65 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 74420 | 1 | 2013-10-25 06:19:41 | f3f9fedfc92b125fa2dbe10c5e3f72db3fdfb7a9 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | y |
| 74420 | 1 | 2013-10-25 06:19:41 | f3f9fedfc92b125fa2dbe10c5e3f72db3fdfb7a9 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | y |
| 74420 | 1 | 2013-10-25 06:19:41 | f3f9fedfc92b125fa2dbe10c5e3f72db3fdfb7a9 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 74424 | 1 | 2013-10-25 07:05:26 | 687a233c574de8c95ddb9187b8fdd72be0d07902 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 74424 | 1 | 2013-10-25 07:05:26 | 687a233c574de8c95ddb9187b8fdd72be0d07902 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 74424 | 1 | 2013-10-25 07:05:26 | 687a233c574de8c95ddb9187b8fdd72be0d07902 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 74469 | 1 | 2013-10-25 15:38:14 | d232d06b5ab9a7b1c5a4d76a79b3794cde8e2274 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 74469 | 1 | 2013-10-25 15:38:14 | d232d06b5ab9a7b1c5a4d76a79b3794cde8e2274 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | y |
| 74469 | 1 | 2013-10-25 15:38:14 | d232d06b5ab9a7b1c5a4d76a79b3794cde8e2274 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 74625 | 1 | 2013-10-26 21:12:23 | 9782922ab3fbda9471043d08efb88da1fcb1024a | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 74625 | 1 | 2013-10-26 21:12:23 | 9782922ab3fbda9471043d08efb88da1fcb1024a | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | y |
| 74625 | 1 | 2013-10-26 21:12:23 | 9782922ab3fbda9471043d08efb88da1fcb1024a | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 74984 | 1 | 2013-10-30 01:22:40 | 39ac33c0e325d5e8009337f0cfc83dc364e9c463 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | y |
| 74984 | 1 | 2013-10-30 01:22:40 | 39ac33c0e325d5e8009337f0cfc83dc364e9c463 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 74984 | 1 | 2013-10-30 01:22:40 | 39ac33c0e325d5e8009337f0cfc83dc364e9c463 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 75346 | 1 | 2013-11-01 19:16:34 | 6f209b4e3e6eade884eb37c5c761b42e83e3da74 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 75346 | 1 | 2013-11-01 19:16:34 | 6f209b4e3e6eade884eb37c5c761b42e83e3da74 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | y |
| 75346 | 1 | 2013-11-01 19:16:34 | 6f209b4e3e6eade884eb37c5c761b42e83e3da74 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 75411 | 1 | 2013-11-02 04:36:54 | d16d73a716ca0f3e6c16fe23ef748707495eb787 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | y |
| 75411 | 1 | 2013-11-02 04:36:54 | d16d73a716ca0f3e6c16fe23ef748707495eb787 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | y |
| 75411 | 1 | 2013-11-02 04:36:54 | d16d73a716ca0f3e6c16fe23ef748707495eb787 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 75489 | 1 | 2013-11-02 19:51:45 | 32b011100f96d3462d98b365591bf2422f4d3ec3 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 75489 | 1 | 2013-11-02 19:51:45 | 32b011100f96d3462d98b365591bf2422f4d3ec3 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | y |
| 75489 | 1 | 2013-11-02 19:51:45 | 32b011100f96d3462d98b365591bf2422f4d3ec3 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 75497 | 1 | 2013-11-02 21:18:31 | 3939930a693ab7f244ed81d295898fad15f60700 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | y |
| 75497 | 1 | 2013-11-02 21:18:31 | 3939930a693ab7f244ed81d295898fad15f60700 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 75497 | 1 | 2013-11-02 21:18:31 | 3939930a693ab7f244ed81d295898fad15f60700 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 75660 | 1 | 2013-11-03 23:41:57 | e514a5122b2524453dff8d5617be4b8de65c544c | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | y |
| 75660 | 1 | 2013-11-03 23:41:57 | e514a5122b2524453dff8d5617be4b8de65c544c | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 75660 | 1 | 2013-11-03 23:41:57 | e514a5122b2524453dff8d5617be4b8de65c544c | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 75689 | 1 | 2013-11-04 04:04:59 | 02796a47a03fc36ce1dfa476a6145be47f283a18 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 75689 | 1 | 2013-11-04 04:04:59 | 02796a47a03fc36ce1dfa476a6145be47f283a18 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 75689 | 1 | 2013-11-04 04:04:59 | 02796a47a03fc36ce1dfa476a6145be47f283a18 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 75704 | 1 | 2013-11-04 06:42:55 | f30943e20af19b5c7eba642febc8018c2a60a9fe | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 75704 | 1 | 2013-11-04 06:42:55 | f30943e20af19b5c7eba642febc8018c2a60a9fe | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | y |
| 75704 | 1 | 2013-11-04 06:42:55 | f30943e20af19b5c7eba642febc8018c2a60a9fe | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 75758 | 1 | 2013-11-04 16:29:13 | 7dafb56700cb86bd4c20e397cd6e6d568229be2d | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 75758 | 1 | 2013-11-04 16:29:13 | 7dafb56700cb86bd4c20e397cd6e6d568229be2d | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | y |
| 75758 | 1 | 2013-11-04 16:29:13 | 7dafb56700cb86bd4c20e397cd6e6d568229be2d | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 76035 | 1 | 2013-11-07 01:02:15 | 1bb18ff3037e5b73e7b504e14bfd396d42917c5b | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | y |
| 76035 | 1 | 2013-11-07 01:02:15 | 1bb18ff3037e5b73e7b504e14bfd396d42917c5b | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 76035 | 1 | 2013-11-07 01:02:15 | 1bb18ff3037e5b73e7b504e14bfd396d42917c5b | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 76084 | 1 | 2013-11-07 13:35:59 | 6a5f5cbf6e3f59f7563b6f7d0f59a56a2fdbe8dc | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 76084 | 1 | 2013-11-07 13:35:59 | 6a5f5cbf6e3f59f7563b6f7d0f59a56a2fdbe8dc | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 76084 | 1 | 2013-11-07 13:35:59 | 6a5f5cbf6e3f59f7563b6f7d0f59a56a2fdbe8dc | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 76200 | 1 | 2013-11-08 13:43:54 | 2d3d255b2d3ae1456a377dbc03f695b7adf010e8 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | y |
| 76200 | 1 | 2013-11-08 13:43:54 | 2d3d255b2d3ae1456a377dbc03f695b7adf010e8 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 76200 | 1 | 2013-11-08 13:43:54 | 2d3d255b2d3ae1456a377dbc03f695b7adf010e8 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 76219 | 1 | 2013-11-08 16:54:15 | 11de6f161585c12148c1b2b4fc8ab830183edfe9 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 76219 | 1 | 2013-11-08 16:54:15 | 11de6f161585c12148c1b2b4fc8ab830183edfe9 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | y |
| 76219 | 1 | 2013-11-08 16:54:15 | 11de6f161585c12148c1b2b4fc8ab830183edfe9 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 76361 | 1 | 2013-11-09 18:53:59 | a476260a0fff7ae7502e858b30943d9067fb1214 | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 76361 | 1 | 2013-11-09 18:53:59 | a476260a0fff7ae7502e858b30943d9067fb1214 | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 76361 | 1 | 2013-11-09 18:53:59 | a476260a0fff7ae7502e858b30943d9067fb1214 | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
| 76463 | 1 | 2013-11-10 14:13:26 | 4f6f05293c61906b169ddfcd9a239cc9393b626e | xtensa | binutils-2.22 | BR2_PACKAGE_DROPWATCH | |
| 76463 | 1 | 2013-11-10 14:13:26 | 4f6f05293c61906b169ddfcd9a239cc9393b626e | xtensa | binutils-2.22 | BR2_PACKAGE_OPROFILE | |
| 76463 | 1 | 2013-11-10 14:13:26 | 4f6f05293c61906b169ddfcd9a239cc9393b626e | xtensa | binutils-2.22 | BR2_PACKAGE_BINUTILS | y |
+-------+--------+---------------------+------------------------------------------+--------+-----------------+-----------------------+-------+
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-11 10:17 ` Thomas Petazzoni
@ 2013-11-11 10:25 ` Will Newton
2013-11-11 10:43 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Will Newton @ 2013-11-11 10:25 UTC (permalink / raw)
To: buildroot
On Mon, Nov 11, 2013 at 10:17 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Will Newton,
>
> On Mon, 11 Nov 2013 10:01:17 +0000, Will Newton wrote:
>
>> >> arm | valgrind-3.8.1 | NOK | http://autobuild.buildroot.net/results/f174541ac06aeeac82b8399686a8d4371532760d/
>> >
>> > /tmp/cceJNtCh.s: Assembler messages:
>> > /tmp/cceJNtCh.s:200: Error: r15 not allowed here -- `str r15,[r3,#+0]'
>> > make[4]: *** [libcoregrind_arm_linux_a-m_libcassert.o] Error 1
>> > make[4]: *** Waiting for unfinished jobs....
>> >
>> > Not sure what's going on here. Anyone to have a look?
>>
>> valgrind uses inline assembly that is not Thumb compatible. It seems
>> it isn't expected to build it in Thumb mode (although it emulates
>> Thumb mode). It might be quite simple to fix but would need
>> coordination with upstream etc.
>
> Are you talking about Thumb, or Thumb-2 ? Because here the
> configuration has:
>
> BR2_arm=y
> BR2_cortex_a8=y
> BR2_TARGET_OPTIMIZATION="-mthumb"
>
> so it's an ARMv7-A with -mthumb, so that means Thumb-2, right?
Yes, Thumb-2. Only those crazy microcontroller guys care about Thumb-1. ;-)
ARM ARM A8.8.203 is the relevant page, Thumb-2 cannot store pc/r15
directly. It should be possible to use a temporary to achieve the same
effect but it would need thorough testing.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-11 10:15 ` Thomas Petazzoni
@ 2013-11-11 10:20 ` Baruch Siach
2013-11-11 10:39 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Baruch Siach @ 2013-11-11 10:20 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Mon, Nov 11, 2013 at 11:15:46AM +0100, Thomas Petazzoni wrote:
> On Mon, 11 Nov 2013 12:10:53 +0200, Baruch Siach wrote:
> > On Mon, Nov 11, 2013 at 10:58:30AM +0100, Thomas Petazzoni wrote:
> > > On Sun, 10 Nov 2013 21:33:16 -0800, Chris Zankel wrote:
> > > > (I'm a bit surprised to get all those errors as binutils currently doesn't
> > > > build. Are you using an older toolchain, or are these packages not
> > > > dependent on the final binutils build?)
> > >
> > > The binutils issues you're seeing are while building native binutils
> > > for the target, not when building cross-binutils for the cross
> > > compilation toolchain. Building the cross-binutils works ok, because
> > > they are built against the build machine C library, which is glibc and
> > > therefore has obstack stuff.
> >
> > Why do we need binutils on target?
>
> $ git grep "select BR2_PACKAGE_BINUTILS"
> package/dropwatch/Config.in: select BR2_PACKAGE_BINUTILS
> package/oprofile/Config.in: select BR2_PACKAGE_BINUTILS
>
> So we need it for dropwatch and oprofile. In fact, what is needed is
> not the full binutils (i.e the binutils programs), but the libbfd
> library which is part of the binutils tarball.
This is strange. More than half of xtensa autobuilds used to fail on target
binutils before Chris' obstack fix. Does this mean that all failing configs
had dropwatch or oprofile enabled?
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-11 10:01 ` Will Newton
@ 2013-11-11 10:17 ` Thomas Petazzoni
2013-11-11 10:25 ` Will Newton
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2013-11-11 10:17 UTC (permalink / raw)
To: buildroot
Dear Will Newton,
On Mon, 11 Nov 2013 10:01:17 +0000, Will Newton wrote:
> >> arm | valgrind-3.8.1 | NOK | http://autobuild.buildroot.net/results/f174541ac06aeeac82b8399686a8d4371532760d/
> >
> > /tmp/cceJNtCh.s: Assembler messages:
> > /tmp/cceJNtCh.s:200: Error: r15 not allowed here -- `str r15,[r3,#+0]'
> > make[4]: *** [libcoregrind_arm_linux_a-m_libcassert.o] Error 1
> > make[4]: *** Waiting for unfinished jobs....
> >
> > Not sure what's going on here. Anyone to have a look?
>
> valgrind uses inline assembly that is not Thumb compatible. It seems
> it isn't expected to build it in Thumb mode (although it emulates
> Thumb mode). It might be quite simple to fix but would need
> coordination with upstream etc.
Are you talking about Thumb, or Thumb-2 ? Because here the
configuration has:
BR2_arm=y
BR2_cortex_a8=y
BR2_TARGET_OPTIMIZATION="-mthumb"
so it's an ARMv7-A with -mthumb, so that means Thumb-2, right?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-11 10:10 ` Baruch Siach
@ 2013-11-11 10:15 ` Thomas Petazzoni
2013-11-11 10:20 ` Baruch Siach
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2013-11-11 10:15 UTC (permalink / raw)
To: buildroot
Dear Baruch Siach,
On Mon, 11 Nov 2013 12:10:53 +0200, Baruch Siach wrote:
> On Mon, Nov 11, 2013 at 10:58:30AM +0100, Thomas Petazzoni wrote:
> > On Sun, 10 Nov 2013 21:33:16 -0800, Chris Zankel wrote:
> > > (I'm a bit surprised to get all those errors as binutils currently doesn't
> > > build. Are you using an older toolchain, or are these packages not
> > > dependent on the final binutils build?)
> >
> > The binutils issues you're seeing are while building native binutils
> > for the target, not when building cross-binutils for the cross
> > compilation toolchain. Building the cross-binutils works ok, because
> > they are built against the build machine C library, which is glibc and
> > therefore has obstack stuff.
>
> Why do we need binutils on target?
$ git grep "select BR2_PACKAGE_BINUTILS"
package/dropwatch/Config.in: select BR2_PACKAGE_BINUTILS
package/oprofile/Config.in: select BR2_PACKAGE_BINUTILS
So we need it for dropwatch and oprofile. In fact, what is needed is
not the full binutils (i.e the binutils programs), but the libbfd
library which is part of the binutils tarball.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-11 9:58 ` Thomas Petazzoni
@ 2013-11-11 10:10 ` Baruch Siach
2013-11-11 10:15 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Baruch Siach @ 2013-11-11 10:10 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Mon, Nov 11, 2013 at 10:58:30AM +0100, Thomas Petazzoni wrote:
> On Sun, 10 Nov 2013 21:33:16 -0800, Chris Zankel wrote:
> > (I'm a bit surprised to get all those errors as binutils currently doesn't
> > build. Are you using an older toolchain, or are these packages not
> > dependent on the final binutils build?)
>
> The binutils issues you're seeing are while building native binutils
> for the target, not when building cross-binutils for the cross
> compilation toolchain. Building the cross-binutils works ok, because
> they are built against the build machine C library, which is glibc and
> therefore has obstack stuff.
Why do we need binutils on target?
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-11 9:14 ` Fatih Aşıcı
@ 2013-11-11 10:09 ` Thomas Petazzoni
2013-11-11 12:26 ` Fatih Aşıcı
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2013-11-11 10:09 UTC (permalink / raw)
To: buildroot
Dear Fatih A??c?,
On Mon, 11 Nov 2013 11:14:51 +0200, Fatih A??c? wrote:
> > http://autobuild.buildroot.net/results/555278227680e90737e6dbe0a6dcc035507150aa/build-end.log
> > (sqlite problem)
>
> Needs posix_fallocate() which is not available in the test toolchain.
Except that posix_fallocate() is not available in uClibc. It is indeed
available in the internal toolchain backend, due to a patch that we
have added, but we cannot assume it will be available in external
uClibc toolchains that may not have the same of patches applied.
Moreover, the sqlite3.c code in Qt seems to have some code to handle
the absence of posix_fallocate():
#if defined(HAVE_POSIX_FALLOCATE) && HAVE_POSIX_FALLOCATE
{ "fallocate", (sqlite3_syscall_ptr)posix_fallocate, 0 },
#else
{ "fallocate", (sqlite3_syscall_ptr)0, 0 },
#endif
It would be nice to have a look at why HAVE_POSIX_FALLOCATE is defined
even though posix_fallocate() is not available.
> > http://autobuild.buildroot.net/results/bbe7d79da059fdf67fb29880b8539ca2320ba86d/build-end.log
> > (inlining problem)
>
> It seems this is fixed in GCC 4.7.3 [1].
Ok.
> > are not fixed. Fatih, would you mind having a look?
> >
>
> Is there a method to solve such cases with custom external toolchains?
No, there isn't a really good way. Possibilities are:
(1) Add an exception to my autobuilder scripts, and document this
exception (i.e gcc version <foo> fails to build qt5base).
(2) Rebuild the toolchain with a newer ct-ng and therefore a newer
gcc, and forget about the problem :-) I anyway desperately need to
rebuild the Crosstool-NG toolchains used in the autobuilders.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-09 18:15 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (6 preceding siblings ...)
[not found] ` <5280A0D3.1080605@imgtec.com>
@ 2013-11-11 10:01 ` Will Newton
2013-11-11 10:17 ` Thomas Petazzoni
2013-11-11 11:25 ` Ezequiel García
8 siblings, 1 reply; 416+ messages in thread
From: Will Newton @ 2013-11-11 10:01 UTC (permalink / raw)
To: buildroot
On Sat, Nov 9, 2013 at 6:15 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello all,
>
> If you're Cc'ed on this e-mail, it means that there is a question for
> you below. Here is a summary of who should look at what problems (note
> that some problems are not affected to anyone, either because the
> reason is unknown or because there is no clear "owner" for the problem):
>
> Markos Chandras aespipe, fdk-aac, gmp, libiscsi
> Sonic Zhang, Aaron Wu boost, icu, openpgm
> Chris Zankel cdrkit
> Peter Korsgaard gst1-plugins-bad, pulseaudio
> Gustavo Zacarias protobuf-c, mplayer, nettle (ARM), php
> Simon Dawson libcap-ng, util-linux, zeromq, zmqpp
> Spenser Gilliland libglib2, nettle (Microblaze), openssl
> Ezequiel Garcia libnspr
> Mischa Jonker pulseaudio, ti-utils
> Fatih A??c? qt5base
> Tzu-Jung Lee tstools
>
> Thanks!
>
> Thomas
>
> On Sat, 9 Nov 2013 08:30:28 +0100 (CET), Thomas Petazzoni wrote:
>
>> Detail of failures
>> ===================
>>
>> mips | aespipe-2.4c | NOK | http://autobuild.buildroot.net/results/da0268df99b9bf920d88121e7c3d33d41a57d951/
>
> Unknown problem (error: C compiler cannot create executables). Markos,
> as our MIPS guy, can you have a look at this one?
>
>> arm | alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/983828bd27a521020e42e58cce9393e6b8d23502/
>
> It was a wrong toolchain configuration, with a weird toolchain.
> I've removed the toolchain from the autobuilders.
>
>> powerpc | alsa-utils-1.0.26 | NOK | http://autobuild.buildroot.net/results/1c6a33e75fe0617e01d7413cdfd5fbd466f822d4/
>
> Missing link against -lrt for static linking.
>
>> arm | alsa-utils-1.0.26 | NOK | http://autobuild.buildroot.net/results/6123186a66bbea833ab2fa980346f16825b22d21/
>
> checking for snd_ctl_open in -lasound... no
> configure: error: No linkable libasound was found.
> make: *** [/home/test/test/3/output/build/alsa-utils-1.0.26/.stamp_configured] Error 1
>
> Weird, don't know what's happening here.
>
>> arm | audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/6aff0a6b9c7b2890cc069868b041ed74e549933b/
>
> This was my funky toolchain (same as alsa-lib problem above). Toolchain
> removed from the autobuilders.
>
>> xtensa | binutils-2.22 | NOK | http://autobuild.buildroot.net/results/11de6f161585c12148c1b2b4fc8ab830183edfe9/
>> xtensa | binutils-2.22 | NOK | http://autobuild.buildroot.net/results/2d3d255b2d3ae1456a377dbc03f695b7adf010e8/
>
> This is fixed by http://patchwork.ozlabs.org/patch/289532/, which
> hasn't been committed yet. It will also require a rebuild of the
> toolchain in the autobuilders.
>
> Peter, can you commit this patch?
>
>> bfin | boost-1.54.0 | NOK | http://autobuild.buildroot.net/results/84f9d9d2b6b5356984c6d59aad5e28b3e7847651/
>
> Don't know what's going on. Sonic, Aaron, can you have a look?
>
>> arm | busybox-1.21.1 | NOK | http://autobuild.buildroot.net/results/116d13f7489981c39c3759eaf8302be4d795f339/
>
> This was my weird toolchain (same problem as alsa-lib). Toolchain
> removed from the autobuilders.
>
>> xtensa | cdrkit-1.1.11 | NOK | http://autobuild.buildroot.net/results/0315c117986f3aac8c0719d744cb47ee03738ee9/
>
> [ 58%] Building C object libhfs_iso/CMakeFiles/hfs_iso.dir/record.o
> ../libusal/libusal.a(scsi-remote.o):(.literal+0xe0): undefined reference to `valloc'
>
> Chris, can you have a look at this one, since it's apparently a
> Xtensa-specific problem?
>
>> mipsel | fdk-aac-0.1.2 | NOK | http://autobuild.buildroot.net/results/cb87635832f4a1128f174a25c264f716399c52d4/
>
> MIPS specific problem. We're building for mips1, but fdk-aac uses some
> instructions not available on mips1. Maybe we should only enable
> fdk-aac for some more capable variant of MIPS instruction sets.
>
> Markos, can you have a look at this one?
>
>> bfin | fontconfig-2.6.0 | NOK | http://autobuild.buildroot.net/results/8579cb481e86dcae0988379c5781bd00f4e70809/
>
> fontconfig forgets to link against libpng. Anyone willing to fix this?
>
>> mips | gmp-5.1.3 | NOK | http://autobuild.buildroot.net/results/69b0804cbfbb24c70f90435a37fb56a118247a57/
>
> configure: error: could not find a working compiler, see config.log for details
>
> Markos, can you have a look?
>
>> arm | gst1-plugins-bad-1.2.0 | NOK | http://autobuild.buildroot.net/results/b99eb6a9067cee885da88bff64ee447c37e31e0c/
>> arm | gst1-plugins-bad-1.2.0 | NOK | http://autobuild.buildroot.net/results/b320bb61650c58e9c855e3136f5f6d7bf5e4ef56/
>
> Same problem in both cases, related to the DirectFB plugin. Peter, you
> are the one taking care of Gstreamer most of the time, can you have a
> look into this?
>
>> x86_64 | host-protobuf-c-0.15 | NOK | http://autobuild.buildroot.net/results/5d163e750808f2fdd8098cb58240bada12b770a9/
>> mips64el | host-protobuf-c-0.15 | NOK | http://autobuild.buildroot.net/results/038340dfbbbedbcfcb98ad5dbf828bc03fe26af6/
>
> Weird compilation problem, seems really caused by an issue in
> protobuf-c itself. Gustavo, you're the one who added protobuf-c, can
> you have a look at this?
>
>> bfin | icu-51.2 | NOK | http://autobuild.buildroot.net/results/e0a1130feb1784b3d4fefe1224943d93409a3494/
>> bfin | icu-51.2 | NOK | http://autobuild.buildroot.net/results/85c082a693ef795cecf0ef9204b7c9c0850d4b74/
>
> Problem building icu on Blackfin:
>
> *** ERROR - configure could not detect your platform
>
> Sonic, Zhang, can you have a look into this?
>
>> avr32 | libcap-ng-0.7.3 | NOK | http://autobuild.buildroot.net/results/3df16d60f6bbb679129cd568df4440be6f35cd9f/
>
> The missing TLS problem on AVR32. We still haven't found the solution
> to handle this one. As I've suggested previously, I would simply make
> TLS support unconditional in Buildroot as soon as thread support is
> enabled, and then mark libcap-ng as not available on AVR32. Of course,
> if you have an external toolchain without TLS support, you're on your
> own.
>
>> microblaze | libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/6f0066f56f10d3f17023e698fd3ba1bd2d00c4c1/
>> microblaze | libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/79d2df836063167f12f5bba177297a041bb7c16f/
>
> Missing compiler intrinsics and fallocate in the Microblaze toolchain.
> We're waiting for Spenser Gilliland to finish the Microblaze internal
> toolchain support, so that we can ditch the crappy Microblaze external
> toolchains.
>
>> mips64el | libiscsi-1.6.0 | NOK | http://autobuild.buildroot.net/results/39e8e0ebbeb196276492b928b41cc0b0fe1e9ec3/
>> mips64el | libiscsi-1.6.0 | NOK | http://autobuild.buildroot.net/results/efb87b17c49170f6377631371438911b18029cea/
>
> The usual problem of ld being used instead of gcc, causing problem on
> mips64el. However, you can't do partial linking with gcc, so a libtool
> fix is needed.
>
> Markos, I know you've identified the libtool fix for this. Could you
> backport it on top of libtool 2.4.2 (that we have in Buildroot), add it
> as a patch in package/libtool/, and then mark LIBISCSI_AUTORECONF =
> YES so that the libtool stuff gets regenerated with a known-working
> version?
>
>> nios2 | libnspr-4.9.6 | NOK | http://autobuild.buildroot.net/results/8c01fdaac7afa00bd1117c79ae047344242d1463/
>> nios2 | libnspr-4.9.6 | NOK | http://autobuild.buildroot.net/results/a418145d72e92f64956518bb2786e33dadd08a86/
>
> NIOS2 support missing in libnspr. Ezequiel, can you look into this?
> Normally, adding an architecture support in libnspr is really easy, so
> adding a patch to libnspr should be feasible.
>
>> aarch64 | libv4l-0.8.9 | NOK | http://autobuild.buildroot.net/results/4de7dc58e826d1dd60add2821f774c9c5f5a2a71/
>
> Package needs to be bumped, I have already started working on this.
>
>> arm | mplayer-1.1.1 | NOK | http://autobuild.buildroot.net/results/8f946e28b11b2ab1ba0d9688286c665488de0486/
>
> libmpeg2/motion_comp_arm_s.S: Assembler messages:
> libmpeg2/motion_comp_arm_s.S:29: Error: selected processor does not support ARM mode `pld [r1]'
> libmpeg2/motion_comp_arm_s.S:39: Error: selected processor does not support ARM mode `pld [r1]'
>
> That's an ARMv4t configuration. Maybe building mplayer on ARMv4t is not
> possible. Adding a bunch of depends on !BR2_arm<something> is probably
> the solution here. Gustavo, maybe?
>
>> arm | ne10-88c18f02199947b2c8b577... | NOK | http://autobuild.buildroot.net/results/3631f7e9dad9fab356d31160ac95b7d0fec70ce2/
>
> Needs NEON support apparently. Should be something for me.
>
>> microblaze | nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/82acbea862ee0bb5288ab498d86772bc475d3a53/
>> arm | nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/88ea0cc0815f865e1a144d39231fdc9b47e689b0/
>
> On Microblaze, a compiler error. Should be fixed by the internal
> toolchain support for Microblaze. Waiting for Spenser on this :)
>
> On ARM, the failure is due to nettle tests requiring C++ support. It
> would be good to disable the compilation of those tests. Gustavo,
> you're the one looking after nettle in general, can you look into this?
>
>> bfin | openpgm-5.1.118~dfsg | NOK | http://autobuild.buildroot.net/results/120b7de960a04def5c53b59644eefc598bd0a1d4/
>
> Blackfin does not have getifaddrs():
>
> getifaddrs.c:853:3: error: #error "Unsupported interface enumeration on this platform."
>
> Not sure how to handle this uClibc configuration difference, except by
> adding "depends on !" to exclude the specific Blackfin toolchains
> causing problems.
>
>> microblaze | openssl-1.0.1e | NOK | http://autobuild.buildroot.net/results/f313ac3233a8ed5b3087936c1cd8408a00fdf2bb/
>
> Compiler error. Spenser, we need your patches!
>
>> aarch64 | php-5.3.27 | NOK | http://autobuild.buildroot.net/results/08d3255303f7ceda8a1ecfcf56ad665f00829632/
>
> /usr/include/bits/predefs.h:20:3: error: #error "Never use <bits/predefs.h> directly; include <features.h> instead."
> # error "Never use <bits/predefs.h> directly; include <features.h> instead."
>
> Gustavo, you like PHP, no ? :-)
>
>> arc | pulseaudio-4.0 | NOK | http://autobuild.buildroot.net/results/281ff1c8046b7e93759c5f51995f34788e717fad/
>
> checking for atomic_ops.h... no
> configure: error: *** libatomic-ops headers not found
> make: *** [/home/test/test/1/output/build/pulseaudio-4.0/.stamp_configured] Error 1
>
> For some reason, on ARC, atomic_ops is needed. Why not on other
> architectures? Peter, Mischa, any idea?
>
>> powerpc | qt-4.8.5 | NOK | http://autobuild.buildroot.net/results/0ee61f71e61f2215a15e4655a4e22d0521334c35/
>
> Will be fixed by my patch that prevents building parts of Qt on some
> unsupported architectures.
>
>> i686 | qt5base-5.1.1 | NOK | http://autobuild.buildroot.net/results/bbe7d79da059fdf67fb29880b8539ca2320ba86d/
>> arm | qt5base-5.1.1 | NOK | http://autobuild.buildroot.net/results/37613281f21895716ceaf64654e175148d7f543c/
>> i686 | qt5base-5.1.1 | NOK | http://autobuild.buildroot.net/results/555278227680e90737e6dbe0a6dcc035507150aa/
>
> For
> http://autobuild.buildroot.net/results/37613281f21895716ceaf64654e175148d7f543c/build-end.log,
> Samuel has already sent a patch
> (http://patchwork.ozlabs.org/patch/289999/). The other two ones:
>
> http://autobuild.buildroot.net/results/555278227680e90737e6dbe0a6dcc035507150aa/build-end.log
> (sqlite problem)
>
> http://autobuild.buildroot.net/results/bbe7d79da059fdf67fb29880b8539ca2320ba86d/build-end.log
> (inlining problem)
>
> are not fixed. Fatih, would you mind having a look?
>
>> arc | ti-utils-06dbdb2727354b5f3a... | NOK | http://autobuild.buildroot.net/results/63d294574b053aa4e2148fbc3185c5594d925ae9/
>
> {standard input}: Assembler messages:
> {standard input}:1680: Error: missing operand
> {standard input}:1680: Error: junk at end of line: `@plt_tx_bip.part.8'
>
> ARC toolchain problem, for Mischa.
>
>> x86_64 | tstools-1_11 | NOK | http://autobuild.buildroot.net/results/ce02d7fb9ae3aa06eaf53db39cbef27c051b525d/
>
> Should use gcc for linking and not ld + missing -lm. Tzu-Jung Lee,
> you're the one who added tstools, can you have a look at this problem?
>
>> avr32 | util-linux-2.23.2 | NOK | http://autobuild.buildroot.net/results/2ba1bd78f4303ef2f543a4e4fa65d1b68ba3a765/
>
> Missing fallocate on avr32. Simon, what is the proposal to solve this?
> Add fallocate support to 0.9.31 ?
>
>> arm | valgrind-3.8.1 | NOK | http://autobuild.buildroot.net/results/f174541ac06aeeac82b8399686a8d4371532760d/
>
> /tmp/cceJNtCh.s: Assembler messages:
> /tmp/cceJNtCh.s:200: Error: r15 not allowed here -- `str r15,[r3,#+0]'
> make[4]: *** [libcoregrind_arm_linux_a-m_libcassert.o] Error 1
> make[4]: *** Waiting for unfinished jobs....
>
> Not sure what's going on here. Anyone to have a look?
valgrind uses inline assembly that is not Thumb compatible. It seems
it isn't expected to build it in Thumb mode (although it emulates
Thumb mode). It might be quite simple to fix but would need
coordination with upstream etc.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-11 5:33 ` Chris Zankel
@ 2013-11-11 9:58 ` Thomas Petazzoni
2013-11-11 10:10 ` Baruch Siach
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2013-11-11 9:58 UTC (permalink / raw)
To: buildroot
Dear Chris Zankel,
On Sun, 10 Nov 2013 21:33:16 -0800, Chris Zankel wrote:
> (I'm a bit surprised to get all those errors as binutils currently
> doesn't build. Are you using an older toolchain, or are these packages
> not dependent on the final binutils build?)
The binutils issues you're seeing are while building native binutils
for the target, not when building cross-binutils for the cross
compilation toolchain. Building the cross-binutils works ok, because
they are built against the build machine C library, which is glibc and
therefore has obstack stuff.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-11 9:46 ` Peter Korsgaard
@ 2013-11-11 9:49 ` Markos Chandras
0 siblings, 0 replies; 416+ messages in thread
From: Markos Chandras @ 2013-11-11 9:49 UTC (permalink / raw)
To: buildroot
On 11/11/2013 09:46 AM, Peter Korsgaard wrote:
>>>>>> "Markos" == Markos Chandras <Markos.Chandras@imgtec.com> writes:
>
> Hi,
>
>>>> mipsel | fdk-aac-0.1.2 | NOK | http://autobuild.buildroot.net/results/cb87635832f4a1128f174a25c264f716399c52d4/
>>>
>>> MIPS specific problem. We're building for mips1, but fdk-aac uses some
>>> instructions not available on mips1. Maybe we should only enable
>>> fdk-aac for some more capable variant of MIPS instruction sets.
>
>> This needs for 'your-peter' branch to be merged first which contains
>> the change from -mtune->-march for MIPS. I checked and that branch was
>> still not merged so this will have to wait.
>
> But it is?
>
> http://git.buildroot.net/buildroot/commit/?id=f60dafe06833a17540608d1c8172
>
Yes sorry I didn't notice :)
--
markos
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
[not found] ` <5280A0D3.1080605@imgtec.com>
2013-11-11 9:21 ` Markos Chandras
@ 2013-11-11 9:46 ` Peter Korsgaard
2013-11-11 9:49 ` Markos Chandras
1 sibling, 1 reply; 416+ messages in thread
From: Peter Korsgaard @ 2013-11-11 9:46 UTC (permalink / raw)
To: buildroot
>>>>> "Markos" == Markos Chandras <Markos.Chandras@imgtec.com> writes:
Hi,
>>> mipsel | fdk-aac-0.1.2 | NOK | http://autobuild.buildroot.net/results/cb87635832f4a1128f174a25c264f716399c52d4/
>>
>> MIPS specific problem. We're building for mips1, but fdk-aac uses some
>> instructions not available on mips1. Maybe we should only enable
>> fdk-aac for some more capable variant of MIPS instruction sets.
> This needs for 'your-peter' branch to be merged first which contains
> the change from -mtune->-march for MIPS. I checked and that branch was
> still not merged so this will have to wait.
But it is?
http://git.buildroot.net/buildroot/commit/?id=f60dafe06833a17540608d1c8172
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-11 12:26 ` Fatih Aşıcı
@ 2013-11-11 9:30 ` Gustavo Zacarias
0 siblings, 0 replies; 416+ messages in thread
From: Gustavo Zacarias @ 2013-11-11 9:30 UTC (permalink / raw)
To: buildroot
On 11/11/2013 09:26 AM, Fatih A??c? wrote:
> Probably the following change will fix it:
>
> --- a/src/3rdparty/sqlite/sqlite3.c
> +++ b/src/3rdparty/sqlite/sqlite3.c
> @@ -22938,7 +22938,8 @@ SQLITE_PRIVATE const char *sqlite3OpcodeName(int i){
> /* Use posix_fallocate() if it is available
> */
> #if !defined(HAVE_POSIX_FALLOCATE) \
> - && (_XOPEN_SOURCE >= 600 || _POSIX_C_SOURCE >= 200112L)
> + && (_XOPEN_SOURCE >= 600 || _POSIX_C_SOURCE >= 200112L) \
> + && !defined(__UCLIBC__)
> # define HAVE_POSIX_FALLOCATE 1
> #endif
>
>
>
> sqlite3's own build system (which is not available in qt) checks if
> posix_fallocate() is available. I wonder if there is a special reason for
> providing an option to use the built-in sqlite.
There was a bug in sqlite 3.7.17 with this, see
http://git.buildroot.net/buildroot/commit/package/sqlite?id=316f991729c423c9a49a955d3747ff31ad7a0068
It's fixed now, but a similar solution might be appropiate.
Newer uClibc versions might have posix_fallocate so excluding uClibc
might not be appropiate in the future.
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
[not found] ` <5280A0D3.1080605@imgtec.com>
@ 2013-11-11 9:21 ` Markos Chandras
2013-11-11 9:46 ` Peter Korsgaard
1 sibling, 0 replies; 416+ messages in thread
From: Markos Chandras @ 2013-11-11 9:21 UTC (permalink / raw)
To: buildroot
On 11/11/2013 09:18 AM, Markos Chandras wrote:
> Hi,>
>>> Detail of failures
>>> ===================
>>>
>>> mips | aespipe-2.4c | NOK |
>>> http://autobuild.buildroot.net/results/da0268df99b9bf920d88121e7c3d33d41a57d951/
>>>
>>
>> Unknown problem (error: C compiler cannot create executables). Markos,
>> as our MIPS guy, can you have a look at this one?
>
> Ok I will
>
>>
>>> mipsel | fdk-aac-0.1.2 | NOK |
>>> http://autobuild.buildroot.net/results/cb87635832f4a1128f174a25c264f716399c52d4/
>>>
>>
>> MIPS specific problem. We're building for mips1, but fdk-aac uses some
>> instructions not available on mips1. Maybe we should only enable
>> fdk-aac for some more capable variant of MIPS instruction sets.
>
> This needs for 'your-peter' branch to be merged first which contains the
> change from -mtune->-march for MIPS. I checked and that branch was still
> not merged so this will have to wait.
>
>>
>>> mips | gmp-5.1.3 | NOK |
>>> http://autobuild.buildroot.net/results/69b0804cbfbb24c70f90435a37fb56a118247a57/
>>>
>>
>> configure: error: could not find a working compiler, see config.log
>> for details
>>
>> Markos, can you have a look?
> Yep
>
>>
>>> arm | gst1-plugins-bad-1.2.0 | NOK |
>>> http://autobuild.buildroot.net/results/b99eb6a9067cee885da88bff64ee447c37e31e0c/
>>>
>>> arm | gst1-plugins-bad-1.2.0 | NOK |
>>> http://autobuild.buildroot.net/results/b320bb61650c58e9c855e3136f5f6d7bf5e4ef56/
>>>
>>
>> Same problem in both cases, related to the DirectFB plugin. Peter, you
>> are the one taking care of Gstreamer most of the time, can you have a
>> look into this?
>>
>>> x86_64 | host-protobuf-c-0.15 | NOK |
>>> http://autobuild.buildroot.net/results/5d163e750808f2fdd8098cb58240bada12b770a9/
>>>
>>> mips64el | host-protobuf-c-0.15 | NOK |
>>> http://autobuild.buildroot.net/results/038340dfbbbedbcfcb98ad5dbf828bc03fe26af6/
>>>
>>
>> Weird compilation problem, seems really caused by an issue in
>> protobuf-c itself. Gustavo, you're the one who added protobuf-c, can
>> you have a look at this?
>>
>>> bfin | icu-51.2 | NOK |
>>> http://autobuild.buildroot.net/results/e0a1130feb1784b3d4fefe1224943d93409a3494/
>>>
>>> bfin | icu-51.2 | NOK |
>>> http://autobuild.buildroot.net/results/85c082a693ef795cecf0ef9204b7c9c0850d4b74/
>>>
>>
>> Problem building icu on Blackfin:
>>
>> *** ERROR - configure could not detect your platform
>>
>> Sonic, Zhang, can you have a look into this?
>>
>>> avr32 | libcap-ng-0.7.3 | NOK |
>>> http://autobuild.buildroot.net/results/3df16d60f6bbb679129cd568df4440be6f35cd9f/
>>>
>>
>> The missing TLS problem on AVR32. We still haven't found the solution
>> to handle this one. As I've suggested previously, I would simply make
>> TLS support unconditional in Buildroot as soon as thread support is
>> enabled, and then mark libcap-ng as not available on AVR32. Of course,
>> if you have an external toolchain without TLS support, you're on your
>> own.
>>
>>> microblaze | libglib2-2.36.3 | NOK |
>>> http://autobuild.buildroot.net/results/6f0066f56f10d3f17023e698fd3ba1bd2d00c4c1/
>>>
>>> microblaze | libglib2-2.36.3 | NOK |
>>> http://autobuild.buildroot.net/results/79d2df836063167f12f5bba177297a041bb7c16f/
>>>
>>
>> Missing compiler intrinsics and fallocate in the Microblaze toolchain.
>> We're waiting for Spenser Gilliland to finish the Microblaze internal
>> toolchain support, so that we can ditch the crappy Microblaze external
>> toolchains.
>>
>>> mips64el | libiscsi-1.6.0 | NOK |
>>> http://autobuild.buildroot.net/results/39e8e0ebbeb196276492b928b41cc0b0fe1e9ec3/
>>>
>>> mips64el | libiscsi-1.6.0 | NOK |
>>> http://autobuild.buildroot.net/results/efb87b17c49170f6377631371438911b18029cea/
>>>
>>
>> The usual problem of ld being used instead of gcc, causing problem on
>> mips64el. However, you can't do partial linking with gcc, so a libtool
>> fix is needed.
>>
>> Markos, I know you've identified the libtool fix for this. Could you
>> backport it on top of libtool 2.4.2 (that we have in Buildroot), add it
>> as a patch in package/libtool/, and then mark LIBISCSI_AUTORECONF =
>> YES so that the libtool stuff gets regenerated with a known-working
>> version?
>
> Yes it is on my TODO list. I tried beackporting it to Gentoo but it does
> not apply cleanly as it is. So it needs a little bit a work (not
> anything serious as far as I can tell)
>
Apologies if you got the message twice. The e-mail client messed up the
buildroot address.
--
markos
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-09 18:15 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (4 preceding siblings ...)
2013-11-11 5:33 ` Chris Zankel
@ 2013-11-11 9:14 ` Fatih Aşıcı
2013-11-11 10:09 ` Thomas Petazzoni
[not found] ` <5280A0D3.1080605@imgtec.com>
` (2 subsequent siblings)
8 siblings, 1 reply; 416+ messages in thread
From: Fatih Aşıcı @ 2013-11-11 9:14 UTC (permalink / raw)
To: buildroot
On Saturday 09 November 2013 20:15:43 Thomas Petazzoni wrote:
> > i686 | qt5base-5.1.1 | NOK | http://autobuild.buildroot.net/results/bbe7d79da059fdf67fb29880b8539ca2320ba86d/
> > arm | qt5base-5.1.1 | NOK | http://autobuild.buildroot.net/results/37613281f21895716ceaf64654e175148d7f543c/
> > i686 | qt5base-5.1.1 | NOK | http://autobuild.buildroot.net/results/555278227680e90737e6dbe0a6dcc035507150aa/
>
> For
> http://autobuild.buildroot.net/results/37613281f21895716ceaf64654e175148d7f543c/build-end.log,
> Samuel has already sent a patch
> (http://patchwork.ozlabs.org/patch/289999/). The other two ones:
>
> http://autobuild.buildroot.net/results/555278227680e90737e6dbe0a6dcc035507150aa/build-end.log
> (sqlite problem)
Needs posix_fallocate() which is not available in the test toolchain.
> http://autobuild.buildroot.net/results/bbe7d79da059fdf67fb29880b8539ca2320ba86d/build-end.log
> (inlining problem)
It seems this is fixed in GCC 4.7.3 [1].
> are not fixed. Fatih, would you mind having a look?
>
Is there a method to solve such cases with custom external toolchains?
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54988
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-09 18:15 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (3 preceding siblings ...)
2013-11-10 10:57 ` Gustavo Zacarias
@ 2013-11-11 5:33 ` Chris Zankel
2013-11-11 9:58 ` Thomas Petazzoni
2013-11-11 9:14 ` Fatih Aşıcı
` (3 subsequent siblings)
8 siblings, 1 reply; 416+ messages in thread
From: Chris Zankel @ 2013-11-11 5:33 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On 11/9/13, 10:15 AM, Thomas Petazzoni wrote:
>
>> xtensa | cdrkit-1.1.11 | NOK | http://autobuild.buildroot.net/results/0315c117986f3aac8c0719d744cb47ee03738ee9/
> [ 58%] Building C object libhfs_iso/CMakeFiles/hfs_iso.dir/record.o
> ../libusal/libusal.a(scsi-remote.o):(.literal+0xe0): undefined reference to `valloc'
>
> Chris, can you have a look at this one, since it's apparently a
> Xtensa-specific problem?
Looks that Baruch already found the issue (cdrkit has a very similar issue):
> cdrkit has not see a release in more than 3 years. There are probably other
> packages making use of the obsolete valloc() routine, so I guess we want to
> enable UCLIBC_SUSV2_LEGACY anyway.
I haven't seen a patch yet, so will also work on it and should have it soon.
(I'm a bit surprised to get all those errors as binutils currently
doesn't build. Are you using an older toolchain, or are these packages
not dependent on the final binutils build?)
Thanks,
-Chris
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-10 10:46 ` Thomas Petazzoni
2013-11-10 11:21 ` Simon Dawson
@ 2013-11-10 22:56 ` Peter Korsgaard
1 sibling, 0 replies; 416+ messages in thread
From: Peter Korsgaard @ 2013-11-10 22:56 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> > The missing TLS problem on AVR32. We still haven't found the solution
>> > to handle this one. As I've suggested previously, I would simply make
>> > TLS support unconditional in Buildroot as soon as thread support is
>> > enabled, and then mark libcap-ng as not available on AVR32. Of course,
>> > if you have an external toolchain without TLS support, you're on your
>> > own.
>>
>> As you say, we still don't appear to have reached a consensus of
>> opinion on how to solve this.
> Peter, can we agree on the following solution for this:
> (1) Remove BR2_GCC_ENABLE_TLS, and enable TLS support unconditionally,
> except when thread support is not enabled.
> (2) Everywhere, assume that TLS support is always available when we
> have thread support. If it's not the case (such as AVR32), mark
> the package as "depends on !<architecture>".
Yes, sounds sensible.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-10 10:32 ` Baruch Siach
@ 2013-11-10 15:21 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2013-11-10 15:21 UTC (permalink / raw)
To: buildroot
Dear Baruch Siach,
On Sun, 10 Nov 2013 12:32:35 +0200, Baruch Siach wrote:
> > Yes. The UCLIBC_SUSV2_LEGACY symbol was added after 0.9.33.2, so it
> > explains why only Xtensa (which uses the uClibc snapshot version) is
> > affected.
>
> I see if I can cook up a patch.
>
> > Maybe we can replace the valloc() call with posix_memalign()
> > and send the patch upstream to cdrkit?
>
> cdrkit has not see a release in more than 3 years. There are probably other
> packages making use of the obsolete valloc() routine, so I guess we want to
> enable UCLIBC_SUSV2_LEGACY anyway.
Fine with me.
> > Also, can you sync up with Chris to provide a patch that makes Xtensa
> > not use a snapshot version, but a fixed version of uClibc (based on a
> > git commit, for example) ? The snapshot version we currently use is
> > really bad, because depending on when you run the build, you will get
> > different build results. This is really not how Buildroot should work:
> > snapshot versions are only provided for expert users who want to test
> > the latest versions of uClibc, such versions shouldn't be used as the
> > default.
>
> The original patch of Chris adding xtensa support (75720db3, xtensa: add
> support for the Xtensa architecture) just disabled all other uClibc version
> for xtensa. The uClibc snapshot just became the version of choice by default.
> As far as I know any recent master branch commit id could reasonably be used.
> Should we add an "xtensa only" uClibc version, like the "avr32 only (0.9.31)"
> version that we now have? Hasn't Bernhard Reutner-Fischer declared some kind
> of -rc in the uclibc mailing list
> (http://lists.uclibc.org/pipermail/uclibc/2013-November/048069.html)?
Well, seeing the activity of uClibc, I wouldn't expect an -rc version
or a stable reason any time soon.
Therefore, adding a Xtensa specific uClibc version, pinned to a
specific Git commit, seems like the best option for now.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-10 11:21 ` Simon Dawson
@ 2013-11-10 11:36 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2013-11-10 11:36 UTC (permalink / raw)
To: buildroot
Dear Simon Dawson,
On Sun, 10 Nov 2013 11:21:14 +0000, Simon Dawson wrote:
> Unfortunately, there is no fallocate syscall on avr32. So I think I'll
> have to revert to my original plan to disable fallocate in the
> util-linux package for avr32.
Ok. I guess there will be a bunch of packages that use fallocate(), so
we'll have to mark them !BR2_avr32, or find some other trick.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-10 10:46 ` Thomas Petazzoni
@ 2013-11-10 11:21 ` Simon Dawson
2013-11-10 11:36 ` Thomas Petazzoni
2013-11-10 22:56 ` Peter Korsgaard
1 sibling, 1 reply; 416+ messages in thread
From: Simon Dawson @ 2013-11-10 11:21 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On 10 November 2013 10:46, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On Sun, 10 Nov 2013 10:32:29 +0000, Simon Dawson wrote:
>> Yes, I'm working on backporting fallocate support to 0.9.31 now.
>
> Great.
Unfortunately, there is no fallocate syscall on avr32. So I think I'll
have to revert to my original plan to disable fallocate in the
util-linux package for avr32.
Simon.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-10 10:57 ` Gustavo Zacarias
@ 2013-11-10 11:07 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2013-11-10 11:07 UTC (permalink / raw)
To: buildroot
Dear Gustavo Zacarias,
On Sun, 10 Nov 2013 07:57:07 -0300, Gustavo Zacarias wrote:
> >> mipsel | fdk-aac-0.1.2 | NOK | http://autobuild.buildroot.net/results/cb87635832f4a1128f174a25c264f716399c52d4/
> >
> > MIPS specific problem. We're building for mips1, but fdk-aac uses some
> > instructions not available on mips1. Maybe we should only enable
> > fdk-aac for some more capable variant of MIPS instruction sets.
> >
> > Markos, can you have a look at this one?
>
> Why not just ditch MIPS1 & MIPS2 ISAs like we did with generic ARM?
> AFAIK (and Markos feel free to chime in) those aren't used in anything
> modern these days, just in very very old SGI machines that didn't run
> linux as far as i know.
> Even MIPS3's usefulness is doubtful.
I don't have a very good vision of the MIPS space, but if Markos
agrees, I'm definitely fine with not supporting old MIPS processors
that are never used with Linux.
> I've looked into the source and the asm optimizations are so messy that
> it hurts to look at, and don't seem to be easily disabled.
Well, my idea was certainly not to fix fdk-aac itself, but simply add a
bunch of 'depends on !BR2_mips<something>' to avoid the problematic
platforms.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-09 18:15 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (2 preceding siblings ...)
2013-11-10 10:32 ` Simon Dawson
@ 2013-11-10 10:57 ` Gustavo Zacarias
2013-11-10 11:07 ` Thomas Petazzoni
2013-11-11 5:33 ` Chris Zankel
` (4 subsequent siblings)
8 siblings, 1 reply; 416+ messages in thread
From: Gustavo Zacarias @ 2013-11-10 10:57 UTC (permalink / raw)
To: buildroot
On 11/09/2013 03:15 PM, Thomas Petazzoni wrote:
>> mipsel | fdk-aac-0.1.2 | NOK | http://autobuild.buildroot.net/results/cb87635832f4a1128f174a25c264f716399c52d4/
>
> MIPS specific problem. We're building for mips1, but fdk-aac uses some
> instructions not available on mips1. Maybe we should only enable
> fdk-aac for some more capable variant of MIPS instruction sets.
>
> Markos, can you have a look at this one?
Why not just ditch MIPS1 & MIPS2 ISAs like we did with generic ARM?
AFAIK (and Markos feel free to chime in) those aren't used in anything
modern these days, just in very very old SGI machines that didn't run
linux as far as i know.
Even MIPS3's usefulness is doubtful.
I've looked into the source and the asm optimizations are so messy that
it hurts to look at, and don't seem to be easily disabled.
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-10 10:32 ` Simon Dawson
@ 2013-11-10 10:46 ` Thomas Petazzoni
2013-11-10 11:21 ` Simon Dawson
2013-11-10 22:56 ` Peter Korsgaard
0 siblings, 2 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2013-11-10 10:46 UTC (permalink / raw)
To: buildroot
Dear Simon Dawson,
On Sun, 10 Nov 2013 10:32:29 +0000, Simon Dawson wrote:
> > The missing TLS problem on AVR32. We still haven't found the solution
> > to handle this one. As I've suggested previously, I would simply make
> > TLS support unconditional in Buildroot as soon as thread support is
> > enabled, and then mark libcap-ng as not available on AVR32. Of course,
> > if you have an external toolchain without TLS support, you're on your
> > own.
>
> As you say, we still don't appear to have reached a consensus of
> opinion on how to solve this.
Peter, can we agree on the following solution for this:
(1) Remove BR2_GCC_ENABLE_TLS, and enable TLS support unconditionally,
except when thread support is not enabled.
(2) Everywhere, assume that TLS support is always available when we
have thread support. If it's not the case (such as AVR32), mark
the package as "depends on !<architecture>".
Another solution is to add a config knob for the external toolchains.
> >> avr32 | util-linux-2.23.2 | NOK | http://autobuild.buildroot.net/results/2ba1bd78f4303ef2f543a4e4fa65d1b68ba3a765/
> >
> > Missing fallocate on avr32. Simon, what is the proposal to solve this?
> > Add fallocate support to 0.9.31 ?
>
> Yes, I'm working on backporting fallocate support to 0.9.31 now.
Great.
> >> avr32 | zeromq-3.2.4 | NOK | http://autobuild.buildroot.net/results/5cdf3e58df0df184f2ae1f2896c44f3f0f41c94d/
> >
> > Missing compiler intrinsics on AVR32. Problem already in the process of
> > being solved (Simon, Alexander).
>
> I think Alexander's patches have been applied now.
Yes.
> >> arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/64494152b75037a1194312a2a408eb7ecb6b56c8/
> >> arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/75f2cc531892e649599681433f62a1d76e5736c9/
> >> arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/65783df07ebb447f7561cb84b1bcf581a3084748/
> >> arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/14d441c5f3a50f61cd5a872711d09fda4e5f8bbd/
> >
> > Forgets to link against pthread. Simon, can you link into this?
>
> Yes, I'll have a look when I get a chance.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-10 8:43 ` Thomas Petazzoni
@ 2013-11-10 10:32 ` Baruch Siach
2013-11-10 15:21 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Baruch Siach @ 2013-11-10 10:32 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Sun, Nov 10, 2013 at 09:43:19AM +0100, Thomas Petazzoni wrote:
> On Sun, 10 Nov 2013 08:25:25 +0200, Baruch Siach wrote:
> > uClibc valloc() depends on UCLIBC_SUSV2_LEGACY which is not enabled in the
> > default uClibc config. Should we enable it?
>
> Yes. The UCLIBC_SUSV2_LEGACY symbol was added after 0.9.33.2, so it
> explains why only Xtensa (which uses the uClibc snapshot version) is
> affected.
I see if I can cook up a patch.
> Maybe we can replace the valloc() call with posix_memalign()
> and send the patch upstream to cdrkit?
cdrkit has not see a release in more than 3 years. There are probably other
packages making use of the obsolete valloc() routine, so I guess we want to
enable UCLIBC_SUSV2_LEGACY anyway.
> Also, can you sync up with Chris to provide a patch that makes Xtensa
> not use a snapshot version, but a fixed version of uClibc (based on a
> git commit, for example) ? The snapshot version we currently use is
> really bad, because depending on when you run the build, you will get
> different build results. This is really not how Buildroot should work:
> snapshot versions are only provided for expert users who want to test
> the latest versions of uClibc, such versions shouldn't be used as the
> default.
The original patch of Chris adding xtensa support (75720db3, xtensa: add
support for the Xtensa architecture) just disabled all other uClibc version
for xtensa. The uClibc snapshot just became the version of choice by default.
As far as I know any recent master branch commit id could reasonably be used.
Should we add an "xtensa only" uClibc version, like the "avr32 only (0.9.31)"
version that we now have? Hasn't Bernhard Reutner-Fischer declared some kind
of -rc in the uclibc mailing list
(http://lists.uclibc.org/pipermail/uclibc/2013-November/048069.html)?
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-09 18:15 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2013-11-09 20:46 ` Gustavo Zacarias
2013-11-10 6:25 ` Baruch Siach
@ 2013-11-10 10:32 ` Simon Dawson
2013-11-10 10:46 ` Thomas Petazzoni
2013-11-10 10:57 ` Gustavo Zacarias
` (5 subsequent siblings)
8 siblings, 1 reply; 416+ messages in thread
From: Simon Dawson @ 2013-11-10 10:32 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On 9 November 2013 18:15, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>> avr32 | libcap-ng-0.7.3 | NOK | http://autobuild.buildroot.net/results/3df16d60f6bbb679129cd568df4440be6f35cd9f/
>
> The missing TLS problem on AVR32. We still haven't found the solution
> to handle this one. As I've suggested previously, I would simply make
> TLS support unconditional in Buildroot as soon as thread support is
> enabled, and then mark libcap-ng as not available on AVR32. Of course,
> if you have an external toolchain without TLS support, you're on your
> own.
As you say, we still don't appear to have reached a consensus of
opinion on how to solve this.
>> avr32 | util-linux-2.23.2 | NOK | http://autobuild.buildroot.net/results/2ba1bd78f4303ef2f543a4e4fa65d1b68ba3a765/
>
> Missing fallocate on avr32. Simon, what is the proposal to solve this?
> Add fallocate support to 0.9.31 ?
Yes, I'm working on backporting fallocate support to 0.9.31 now.
>> avr32 | zeromq-3.2.4 | NOK | http://autobuild.buildroot.net/results/5cdf3e58df0df184f2ae1f2896c44f3f0f41c94d/
>
> Missing compiler intrinsics on AVR32. Problem already in the process of
> being solved (Simon, Alexander).
I think Alexander's patches have been applied now.
>> arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/64494152b75037a1194312a2a408eb7ecb6b56c8/
>> arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/75f2cc531892e649599681433f62a1d76e5736c9/
>> arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/65783df07ebb447f7561cb84b1bcf581a3084748/
>> arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/14d441c5f3a50f61cd5a872711d09fda4e5f8bbd/
>
> Forgets to link against pthread. Simon, can you link into this?
Yes, I'll have a look when I get a chance.
Simon.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-10 6:25 ` Baruch Siach
@ 2013-11-10 8:43 ` Thomas Petazzoni
2013-11-10 10:32 ` Baruch Siach
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2013-11-10 8:43 UTC (permalink / raw)
To: buildroot
Dear Baruch Siach,
On Sun, 10 Nov 2013 08:25:25 +0200, Baruch Siach wrote:
> > Chris, can you have a look at this one, since it's apparently a
> > Xtensa-specific problem?
>
> uClibc valloc() depends on UCLIBC_SUSV2_LEGACY which is not enabled in the
> default uClibc config. Should we enable it?
Yes. The UCLIBC_SUSV2_LEGACY symbol was added after 0.9.33.2, so it
explains why only Xtensa (which uses the uClibc snapshot version) is
affected. Maybe we can replace the valloc() call with posix_memalign()
and send the patch upstream to cdrkit?
Also, can you sync up with Chris to provide a patch that makes Xtensa
not use a snapshot version, but a fixed version of uClibc (based on a
git commit, for example) ? The snapshot version we currently use is
really bad, because depending on when you run the build, you will get
different build results. This is really not how Buildroot should work:
snapshot versions are only provided for expert users who want to test
the latest versions of uClibc, such versions shouldn't be used as the
default.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-09 18:15 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2013-11-09 20:46 ` Gustavo Zacarias
@ 2013-11-10 6:25 ` Baruch Siach
2013-11-10 8:43 ` Thomas Petazzoni
2013-11-10 10:32 ` Simon Dawson
` (6 subsequent siblings)
8 siblings, 1 reply; 416+ messages in thread
From: Baruch Siach @ 2013-11-10 6:25 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Sat, Nov 09, 2013 at 07:15:43PM +0100, Thomas Petazzoni wrote:
> If you're Cc'ed on this e-mail, it means that there is a question for
> you below. Here is a summary of who should look at what problems (note
> that some problems are not affected to anyone, either because the
> reason is unknown or because there is no clear "owner" for the problem):
>
> Markos Chandras aespipe, fdk-aac, gmp, libiscsi
> Sonic Zhang, Aaron Wu boost, icu, openpgm
> Chris Zankel cdrkit
> Peter Korsgaard gst1-plugins-bad, pulseaudio
> Gustavo Zacarias protobuf-c, mplayer, nettle (ARM), php
> Simon Dawson libcap-ng, util-linux, zeromq, zmqpp
> Spenser Gilliland libglib2, nettle (Microblaze), openssl
> Ezequiel Garcia libnspr
> Mischa Jonker pulseaudio, ti-utils
> Fatih A??c? qt5base
> Tzu-Jung Lee tstools
>
[snip]
> > xtensa | cdrkit-1.1.11 | NOK |
> > http://autobuild.buildroot.net/results/0315c117986f3aac8c0719d744cb47ee03738ee9/
>
> [ 58%] Building C object libhfs_iso/CMakeFiles/hfs_iso.dir/record.o
> ../libusal/libusal.a(scsi-remote.o):(.literal+0xe0): undefined reference to `valloc'
>
> Chris, can you have a look at this one, since it's apparently a
> Xtensa-specific problem?
uClibc valloc() depends on UCLIBC_SUSV2_LEGACY which is not enabled in the
default uClibc config. Should we enable it?
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-09 18:15 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2013-11-09 20:46 ` Gustavo Zacarias
2013-11-10 6:25 ` Baruch Siach
` (7 subsequent siblings)
8 siblings, 0 replies; 416+ messages in thread
From: Gustavo Zacarias @ 2013-11-09 20:46 UTC (permalink / raw)
To: buildroot
On 11/09/2013 03:15 PM, Thomas Petazzoni wrote:
>> x86_64 | host-protobuf-c-0.15 | NOK | http://autobuild.buildroot.net/results/5d163e750808f2fdd8098cb58240bada12b770a9/
>> mips64el | host-protobuf-c-0.15 | NOK | http://autobuild.buildroot.net/results/038340dfbbbedbcfcb98ad5dbf828bc03fe26af6/
>
> Weird compilation problem, seems really caused by an issue in
> protobuf-c itself. Gustavo, you're the one who added protobuf-c, can
> you have a look at this?
What's the host gcc version / distribution?
I suspect that's at work since the only dep for protobuf-c is
host-protobuf and the host toolchain.
>> arm | mplayer-1.1.1 | NOK | http://autobuild.buildroot.net/results/8f946e28b11b2ab1ba0d9688286c665488de0486/
>
> libmpeg2/motion_comp_arm_s.S: Assembler messages:
> libmpeg2/motion_comp_arm_s.S:29: Error: selected processor does not support ARM mode `pld [r1]'
> libmpeg2/motion_comp_arm_s.S:39: Error: selected processor does not support ARM mode `pld [r1]'
>
> That's an ARMv4t configuration. Maybe building mplayer on ARMv4t is not
> possible. Adding a bunch of depends on !BR2_arm<something> is probably
> the solution here. Gustavo, maybe?
Likely the best option, there's probably not much point in using mplayer
on anything lower than ARMv6 IMHO (or maybe v5 with hard FP) for
performance reasons.
I'll disable it for anything lower than v5.
>> microblaze | nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/82acbea862ee0bb5288ab498d86772bc475d3a53/
>> arm | nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/88ea0cc0815f865e1a144d39231fdc9b47e689b0/
>
> On Microblaze, a compiler error. Should be fixed by the internal
> toolchain support for Microblaze. Waiting for Spenser on this :)
>
> On ARM, the failure is due to nettle tests requiring C++ support. It
> would be good to disable the compilation of those tests. Gustavo,
> you're the one looking after nettle in general, can you look into this?
Actually it's a problem with static linking with C++ since the nettle
test that uses C++ is conditional on AC_PROG_CXX and works happily fine
without static linking.
The problem is that you're not handling static libs in
package/gcc/gcc-final/gcc-final.mk from HOST_GCC_FINAL_USR_LIBS, only
shared ones, hence libstdc++.a is missing since it's not copied anywhere
else (from the gcc packaging, might have been that way too before it).
No happy C++ for static users :(
Care to concoct a patch or shall i?
>> aarch64 | php-5.3.27 | NOK | http://autobuild.buildroot.net/results/08d3255303f7ceda8a1ecfcf56ad665f00829632/
>
> /usr/include/bits/predefs.h:20:3: error: #error "Never use <bits/predefs.h> directly; include <features.h> instead."
> # error "Never use <bits/predefs.h> directly; include <features.h> instead."
>
> Gustavo, you like PHP, no ? :-)
You keep assuming i like things because i tweak/touch them :)
PHP isn't to blame here, don't pick on the big kid, predefs.h isn't even
mentioned in any of the files of the whole php tarball.
Guess it's the toolchain or some package that's used by php, i'll look
into it but really aarch64 on a gut feeling i'll say it's the toolchain.
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-11-09 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2013-11-08 Thomas Petazzoni
@ 2013-11-09 18:15 ` Thomas Petazzoni
2013-11-09 20:46 ` Gustavo Zacarias
` (8 more replies)
0 siblings, 9 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2013-11-09 18:15 UTC (permalink / raw)
To: buildroot
Hello all,
If you're Cc'ed on this e-mail, it means that there is a question for
you below. Here is a summary of who should look at what problems (note
that some problems are not affected to anyone, either because the
reason is unknown or because there is no clear "owner" for the problem):
Markos Chandras aespipe, fdk-aac, gmp, libiscsi
Sonic Zhang, Aaron Wu boost, icu, openpgm
Chris Zankel cdrkit
Peter Korsgaard gst1-plugins-bad, pulseaudio
Gustavo Zacarias protobuf-c, mplayer, nettle (ARM), php
Simon Dawson libcap-ng, util-linux, zeromq, zmqpp
Spenser Gilliland libglib2, nettle (Microblaze), openssl
Ezequiel Garcia libnspr
Mischa Jonker pulseaudio, ti-utils
Fatih A??c? qt5base
Tzu-Jung Lee tstools
Thanks!
Thomas
On Sat, 9 Nov 2013 08:30:28 +0100 (CET), Thomas Petazzoni wrote:
> Detail of failures
> ===================
>
> mips | aespipe-2.4c | NOK | http://autobuild.buildroot.net/results/da0268df99b9bf920d88121e7c3d33d41a57d951/
Unknown problem (error: C compiler cannot create executables). Markos,
as our MIPS guy, can you have a look at this one?
> arm | alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/983828bd27a521020e42e58cce9393e6b8d23502/
It was a wrong toolchain configuration, with a weird toolchain.
I've removed the toolchain from the autobuilders.
> powerpc | alsa-utils-1.0.26 | NOK | http://autobuild.buildroot.net/results/1c6a33e75fe0617e01d7413cdfd5fbd466f822d4/
Missing link against -lrt for static linking.
> arm | alsa-utils-1.0.26 | NOK | http://autobuild.buildroot.net/results/6123186a66bbea833ab2fa980346f16825b22d21/
checking for snd_ctl_open in -lasound... no
configure: error: No linkable libasound was found.
make: *** [/home/test/test/3/output/build/alsa-utils-1.0.26/.stamp_configured] Error 1
Weird, don't know what's happening here.
> arm | audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/6aff0a6b9c7b2890cc069868b041ed74e549933b/
This was my funky toolchain (same as alsa-lib problem above). Toolchain
removed from the autobuilders.
> xtensa | binutils-2.22 | NOK | http://autobuild.buildroot.net/results/11de6f161585c12148c1b2b4fc8ab830183edfe9/
> xtensa | binutils-2.22 | NOK | http://autobuild.buildroot.net/results/2d3d255b2d3ae1456a377dbc03f695b7adf010e8/
This is fixed by http://patchwork.ozlabs.org/patch/289532/, which
hasn't been committed yet. It will also require a rebuild of the
toolchain in the autobuilders.
Peter, can you commit this patch?
> bfin | boost-1.54.0 | NOK | http://autobuild.buildroot.net/results/84f9d9d2b6b5356984c6d59aad5e28b3e7847651/
Don't know what's going on. Sonic, Aaron, can you have a look?
> arm | busybox-1.21.1 | NOK | http://autobuild.buildroot.net/results/116d13f7489981c39c3759eaf8302be4d795f339/
This was my weird toolchain (same problem as alsa-lib). Toolchain
removed from the autobuilders.
> xtensa | cdrkit-1.1.11 | NOK | http://autobuild.buildroot.net/results/0315c117986f3aac8c0719d744cb47ee03738ee9/
[ 58%] Building C object libhfs_iso/CMakeFiles/hfs_iso.dir/record.o
../libusal/libusal.a(scsi-remote.o):(.literal+0xe0): undefined reference to `valloc'
Chris, can you have a look at this one, since it's apparently a
Xtensa-specific problem?
> mipsel | fdk-aac-0.1.2 | NOK | http://autobuild.buildroot.net/results/cb87635832f4a1128f174a25c264f716399c52d4/
MIPS specific problem. We're building for mips1, but fdk-aac uses some
instructions not available on mips1. Maybe we should only enable
fdk-aac for some more capable variant of MIPS instruction sets.
Markos, can you have a look at this one?
> bfin | fontconfig-2.6.0 | NOK | http://autobuild.buildroot.net/results/8579cb481e86dcae0988379c5781bd00f4e70809/
fontconfig forgets to link against libpng. Anyone willing to fix this?
> mips | gmp-5.1.3 | NOK | http://autobuild.buildroot.net/results/69b0804cbfbb24c70f90435a37fb56a118247a57/
configure: error: could not find a working compiler, see config.log for details
Markos, can you have a look?
> arm | gst1-plugins-bad-1.2.0 | NOK | http://autobuild.buildroot.net/results/b99eb6a9067cee885da88bff64ee447c37e31e0c/
> arm | gst1-plugins-bad-1.2.0 | NOK | http://autobuild.buildroot.net/results/b320bb61650c58e9c855e3136f5f6d7bf5e4ef56/
Same problem in both cases, related to the DirectFB plugin. Peter, you
are the one taking care of Gstreamer most of the time, can you have a
look into this?
> x86_64 | host-protobuf-c-0.15 | NOK | http://autobuild.buildroot.net/results/5d163e750808f2fdd8098cb58240bada12b770a9/
> mips64el | host-protobuf-c-0.15 | NOK | http://autobuild.buildroot.net/results/038340dfbbbedbcfcb98ad5dbf828bc03fe26af6/
Weird compilation problem, seems really caused by an issue in
protobuf-c itself. Gustavo, you're the one who added protobuf-c, can
you have a look at this?
> bfin | icu-51.2 | NOK | http://autobuild.buildroot.net/results/e0a1130feb1784b3d4fefe1224943d93409a3494/
> bfin | icu-51.2 | NOK | http://autobuild.buildroot.net/results/85c082a693ef795cecf0ef9204b7c9c0850d4b74/
Problem building icu on Blackfin:
*** ERROR - configure could not detect your platform
Sonic, Zhang, can you have a look into this?
> avr32 | libcap-ng-0.7.3 | NOK | http://autobuild.buildroot.net/results/3df16d60f6bbb679129cd568df4440be6f35cd9f/
The missing TLS problem on AVR32. We still haven't found the solution
to handle this one. As I've suggested previously, I would simply make
TLS support unconditional in Buildroot as soon as thread support is
enabled, and then mark libcap-ng as not available on AVR32. Of course,
if you have an external toolchain without TLS support, you're on your
own.
> microblaze | libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/6f0066f56f10d3f17023e698fd3ba1bd2d00c4c1/
> microblaze | libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/79d2df836063167f12f5bba177297a041bb7c16f/
Missing compiler intrinsics and fallocate in the Microblaze toolchain.
We're waiting for Spenser Gilliland to finish the Microblaze internal
toolchain support, so that we can ditch the crappy Microblaze external
toolchains.
> mips64el | libiscsi-1.6.0 | NOK | http://autobuild.buildroot.net/results/39e8e0ebbeb196276492b928b41cc0b0fe1e9ec3/
> mips64el | libiscsi-1.6.0 | NOK | http://autobuild.buildroot.net/results/efb87b17c49170f6377631371438911b18029cea/
The usual problem of ld being used instead of gcc, causing problem on
mips64el. However, you can't do partial linking with gcc, so a libtool
fix is needed.
Markos, I know you've identified the libtool fix for this. Could you
backport it on top of libtool 2.4.2 (that we have in Buildroot), add it
as a patch in package/libtool/, and then mark LIBISCSI_AUTORECONF =
YES so that the libtool stuff gets regenerated with a known-working
version?
> nios2 | libnspr-4.9.6 | NOK | http://autobuild.buildroot.net/results/8c01fdaac7afa00bd1117c79ae047344242d1463/
> nios2 | libnspr-4.9.6 | NOK | http://autobuild.buildroot.net/results/a418145d72e92f64956518bb2786e33dadd08a86/
NIOS2 support missing in libnspr. Ezequiel, can you look into this?
Normally, adding an architecture support in libnspr is really easy, so
adding a patch to libnspr should be feasible.
> aarch64 | libv4l-0.8.9 | NOK | http://autobuild.buildroot.net/results/4de7dc58e826d1dd60add2821f774c9c5f5a2a71/
Package needs to be bumped, I have already started working on this.
> arm | mplayer-1.1.1 | NOK | http://autobuild.buildroot.net/results/8f946e28b11b2ab1ba0d9688286c665488de0486/
libmpeg2/motion_comp_arm_s.S: Assembler messages:
libmpeg2/motion_comp_arm_s.S:29: Error: selected processor does not support ARM mode `pld [r1]'
libmpeg2/motion_comp_arm_s.S:39: Error: selected processor does not support ARM mode `pld [r1]'
That's an ARMv4t configuration. Maybe building mplayer on ARMv4t is not
possible. Adding a bunch of depends on !BR2_arm<something> is probably
the solution here. Gustavo, maybe?
> arm | ne10-88c18f02199947b2c8b577... | NOK | http://autobuild.buildroot.net/results/3631f7e9dad9fab356d31160ac95b7d0fec70ce2/
Needs NEON support apparently. Should be something for me.
> microblaze | nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/82acbea862ee0bb5288ab498d86772bc475d3a53/
> arm | nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/88ea0cc0815f865e1a144d39231fdc9b47e689b0/
On Microblaze, a compiler error. Should be fixed by the internal
toolchain support for Microblaze. Waiting for Spenser on this :)
On ARM, the failure is due to nettle tests requiring C++ support. It
would be good to disable the compilation of those tests. Gustavo,
you're the one looking after nettle in general, can you look into this?
> bfin | openpgm-5.1.118~dfsg | NOK | http://autobuild.buildroot.net/results/120b7de960a04def5c53b59644eefc598bd0a1d4/
Blackfin does not have getifaddrs():
getifaddrs.c:853:3: error: #error "Unsupported interface enumeration on this platform."
Not sure how to handle this uClibc configuration difference, except by
adding "depends on !" to exclude the specific Blackfin toolchains
causing problems.
> microblaze | openssl-1.0.1e | NOK | http://autobuild.buildroot.net/results/f313ac3233a8ed5b3087936c1cd8408a00fdf2bb/
Compiler error. Spenser, we need your patches!
> aarch64 | php-5.3.27 | NOK | http://autobuild.buildroot.net/results/08d3255303f7ceda8a1ecfcf56ad665f00829632/
/usr/include/bits/predefs.h:20:3: error: #error "Never use <bits/predefs.h> directly; include <features.h> instead."
# error "Never use <bits/predefs.h> directly; include <features.h> instead."
Gustavo, you like PHP, no ? :-)
> arc | pulseaudio-4.0 | NOK | http://autobuild.buildroot.net/results/281ff1c8046b7e93759c5f51995f34788e717fad/
checking for atomic_ops.h... no
configure: error: *** libatomic-ops headers not found
make: *** [/home/test/test/1/output/build/pulseaudio-4.0/.stamp_configured] Error 1
For some reason, on ARC, atomic_ops is needed. Why not on other
architectures? Peter, Mischa, any idea?
> powerpc | qt-4.8.5 | NOK | http://autobuild.buildroot.net/results/0ee61f71e61f2215a15e4655a4e22d0521334c35/
Will be fixed by my patch that prevents building parts of Qt on some
unsupported architectures.
> i686 | qt5base-5.1.1 | NOK | http://autobuild.buildroot.net/results/bbe7d79da059fdf67fb29880b8539ca2320ba86d/
> arm | qt5base-5.1.1 | NOK | http://autobuild.buildroot.net/results/37613281f21895716ceaf64654e175148d7f543c/
> i686 | qt5base-5.1.1 | NOK | http://autobuild.buildroot.net/results/555278227680e90737e6dbe0a6dcc035507150aa/
For
http://autobuild.buildroot.net/results/37613281f21895716ceaf64654e175148d7f543c/build-end.log,
Samuel has already sent a patch
(http://patchwork.ozlabs.org/patch/289999/). The other two ones:
http://autobuild.buildroot.net/results/555278227680e90737e6dbe0a6dcc035507150aa/build-end.log
(sqlite problem)
http://autobuild.buildroot.net/results/bbe7d79da059fdf67fb29880b8539ca2320ba86d/build-end.log
(inlining problem)
are not fixed. Fatih, would you mind having a look?
> arc | ti-utils-06dbdb2727354b5f3a... | NOK | http://autobuild.buildroot.net/results/63d294574b053aa4e2148fbc3185c5594d925ae9/
{standard input}: Assembler messages:
{standard input}:1680: Error: missing operand
{standard input}:1680: Error: junk at end of line: `@plt_tx_bip.part.8'
ARC toolchain problem, for Mischa.
> x86_64 | tstools-1_11 | NOK | http://autobuild.buildroot.net/results/ce02d7fb9ae3aa06eaf53db39cbef27c051b525d/
Should use gcc for linking and not ld + missing -lm. Tzu-Jung Lee,
you're the one who added tstools, can you have a look at this problem?
> avr32 | util-linux-2.23.2 | NOK | http://autobuild.buildroot.net/results/2ba1bd78f4303ef2f543a4e4fa65d1b68ba3a765/
Missing fallocate on avr32. Simon, what is the proposal to solve this?
Add fallocate support to 0.9.31 ?
> arm | valgrind-3.8.1 | NOK | http://autobuild.buildroot.net/results/f174541ac06aeeac82b8399686a8d4371532760d/
/tmp/cceJNtCh.s: Assembler messages:
/tmp/cceJNtCh.s:200: Error: r15 not allowed here -- `str r15,[r3,#+0]'
make[4]: *** [libcoregrind_arm_linux_a-m_libcassert.o] Error 1
make[4]: *** Waiting for unfinished jobs....
Not sure what's going on here. Anyone to have a look?
> avr32 | zeromq-3.2.4 | NOK | http://autobuild.buildroot.net/results/5cdf3e58df0df184f2ae1f2896c44f3f0f41c94d/
Missing compiler intrinsics on AVR32. Problem already in the process of
being solved (Simon, Alexander).
> arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/64494152b75037a1194312a2a408eb7ecb6b56c8/
> arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/75f2cc531892e649599681433f62a1d76e5736c9/
> arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/65783df07ebb447f7561cb84b1bcf581a3084748/
> arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/14d441c5f3a50f61cd5a872711d09fda4e5f8bbd/
Forgets to link against pthread. Simon, can you link into this?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-08-29 15:12 ` Thomas De Schampheleire
2013-08-30 9:26 ` Jérôme Pouiller
@ 2013-08-30 11:08 ` Thomas Petazzoni
1 sibling, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2013-08-30 11:08 UTC (permalink / raw)
To: buildroot
Dear Thomas De Schampheleire,
On Thu, 29 Aug 2013 17:12:14 +0200, Thomas De Schampheleire wrote:
> Thomas, can you save the strongswan build output somewhere, or check
> the output of the above checks and the value of HAVE_BACKTRACE ?
So, in the failing case, for some reason, it detects that backtrace
support is available:
[...]
checking for library containing backtrace... none required
checking for backtrace... yes
[...]
Relevant config.log output:
configure:16457: /home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/usr/bin/x86_64-unknown-linux-uclibc-gcc -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pipe -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -L/usr/lib conftest.c >&5
/home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-unknown-linux-uclibc/4.6.3/../../../../x86_64-unknown-linux-uclibc/bin/ld: warning: libc.so.0, needed by /home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-unknown-linux-uclibc/4.6.3/../../../../x86_64-unknown-linux-uclibc/lib/../lib64/libgcc_s.so, may conflict with libc.so.6
/home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/lib64/libc.so.0: warning: the `gets' function is dangerous and should not be used.
/home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/lib64/libc.so.0: warning: the `getpw' function is dangerous and should not be used.
/home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/lib64/libc.so.0: warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp'
/home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/lib64/libc.so.0: warning: the use of `tmpnam_r' is dangerous, better use `mkstemp'
/home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/lib64/libc.so.0: warning: warning: `siggetmask' is obsolete; `sigprocmask' is best
/home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/lib64/libc.so.0: warning: the use of `tmpnam' is dangerous, better use `mkstemp'
/home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/lib64/libc.so.0: warning: the use of `tempnam' is dangerous, better use `mkstemp'
configure:16457: $? = 0
configure:16457: result: yes
I believe the problem is caused by the -L/usr/lib. Since both the
target and host have the same architecture (x86-64), it probably links
with the host C library for this test (which has backtrace support)
instead of the target C library (which doesn't have it).
It is caused by the AC_LIB_PREFIX macro that provides the
--with-lib-prefix and --without-lib-prefix options, and that by default
adds ${prefix}/lib and ${prefix}/include to LDFLAGS and CPPFLAGS
respectively.
I've just sent a patch that passes --without-lib-prefix, as it fixes
the build failure.
Thanks,
Thomas Petazzoni
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-08-29 15:12 ` Thomas De Schampheleire
@ 2013-08-30 9:26 ` Jérôme Pouiller
2013-08-30 11:08 ` Thomas Petazzoni
1 sibling, 0 replies; 416+ messages in thread
From: Jérôme Pouiller @ 2013-08-30 9:26 UTC (permalink / raw)
To: buildroot
On 2013-08-29 17:12, Thomas De Schampheleire wrote:
> On Thu, Aug 29, 2013 at 3:17 PM, J?r?me Pouiller <jezz@sysmic.org>
> wrote:
>> On 2013-08-28 09:08, Thomas Petazzoni wrote:
>>>> x86_64 | strongswan-5.0.4 | NOK |
>>>>
>>>> http://autobuild.buildroot.net/results/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/
>>>
>>>
>>> utils/backtrace.c:23:23: fatal error: execinfo.h: No such file or
>>> directory
>>>
>>> uClibc doesn't have execinfo.h by default. Proper testing should be
>>> added in strongswan code. J?r?me, can you have a look at this?
>>
>>
>> I track down this error for some time but I can't reproduce it.
>>
>> There is a test in ./configure that disable inclusion of execinfo.h
>> if
>> backtrace()
>> is not found. When re-run autobuilder configuration, this check is
>> correctly
>> executed and execinfo.h is not included.
>>
>> Is anyone else can reproduce it?
>
> I also cannot reproduce it. In my test build HAVE_BACKTRACE is set to
> 1 in config.h, and in the configure output I see:
>
> checking for library containing backtrace... none required
> checking for backtrace... yes
I have "checking for backtrace... no". I think, you can reproduce the
bug with
this configuration.
On my side, I retry with patch called "Fix build reproducibility with
Make 3.82"
I sent one hour ago.
--
J?r?me Pouiller, Sysmic
Embedded Linux specialist
http://www.sysmic.fr
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-08-29 13:17 ` Jérôme Pouiller
@ 2013-08-29 15:12 ` Thomas De Schampheleire
2013-08-30 9:26 ` Jérôme Pouiller
2013-08-30 11:08 ` Thomas Petazzoni
0 siblings, 2 replies; 416+ messages in thread
From: Thomas De Schampheleire @ 2013-08-29 15:12 UTC (permalink / raw)
To: buildroot
Hi J?r?me,
On Thu, Aug 29, 2013 at 3:17 PM, J?r?me Pouiller <jezz@sysmic.org> wrote:
> Hi Thomas,
>
> On 2013-08-28 09:08, Thomas Petazzoni wrote:
> [...]
>
>>> x86_64 | strongswan-5.0.4 | NOK |
>>> http://autobuild.buildroot.net/results/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/
>>
>>
>> utils/backtrace.c:23:23: fatal error: execinfo.h: No such file or
>> directory
>>
>> uClibc doesn't have execinfo.h by default. Proper testing should be
>> added in strongswan code. J?r?me, can you have a look at this?
>
>
> I track down this error for some time but I can't reproduce it.
>
> There is a test in ./configure that disable inclusion of execinfo.h if
> backtrace()
> is not found. When re-run autobuilder configuration, this check is correctly
> executed and execinfo.h is not included.
>
> Is anyone else can reproduce it?
I also cannot reproduce it. In my test build HAVE_BACKTRACE is set to
1 in config.h, and in the configure output I see:
checking for library containing backtrace... none required
checking for backtrace... yes
Thomas, can you save the strongswan build output somewhere, or check
the output of the above checks and the value of HAVE_BACKTRACE ?
Thanks,
Thomas
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-08-28 7:08 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (5 preceding siblings ...)
2013-08-28 21:29 ` Arnout Vandecappelle
@ 2013-08-29 13:17 ` Jérôme Pouiller
2013-08-29 15:12 ` Thomas De Schampheleire
6 siblings, 1 reply; 416+ messages in thread
From: Jérôme Pouiller @ 2013-08-29 13:17 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On 2013-08-28 09:08, Thomas Petazzoni wrote:
[...]
>> x86_64 | strongswan-5.0.4 | NOK |
>> http://autobuild.buildroot.net/results/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/
>
> utils/backtrace.c:23:23: fatal error: execinfo.h: No such file or
> directory
>
> uClibc doesn't have execinfo.h by default. Proper testing should be
> added in strongswan code. J?r?me, can you have a look at this?
I track down this error for some time but I can't reproduce it.
There is a test in ./configure that disable inclusion of execinfo.h if
backtrace()
is not found. When re-run autobuilder configuration, this check is
correctly
executed and execinfo.h is not included.
Is anyone else can reproduce it?
[...]
--
J?r?me Pouiller, Sysmic
Embedded Linux specialist
http://www.sysmic.fr
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-08-28 7:08 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (4 preceding siblings ...)
2013-08-28 21:09 ` Arnout Vandecappelle
@ 2013-08-28 21:29 ` Arnout Vandecappelle
2013-08-29 13:17 ` Jérôme Pouiller
6 siblings, 0 replies; 416+ messages in thread
From: Arnout Vandecappelle @ 2013-08-28 21:29 UTC (permalink / raw)
To: buildroot
On 08/28/13 09:08, Thomas Petazzoni wrote:
>> i686 | bash-4.2 | NOK |http://autobuild.buildroot.net/results/b85caa22ddc13bdaaac25b9016fe902ade5027de/
> ./mksyntax -o syntax.c
> make[1]: execvp: ./mksyntax: Permission denied
> ./mksignames lsignames.h
>
> Strange. Missing executable permissions on this program? Why does it
> happen only rarely?
Parallel build problem. mksyntax is built twice, and is sometimes
executed while it is being rebuilt. I can't immediately see the problem
in the Makefile.in, though.
Non-parallel build takes about the twice the time of the configure
step, so I guess that's the easiest way out.
Patch follows.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-08-28 7:08 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (3 preceding siblings ...)
2013-08-28 11:45 ` Markos Chandras
@ 2013-08-28 21:09 ` Arnout Vandecappelle
2013-08-28 21:29 ` Arnout Vandecappelle
2013-08-29 13:17 ` Jérôme Pouiller
6 siblings, 0 replies; 416+ messages in thread
From: Arnout Vandecappelle @ 2013-08-28 21:09 UTC (permalink / raw)
To: buildroot
On 08/28/13 09:08, Thomas Petazzoni wrote:
>> x86_64 | gpsd-3.9 | NOK |http://autobuild.buildroot.net/results/d58be37b9b18b37eab4acec9a6bbe28863ef4d22/
> scons: *** [gpsd] Implicit dependency `/home/test/test/2/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libm.so' not found, needed by target `gpsd'.
>
> Not sure what's happening here. Surely if -lm was missing, we would be
> seeing more build failures of gpsd, no?
This one should be fixed by 5628776c4a4d29d0715633ea463b64cc19e19c5a.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-08-28 13:13 ` Thomas De Schampheleire
@ 2013-08-28 13:21 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2013-08-28 13:21 UTC (permalink / raw)
To: buildroot
Dear Thomas De Schampheleire,
On Wed, 28 Aug 2013 15:13:40 +0200, Thomas De Schampheleire wrote:
> >> Good idea! Ideally we can get them to 0, so that from that point
> >> onwards any autobuild failure becomes a clear focus point.
> >
> > Agreed. Though we have to keep in mind that the release is in 3 days,
> > and after that 'next' will be merged in master, and we'll have plenty
> > of new autobuilder failures to look at.
>
> I don't think we will be able to fix everything before the release. So
> after next is merged in, we should try fixing the new problems as soon
> as possible, in addition to the current ones.
Right, but isn't this what we are all continuously doing? :-)
> Have you heard of the 'stop&fix' principle? The idea is that no new
> patches are accepted when there are existing failures, and all
> developers are expected to help in fixing the problem before doing
> anything else.
I had never heard of it as a formal principle with the 'stop&fix' name,
but it obviously looks like a natural solution to try to get some
attention from the developers. I'm not sure we want to get this far,
especially since some of the issues are quite complex, need some
discussion, etc.
I'm also using the autobuilders to progressively 'push' for more
coverage of some specific use-cases. For example, in the past, there
were never BR2_PREFER_STATIC_LIB builds, and I introduced that a few
months ago. I knew it would generate a lot of new autobuilder failures,
but that was the only way to make sure this feature is properly
supported. And I think it actually worked: people have contributed a
lot of patches to progressively fix static build problems, and the
situation has improved a lot.
One of the next thing I'll probably add is random usage of ccache, to
catch problems such as the "$(CC)" problem you fixed this morning.
So if our goal is really 0 failures, it can certainly be achieved
easily by removing the most exotic configurations from the
autobuilders, but I'm not sure if it's really a desirable goal. On the
other side, having too many failures in the autobuilders is very
discouraging and nobody wants to fix failures when they are hundreds of
them.
> >> >> powerpc | media-ctl-ac40b79f002a2315f... | NOK | http://autobuild.buildroot.net/results/7bcab9b94a81b89789dc1cabe9f6940ed4f5ea51/
> >> >
> >> > Too old kernel headers in toolchain. Options:
> >> >
> >> > 1/ Add an exception in the autobuilder script.
> >> >
> >> > 2/ Modify media-ctl to integrate the necessary kernel headers and use
> >> > them when not available from the toolchain.
> >> >
> >> > I'm inclined to favor 1/.
> >>
> >> I once took a look at this. The media-ctl package already has some
> >> copies of kernel headers to deal with older kernels. There was a check
> >> in configure to detect this, IIRC. The stupid thing was that the
> >> headers in the media-ctl sources would be applied unconditionally.
> >> My intent was to patch media-ctl to provide also this missing header,
> >> and cleanup the stupidity described. Unfortunately I didn't continue
> >> this yet.
> >>
> >> What exactly do you mean with approach 1/? Forcing a recent kernel
> >> when building media-ctl?
> >> That doesn't solve the problem for other users that try to enable
> >> media-ctl on older kernels, right?
> >
> > By 1/ I meant to not fix the problem, and only avoid it in the
> > autobuilders by making sure that when a non-suitable toolchain (too old
> > kernel headers) is used to build media-ctl, then we exclude media-ctl
> > from the build. I already have quite a few of such exclusions. What I
> > find not very nice is that the set of exclusions is not documented
> > anywhere, while they should be documented as "Known issues", or
> > something like that.
>
> I think this can be a good solution. Some problems are either too
> complex to fix in buildroot and are really problems of upstream
> packages, or some problems are exhibited in such exotic configurations
> that no-one really cares about, or problems are caused by old
> toolchains/kernels that could be upgraded by the user.
>
> In these cases, a 'Known issues' + autobuild check may be better than
> leaving the autobuild fail continuously. Users that bump into such an
> issue, and do want to have a solution, can bring up the issue on the
> mailing list and help look for a real solution.
>
> Of course it's not the solution to add each build failure to the known
> issue, because then buildroot becomes useless. But I'm sure we can
> have good judgement here by the community members.
I fully agree.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-08-28 11:55 ` Thomas Petazzoni
@ 2013-08-28 13:13 ` Thomas De Schampheleire
2013-08-28 13:21 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Thomas De Schampheleire @ 2013-08-28 13:13 UTC (permalink / raw)
To: buildroot
On Wed, Aug 28, 2013 at 1:55 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Wed, 28 Aug 2013 13:31:38 +0200, Thomas De Schampheleire wrote:
>
>> > We don't have that many build failures today, so let's have a look
>> > together at each of them and see what we can do about them.
>>
>> Good idea! Ideally we can get them to 0, so that from that point
>> onwards any autobuild failure becomes a clear focus point.
>
> Agreed. Though we have to keep in mind that the release is in 3 days,
> and after that 'next' will be merged in master, and we'll have plenty
> of new autobuilder failures to look at.
I don't think we will be able to fix everything before the release. So
after next is merged in, we should try fixing the new problems as soon
as possible, in addition to the current ones.
Have you heard of the 'stop&fix' principle? The idea is that no new
patches are accepted when there are existing failures, and all
developers are expected to help in fixing the problem before doing
anything else.
>
>> >> powerpc | media-ctl-ac40b79f002a2315f... | NOK | http://autobuild.buildroot.net/results/7bcab9b94a81b89789dc1cabe9f6940ed4f5ea51/
>> >
>> > Too old kernel headers in toolchain. Options:
>> >
>> > 1/ Add an exception in the autobuilder script.
>> >
>> > 2/ Modify media-ctl to integrate the necessary kernel headers and use
>> > them when not available from the toolchain.
>> >
>> > I'm inclined to favor 1/.
>>
>> I once took a look at this. The media-ctl package already has some
>> copies of kernel headers to deal with older kernels. There was a check
>> in configure to detect this, IIRC. The stupid thing was that the
>> headers in the media-ctl sources would be applied unconditionally.
>> My intent was to patch media-ctl to provide also this missing header,
>> and cleanup the stupidity described. Unfortunately I didn't continue
>> this yet.
>>
>> What exactly do you mean with approach 1/? Forcing a recent kernel
>> when building media-ctl?
>> That doesn't solve the problem for other users that try to enable
>> media-ctl on older kernels, right?
>
> By 1/ I meant to not fix the problem, and only avoid it in the
> autobuilders by making sure that when a non-suitable toolchain (too old
> kernel headers) is used to build media-ctl, then we exclude media-ctl
> from the build. I already have quite a few of such exclusions. What I
> find not very nice is that the set of exclusions is not documented
> anywhere, while they should be documented as "Known issues", or
> something like that.
I think this can be a good solution. Some problems are either too
complex to fix in buildroot and are really problems of upstream
packages, or some problems are exhibited in such exotic configurations
that no-one really cares about, or problems are caused by old
toolchains/kernels that could be upgraded by the user.
In these cases, a 'Known issues' + autobuild check may be better than
leaving the autobuild fail continuously. Users that bump into such an
issue, and do want to have a solution, can bring up the issue on the
mailing list and help look for a real solution.
Of course it's not the solution to add each build failure to the known
issue, because then buildroot becomes useless. But I'm sure we can
have good judgement here by the community members.
>
> For reference, here is the current set of tweaks that I apply to the
> randpackageconfig before starting the build. Note that when "return
> False" is used, it means that the configuration is rejected and not
> built, so a completely different random configuration will be tried.
>
> # Make sure Qt license is approved
> if "BR2_PACKAGE_QT=y\n" in config_items:
> if "# BR2_PACKAGE_QT_LICENSE_APPROVED is not set\n" in config_items:
> config_items.remove("# BR2_PACKAGE_QT_LICENSE_APPROVED is not set\n")
> config_items.append("BR2_PACKAGE_QT_LICENSE_APPROVED=y\n")
> if "BR2_PACKAGE_QT5BASE=y\n" in config_items:
> if "# BR2_PACKAGE_QT5BASE_LICENSE_APPROVED is not set\n" in config_items:
> config_items.remove("# BR2_PACKAGE_QT5BASE_LICENSE_APPROVED is not set\n")
> config_items.append("BR2_PACKAGE_QT5BASE_LICENSE_APPROVED=y\n")
> # Make sure LTP is not enabled when we have an uClibc toolchain
> if "BR2_PACKAGE_LTP_TESTSUITE=y\n" in config_items and \
> toolchain_is_uclibc(config_items):
> config_items.remove("BR2_PACKAGE_LTP_TESTSUITE=y\n")
> # Make sure xfsprogs is not enabled when we have an uClibc toolchain
> if "BR2_PACKAGE_XFSPROGS=y\n" in config_items and \
> toolchain_is_uclibc(config_items):
> config_items.remove("BR2_PACKAGE_XFSPROGS=y\n")
> # Make sure mrouted is not enabled when we have an uClibc toolchain
> if "BR2_PACKAGE_MROUTED=y\n" in config_items and \
> toolchain_is_uclibc(config_items):
> config_items.remove("BR2_PACKAGE_MROUTED=y\n")
> if 'BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/ctng-mips64-eglibc.tar.bz2"\n' in config_items and \
> "BR2_PACKAGE_SQUID=y\n" in config_items:
> # Reject this configuration
> return False
> if 'BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-mipsel-o32-full.tar.bz2"\n' in config_items and \
> "BR2_PACKAGE_SQUID=y\n" in config_items:
> # Reject this configuration
> return False
> if 'BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_MIPS44=y\n' in config_items and \
> "BR2_PACKAGE_SQUID=y\n" in config_items:
> # Reject this configuration
> return False
> if 'BR2_PACKAGE_CLASSPATH=y\n' in config_items:
> # Reject this configuration
> return False
> if 'BR2_sh2a=y\n' in config_items and 'BR2_PACKAGE_LIBFFI=y\n' in config_items:
> return False
> if 'BR2_arc=y\n' in config_items and 'BR2_PACKAGE_LIBFFI=y\n' in config_items:
> return False
> if 'BR2_PACKAGE_SUNXI_BOARDS=y\n' in config_items:
> config_items.remove("# BR2_PACKAGE_SUNXI_BOARDS_FEX_FILE is not set\n")
> config_items.append('BR2_PACKAGE_SUNXI_BOARDS_FEX_FILE="a10/hackberry.fex"\n')
>
Best regards,
Thomas
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-08-28 11:45 ` Markos Chandras
@ 2013-08-28 12:07 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2013-08-28 12:07 UTC (permalink / raw)
To: buildroot
Dear Markos Chandras,
On Wed, 28 Aug 2013 12:45:58 +0100, Markos Chandras wrote:
> Hi Thomas,
>
> On 28 August 2013 08:08, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> >
> >> mips64el | directfb-1.6.3 | NOK | http://autobuild.buildroot.net/results/fab819eee4002a9c392c48c1ebaca5c5b6555567/
> >
> > (cd .libs/libdirectfb_dummy.a.tmp && /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ar x ../../.libs/libdirectfb_dummy.a)
> > /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld -o libdirectfb_dummy.o -r .libs/libdirectfb_dummy.a.tmp/*.o
> > /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: .libs/libdirectfb_dummy.a.tmp/dummy.o: ABI is incompatible with that of the selected emulation
> > /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: failed to merge target specific data of file .libs/libdirectfb_dummy.a.tmp/dummy.o
> > /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: Attempt to do relocatable link with elf64-tradlittlemips input and elf32-ntradlittlemips output
> > /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: final link failed: File in wrong format
> >
> > Still the same problem of mixing MIPS ABIs, because DirectFB is calling
> > "ld" directly and not "gcc" to do the link.
> >
> > I had proposed a solution in
> > http://lists.busybox.net/pipermail/buildroot/2013-June/073399.html and
> > http://lists.busybox.net/pipermail/buildroot/2013-June/073400.html, but
> > Markos Chandras said that the upstream package should rather be fixed
> > to use gcc instead of ld for linking. So I guess we should fix DirectFB here.
>
> I will work on this and fix it properly. I will also submit a patch upstream.
Excellent, thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-08-28 11:31 ` Thomas De Schampheleire
@ 2013-08-28 11:55 ` Thomas Petazzoni
2013-08-28 13:13 ` Thomas De Schampheleire
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2013-08-28 11:55 UTC (permalink / raw)
To: buildroot
Dear Thomas De Schampheleire,
On Wed, 28 Aug 2013 13:31:38 +0200, Thomas De Schampheleire wrote:
> > We don't have that many build failures today, so let's have a look
> > together at each of them and see what we can do about them.
>
> Good idea! Ideally we can get them to 0, so that from that point
> onwards any autobuild failure becomes a clear focus point.
Agreed. Though we have to keep in mind that the release is in 3 days,
and after that 'next' will be merged in master, and we'll have plenty
of new autobuilder failures to look at.
> >> powerpc | media-ctl-ac40b79f002a2315f... | NOK | http://autobuild.buildroot.net/results/7bcab9b94a81b89789dc1cabe9f6940ed4f5ea51/
> >
> > Too old kernel headers in toolchain. Options:
> >
> > 1/ Add an exception in the autobuilder script.
> >
> > 2/ Modify media-ctl to integrate the necessary kernel headers and use
> > them when not available from the toolchain.
> >
> > I'm inclined to favor 1/.
>
> I once took a look at this. The media-ctl package already has some
> copies of kernel headers to deal with older kernels. There was a check
> in configure to detect this, IIRC. The stupid thing was that the
> headers in the media-ctl sources would be applied unconditionally.
> My intent was to patch media-ctl to provide also this missing header,
> and cleanup the stupidity described. Unfortunately I didn't continue
> this yet.
>
> What exactly do you mean with approach 1/? Forcing a recent kernel
> when building media-ctl?
> That doesn't solve the problem for other users that try to enable
> media-ctl on older kernels, right?
By 1/ I meant to not fix the problem, and only avoid it in the
autobuilders by making sure that when a non-suitable toolchain (too old
kernel headers) is used to build media-ctl, then we exclude media-ctl
from the build. I already have quite a few of such exclusions. What I
find not very nice is that the set of exclusions is not documented
anywhere, while they should be documented as "Known issues", or
something like that.
For reference, here is the current set of tweaks that I apply to the
randpackageconfig before starting the build. Note that when "return
False" is used, it means that the configuration is rejected and not
built, so a completely different random configuration will be tried.
# Make sure Qt license is approved
if "BR2_PACKAGE_QT=y\n" in config_items:
if "# BR2_PACKAGE_QT_LICENSE_APPROVED is not set\n" in config_items:
config_items.remove("# BR2_PACKAGE_QT_LICENSE_APPROVED is not set\n")
config_items.append("BR2_PACKAGE_QT_LICENSE_APPROVED=y\n")
if "BR2_PACKAGE_QT5BASE=y\n" in config_items:
if "# BR2_PACKAGE_QT5BASE_LICENSE_APPROVED is not set\n" in config_items:
config_items.remove("# BR2_PACKAGE_QT5BASE_LICENSE_APPROVED is not set\n")
config_items.append("BR2_PACKAGE_QT5BASE_LICENSE_APPROVED=y\n")
# Make sure LTP is not enabled when we have an uClibc toolchain
if "BR2_PACKAGE_LTP_TESTSUITE=y\n" in config_items and \
toolchain_is_uclibc(config_items):
config_items.remove("BR2_PACKAGE_LTP_TESTSUITE=y\n")
# Make sure xfsprogs is not enabled when we have an uClibc toolchain
if "BR2_PACKAGE_XFSPROGS=y\n" in config_items and \
toolchain_is_uclibc(config_items):
config_items.remove("BR2_PACKAGE_XFSPROGS=y\n")
# Make sure mrouted is not enabled when we have an uClibc toolchain
if "BR2_PACKAGE_MROUTED=y\n" in config_items and \
toolchain_is_uclibc(config_items):
config_items.remove("BR2_PACKAGE_MROUTED=y\n")
if 'BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/ctng-mips64-eglibc.tar.bz2"\n' in config_items and \
"BR2_PACKAGE_SQUID=y\n" in config_items:
# Reject this configuration
return False
if 'BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-mipsel-o32-full.tar.bz2"\n' in config_items and \
"BR2_PACKAGE_SQUID=y\n" in config_items:
# Reject this configuration
return False
if 'BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_MIPS44=y\n' in config_items and \
"BR2_PACKAGE_SQUID=y\n" in config_items:
# Reject this configuration
return False
if 'BR2_PACKAGE_CLASSPATH=y\n' in config_items:
# Reject this configuration
return False
if 'BR2_sh2a=y\n' in config_items and 'BR2_PACKAGE_LIBFFI=y\n' in config_items:
return False
if 'BR2_arc=y\n' in config_items and 'BR2_PACKAGE_LIBFFI=y\n' in config_items:
return False
if 'BR2_PACKAGE_SUNXI_BOARDS=y\n' in config_items:
config_items.remove("# BR2_PACKAGE_SUNXI_BOARDS_FEX_FILE is not set\n")
config_items.append('BR2_PACKAGE_SUNXI_BOARDS_FEX_FILE="a10/hackberry.fex"\n')
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-08-28 11:49 ` Thomas Petazzoni
@ 2013-08-28 11:55 ` Gustavo Zacarias
0 siblings, 0 replies; 416+ messages in thread
From: Gustavo Zacarias @ 2013-08-28 11:55 UTC (permalink / raw)
To: buildroot
On 08/28/2013 08:49 AM, Thomas Petazzoni wrote:
>> IIRC that's what gcc says but i think i've tested it and it was in >=4.4
>
> The particular toolchain that caused the build failure is
> BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_POWERPC201103, which is based on
> gcc 4.5.2.
>
> And according to the gcc documentation, it was added in 4.6, see
> http://gcc.gnu.org/gcc-4.6/changes.html. It's also confirmed by
> http://forums.gentoo.org/viewtopic-t-947998-start-0.html, which says
> that the undefined reference to _Static_assert disappeared when moving
> from 4.5 to 4.6.
Mixed up with sync_and_fetch stuff then which 4.4+ handles IIRC.
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-08-28 11:34 ` Gustavo Zacarias
@ 2013-08-28 11:49 ` Thomas Petazzoni
2013-08-28 11:55 ` Gustavo Zacarias
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2013-08-28 11:49 UTC (permalink / raw)
To: buildroot
Dear Gustavo Zacarias,
On Wed, 28 Aug 2013 08:34:22 -0300, Gustavo Zacarias wrote:
> On 08/28/2013 08:30 AM, Thomas Petazzoni wrote:
> >>>> powerpc | pciutils-3.2.0 | NOK | http://autobuild.buildroot.net/results/9daf0f46642020591731e20d3bf9041ff6259846/
> >>>
> >>> /home/test/test/3/output/host/usr/bin/powerpc-linux-gnu-gcc example.o lib/libpci.so.3.2.0 -o example
> >>> /home/test/test/3/output/host/usr/powerpc-buildroot-linux-gnu/sysroot/usr/lib/libkmod.so: undefined reference to `_Static_assert'
> >>>
> >>> No idea, I haven't investigated.
> >>
> >> Old gcc again.
> >> We need the GCC_AT_LEAST_X_Y for these cases or just kill old gcc versions.
> >
> > _Static_assert was added in gcc 4.6, I don't think gcc 4.4 or 4.5 are
> > "too old". I'll cook a patch for kmod.
>
> IIRC that's what gcc says but i think i've tested it and it was in >=4.4
The particular toolchain that caused the build failure is
BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_POWERPC201103, which is based on
gcc 4.5.2.
And according to the gcc documentation, it was added in 4.6, see
http://gcc.gnu.org/gcc-4.6/changes.html. It's also confirmed by
http://forums.gentoo.org/viewtopic-t-947998-start-0.html, which says
that the undefined reference to _Static_assert disappeared when moving
from 4.5 to 4.6.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-08-28 7:08 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (2 preceding siblings ...)
2013-08-28 11:31 ` Thomas De Schampheleire
@ 2013-08-28 11:45 ` Markos Chandras
2013-08-28 12:07 ` Thomas Petazzoni
2013-08-28 21:09 ` Arnout Vandecappelle
` (2 subsequent siblings)
6 siblings, 1 reply; 416+ messages in thread
From: Markos Chandras @ 2013-08-28 11:45 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On 28 August 2013 08:08, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
>> mips64el | directfb-1.6.3 | NOK | http://autobuild.buildroot.net/results/fab819eee4002a9c392c48c1ebaca5c5b6555567/
>
> (cd .libs/libdirectfb_dummy.a.tmp && /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ar x ../../.libs/libdirectfb_dummy.a)
> /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld -o libdirectfb_dummy.o -r .libs/libdirectfb_dummy.a.tmp/*.o
> /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: .libs/libdirectfb_dummy.a.tmp/dummy.o: ABI is incompatible with that of the selected emulation
> /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: failed to merge target specific data of file .libs/libdirectfb_dummy.a.tmp/dummy.o
> /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: Attempt to do relocatable link with elf64-tradlittlemips input and elf32-ntradlittlemips output
> /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: final link failed: File in wrong format
>
> Still the same problem of mixing MIPS ABIs, because DirectFB is calling
> "ld" directly and not "gcc" to do the link.
>
> I had proposed a solution in
> http://lists.busybox.net/pipermail/buildroot/2013-June/073399.html and
> http://lists.busybox.net/pipermail/buildroot/2013-June/073400.html, but
> Markos Chandras said that the upstream package should rather be fixed
> to use gcc instead of ld for linking. So I guess we should fix DirectFB here.
>
I will work on this and fix it properly. I will also submit a patch upstream.
--
Regards,
Markos Chandras
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-08-28 11:30 ` Thomas Petazzoni
@ 2013-08-28 11:34 ` Gustavo Zacarias
2013-08-28 11:49 ` Thomas Petazzoni
0 siblings, 1 reply; 416+ messages in thread
From: Gustavo Zacarias @ 2013-08-28 11:34 UTC (permalink / raw)
To: buildroot
On 08/28/2013 08:30 AM, Thomas Petazzoni wrote:
>>>> powerpc | pciutils-3.2.0 | NOK | http://autobuild.buildroot.net/results/9daf0f46642020591731e20d3bf9041ff6259846/
>>>
>>> /home/test/test/3/output/host/usr/bin/powerpc-linux-gnu-gcc example.o lib/libpci.so.3.2.0 -o example
>>> /home/test/test/3/output/host/usr/powerpc-buildroot-linux-gnu/sysroot/usr/lib/libkmod.so: undefined reference to `_Static_assert'
>>>
>>> No idea, I haven't investigated.
>>
>> Old gcc again.
>> We need the GCC_AT_LEAST_X_Y for these cases or just kill old gcc versions.
>
> _Static_assert was added in gcc 4.6, I don't think gcc 4.4 or 4.5 are
> "too old". I'll cook a patch for kmod.
IIRC that's what gcc says but i think i've tested it and it was in >=4.4
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-08-28 7:08 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2013-08-28 7:17 ` Will Newton
2013-08-28 11:00 ` Gustavo Zacarias
@ 2013-08-28 11:31 ` Thomas De Schampheleire
2013-08-28 11:55 ` Thomas Petazzoni
2013-08-28 11:45 ` Markos Chandras
` (3 subsequent siblings)
6 siblings, 1 reply; 416+ messages in thread
From: Thomas De Schampheleire @ 2013-08-28 11:31 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Wed, Aug 28, 2013 at 9:08 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> We don't have that many build failures today, so let's have a look
> together at each of them and see what we can do about them.
Good idea! Ideally we can get them to 0, so that from that point
onwards any autobuild failure becomes a clear focus point.
[snip]
>
>> powerpc | media-ctl-ac40b79f002a2315f... | NOK | http://autobuild.buildroot.net/results/7bcab9b94a81b89789dc1cabe9f6940ed4f5ea51/
>
> Too old kernel headers in toolchain. Options:
>
> 1/ Add an exception in the autobuilder script.
>
> 2/ Modify media-ctl to integrate the necessary kernel headers and use
> them when not available from the toolchain.
>
> I'm inclined to favor 1/.
I once took a look at this. The media-ctl package already has some
copies of kernel headers to deal with older kernels. There was a check
in configure to detect this, IIRC. The stupid thing was that the
headers in the media-ctl sources would be applied unconditionally.
My intent was to patch media-ctl to provide also this missing header,
and cleanup the stupidity described. Unfortunately I didn't continue
this yet.
What exactly do you mean with approach 1/? Forcing a recent kernel
when building media-ctl?
That doesn't solve the problem for other users that try to enable
media-ctl on older kernels, right?
Best regards,
Thomas
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-08-28 11:00 ` Gustavo Zacarias
@ 2013-08-28 11:30 ` Thomas Petazzoni
2013-08-28 11:34 ` Gustavo Zacarias
0 siblings, 1 reply; 416+ messages in thread
From: Thomas Petazzoni @ 2013-08-28 11:30 UTC (permalink / raw)
To: buildroot
Hello,
Fran?ois, Spenser, you're Cc'ed due to a question below.
On Wed, 28 Aug 2013 08:00:40 -0300, Gustavo Zacarias wrote:
> On 08/28/2013 04:08 AM, Thomas Petazzoni wrote:
>
> >> bfin | alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/1d587ef565425b574aeb85e6e2bebd2322634868/
> >> bfin | alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/a771c47b8d818245f8b66f128ea49db208fdfe52/
> >
> > That's the same problem: some parts of alsa-lib require dlopen()
> > functionality, but it isn't available for the FLAT-only bfin toolchain,
> > since it doesn't support shared library.
> >
> > Should we mark all packages that use dlopen()
> > as !BR2_PREFER_STATIC_LIB ?
> >
> > (Note: in the specific case of alsa-lib, maybe not the entire package
> > needs to be marked this way, but one of its suboptions).
>
> IIRC it's some builtin (non-disableable) plugin that fails.
> Since there's an alsa bump in the pipe i can take a look at it.
Good.
> >> i686 | bash-4.2 | NOK | http://autobuild.buildroot.net/results/b85caa22ddc13bdaaac25b9016fe902ade5027de/
> >
> > ./mksyntax -o syntax.c
> > make[1]: execvp: ./mksyntax: Permission denied
> > ./mksignames lsignames.h
> >
> > Strange. Missing executable permissions on this program? Why does it
> > happen only rarely?
>
> umask afecting the build?
I don't know, maybe.
> >> microblaze | libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/519219ec8e4c4aa06baf3353cd2e37bf4fef9362/
> >
> > ./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_or_4'
> > ./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_sub_4'
> > ./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_xor_4'
> > ./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_add_4'
> > ./.libs/libglib-2.0.so: undefined reference to `fallocate64'
> > ./.libs/libglib-2.0.so: undefined reference to `__sync_bool_compare_and_swap_4'
> > ./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_and_4'
> >
> > Too old gcc?
>
> Yes!
This is annoying. I'm wondering if some of the glib code is not buggy
here, because the usage of those compiler intrinsics is normally
conditional in gatomic.h.
> >> bfin | lua-5.1.5 | NOK | http://autobuild.buildroot.net/results/760bfa75559ec1fe2a7060e9e6792c9789410f2c/
> >
> > loadlib.c:61:19: error: dlfcn.h: No such file or directory
> >
> > Uses dlopen() functionality. Should we mark !BR2_PREFER_STATIC_LIB ?
>
> This is fixable by not defining LUA_USE_DLOPEN, which was the original
> intention of the LUA_SHARED_LIBRARY knob which was removed in 76983349
Fran?ois, can you take care of this one?
>
> >> microblaze | nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/b95477576f1d3a84951c70ddd158b75e9f19efbd/
> >
> > sha512-compress.c: In function '_nettle_sha512_compress':
> > sha512-compress.c:180:1: internal compiler error: in reload, at reload1.c:1059
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See <http://gcc.gnu.org/bugs.html> for instructions.
> >
> > Oops. Not much we can do here.
> >
> > Should we add an exception in the autobuilder scripts? Or an exception
> > directly within Buildroot between this package and the particular
> > Microblaze toolchain causing the issue?
>
> It sounds rather harsh but maybe we should just remove microblaze builds
> from the autobuilder - the toolchain is too broken, it fails with
> openssl too for example.
I don't really agree. If we support the architecture, then we should
support it, and therefore try to ensure that things are building. I
don't mind adding more !BR2_microblaze or exclude some toolchain
versions, but either we support Microblaze and have it in the
autobuilders, or we remove support for it.
Spenser, you're the one who added Microblaze support originally. We
have issues with the Microblaze toolchain. What can we do to get more
recent Microblaze toolchains, or get some support from Xilinx about our
issues?
> >> powerpc | pciutils-3.2.0 | NOK | http://autobuild.buildroot.net/results/9daf0f46642020591731e20d3bf9041ff6259846/
> >
> > /home/test/test/3/output/host/usr/bin/powerpc-linux-gnu-gcc example.o lib/libpci.so.3.2.0 -o example
> > /home/test/test/3/output/host/usr/powerpc-buildroot-linux-gnu/sysroot/usr/lib/libkmod.so: undefined reference to `_Static_assert'
> >
> > No idea, I haven't investigated.
>
> Old gcc again.
> We need the GCC_AT_LEAST_X_Y for these cases or just kill old gcc versions.
_Static_assert was added in gcc 4.6, I don't think gcc 4.4 or 4.5 are
"too old". I'll cook a patch for kmod.
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-08-28 7:17 ` Will Newton
@ 2013-08-28 11:19 ` Thomas Petazzoni
0 siblings, 0 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2013-08-28 11:19 UTC (permalink / raw)
To: buildroot
Dear Will Newton,
On Wed, 28 Aug 2013 08:17:55 +0100, Will Newton wrote:
> On Wed, Aug 28, 2013 at 8:08 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>
> Hi Thomas,
>
> >> aarch64 | cups-1.3.11 | NOK | http://autobuild.buildroot.net/results/6c179dca4455e4cb651f9b6bce1b2604366431f4/
> >
> > {standard input}: Assembler messages:
> > {standard input}:7522: Error: immediate value out of range 0 to 255 at operand 2 -- `movi v14.8b,-1'
> >
> > Seems like a deeply AArch64 problem, should be reported to the AArch64 people at Linaro.
>
> That's a known issue that should be fixed in the most recent release.
Great, thanks, I'll bump the Linaro toolchains soon.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-08-28 7:08 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2013-08-28 7:17 ` Will Newton
@ 2013-08-28 11:00 ` Gustavo Zacarias
2013-08-28 11:30 ` Thomas Petazzoni
2013-08-28 11:31 ` Thomas De Schampheleire
` (4 subsequent siblings)
6 siblings, 1 reply; 416+ messages in thread
From: Gustavo Zacarias @ 2013-08-28 11:00 UTC (permalink / raw)
To: buildroot
On 08/28/2013 04:08 AM, Thomas Petazzoni wrote:
>> bfin | alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/1d587ef565425b574aeb85e6e2bebd2322634868/
>> bfin | alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/a771c47b8d818245f8b66f128ea49db208fdfe52/
>
> That's the same problem: some parts of alsa-lib require dlopen()
> functionality, but it isn't available for the FLAT-only bfin toolchain,
> since it doesn't support shared library.
>
> Should we mark all packages that use dlopen()
> as !BR2_PREFER_STATIC_LIB ?
>
> (Note: in the specific case of alsa-lib, maybe not the entire package
> needs to be marked this way, but one of its suboptions).
IIRC it's some builtin (non-disableable) plugin that fails.
Since there's an alsa bump in the pipe i can take a look at it.
>
>> i686 | bash-4.2 | NOK | http://autobuild.buildroot.net/results/b85caa22ddc13bdaaac25b9016fe902ade5027de/
>
> ./mksyntax -o syntax.c
> make[1]: execvp: ./mksyntax: Permission denied
> ./mksignames lsignames.h
>
> Strange. Missing executable permissions on this program? Why does it
> happen only rarely?
umask afecting the build?
>> microblaze | libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/519219ec8e4c4aa06baf3353cd2e37bf4fef9362/
>
> ./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_or_4'
> ./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_sub_4'
> ./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_xor_4'
> ./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_add_4'
> ./.libs/libglib-2.0.so: undefined reference to `fallocate64'
> ./.libs/libglib-2.0.so: undefined reference to `__sync_bool_compare_and_swap_4'
> ./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_and_4'
>
> Too old gcc?
Yes!
>> bfin | lua-5.1.5 | NOK | http://autobuild.buildroot.net/results/760bfa75559ec1fe2a7060e9e6792c9789410f2c/
>
> loadlib.c:61:19: error: dlfcn.h: No such file or directory
>
> Uses dlopen() functionality. Should we mark !BR2_PREFER_STATIC_LIB ?
This is fixable by not defining LUA_USE_DLOPEN, which was the original
intention of the LUA_SHARED_LIBRARY knob which was removed in 76983349
>> microblaze | nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/b95477576f1d3a84951c70ddd158b75e9f19efbd/
>
> sha512-compress.c: In function '_nettle_sha512_compress':
> sha512-compress.c:180:1: internal compiler error: in reload, at reload1.c:1059
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
>
> Oops. Not much we can do here.
>
> Should we add an exception in the autobuilder scripts? Or an exception
> directly within Buildroot between this package and the particular
> Microblaze toolchain causing the issue?
It sounds rather harsh but maybe we should just remove microblaze builds
from the autobuilder - the toolchain is too broken, it fails with
openssl too for example.
>> powerpc | pciutils-3.2.0 | NOK | http://autobuild.buildroot.net/results/9daf0f46642020591731e20d3bf9041ff6259846/
>
> /home/test/test/3/output/host/usr/bin/powerpc-linux-gnu-gcc example.o lib/libpci.so.3.2.0 -o example
> /home/test/test/3/output/host/usr/powerpc-buildroot-linux-gnu/sysroot/usr/lib/libkmod.so: undefined reference to `_Static_assert'
>
> No idea, I haven't investigated.
Old gcc again.
We need the GCC_AT_LEAST_X_Y for these cases or just kill old gcc versions.
Regards.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-08-28 7:08 ` [Buildroot] Analysis of build failures Thomas Petazzoni
@ 2013-08-28 7:17 ` Will Newton
2013-08-28 11:19 ` Thomas Petazzoni
2013-08-28 11:00 ` Gustavo Zacarias
` (5 subsequent siblings)
6 siblings, 1 reply; 416+ messages in thread
From: Will Newton @ 2013-08-28 7:17 UTC (permalink / raw)
To: buildroot
On Wed, Aug 28, 2013 at 8:08 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
Hi Thomas,
>> aarch64 | cups-1.3.11 | NOK | http://autobuild.buildroot.net/results/6c179dca4455e4cb651f9b6bce1b2604366431f4/
>
> {standard input}: Assembler messages:
> {standard input}:7522: Error: immediate value out of range 0 to 255 at operand 2 -- `movi v14.8b,-1'
>
> Seems like a deeply AArch64 problem, should be reported to the AArch64 people at Linaro.
That's a known issue that should be fixed in the most recent release.
^ permalink raw reply [flat|nested] 416+ messages in thread
* [Buildroot] Analysis of build failures
2013-08-28 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2013-08-27 Thomas Petazzoni
@ 2013-08-28 7:08 ` Thomas Petazzoni
2013-08-28 7:17 ` Will Newton
` (6 more replies)
0 siblings, 7 replies; 416+ messages in thread
From: Thomas Petazzoni @ 2013-08-28 7:08 UTC (permalink / raw)
To: buildroot
Hello,
We don't have that many build failures today, so let's have a look
together at each of them and see what we can do about them.
> x86_64 | alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/dafc9f0c237e98b9280e813ed8100ab913e629be/
/home/test/test/3/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/usr/lib/../lib64/libc.a(vfork.os):
In function `__GI_vfork': (.text+0x0): multiple definition of `__vfork'
/home/test/test/3/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/usr/lib/../lib64/libpthread.a(pt-vfork.os):(.text+0x0):
first defined here collect2: ld returned 1 exit status
Is this some bug in uClibc ?
The toolchain is some old toolchain I've built quite some time ago with
Crosstool-NG. Maybe I should update it.
> bfin | alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/1d587ef565425b574aeb85e6e2bebd2322634868/
> bfin | alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/a771c47b8d818245f8b66f128ea49db208fdfe52/
That's the same problem: some parts of alsa-lib require dlopen()
functionality, but it isn't available for the FLAT-only bfin toolchain,
since it doesn't support shared library.
Should we mark all packages that use dlopen()
as !BR2_PREFER_STATIC_LIB ?
(Note: in the specific case of alsa-lib, maybe not the entire package
needs to be marked this way, but one of its suboptions).
> i686 | bash-4.2 | NOK | http://autobuild.buildroot.net/results/b85caa22ddc13bdaaac25b9016fe902ade5027de/
./mksyntax -o syntax.c
make[1]: execvp: ./mksyntax: Permission denied
./mksignames lsignames.h
Strange. Missing executable permissions on this program? Why does it
happen only rarely?
> arm | busybox-1.21.1 | NOK | http://autobuild.buildroot.net/results/7673109f00d51a6072c23104ac82106962903e54/
/home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-unknown-linux-uclibcgnueabi/4.6.4/../../../../arm-unknown-linux-uclibcgnueabi/bin/ld: error: busybox_unstripped uses VFP register arguments, libpwdgrp/lib.a(uidgid_get.o) does not
/home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-unknown-linux-uclibcgnueabi/4.6.4/../../../../arm-unknown-linux-uclibcgnueabi/bin/ld: failed to merge target specific data of file libpwdgrp/lib.a(uidgid_get.o)
Not sure what's going on here. We're mixing hardfp with softfp for
sure, but not sure why. The toolchain is also an old toolchain
generated a while ago with Crosstool-NG. I should probably update it
before looking into this.
> aarch64 | cups-1.3.11 | NOK | http://autobuild.buildroot.net/results/6c179dca4455e4cb651f9b6bce1b2604366431f4/
{standard input}: Assembler messages:
{standard input}:7522: Error: immediate value out of range 0 to 255 at operand 2 -- `movi v14.8b,-1'
Seems like a deeply AArch64 problem, should be reported to the AArch64 people at Linaro.
> mips64el | directfb-1.6.3 | NOK | http://autobuild.buildroot.net/results/fab819eee4002a9c392c48c1ebaca5c5b6555567/
(cd .libs/libdirectfb_dummy.a.tmp && /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ar x ../../.libs/libdirectfb_dummy.a)
/home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld -o libdirectfb_dummy.o -r .libs/libdirectfb_dummy.a.tmp/*.o
/home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: .libs/libdirectfb_dummy.a.tmp/dummy.o: ABI is incompatible with that of the selected emulation
/home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: failed to merge target specific data of file .libs/libdirectfb_dummy.a.tmp/dummy.o
/home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: Attempt to do relocatable link with elf64-tradlittlemips input and elf32-ntradlittlemips output
/home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: final link failed: File in wrong format
Still the same problem of mixing MIPS ABIs, because DirectFB is calling
"ld" directly and not "gcc" to do the link.
I had proposed a solution in
http://lists.busybox.net/pipermail/buildroot/2013-June/073399.html and
http://lists.busybox.net/pipermail/buildroot/2013-June/073400.html, but
Markos Chandras said that the upstream package should rather be fixed
to use gcc instead of ld for linking. So I guess we should fix DirectFB here.
> microblaze | e2fsprogs-1.42.8 | NOK | http://autobuild.buildroot.net/results/94661d9cb3e27579a09e4518f55dd8406d1cc502/
../lib/libext2fs.so: undefined reference to `fallocate64'
collect2: ld returned 1 exit status
No largefile support in this toolchain? Something else?
> x86_64 | gpsd-3.9 | NOK | http://autobuild.buildroot.net/results/d58be37b9b18b37eab4acec9a6bbe28863ef4d22/
scons: *** [gpsd] Implicit dependency `/home/test/test/2/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libm.so' not found, needed by target `gpsd'.
Not sure what's happening here. Surely if -lm was missing, we would be
seeing more build failures of gpsd, no?
> mips64el | libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/8159d3a5e7ea17ef4c3ee732fb21941a017429db/
/home/test/test/1/output/host/usr/mips64el-buildroot-linux-gnu/sysroot/usr/lib/libc.a(vfprintf.o): In function `_i18n_number_rewrite':
printf-parse.h:(.text.unlikely+0x338): relocation truncated to fit: R_MIPS_TLS_GOTTPREL against `_nl_current_LC_CTYPE'
No idea.
> microblaze | libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/519219ec8e4c4aa06baf3353cd2e37bf4fef9362/
./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_or_4'
./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_sub_4'
./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_xor_4'
./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_add_4'
./.libs/libglib-2.0.so: undefined reference to `fallocate64'
./.libs/libglib-2.0.so: undefined reference to `__sync_bool_compare_and_swap_4'
./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_and_4'
Too old gcc?
> mips64el | libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/0a19073440d22b36df05a54c9104c139cc6d376b/
Same as the one above (relocation truncated to fit).
> bfin | libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/c3084342085371618f961c00cc866ae37b5e9453/
libglib uses fork(). I did post
http://patchwork.ozlabs.org/patch/226374/ a while ago.
> arm | libtirpc-0.2.2 | NOK | http://autobuild.buildroot.net/results/1f51c9fce5d3e2758ccea8176406289a1bc069b5/
auth_none.c:46:21: fatal error: pthread.h: No such file or directory
libtirpc needs thread support. Originally, I was against adding the
BR2_TOOLCHAIN_HAS_THREADS dependency and thought we should fix libtirpc
instead. But I've changed my mind, I think we shouldn't diverge too
much from upstream (we already have large patches on libtirpc).
So I believe we should apply a refresh of
http://patchwork.ozlabs.org/patch/244409/, with some adjustments.
> bfin | lua-5.1.5 | NOK | http://autobuild.buildroot.net/results/760bfa75559ec1fe2a7060e9e6792c9789410f2c/
loadlib.c:61:19: error: dlfcn.h: No such file or directory
Uses dlopen() functionality. Should we mark !BR2_PREFER_STATIC_LIB ?
> powerpc | media-ctl-ac40b79f002a2315f... | NOK | http://autobuild.buildroot.net/results/7bcab9b94a81b89789dc1cabe9f6940ed4f5ea51/
Too old kernel headers in toolchain. Options:
1/ Add an exception in the autobuilder script.
2/ Modify media-ctl to integrate the necessary kernel headers and use
them when not available from the toolchain.
I'm inclined to favor 1/.
> i686 | ncftp-3.2.5 | NOK | http://autobuild.buildroot.net/results/e2090822a32da8b70f0928644a03873a712f3c97/
/usr/bin/install: cannot stat `/home/test/test/3/output/build/ncftp-3.2.5/bin/ncftpbookmarks': No such file or directory
make: *** [/home/test/test/3/output/build/ncftp-3.2.5/.stamp_target_installed] Error 1
Some binary is not generated as our .mk file expects. Should be trivial
to fix.
> microblaze | nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/b95477576f1d3a84951c70ddd158b75e9f19efbd/
sha512-compress.c: In function '_nettle_sha512_compress':
sha512-compress.c:180:1: internal compiler error: in reload, at reload1.c:1059
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Oops. Not much we can do here.
Should we add an exception in the autobuilder scripts? Or an exception
directly within Buildroot between this package and the particular
Microblaze toolchain causing the issue?
> powerpc | pciutils-3.2.0 | NOK | http://autobuild.buildroot.net/results/9daf0f46642020591731e20d3bf9041ff6259846/
/home/test/test/3/output/host/usr/bin/powerpc-linux-gnu-gcc example.o lib/libpci.so.3.2.0 -o example
/home/test/test/3/output/host/usr/powerpc-buildroot-linux-gnu/sysroot/usr/lib/libkmod.so: undefined reference to `_Static_assert'
No idea, I haven't investigated.
> arm | pulseaudio-4.0 | NOK | http://autobuild.buildroot.net/results/d859068bc4a7f2b406ca83b8e19fe8b60391c0ba/
/home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.7.3/include/arm_neon.h:32:2: error: #error You must enable NEON instructions (e.g. -mfloat-abi=softfp -mfpu=neon) to use arm_neon.h
Should be fixed by the recently committed
http://git.buildroot.net/buildroot/commit/?id=f09636710b14f1493de7c8cd24aaf3a5d1322389.
> arm | qt-4.8.5 | NOK | http://autobuild.buildroot.net/results/b970d41df5fa8f63b7ee90e99e7a91846f6715e1/
The EGL functionality test failed!
EGL is required for OpenGL ES to manage contexts & surfaces.
You might need to modify the include and library search paths by editing
QMAKE_INCDIR_EGL, QMAKE_LIBDIR_EGL and QMAKE_LIBS_EGL in
/scratch/peko/build/qt-4.8.5/mkspecs/qws/linux-arm-g++.
make: *** [/scratch/peko/build/qt-4.8.5/.stamp_configured] Error 1
The OpenGL implementation being selected is BR2_PACKAGE_RPI_USERLAND.
Not sure why it doesn't find it. Needs investigation.
> arm | qt5base-5.0.2 | NOK | http://autobuild.buildroot.net/results/3577a7221d429658b459507cd2430fc275be8564/
DirectFB disabled.
DirectFB support cannot be enabled due to functionality tests!
Turn on verbose messaging (-v) to ./configure to see the final report.
If you believe this message is in error you may use the continue
switch (-continue) to ./configure to continue.
make: *** [/scratch/peko/build/qt5base-5.0.2/.stamp_configured] Error 101
To be reproduced/investigated.
> arm | qt5base-5.0.2 | NOK | http://autobuild.buildroot.net/results/d268003b0a3402dde930a72ab467ee393b2ebe64/
OpenGL ES 2.x disabled.
The OpenGL ES 2.0 functionality test failed!
You might need to modify the include and library search paths by editing
QMAKE_INCDIR_OPENGL_ES2, QMAKE_LIBDIR_OPENGL_ES2 and QMAKE_LIBS_OPENGL_ES2 in
/home/test/test/1/output/build/qt5base-5.0.2/mkspecs/devices/linux-buildroot-g++.
make: *** [/home/test/test/1/output/build/qt5base-5.0.2/.stamp_configured] Error 1
As I pointed to Peter, this should be fixed by
http://patchwork.ozlabs.org/patch/269662/.
> i686 | qt5webkit-5.0.2 | NOK | http://autobuild.buildroot.net/results/4532e7835c0bc047266d74fa5144d1e67a367ae0/
cp -dpfr /home/test/test/2/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/qml/QtWebKit /home/test/test/2/output/target/usr/qml/
cp: cannot stat `/home/test/test/2/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/qml/QtWebKit': No such file or directory
make: *** [/home/test/test/2/output/build/qt5webkit-5.0.2/.stamp_target_installed] Error 1
This has been reported several times by users. Apparently, we can build
webkit without QML support, but this isn't correctly taken into account
in our qt5webkit.mk.
> arm | qt5webkit-5.0.2 | NOK | http://autobuild.buildroot.net/results/439ce2c3c33a92966808071d4fc7231d50453c79/
Project ERROR: Unknown module(s) in QT: gui
qt5webkit would need gui support in qt5base, which sounds logical.
> mipsel | rt-tests-0.83 | NOK | http://autobuild.buildroot.net/results/41534b06b9bdf1a373f3fe4f4717c3bc8c9d7e1d/
src/cyclictest/cyclictest.c: In function 'timerthread':
src/cyclictest/cyclictest.c:638:9: error: 'union <anonymous>' has no member named '_tid'
Toolchain is a MIPS toolchain built with Buildroot 2013.05, so not old.
> x86_64 | strongswan-5.0.4 | NOK | http://autobuild.buildroot.net/results/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/
utils/backtrace.c:23:23: fatal error: execinfo.h: No such file or directory
uClibc doesn't have execinfo.h by default. Proper testing should be
added in strongswan code. J?r?me, can you have a look at this?
> mips | stunnel-4.55 | NOK | http://autobuild.buildroot.net/results/28527d8ec87d7c0e9d380682216a33ea192eee42/
/home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-linux-gnu/4.7.3/../../../../mips-linux-gnu/bin/ld: note: 'pthread_setcancelstate@@GLIBC_2.0' is defined in DSO /home/test/test/2/output/host/usr/mips-buildroot-linux-gnu/sysroot/soft-float/lib/libc.so.6 so try adding it to the linker command line
/home/test/test/2/output/host/usr/mips-buildroot-linux-gnu/sysroot/soft-float/lib/libc.so.6: could not read symbols: Invalid operation
> mips | stunnel-4.55 | NOK | http://autobuild.buildroot.net/results/876ea074ef53e020d7e72bc508aca834d2dda341/
Same problem.
> powerpc | sysklogd-1.5 | NOK | http://autobuild.buildroot.net/results/f037bf84f58ae293d5b26d5260e3a47a0ed36749/
syslogd.c: In function 'main':
syslogd.c:1237:1: error: unrecognizable insn:
(insn 66 65 67 4 (set (subreg:SI (reg:V2SI 502) 0)
(lo_sum:SI (reg:SI 503)
(symbol_ref/f:SI ("*.LC98") [flags 0x82] <var_decl 0x55e10ae0 *.LC98>))) syslogd.c:885 -1
(nil))
syslogd.c:1237:1: internal compiler error: in extract_insn, at recog.c:2109
Please submit a full bug report,
Ooh. That's an old toolchain built with Crosstool-NG. I should maybe
rebuild it with a more recent compiler.
> mips64el | tvheadend-5956233 | NOK | http://autobuild.buildroot.net/results/a24bcf23cfc4e5d69ee29ef11397679eb8198468/
src/v4l.c: In function 'v4l_adapter_check':
src/v4l.c:468:5: error: format '%llx' expects argument of type 'long long unsigned int', but argument 9 has type 'v4l2_std_id' [-Werror=format]
src/v4l.c:504:5: error: format '%llx' expects argument of type 'long long unsigned int', but argument 13 has type 'v4l2_std_id' [-Werror=format]
cc1: all warnings being treated as errors
tvheadend is built with -Werror, this is not good. Yann, can you change
this?
> powerpc | w_scan-20130331 | NOK | http://autobuild.buildroot.net/results/f3a1c2245eab30a512fddda620c42b1cab1725bf/
checking for linux/dvb/frontend.h usability (DVB-T2, DVB API >= v5.3)... no
*******************************************************
*** ERROR: w_scan requires linux DVB API v5.3 or higher.
*** Please update your linux dvb headers,
*** (usually /usr/include/linux/dvb).
*** EXITING!
*******************************************************
make: *** [/home/test/test/1/output/build/w_scan-20130331/.stamp_configured] Error 1
Does this means the kernel headers of the toolchain are too old? What
are the solutions to this?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 416+ messages in thread
end of thread, other threads:[~2016-02-15 13:15 UTC | newest]
Thread overview: 416+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-05 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2015-05-04 Thomas Petazzoni
2015-05-05 7:59 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2015-05-05 13:44 ` Gustavo Zacarias
2015-05-05 13:47 ` Thomas Petazzoni
[not found] ` <5548C487.90604@gmail.com>
2015-05-05 13:48 ` Thomas Petazzoni
2015-05-06 9:16 ` Pascal Huerst
2015-05-05 14:52 ` Max Filippov
2015-05-05 15:06 ` Thomas Petazzoni
2015-05-05 15:22 ` Peter Korsgaard
2015-05-05 15:26 ` Thomas Petazzoni
2015-05-05 15:50 ` Peter Korsgaard
2015-05-05 15:54 ` Thomas Petazzoni
2015-05-05 18:46 ` Peter Korsgaard
2015-05-06 7:34 ` Angelo Compagnucci
2015-05-06 7:44 ` Thomas Petazzoni
[not found] <mailman.19.1455278403.3863.buildroot@busybox.net>
2016-02-13 1:04 ` Ricardo Martincoski
-- strict thread matches above, loose matches on Subject: below --
2016-02-12 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2016-02-11 Thomas Petazzoni
2016-02-12 9:45 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2016-02-12 11:54 ` Martin Bark
2016-02-15 13:15 ` Martin Bark
2016-02-12 18:01 ` Bernd Kuhls
2016-02-12 18:29 ` Bernd Kuhls
2016-02-12 19:26 ` Romain Naour
2016-02-12 20:35 ` Thomas Petazzoni
2016-02-12 20:52 ` Romain Naour
2016-01-23 12:33 Ricardo Martincoski
2016-01-23 12:55 ` Thomas Petazzoni
2016-01-23 13:03 ` Thomas De Schampheleire
2016-01-23 13:56 ` Ricardo Martincoski
2016-01-23 14:26 ` Thomas De Schampheleire
2016-01-23 14:42 ` Thomas Petazzoni
2016-01-23 15:16 ` Ricardo Martincoski
2016-01-23 15:58 ` Thomas Petazzoni
2016-01-23 16:07 ` Thomas De Schampheleire
2016-01-23 17:14 ` Ricardo Martincoski
2016-01-23 20:48 ` Thomas Petazzoni
2016-01-22 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2016-01-21 Thomas Petazzoni
2016-01-22 9:29 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2016-01-22 9:36 ` Thomas De Schampheleire
2016-01-22 11:26 ` Gustavo Zacarias
2016-01-22 18:38 ` Waldemar Brodkorb
2016-01-22 23:19 ` Romain Naour
2016-01-23 8:32 ` Thomas Petazzoni
2016-01-23 10:47 ` Romain Naour
2016-01-23 1:07 ` Frank Hunleth
2016-01-23 10:55 ` Samuel Martin
2016-01-26 12:02 ` Joao Pinto
2016-01-26 13:26 ` Thomas Petazzoni
2016-01-27 11:37 ` Joao Pinto
2016-01-27 12:16 ` Thomas Petazzoni
2016-01-27 14:25 ` Joao Pinto
2016-01-27 15:09 ` Thomas Petazzoni
2016-01-27 15:13 ` Joao Pinto
2016-01-26 21:06 ` Bernd Kuhls
2016-01-27 17:18 ` Peter Korsgaard
2016-02-03 9:37 ` Max Filippov
2016-01-16 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2016-01-15 Thomas Petazzoni
2016-01-16 23:11 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2016-01-17 1:42 ` Frank Hunleth
2016-01-17 11:23 ` Thomas Petazzoni
2016-01-17 16:33 ` Frank Hunleth
2016-01-23 1:05 ` Frank Hunleth
2016-01-23 8:01 ` Thomas Petazzoni
2016-01-25 9:06 ` Joris Lijssens
2016-01-25 9:09 ` Thomas Petazzoni
2016-01-25 9:10 ` Joris Lijssens
2016-01-25 9:30 ` Joris Lijssens
2016-01-17 15:06 ` Matthew Weber
2016-01-17 17:26 ` Thomas Petazzoni
2016-01-17 17:10 ` Maxime Hadjinlian
2016-01-18 22:10 ` Thomas Petazzoni
2016-01-17 17:36 ` Jörg Krause
2016-01-17 18:22 ` Rodrigo Rebello
2016-01-17 19:02 ` Gary Bisson
2016-01-17 19:06 ` Romain Naour
2016-01-18 7:06 ` Alexey Brodkin
2016-01-18 12:22 ` Gustavo Zacarias
2016-01-18 20:53 ` Peter Seiderer
2016-01-18 21:03 ` Thomas Petazzoni
2015-07-29 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2015-07-28 Thomas Petazzoni
2015-07-29 8:03 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2015-07-29 9:30 ` Jérôme Pouiller
2015-07-29 19:55 ` Bernd Kuhls
2015-08-04 13:45 ` Angelo Compagnucci
2015-08-06 13:53 ` Guillaume GARDET - Oliséo
2015-08-06 13:58 ` Thomas Petazzoni
2015-08-06 14:07 ` Guillaume GARDET - Oliséo
2015-08-06 18:50 ` Thomas Petazzoni
2015-08-07 12:09 ` Guillaume GARDET - Oliséo
2015-07-22 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2015-07-21 Thomas Petazzoni
2015-07-22 7:43 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2015-07-22 9:07 ` Yegor Yefremov
2015-07-22 9:19 ` Thomas Petazzoni
2015-07-22 9:34 ` Guillaume GARDET - Oliséo
2015-07-22 10:04 ` Nicolas Ménégale
2015-07-22 11:20 ` Thomas Petazzoni
2015-07-22 10:06 ` Romain Naour
2015-07-22 11:22 ` Thomas Petazzoni
2015-07-22 12:15 ` Romain Naour
2015-07-22 16:27 ` Waldemar Brodkorb
2015-07-22 17:53 ` Romain Naour
2015-07-30 10:46 ` Romain Naour
2015-08-01 8:25 ` Waldemar Brodkorb
2015-08-01 16:40 ` Romain Naour
2015-07-22 10:48 ` Brendan Heading
2015-07-22 11:24 ` Brendan Heading
2015-07-22 12:30 ` Gustavo Zacarias
2015-07-22 12:45 ` Thomas Petazzoni
2015-07-22 12:51 ` Gustavo Zacarias
2015-07-22 12:52 ` Thomas Petazzoni
2015-07-22 14:23 ` Brendan Heading
2015-07-22 14:54 ` Thomas Petazzoni
2015-07-22 15:27 ` Brendan Heading
2015-07-22 15:40 ` Gustavo Zacarias
2015-07-22 15:44 ` Brendan Heading
2015-07-22 20:06 ` Thomas Petazzoni
2015-07-22 20:40 ` Brendan Heading
2015-07-22 20:46 ` Thomas Petazzoni
2015-07-22 21:03 ` Brendan Heading
2015-07-23 18:15 ` Gustavo Zacarias
2015-07-23 19:03 ` Brendan Heading
2015-07-23 19:04 ` Gustavo Zacarias
2015-07-22 12:51 ` Gustavo Zacarias
2015-07-22 13:03 ` Thomas Petazzoni
2015-07-28 13:56 ` Gustavo Zacarias
2015-07-28 14:02 ` Thomas Petazzoni
2015-07-22 14:49 ` Clayton Shotwell
2015-07-22 14:56 ` Thomas Petazzoni
2015-07-22 15:06 ` Alexey Brodkin
2015-07-22 15:14 ` Thomas Petazzoni
2015-07-22 15:26 ` Alexey Brodkin
2015-07-22 15:33 ` Thomas Petazzoni
2015-07-22 16:15 ` Waldemar Brodkorb
2015-07-22 17:04 ` Max Filippov
2015-07-23 6:27 ` Angelo Compagnucci
2015-05-19 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2015-05-18 Thomas Petazzoni
2015-05-19 8:00 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2015-05-19 8:12 ` Romain Naour
2015-05-21 13:28 ` Bartosz Golaszewski
2015-05-21 13:33 ` Thomas Petazzoni
2015-05-19 13:49 ` Alexey Brodkin
2015-05-19 15:48 ` Thomas Petazzoni
2015-05-25 11:08 ` Alexey Brodkin
2015-05-19 17:59 ` Peter Korsgaard
2015-05-20 17:49 ` Yann E. MORIN
2015-05-17 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2015-05-16 Thomas Petazzoni
2015-05-17 10:49 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2015-05-17 11:37 ` Yann E. MORIN
2015-05-17 12:08 ` Romain Naour
2015-05-17 13:52 ` Thomas Petazzoni
2015-05-17 14:19 ` Romain Naour
2015-05-14 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2015-05-13 Thomas Petazzoni
2015-05-14 21:13 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2015-05-14 22:58 ` Peter Korsgaard
2015-05-15 16:02 ` Thomas Petazzoni
2015-05-15 14:06 ` Waldemar Brodkorb
2015-05-15 15:17 ` Thomas Petazzoni
2015-05-06 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2015-05-05 Thomas Petazzoni
2015-05-06 7:42 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2015-05-06 8:07 ` gwenhael.goavec
2015-05-06 17:53 ` Waldemar Brodkorb
2015-05-06 20:58 ` Alexey Brodkin
2015-05-06 21:32 ` Peter Korsgaard
2015-05-06 21:42 ` Thomas Petazzoni
2015-05-06 22:01 ` Thomas Petazzoni
2015-05-07 6:51 ` Peter Korsgaard
2015-05-07 7:31 ` Thomas Petazzoni
2015-05-07 4:05 ` Waldemar Brodkorb
2015-05-07 7:33 ` Thomas Petazzoni
2015-05-07 7:42 ` Peter Korsgaard
2015-05-02 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2015-05-01 Thomas Petazzoni
2015-05-03 8:50 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2015-05-03 10:39 ` Romain Naour
2015-05-03 11:23 ` Peter Korsgaard
2015-05-04 6:50 ` Richard Genoud
2015-05-04 13:52 ` Peter Korsgaard
2015-05-04 14:57 ` Richard Genoud
2015-05-04 21:30 ` Thomas Petazzoni
2015-05-05 11:00 ` Richard Genoud
2015-05-03 11:53 ` Baruch Siach
2015-05-04 10:28 ` Jörg Krause
2014-12-29 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-12-28 Thomas Petazzoni
2014-12-29 8:30 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-09-14 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-09-13 Thomas Petazzoni
2014-09-14 10:19 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-09-15 2:52 ` Matthew Weber
[not found] ` <CA+-urNSSKAn3=oXPM2553CO6+8XQB=4hKjzNR4mSg61aAY_LgQ@mail.gmail.com>
2014-09-15 13:59 ` Thomas Petazzoni
2014-09-15 14:48 ` Frank Hunleth
2014-09-28 10:47 ` Bernd Kuhls
2014-09-12 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-09-11 Thomas Petazzoni
2014-09-12 8:11 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-09-12 8:20 ` Nathaniel Roach
2014-09-12 8:53 ` Vicente Olivert Riera
2014-09-12 8:57 ` Thomas Petazzoni
2014-09-12 9:00 ` Vicente Olivert Riera
2014-09-12 9:01 ` Jörg Krause
2014-09-12 9:45 ` Anton Kolesov
2014-09-12 9:50 ` Thomas Petazzoni
2014-09-20 12:10 ` Bernd Kuhls
2014-09-07 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-09-06 Thomas Petazzoni
2014-09-07 8:09 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-09-07 12:56 ` Gustavo Zacarias
2014-09-07 13:06 ` Thomas Petazzoni
2014-09-07 13:07 ` Gustavo Zacarias
2014-09-08 8:32 ` Vicente Olivert Riera
2014-09-08 8:34 ` Thomas Petazzoni
2014-09-08 8:37 ` Vicente Olivert Riera
2014-09-08 9:17 ` Thomas Petazzoni
2014-09-08 12:20 ` Vicente Olivert Riera
2014-09-08 12:29 ` Thomas Petazzoni
2014-09-08 12:59 ` Vicente Olivert Riera
2014-09-08 13:18 ` Thomas Petazzoni
2014-09-06 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-09-05 Thomas Petazzoni
2014-09-06 18:36 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-09-06 20:25 ` Peter Korsgaard
2014-09-07 7:21 ` Thomas Petazzoni
2014-09-07 12:17 ` Thomas De Schampheleire
2014-09-07 12:26 ` Thomas Petazzoni
2014-09-07 15:34 ` Nathaniel Roach
2014-09-07 15:44 ` Yann E. MORIN
2014-09-07 18:18 ` Peter Korsgaard
2014-09-07 3:49 ` Nathaniel Roach
2014-09-07 7:41 ` Thomas Petazzoni
2014-08-29 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-28 Thomas Petazzoni
2014-08-29 7:30 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-08-26 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-25 Thomas Petazzoni
2014-08-26 7:29 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-08-26 7:37 ` Jörg Krause
2014-08-26 11:18 ` Gustavo Zacarias
2014-08-26 11:29 ` Vicente Olivert Riera
2014-08-26 11:46 ` Gustavo Zacarias
2014-08-26 11:48 ` Vicente Olivert Riera
2014-08-26 12:13 ` Gustavo Zacarias
2014-08-13 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-12 Thomas Petazzoni
2014-08-13 8:15 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-08-13 8:26 ` Nathaniel Roach
2014-08-13 9:05 ` Luca Ceresoli
2014-08-13 9:06 ` Thomas Petazzoni
2014-08-13 10:31 ` Peter Korsgaard
2014-08-13 8:33 ` yuvaraj.patil at wipro.com
2014-06-15 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-06-14 Thomas Petazzoni
2014-06-15 10:20 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-06-15 10:36 ` Thomas De Schampheleire
2014-06-15 10:42 ` Thomas Petazzoni
2014-06-15 14:11 ` Thomas De Schampheleire
2014-06-13 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-06-12 Thomas Petazzoni
2014-06-13 9:12 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-06-13 14:55 ` Eric Le Bihan
2014-06-13 15:07 ` Thomas Petazzoni
2014-06-13 15:50 ` Eric Le Bihan
2014-06-13 15:59 ` Thomas Petazzoni
2014-05-07 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-05-06 Thomas Petazzoni
2014-05-07 7:31 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-05-07 8:04 ` Will Newton
2014-05-07 8:58 ` Thomas Petazzoni
2014-05-07 9:04 ` Peter Seiderer
2014-05-07 9:06 ` Thomas Petazzoni
2014-05-07 9:23 ` Thomas De Schampheleire
2014-05-07 9:26 ` Thomas Petazzoni
2014-05-07 13:04 ` Peter Korsgaard
2014-05-08 23:24 ` Arnout Vandecappelle
2014-05-09 13:34 ` Ezequiel Garcia
2014-05-09 19:06 ` Frank Bergmann
2014-03-05 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-03-04 Thomas Petazzoni
2014-03-05 10:27 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-03-05 10:29 ` Alvaro Gamez
2014-03-05 14:37 ` Alvaro Gamez
2014-03-05 14:42 ` Thomas Petazzoni
2014-03-05 15:01 ` Samuel Martin
2014-03-03 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-03-02 Thomas Petazzoni
2014-03-03 8:02 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-03-03 9:10 ` Baruch Siach
2014-03-03 9:38 ` Samuel Martin
2014-03-03 10:05 ` Thomas Petazzoni
2014-03-03 10:19 ` Samuel Martin
2014-03-03 10:27 ` Thomas Petazzoni
2014-03-03 11:17 ` Gustavo Zacarias
2014-03-03 11:31 ` Romain Naour
2014-03-03 12:48 ` Thomas Petazzoni
2014-03-07 0:44 ` Romain Naour
2014-03-07 8:30 ` Thomas Petazzoni
2014-03-10 21:27 ` Romain Naour
2014-03-02 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-03-01 Thomas Petazzoni
2014-03-02 8:57 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-03-02 9:50 ` Samuel Martin
2014-03-02 10:08 ` Thomas Petazzoni
2014-03-04 23:18 ` Arnout Vandecappelle
2014-03-05 9:04 ` Thomas Petazzoni
2014-03-05 10:10 ` Arnout Vandecappelle
2014-03-05 12:40 ` Thomas Petazzoni
2014-02-23 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-22 Thomas Petazzoni
2014-02-23 10:00 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-02-23 10:16 ` Thomas De Schampheleire
2014-02-23 10:56 ` Thomas Petazzoni
2014-02-23 15:45 ` Peter Korsgaard
2014-02-23 23:46 ` Ezequiel García
2014-02-24 21:16 ` Thomas Petazzoni
2014-02-24 21:18 ` Ezequiel García
2014-02-26 21:10 ` Thomas Petazzoni
2014-02-24 10:12 ` Vicente Olivert Riera
2014-02-24 10:30 ` Vicente Olivert Riera
2014-02-25 21:08 ` Samuel Martin
2014-02-21 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-20 Thomas Petazzoni
2014-02-21 9:08 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-02-21 9:24 ` Peter Korsgaard
2014-02-21 9:46 ` Frank Bergmann
2014-02-21 9:49 ` Anton Kolesov
2014-02-21 9:50 ` Thomas De Schampheleire
2014-02-21 13:54 ` Vicente Olivert Riera
2014-02-22 21:54 ` Ryan Barnett
2014-02-24 9:47 ` Vicente Olivert Riera
2014-02-26 11:06 ` Vicente Olivert Riera
2014-02-14 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-13 Thomas Petazzoni
2014-02-14 9:12 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-02-14 10:23 ` Anton Kolesov
2014-02-14 14:13 ` Thomas Petazzoni
2014-02-14 14:42 ` Peter Korsgaard
2014-02-14 15:19 ` Thomas Petazzoni
2014-02-14 17:05 ` Anton Kolesov
2014-02-14 17:42 ` Thomas Petazzoni
2014-02-14 11:29 ` Peter Korsgaard
2014-02-14 13:15 ` Ezequiel García
2014-02-15 7:27 ` Frank Bergmann
2014-02-15 17:29 ` Frank Bergmann
2014-02-15 21:31 ` Baruch Siach
2014-02-16 0:00 ` Romain Naour
2014-02-12 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-11 Thomas Petazzoni
2014-02-12 8:32 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-02-12 9:21 ` Peter Korsgaard
2014-02-12 9:29 ` Thomas Petazzoni
2014-02-12 9:39 ` Peter Korsgaard
2014-02-12 9:45 ` Thomas Petazzoni
2014-02-12 9:52 ` Peter Korsgaard
2014-02-12 10:15 ` Thomas Petazzoni
2014-02-12 9:41 ` Thomas De Schampheleire
2014-02-12 9:47 ` Thomas Petazzoni
2014-02-12 9:50 ` Thomas De Schampheleire
2014-02-12 11:39 ` Thomas De Schampheleire
2014-02-12 12:29 ` Thomas De Schampheleire
2014-02-12 12:31 ` Thomas Petazzoni
2014-02-12 12:44 ` Thomas De Schampheleire
2014-02-12 12:47 ` Thomas Petazzoni
2014-02-12 11:25 ` Samuel Martin
2014-02-12 17:52 ` Yann E. MORIN
2014-02-11 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-10 Thomas Petazzoni
2014-02-11 9:10 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-02-11 17:37 ` Baruch Siach
2014-02-12 8:05 ` Thomas Petazzoni
2014-02-12 8:11 ` Baruch Siach
2014-02-11 18:01 ` Yann E. MORIN
2014-02-12 8:06 ` Thomas Petazzoni
2014-02-12 20:58 ` Romain Naour
2014-02-13 11:29 ` Thomas Petazzoni
2014-02-13 18:54 ` Thomas Petazzoni
2014-02-13 21:17 ` Romain Naour
2014-02-13 21:59 ` Thomas Petazzoni
2014-02-07 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-06 Thomas Petazzoni
2014-02-07 12:53 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-02-07 13:01 ` Thomas De Schampheleire
2014-02-07 13:33 ` Thomas Petazzoni
2014-02-07 18:40 ` Yann E. MORIN
2014-02-07 13:25 ` Gustavo Zacarias
2014-02-07 19:18 ` Arnout Vandecappelle
2014-02-08 21:43 ` Peter Korsgaard
2014-02-07 14:00 ` Anton Kolesov
2014-02-07 14:53 ` Ezequiel García
2014-02-07 14:55 ` Thomas Petazzoni
2014-02-07 15:07 ` Ezequiel García
2014-02-07 15:14 ` Thomas Petazzoni
2014-02-07 15:19 ` Ezequiel García
2014-02-07 15:18 ` Peter Korsgaard
2014-02-07 18:53 ` Yann E. MORIN
2014-02-07 19:03 ` Spenser Gilliland
2014-02-08 11:40 ` Romain Naour
2014-02-17 15:40 ` Vicente Olivert Riera
2014-02-17 15:44 ` Markos Chandras
2014-02-17 15:45 ` Vicente Olivert Riera
2014-02-17 16:09 ` Thomas Petazzoni
2013-11-29 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2013-11-28 Thomas Petazzoni
2013-11-29 8:51 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2013-11-29 9:00 ` Peter Korsgaard
2013-11-29 10:04 ` Gustavo Zacarias
2013-11-22 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2013-11-21 Thomas Petazzoni
2013-11-22 8:14 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2013-11-22 9:15 ` Fabio Porcedda
2013-11-29 10:25 ` Fabio Porcedda
2013-11-22 10:42 ` Thomas De Schampheleire
2013-11-22 12:59 ` Thomas De Schampheleire
2013-11-22 16:01 ` Arnout Vandecappelle
2013-11-22 16:03 ` Thomas De Schampheleire
2013-11-22 11:56 ` Thomas Petazzoni
2013-11-22 11:58 ` Fatih Aşıcı
2013-11-22 12:13 ` Thomas Petazzoni
2013-11-23 23:07 ` Arnout Vandecappelle
2013-11-22 15:20 ` Peter Korsgaard
2013-11-09 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2013-11-08 Thomas Petazzoni
2013-11-09 18:15 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2013-11-09 20:46 ` Gustavo Zacarias
2013-11-10 6:25 ` Baruch Siach
2013-11-10 8:43 ` Thomas Petazzoni
2013-11-10 10:32 ` Baruch Siach
2013-11-10 15:21 ` Thomas Petazzoni
2013-11-10 10:32 ` Simon Dawson
2013-11-10 10:46 ` Thomas Petazzoni
2013-11-10 11:21 ` Simon Dawson
2013-11-10 11:36 ` Thomas Petazzoni
2013-11-10 22:56 ` Peter Korsgaard
2013-11-10 10:57 ` Gustavo Zacarias
2013-11-10 11:07 ` Thomas Petazzoni
2013-11-11 5:33 ` Chris Zankel
2013-11-11 9:58 ` Thomas Petazzoni
2013-11-11 10:10 ` Baruch Siach
2013-11-11 10:15 ` Thomas Petazzoni
2013-11-11 10:20 ` Baruch Siach
2013-11-11 10:39 ` Thomas Petazzoni
2013-11-11 9:14 ` Fatih Aşıcı
2013-11-11 10:09 ` Thomas Petazzoni
2013-11-11 12:26 ` Fatih Aşıcı
2013-11-11 9:30 ` Gustavo Zacarias
[not found] ` <5280A0D3.1080605@imgtec.com>
2013-11-11 9:21 ` Markos Chandras
2013-11-11 9:46 ` Peter Korsgaard
2013-11-11 9:49 ` Markos Chandras
2013-11-11 10:01 ` Will Newton
2013-11-11 10:17 ` Thomas Petazzoni
2013-11-11 10:25 ` Will Newton
2013-11-11 10:43 ` Thomas Petazzoni
2013-11-11 11:25 ` Ezequiel García
2013-11-11 11:27 ` Peter Korsgaard
2013-11-11 11:45 ` Thomas Petazzoni
2013-08-28 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2013-08-27 Thomas Petazzoni
2013-08-28 7:08 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2013-08-28 7:17 ` Will Newton
2013-08-28 11:19 ` Thomas Petazzoni
2013-08-28 11:00 ` Gustavo Zacarias
2013-08-28 11:30 ` Thomas Petazzoni
2013-08-28 11:34 ` Gustavo Zacarias
2013-08-28 11:49 ` Thomas Petazzoni
2013-08-28 11:55 ` Gustavo Zacarias
2013-08-28 11:31 ` Thomas De Schampheleire
2013-08-28 11:55 ` Thomas Petazzoni
2013-08-28 13:13 ` Thomas De Schampheleire
2013-08-28 13:21 ` Thomas Petazzoni
2013-08-28 11:45 ` Markos Chandras
2013-08-28 12:07 ` Thomas Petazzoni
2013-08-28 21:09 ` Arnout Vandecappelle
2013-08-28 21:29 ` Arnout Vandecappelle
2013-08-29 13:17 ` Jérôme Pouiller
2013-08-29 15:12 ` Thomas De Schampheleire
2013-08-30 9:26 ` Jérôme Pouiller
2013-08-30 11:08 ` Thomas Petazzoni
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.