* [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-11
@ 2014-02-12 7:30 Thomas Petazzoni
2014-02-12 8:32 ` [Buildroot] Analysis of build failures Thomas Petazzoni
` (2 more replies)
0 siblings, 3 replies; 23+ messages in thread
From: Thomas Petazzoni @ 2014-02-12 7:30 UTC (permalink / raw)
To: buildroot
Build statistics for 2014-02-11
===============================
success : 99
failures : 27
timeouts : 1
TOTAL : 127
Classification of failures by reason
====================================
vlc-2.1.2 | 3
mplayer-1.1.1 | 2
libnftnl-1.0.0 | 2
ne10-88c18f02199947b2c8b577... | 1
dropwatch-1.4 | 1
elfutils-0.155 | 1
thrift-0.9.1 | 1
sdl-1.2.15 | 1
iozone-3_414 | 1
aiccu-20070115 | 1
qtuio-abe4973ff60654aad9df7... | 1
imlib2-1.4.5 | 1
orc-0.4.18 | 1
audiofile-0.3.6 | 1
lvm2-2.02.103 | 1
enlightenment-0.17.3 | 1
boost-1.55.0 | 1
toolchain-external-undefined | 1
czmq-b5730c5f8290a611fd3b92... | 1
libv4l-0.8.9 | 1
libevas-1.7.7 | 1
unknown | 1
alsa-lib-1.0.26 | 1
coreutils-8.21 | 1
Detail of failures
===================
avr32 | aiccu-20070115 | NOK | http://autobuild.buildroot.net/results/aeeaaf1f22d655eb918a492d430f5cce37b8a201/
bfin | alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/7069e1f43cbed745d65f7dd9904a3fff034530ac/
avr32 | audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/595a83e6f1df0f0c0294d31ccb3857206c0da47a/
bfin | boost-1.55.0 | NOK | http://autobuild.buildroot.net/results/17dd7946631354d59336259d5f31aa899e3599b8/
aarch64 | coreutils-8.21 | NOK | http://autobuild.buildroot.net/results/c57f89ffa732e2bfbb6ebf9af9de5bac3cbc197f/
bfin | czmq-b5730c5f8290a611fd3b92... | NOK | http://autobuild.buildroot.net/results/1ae0fee94f2161ce20ba6efdccf7fb90ddbfcb1b/
microblaze | dropwatch-1.4 | NOK | http://autobuild.buildroot.net/results/0365f1e36a91f64e5c67eb1d4872ec57269ddd8f/
bfin | elfutils-0.155 | NOK | http://autobuild.buildroot.net/results/4c38d5c29d3c338e84c7c3720f89b0b81ab629ac/
powerpc | enlightenment-0.17.3 | NOK | http://autobuild.buildroot.net/results/314694709b3a2d812c18acc70e374b3bc2fbedbd/
bfin | imlib2-1.4.5 | NOK | http://autobuild.buildroot.net/results/567beac5f5d0c19620a6e770d2b9302bed481332/
arm | iozone-3_414 | NOK | http://autobuild.buildroot.net/results/2a33d2c7535a9d867d76dd5cf05e1bcc3f5cdc38/
bfin | libevas-1.7.7 | NOK | http://autobuild.buildroot.net/results/ad90baa5e07569308a7e2b2510b67c5b2a563b44/
powerpc | libnftnl-1.0.0 | NOK | http://autobuild.buildroot.net/results/8be92ceb7e93332b218d3090b1b4fbf64e7af887/
powerpc | libnftnl-1.0.0 | NOK | http://autobuild.buildroot.net/results/9a5c30cccf7b7e1c68a384fa5c49e4009d50400e/
aarch64 | libv4l-0.8.9 | NOK | http://autobuild.buildroot.net/results/6635f7149cd0f5192d49276b2cc3edc5be3b5868/
xtensa | lvm2-2.02.103 | NOK | http://autobuild.buildroot.net/results/2c6b9fdfffe81042d7606893d1ff006f9e6c4296/
xtensa | mplayer-1.1.1 | NOK | http://autobuild.buildroot.net/results/68bb764e5b34a2862537c3bd4b57ef5af529f0a3/
arm | mplayer-1.1.1 | NOK | http://autobuild.buildroot.net/results/ed28908a93362d76fc720cf67f6c530eed8d855b/
arm | ne10-88c18f02199947b2c8b577... | NOK | http://autobuild.buildroot.net/results/4d12fc71a775b0f81afeae1fa5317c0cb319185f/
bfin | orc-0.4.18 | NOK | http://autobuild.buildroot.net/results/dd64c2aed5291b6c083f061709d6179150440a7e/
arm | qtuio-abe4973ff60654aad9df7... | NOK | http://autobuild.buildroot.net/results/9b57f76672c8d0a74980cb1de32661761b666ce7/
x86_64 | sdl-1.2.15 | NOK | http://autobuild.buildroot.net/results/451521367a12cc4eda823526ec1e25580d4a2cc6/
x86_64 | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/23caf6deef3cbd8fd6b150e133d493d26d16d80b/
arm | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/656cddb6f22360808fbe39a9d112a06b87ad313a/
nios2 | unknown | TIM | http://autobuild.buildroot.net/results/fe79fe617e7bb8c7fabcbaefac883604bbb49d80/
i686 | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/39c77ffb5a5599d0b09422433c747b2bac185c4f/
mips | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/05bc24c48da6ccd9cccb90689b7457b973278f9d/
microblaze | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/67d14aaaf6b4c04225a457676c8ff7b125f6b692/
--
http://autobuild.buildroot.net
^ permalink raw reply [flat|nested] 23+ 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)
2014-02-12 8:36 ` [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-11 Fabio Porcedda
2014-02-12 8:57 ` Lionel Orry
2 siblings, 4 replies; 23+ 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] 23+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-11
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 8:36 ` Fabio Porcedda
2014-02-12 8:39 ` Thomas Petazzoni
2014-02-12 8:57 ` Lionel Orry
2 siblings, 1 reply; 23+ messages in thread
From: Fabio Porcedda @ 2014-02-12 8:36 UTC (permalink / raw)
To: buildroot
On Wed, Feb 12, 2014 at 8:30 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Build statistics for 2014-02-11
<snip>
> xtensa | lvm2-2.02.103 | NOK | http://autobuild.buildroot.net/results/2c6b9fdfffe81042d7606893d1ff006f9e6c4296/
I will send the updated patch to disable static building for lvm2.
Best regards
--
Fabio Porcedda
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-11
2014-02-12 8:36 ` [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-11 Fabio Porcedda
@ 2014-02-12 8:39 ` Thomas Petazzoni
2014-02-12 8:43 ` Fabio Porcedda
0 siblings, 1 reply; 23+ messages in thread
From: Thomas Petazzoni @ 2014-02-12 8:39 UTC (permalink / raw)
To: buildroot
Dear Fabio Porcedda,
On Wed, 12 Feb 2014 09:36:40 +0100, Fabio Porcedda wrote:
> > xtensa | lvm2-2.02.103 | NOK | http://autobuild.buildroot.net/results/2c6b9fdfffe81042d7606893d1ff006f9e6c4296/
>
> I will send the updated patch to disable static building for lvm2.
Is it fundamentally unable to do static linking?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-11
2014-02-12 8:39 ` Thomas Petazzoni
@ 2014-02-12 8:43 ` Fabio Porcedda
0 siblings, 0 replies; 23+ messages in thread
From: Fabio Porcedda @ 2014-02-12 8:43 UTC (permalink / raw)
To: buildroot
On Wed, Feb 12, 2014 at 9:39 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Fabio Porcedda,
>
> On Wed, 12 Feb 2014 09:36:40 +0100, Fabio Porcedda wrote:
>
>> > xtensa | lvm2-2.02.103 | NOK | http://autobuild.buildroot.net/results/2c6b9fdfffe81042d7606893d1ff006f9e6c4296/
>>
>> I will send the updated patch to disable static building for lvm2.
>
> Is it fundamentally unable to do static linking?
No, it can be fixed, i've already sent a patch for that:
http://patchwork.ozlabs.org/patch/312469/
The patch is to disable shared building and effectively use the static binaries.
But the patch was not sent upstream because it needs more work to be
able to sent upstream so Peter suggested to just disable static
building.
Both solutions are fine for me.
Best regards
--
Fabio Porcedda
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-11
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 8:36 ` [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-11 Fabio Porcedda
@ 2014-02-12 8:57 ` Lionel Orry
2014-02-12 9:37 ` Thomas Petazzoni
2 siblings, 1 reply; 23+ messages in thread
From: Lionel Orry @ 2014-02-12 8:57 UTC (permalink / raw)
To: buildroot
Hi,
On Wed, Feb 12, 2014 at 8:30 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> <snip>
> powerpc | enlightenment-0.17.3 | NOK | http://autobuild.buildroot.net/results/314694709b3a2d812c18acc70e374b3bc2fbedbd/
This is due to non-existent PTRACE_GETSIGINFO in sys/ptrace.h from
used powerpc uclibc. I noticed this patch for v0.9.31:
http://git.buildroot.net/buildroot/diff/?id=d8de970bae3744fe830e96a1ae0c4aff6ce47ba1
I don't know which uclibc version is used, but more recent ones
upstream do not include this fix, see for example
http://git.uclibc.org/uClibc/tree/libc/sysdeps/linux/powerpc/sys/ptrace.h
I'm not sure about the right fix but it seems there's a problem with
the provided sys/ptrace.h file for powerpc arch in uclibc. That's as
far as I can go, I rarely use uclibc unfortunately.
Hope it helps,
Lionel
^ permalink raw reply [flat|nested] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-11
2014-02-12 8:57 ` Lionel Orry
@ 2014-02-12 9:37 ` Thomas Petazzoni
0 siblings, 0 replies; 23+ messages in thread
From: Thomas Petazzoni @ 2014-02-12 9:37 UTC (permalink / raw)
To: buildroot
Dear Lionel Orry,
On Wed, 12 Feb 2014 09:57:55 +0100, Lionel Orry wrote:
> Hi,
>
> On Wed, Feb 12, 2014 at 8:30 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > <snip>
> > powerpc | enlightenment-0.17.3 | NOK | http://autobuild.buildroot.net/results/314694709b3a2d812c18acc70e374b3bc2fbedbd/
>
> This is due to non-existent PTRACE_GETSIGINFO in sys/ptrace.h from
> used powerpc uclibc. I noticed this patch for v0.9.31:
> http://git.buildroot.net/buildroot/diff/?id=d8de970bae3744fe830e96a1ae0c4aff6ce47ba1
> I don't know which uclibc version is used, but more recent ones
> upstream do not include this fix, see for example
> http://git.uclibc.org/uClibc/tree/libc/sysdeps/linux/powerpc/sys/ptrace.h
>
> I'm not sure about the right fix but it seems there's a problem with
> the provided sys/ptrace.h file for powerpc arch in uclibc. That's as
> far as I can go, I rarely use uclibc unfortunately.
The toolchain is using uClibc 0.9.33.2 + the uClibc patches that we had
back in the 2013.11-rc2 release.
We have a uclibc-0020-update-ptrace.h-to-latest-from-glibc.patch that
updates ptrace.h, but it seems like powerpc doesn't use the common
ptrace.h, but its own version, and this version hasn't been updated in
uClibc master.
Comparing the uClibc powerpc ptrace.h with the one in glibc indeed
shows a significant number of differences, including the addition of
PTRACE_SETSIGINFO. Someone should cook a patch that syncs up the
powerpc ptrace.h of uClibc with the one from glibc.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ messages in thread
end of thread, other threads:[~2014-02-12 17:52 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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-12 8:36 ` [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-11 Fabio Porcedda
2014-02-12 8:39 ` Thomas Petazzoni
2014-02-12 8:43 ` Fabio Porcedda
2014-02-12 8:57 ` Lionel Orry
2014-02-12 9:37 ` 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.