* [Buildroot] [autobuild.buildroot.net] Build results for 2015-05-05 @ 2015-05-06 6:30 Thomas Petazzoni 2015-05-06 6:36 ` Max Filippov 2015-05-06 7:42 ` [Buildroot] Analysis of build failures Thomas Petazzoni 0 siblings, 2 replies; 14+ messages in thread From: Thomas Petazzoni @ 2015-05-06 6:30 UTC (permalink / raw) To: buildroot Build statistics for 2015-05-05 =============================== success : 301 failures : 50 timeouts : 1 TOTAL : 352 Classification of failures by reason ==================================== freerdp-770c67d340d5f0a7b48... | 6 postgresql-9.4.1 | 5 python-pyqt-4.11.3 | 5 cc-tool-0.26 | 4 sane-backends-1.0.24 | 2 cryptsetup-1.6.6 | 2 snmppp-3.3.4 | 2 libsigsegv-2.10 | 2 numactl-2.0.10 | 2 qt-4.8.6 | 2 tinyxml2-2.2.0 | 2 weston-1.7.0 | 1 google-breakpad-1373 | 1 rsyslog-8.9.0 | 1 librsvg-2.26.3 | 1 libepoxy-v1.2 | 1 python-2.7.9 | 1 lua-periphery-1.0.4-1 | 1 zmqpp-3.2.0 | 1 ipmiutil-2.9.5 | 1 cdrkit-1.1.11 | 1 qt5webkit-5.4.1 | 1 libarchive-3.1.2 | 1 gst1-plugins-bad-1.4.5 | 1 host-qemu-2.3.0 | 1 mesa3d-10.5.4 | 1 czmq-v3.0.0 | 1 boost-1.57.0 | 1 Detail of failures =================== powerpc | boost-1.57.0 | NOK | http://autobuild.buildroot.net/results/b64fd94a8ccff7fa8c5e0ca0c4acb7254f9cddc3/ 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/ x86_64 | cdrkit-1.1.11 | NOK | http://autobuild.buildroot.net/results/2bd48ed578a143749d4503aca96f661647afe525/ nios2 | cryptsetup-1.6.6 | NOK | http://autobuild.buildroot.net/results/ff456344eb5bc8af619c1f5d88be0cb758dd5075/ nios2 | cryptsetup-1.6.6 | NOK | http://autobuild.buildroot.net/results/a288b0c5b437c3d82dae4f3bf391c59236739c3a/ xtensa | czmq-v3.0.0 | NOK | http://autobuild.buildroot.net/results/4d3dea604da9a5a1e7fe20548813f8de474ae33f/ 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/ aarch64 | google-breakpad-1373 | NOK | http://autobuild.buildroot.net/results/c9f116443199dab708a18c23fcea3e623664d947/ mips64el | gst1-plugins-bad-1.4.5 | NOK | http://autobuild.buildroot.net/results/a23401c97a11636799b685d9eec8c96e5e202cd0/ sh4a | host-qemu-2.3.0 | NOK | http://autobuild.buildroot.net/results/40a47f11daa201c488519c0b1270cc2e71cc3116/ i686 | ipmiutil-2.9.5 | NOK | http://autobuild.buildroot.net/results/e0a198d88c746c6ad24916d723b5faa9024f8abd/ bfin | libarchive-3.1.2 | NOK | http://autobuild.buildroot.net/results/6c0225e109d87178e80cf7edfff1461b077629b2/ arm | libepoxy-v1.2 | NOK | http://autobuild.buildroot.net/results/fee1e3a4eb7923d7ce166184323b908ed069b3b6/ arc | librsvg-2.26.3 | TIM | http://autobuild.buildroot.net/results/858daf884d04d56d37e3a2e481c45f7b9a2a88f8/ arm | libsigsegv-2.10 | NOK | http://autobuild.buildroot.net/results/a144bc6024415a5272c3cbe60ff636d078d0a555/ arm | libsigsegv-2.10 | NOK | http://autobuild.buildroot.net/results/00195d89a115a314bf4916af127407f61cd1b418/ mips | lua-periphery-1.0.4-1 | NOK | http://autobuild.buildroot.net/results/2c7bd050917ab0a65a53f3516a7023cac5be078a/ xtensa | mesa3d-10.5.4 | NOK | http://autobuild.buildroot.net/results/3e2e24f697e26c93d4d95782b1cb7799fa620a7a/ 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/ 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/ arc | python-2.7.9 | NOK | http://autobuild.buildroot.net/results/4c694d715f66de49964ef36f7236c7575c3a0b5a/ 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/ i686 | qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/50315ab70d313f40a0caeff51dc76354495a5cf9/ mips64el | qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/0e2e877cb75a49d0560ab785c4afa51065fbd54f/ arm | qt5webkit-5.4.1 | NOK | http://autobuild.buildroot.net/results/b6d6e19cfe484afabcd392f6095e8425dd591540/ powerpc | rsyslog-8.9.0 | NOK | http://autobuild.buildroot.net/results/d9c388b15c20c934426400c8e85775ea1efcc007/ 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/ 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/ bfin | tinyxml2-2.2.0 | NOK | http://autobuild.buildroot.net/results/349c1ec8ee9f2e1e1f8f37b6e6823761cad5edc8/ bfin | tinyxml2-2.2.0 | NOK | http://autobuild.buildroot.net/results/c96e4bd3044c89df8e67d9c383886eb61c438e24/ sh4a | weston-1.7.0 | NOK | http://autobuild.buildroot.net/results/b4da4e9f0c85c9fb402cb5a1bb5a8d1d63b05b13/ sh4 | zmqpp-3.2.0 | NOK | http://autobuild.buildroot.net/results/73e5b739887dd0d62fb215bd03b13a31e4a0d1fa/ -- http://autobuild.buildroot.net ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2015-05-05 2015-05-06 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2015-05-05 Thomas Petazzoni @ 2015-05-06 6:36 ` Max Filippov 2015-05-06 7:42 ` [Buildroot] Analysis of build failures Thomas Petazzoni 1 sibling, 0 replies; 14+ messages in thread From: Max Filippov @ 2015-05-06 6:36 UTC (permalink / raw) To: buildroot On Wed, May 6, 2015 at 9:30 AM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Build statistics for 2015-05-05 > =============================== > xtensa | mesa3d-10.5.4 | NOK | http://autobuild.buildroot.net/results/3e2e24f697e26c93d4d95782b1cb7799fa620a7a/ Yet another linker bug. I'm looking at it. -- Thanks. -- Max ^ permalink raw reply [flat|nested] 14+ 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 6:36 ` Max Filippov @ 2015-05-06 7:42 ` Thomas Petazzoni 2015-05-06 8:07 ` gwenhael.goavec ` (4 more replies) 1 sibling, 5 replies; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ messages in thread
end of thread, other threads:[~2015-05-07 7:42 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-05-06 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2015-05-05 Thomas Petazzoni 2015-05-06 6:36 ` Max Filippov 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
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.