* [Buildroot] [autobuild.buildroot.net] Build results for 2017-02-13
@ 2017-02-14 7:28 Thomas Petazzoni
2017-02-14 13:27 ` [Buildroot] Analysis of build " Thomas Petazzoni
0 siblings, 1 reply; 25+ messages in thread
From: Thomas Petazzoni @ 2017-02-14 7:28 UTC (permalink / raw)
To: buildroot
Hello,
Build statistics for 2017-02-13
================================
successes : 179
failures : 62
timeouts : 1
TOTAL : 242
Classification of failures by reason
====================================
wget-1.19 | 7
qt5base-5.8.0 | 5
libepoxy-v1.3.1 | 4
ortp-0.27.0 | 4
sngrep-v1.4.2 | 4
openswan-2.6.46 | 3
qemu-2.7.0 | 3
riemann-c-client-1.9.1 | 3
xfsprogs-4.8.0 | 3
cbootimage-v1.7 | 2
lttng-libust-2.9.0 | 2
mpd-0.20.4 | 2
tcpreplay-4.1.2 | 2
bctoolbox-0.4.0 | 1
cups-2.2.2 | 1
ddrescue-1.22 | 1
gdb-7.11.1 | 1
kmsxx-bd5f6471e619a6ba2987b... | 1
lcdapi-v0.10 | 1
libcec-4.0.2 | 1
libraw-0.17.1 | 1
libsvg-0.1.4 | 1
libv4l-1.12.2 | 1
lttng-tools-2.9.3 | 1
mesa3d-demos-8.3.0 | 1
python-flask-login-0.3.2 | 1
qt5base-5.6.2 | 1
qt5webkit-5.8.0 | 1
slang-2.3.0 | 1
synergy-1.3.1 | 1
vlc-2.2.4 | 1
wavpack-5.1.0 | 1
Detail of failures
===================
powerpc | bctoolbox-0.4.0 | NOK | http://autobuild.buildroot.net/results/cfeb2f542598e5d450b332fb51a6d79bae24158c
arm | cbootimage-v1.7 | NOK | http://autobuild.buildroot.net/results/61bdfb7e0ff9628190d9eb86e40c4c90e768b8e2
arm | cbootimage-v1.7 | NOK | http://autobuild.buildroot.net/results/b78c03b85aef845ff57d499b40f52b476f8a760c
i586 | cups-2.2.2 | NOK | http://autobuild.buildroot.net/results/486dea944d6ecba5c4e6e8ac664261c1909f4b4c
powerpc | ddrescue-1.22 | NOK | http://autobuild.buildroot.net/results/4ac0754f1cc5ea934d6437e89d1f4906fb3fd0a8
x86_64 | gdb-7.11.1 | NOK | http://autobuild.buildroot.net/results/8585f08138a684724ce6293a0fa9e0d005bfa372
m68k | kmsxx-bd5f6471e619a6ba2987b... | NOK | http://autobuild.buildroot.net/results/2738e5fd446467b105f6dcca391500e3734e5a9b
m68k | lcdapi-v0.10 | NOK | http://autobuild.buildroot.net/results/7417f177a850eed85ead40adf3694a4c7cf0b870
i586 | libcec-4.0.2 | NOK | http://autobuild.buildroot.net/results/95bbcebc8768d1be026a83d9437a9b206b94df20
arm | libepoxy-v1.3.1 | NOK | http://autobuild.buildroot.net/results/3912eaa022865ce81535fbb72a206577e32b506f
arm | libepoxy-v1.3.1 | NOK | http://autobuild.buildroot.net/results/1e09ab626e3ecdd0467842b81200d96073af66e6
arm | libepoxy-v1.3.1 | NOK | http://autobuild.buildroot.net/results/e2408c887dde0ad9f7120d2ab3e267da84c16484
arm | libepoxy-v1.3.1 | NOK | http://autobuild.buildroot.net/results/7f2cdfbc125292de2427d16f9ae0b5ad971a24c2
sh4a | libraw-0.17.1 | NOK | http://autobuild.buildroot.net/results/908aef6c82d56060933713df217b6b2ba21a01b0
powerpc64 | libsvg-0.1.4 | NOK | http://autobuild.buildroot.net/results/f2d5b2459080bf9c67906b8b240150303bb61461
i586 | libv4l-1.12.2 | NOK | http://autobuild.buildroot.net/results/b8b96c7bbf2147dacac62485cbfdbcfd758271a5
i686 | lttng-libust-2.9.0 | NOK | http://autobuild.buildroot.net/results/ee1abc83bbe1e2fc2e9097e1f79fbd04f411e431
arm | lttng-libust-2.9.0 | NOK | http://autobuild.buildroot.net/results/72e9a6f39bb8e4da421926d5a73911760777e93b
arm | lttng-tools-2.9.3 | NOK | http://autobuild.buildroot.net/results/11d5a5bcef8e05822136ac302371115f4fe3c4ee
arm | mesa3d-demos-8.3.0 | NOK | http://autobuild.buildroot.net/results/6f197c643972e92f0b27b3afac7da7b4b1115f7e
xtensa | mpd-0.20.4 | NOK | http://autobuild.buildroot.net/results/b3058c729e6b389aa0100d3918c0db3fd1a5dfc3
arc | mpd-0.20.4 | NOK | http://autobuild.buildroot.net/results/3a6b236969982094ec43e2a25e51b2e396574c0f
xtensa | openswan-2.6.46 | NOK | http://autobuild.buildroot.net/results/b52d69c54e07edeeee86a525fac4cf00c47c2e45
arm | openswan-2.6.46 | NOK | http://autobuild.buildroot.net/results/15af420dc866af4bf639f2ef003aacfe9ead7447
xtensa | openswan-2.6.46 | NOK | http://autobuild.buildroot.net/results/5be7eb7606d99c7df1afdd8fa011be5de7daa7f0
arm | ortp-0.27.0 | NOK | http://autobuild.buildroot.net/results/5625f8f1d62ba87d6bd94ab8978f72992b766086
arm | ortp-0.27.0 | NOK | http://autobuild.buildroot.net/results/ae54693a59b2d8dd8d83d224b93f1b4223e0af40
arm | ortp-0.27.0 | NOK | http://autobuild.buildroot.net/results/d69e14b25564ff58844f5b3970fa5e7621f0f0bc
arm | ortp-0.27.0 | NOK | http://autobuild.buildroot.net/results/584fc74d2e7fe790529051eee95c9475ed1033ac
mipsel | python-flask-login-0.3.2 | NOK | http://autobuild.buildroot.net/results/2e0574cbdaa202807b206b4e0988c3ed361d4a21
x86_64 | qemu-2.7.0 | NOK | http://autobuild.buildroot.net/results/17dea7dcb390b3cb9319a0e3ef55562b3c8d6e2d
arm | qemu-2.7.0 | NOK | http://autobuild.buildroot.net/results/42172dfa49d7006426ef7c39ea916174456537b2
arm | qemu-2.7.0 | NOK | http://autobuild.buildroot.net/results/f5be91e90e26b0bc65259ef4262b9cface1d584e
nios2 | qt5base-5.6.2 | NOK | http://autobuild.buildroot.net/results/020da67e98c897e6179b0e62f38a753099637de9
powerpc64 | qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/782f9fec5c0e4abe0e58040d26ad6cc54f5324a0
nios2 | qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/5ebc47dcccffdf03097f72f829344a997874de61
powerpc | qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/6a98ac82436b6b9733a9539ed433fd9c59442229
xtensa | qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/ba5fb88f684b35b7d0bd738b98dd14f37b8b812c
powerpc | qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/58e40dc27305282f8e0c3f91575098e40865a3d8
arm | qt5webkit-5.8.0 | NOK | http://autobuild.buildroot.net/results/e5b926b680c8a1f94148cb1523e3de8380b6aed9
sh4a | riemann-c-client-1.9.1 | NOK | http://autobuild.buildroot.net/results/da6b762c2497ee050ca6decb3db42c913c95c032
nios2 | riemann-c-client-1.9.1 | NOK | http://autobuild.buildroot.net/results/80d83c650c668ee1e87c288bd7a0ce63eab95631
mipsel | riemann-c-client-1.9.1 | NOK | http://autobuild.buildroot.net/results/a613830ffab74f144238ee88a1e5067d387e643f
arm | slang-2.3.0 | NOK | http://autobuild.buildroot.net/results/5da778c67e263736cb2c42a6910ed54983f5c018
arm | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/598882bb0d110eedf4ee85ce93987d91947c675e
arm | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/427aff122138b016f1733b618f7f07b957282610
mipsel | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/666b15fb903369ef7b58d123308037bd44547142
arm | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/36bd529abc930c2ff236bcbee3ad1aba0c39e604
arm | synergy-1.3.1 | NOK | http://autobuild.buildroot.net/results/d9ab699ba314f87a12b4982811ebfa1c3186a408
powerpc | tcpreplay-4.1.2 | TIM | http://autobuild.buildroot.net/results/3883530f1c8c6ec03a4c880fb32acb21464c4323
x86_64 | tcpreplay-4.1.2 | NOK | http://autobuild.buildroot.net/results/b3c31e803ff552a196ce5717372c09d6f64c91bf
arc | vlc-2.2.4 | NOK | http://autobuild.buildroot.net/results/b7405a67745b68dcde907c1d8259851d68984694
microblazeel | wavpack-5.1.0 | NOK | http://autobuild.buildroot.net/results/59b176eb0fa5660a6b2a81a880a2f8559e529c4b
arm | wget-1.19 | NOK | http://autobuild.buildroot.net/results/2c77cb25099f67f87af470528bb05732ad5ac299
x86_64 | wget-1.19 | NOK | http://autobuild.buildroot.net/results/b62ac6fd5ce36453935c309e112262467cf0e3bf
arm | wget-1.19 | NOK | http://autobuild.buildroot.net/results/439bf0b0d446b8da64eece7805c8b1e43b90f764
sparc | wget-1.19 | NOK | http://autobuild.buildroot.net/results/330a4b81d008b3f2f82fcc8712f3109fe72f007d
arm | wget-1.19 | NOK | http://autobuild.buildroot.net/results/4cc37a3f2ca8e79ca6d487da51e032411e466d70
arm | wget-1.19 | NOK | http://autobuild.buildroot.net/results/8e52ea6d0353fe8ab4196b9f959740ab7cfacb87
nios2 | wget-1.19 | NOK | http://autobuild.buildroot.net/results/ac99fadd3cd6590567836a0cf25a2ff5ac3ea4ab
m68k | xfsprogs-4.8.0 | NOK | http://autobuild.buildroot.net/results/d48e61785d25d33106b7dab1b5cb200cf27d4044
arm | xfsprogs-4.8.0 | NOK | http://autobuild.buildroot.net/results/202f0e7898b049b46c29646a57c8d9718cb3eae7
arm | xfsprogs-4.8.0 | NOK | http://autobuild.buildroot.net/results/57975f401f39b673eeec304b4738cfb41a19ece7
--
http://autobuild.buildroot.net
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 7:28 [Buildroot] [autobuild.buildroot.net] Build results for 2017-02-13 Thomas Petazzoni
@ 2017-02-14 13:27 ` Thomas Petazzoni
2017-02-14 14:51 ` Peter Korsgaard
` (8 more replies)
0 siblings, 9 replies; 25+ messages in thread
From: Thomas Petazzoni @ 2017-02-14 13:27 UTC (permalink / raw)
To: buildroot
Hello,
J?rg, Peter, Romain, Bernd, Gustavo, Carsten, Philippe, Yann, Fran?ois,
Dagg, Baruch and ARC/Synopsys developers, there are some questions for
you below.
Thanks!
On Tue, 14 Feb 2017 08:28:56 +0100 (CET), Thomas Petazzoni wrote:
> powerpc | bctoolbox-0.4.0 | NOK | http://autobuild.buildroot.net/results/cfeb2f542598e5d450b332fb51a6d79bae24158c
Not sure:
Could NOT find PolarSSL (missing: POLARSSL_INCLUDE_DIRS
HAVE_POLARSSL_SSL_H)
J?rg, could you have a look?
> arm | cbootimage-v1.7 | NOK | http://autobuild.buildroot.net/results/61bdfb7e0ff9628190d9eb86e40c4c90e768b8e2
> arm | cbootimage-v1.7 | NOK | http://autobuild.buildroot.net/results/b78c03b85aef845ff57d499b40f52b476f8a760c
Musl compatibility issue.
> i586 | cups-2.2.2 | NOK | http://autobuild.buildroot.net/results/486dea944d6ecba5c4e6e8ac664261c1909f4b4c
The musl/i586/SSP issue.
> powerpc | ddrescue-1.22 | NOK | http://autobuild.buildroot.net/results/4ac0754f1cc5ea934d6437e89d1f4906fb3fd0a8
Missing <stdio.h> include in block.h I believe. Peter (Seiderer), could
you send a patch to fix this?
> x86_64 | gdb-7.11.1 | NOK | http://autobuild.buildroot.net/results/8585f08138a684724ce6293a0fa9e0d005bfa372
tracepoint-ipa.o: In function `get_timestamp':
tracepoint.c:(.text+0x14a): undefined reference to `rpl_gettimeofday'
Romain, you looked into this problem and reported the issue to upstream
gdb: https://sourceware.org/bugzilla/show_bug.cgi?id=19798. You said
you worked around it, but it's still there. Could you have a look?
> m68k | kmsxx-bd5f6471e619a6ba2987b... | NOK | http://autobuild.buildroot.net/results/2738e5fd446467b105f6dcca391500e3734e5a9b
Missing magic gcc option, Waldemar will provide a fix.
> m68k | lcdapi-v0.10 | NOK | http://autobuild.buildroot.net/results/7417f177a850eed85ead40adf3694a4c7cf0b870
Same.
> i586 | libcec-4.0.2 | NOK | http://autobuild.buildroot.net/results/95bbcebc8768d1be026a83d9437a9b206b94df20
/usr/lib32/libstdc++.so.6: undefined reference to `__towlower_l at GLIBC_2.1'
/usr/lib32/libstdc++.so.6: undefined reference to `wmemchr at GLIBC_2.0'
/usr/lib32/libstdc++.so.6: undefined reference to `fputs at GLIBC_2.0'
It's incorrectly picking some host libraries, which is wrong. Bernd,
you did the bump of libcec, could you fix this?
> arm | libepoxy-v1.3.1 | NOK | http://autobuild.buildroot.net/results/3912eaa022865ce81535fbb72a206577e32b506f
> arm | libepoxy-v1.3.1 | NOK | http://autobuild.buildroot.net/results/1e09ab626e3ecdd0467842b81200d96073af66e6
> arm | libepoxy-v1.3.1 | NOK | http://autobuild.buildroot.net/results/e2408c887dde0ad9f7120d2ab3e267da84c16484
> arm | libepoxy-v1.3.1 | NOK | http://autobuild.buildroot.net/results/7f2cdfbc125292de2427d16f9ae0b5ad971a24c2
error: conflicting types for 'khronos_ssize_t'
Gustavo, could you have a look ?
> sh4a | libraw-0.17.1 | NOK | http://autobuild.buildroot.net/results/908aef6c82d56060933713df217b6b2ba21a01b0
error: 'SIZE_MAX' was not declared in this scope
Missing header include I believe.
> powerpc64 | libsvg-0.1.4 | NOK | http://autobuild.buildroot.net/results/f2d5b2459080bf9c67906b8b240150303bb61461
/usr/lib64/libexpat.so: error adding symbols: File in wrong format
collect2: error: ld returned 1 exit status
It's picking some host library, which is wrong. Carsten, you're listed
in the DEVELOPERS file for libsvg, could you have a look?
> i586 | libv4l-1.12.2 | NOK | http://autobuild.buildroot.net/results/b8b96c7bbf2147dacac62485cbfdbcfd758271a5
ir-ctl.o: In function `parse_opt':
ir-ctl.c:(.text+0xb06): undefined reference to `strndupa'
ir-ctl.o: In function `lirc_record':
ir-ctl.c:(.text+0xe01): undefined reference to `TEMP_FAILURE_RETRY'
ir-ctl.o: In function `main':
ir-ctl.c:(.text.startup+0x9a): undefined reference to `TEMP_FAILURE_RETRY'
ir-ctl.c:(.text.startup+0xd7): undefined reference to `TEMP_FAILURE_RETRY'
ir-ctl.c:(.text.startup+0x64a): undefined reference to `TEMP_FAILURE_RETRY'
Musl related, perhaps?
> i686 | lttng-libust-2.9.0 | NOK | http://autobuild.buildroot.net/results/ee1abc83bbe1e2fc2e9097e1f79fbd04f411e431
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
CMake 2.8.11 or higher is required. You are running version 2.8.2
Why is this thing trying to use CMake when it is an autotools-package ?
Philippe, could you have a look ?
> arm | lttng-libust-2.9.0 | NOK | http://autobuild.buildroot.net/results/72e9a6f39bb8e4da421926d5a73911760777e93b
Musl issue. Philippe, same thing :-)
> arm | lttng-tools-2.9.3 | NOK | http://autobuild.buildroot.net/results/11d5a5bcef8e05822136ac302371115f4fe3c4ee
prog.c:24:7: warning: implicit declaration of function 'dlmopen' [-Wimplicit-function-declaration]
h1 = dlmopen(LM_ID_BASE, "libfoo.so", RTLD_LAZY);
dlmopen() is not provided by uclibc it seems.
> arm | mesa3d-demos-8.3.0 | NOK | http://autobuild.buildroot.net/results/6f197c643972e92f0b27b3afac7da7b4b1115f7e
BR2_PACKAGE_PROVIDES_LIBGL="mesa3d"
BR2_PACKAGE_PROVIDES_LIBEGL="rpi-userland"
BR2_PACKAGE_PROVIDES_LIBGLES="rpi-userland"
This seems like a quite messy configuration: we have mesa3d as the
OpenGL provider, and rpi-userland as the OpenGLES/EGL provider. Yann,
what do you think about this?
> xtensa | mpd-0.20.4 | NOK | http://autobuild.buildroot.net/results/b3058c729e6b389aa0100d3918c0db3fd1a5dfc3
Static linking issue.
> arc | mpd-0.20.4 | NOK | http://autobuild.buildroot.net/results/3a6b236969982094ec43e2a25e51b2e396574c0f
Weird linking issue, forgets to link with pthread?
Gustavo, J?rg, could one of you look at these issues?
> xtensa | openswan-2.6.46 | NOK | http://autobuild.buildroot.net/results/b52d69c54e07edeeee86a525fac4cf00c47c2e45
> arm | openswan-2.6.46 | NOK | http://autobuild.buildroot.net/results/15af420dc866af4bf639f2ef003aacfe9ead7447
> xtensa | openswan-2.6.46 | NOK | http://autobuild.buildroot.net/results/5be7eb7606d99c7df1afdd8fa011be5de7daa7f0
Fixed by https://git.buildroot.org/buildroot/commit/?id=3a89cfc46489e0bedf27796134698878d0de9281
> arm | ortp-0.27.0 | NOK | http://autobuild.buildroot.net/results/5625f8f1d62ba87d6bd94ab8978f72992b766086
> arm | ortp-0.27.0 | NOK | http://autobuild.buildroot.net/results/ae54693a59b2d8dd8d83d224b93f1b4223e0af40
> arm | ortp-0.27.0 | NOK | http://autobuild.buildroot.net/results/d69e14b25564ff58844f5b3970fa5e7621f0f0bc
> arm | ortp-0.27.0 | NOK | http://autobuild.buildroot.net/results/584fc74d2e7fe790529051eee95c9475ed1033ac
Fixed by https://git.buildroot.org/buildroot/commit/?id=5c4d3560b94c9cb8f1594c9200a632b89ddf7aa0
> mipsel | python-flask-login-0.3.2 | NOK | http://autobuild.buildroot.net/results/2e0574cbdaa202807b206b4e0988c3ed361d4a21
Download issue, ignore.
> x86_64 | qemu-2.7.0 | NOK | http://autobuild.buildroot.net/results/17dea7dcb390b3cb9319a0e3ef55562b3c8d6e2d
/tmp/ccDTRA9B.s: Assembler messages:
/tmp/ccDTRA9B.s:112: Error: instruction `vmovd' isn't supported in 16-bit mode.
/tmp/ccDTRA9B.s:113: Error: instruction `vpinsrd' isn't supported in 16-bit mode.
> arm | qemu-2.7.0 | NOK | http://autobuild.buildroot.net/results/42172dfa49d7006426ef7c39ea916174456537b2
> arm | qemu-2.7.0 | NOK | http://autobuild.buildroot.net/results/f5be91e90e26b0bc65259ef4262b9cface1d584e
/home/test/autobuild/run/instance-3/output/build/qemu-2.7.0/user-exec.c: In function 'cpu_alpha_signal_handler':
/home/test/autobuild/run/instance-3/output/build/qemu-2.7.0/user-exec.c:410:25: error: 'mcontext_t {aka struct sigcontext}' has no member named 'gregs'
Fran?ois, you're taking care of the qemu package, can you have a look?
> nios2 | qt5base-5.6.2 | NOK | http://autobuild.buildroot.net/results/020da67e98c897e6179b0e62f38a753099637de9
> powerpc64 | qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/782f9fec5c0e4abe0e58040d26ad6cc54f5324a0
> nios2 | qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/5ebc47dcccffdf03097f72f829344a997874de61
> powerpc | qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/6a98ac82436b6b9733a9539ed433fd9c59442229
> xtensa | qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/ba5fb88f684b35b7d0bd738b98dd14f37b8b812c
> powerpc | qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/58e40dc27305282f8e0c3f91575098e40865a3d8
I suppose all of this are related to the freetype issue. Peter Seiderer
has submitted some patches to address this.
> arm | qt5webkit-5.8.0 | NOK | http://autobuild.buildroot.net/results/e5b926b680c8a1f94148cb1523e3de8380b6aed9
error: 'khronos_intptr_t' has a previous declaration as 'typedef int khronos_intptr_t'
BR2_PACKAGE_PROVIDES_LIBEGL="odroid-mali"
BR2_PACKAGE_PROVIDES_LIBGLES="odroid-mali"
issue with this specific OpenGL provider?
Dagg, you're the one who contributed odroid-mali. Could you have a look?
> sh4a | riemann-c-client-1.9.1 | NOK | http://autobuild.buildroot.net/results/da6b762c2497ee050ca6decb3db42c913c95c032
> nios2 | riemann-c-client-1.9.1 | NOK | http://autobuild.buildroot.net/results/80d83c650c668ee1e87c288bd7a0ce63eab95631
> mipsel | riemann-c-client-1.9.1 | NOK | http://autobuild.buildroot.net/results/a613830ffab74f144238ee88a1e5067d387e643f
Should be fixed by https://git.buildroot.org/buildroot/commit/?id=896455cff7ff46dd069c74be39c39aa85cb4e129.
> arm | slang-2.3.0 | NOK | http://autobuild.buildroot.net/results/5da778c67e263736cb2c42a6910ed54983f5c018
Static linking issue. Who wants to look at this? Nobody is listed in
the DEVELOPERS file for slang.
> arm | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/598882bb0d110eedf4ee85ce93987d91947c675e
> arm | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/427aff122138b016f1733b618f7f07b957282610
> mipsel | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/666b15fb903369ef7b58d123308037bd44547142
> arm | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/36bd529abc930c2ff236bcbee3ad1aba0c39e604
The ncurses issue. A patch has been posted, but we don't completely
understand what's going on. Needs investigation. Who is interested?
> arm | synergy-1.3.1 | NOK | http://autobuild.buildroot.net/results/d9ab699ba314f87a12b4982811ebfa1c3186a408
CConfig.cpp: In member function 'CConfigReadContext::operator void*() const':
CConfig.cpp:1851:9: error: cannot convert 'std::istream {aka std::basic_istream<char>}' to 'void*' in return
Modern gcc issue ?
> powerpc | tcpreplay-4.1.2 | TIM | http://autobuild.buildroot.net/results/3883530f1c8c6ec03a4c880fb32acb21464c4323
> x86_64 | tcpreplay-4.1.2 | NOK | http://autobuild.buildroot.net/results/b3c31e803ff552a196ce5717372c09d6f64c91bf
error: redefinition of 'struct ethhdr'
I believe this has been fixed by the rebuild of the toolchains I
deployed yesterday, which has the improvements done by Baruch. Baruch,
could you confirm?
> arc | vlc-2.2.4 | NOK | http://autobuild.buildroot.net/results/b7405a67745b68dcde907c1d8259851d68984694
ARC toolchain issue. Developers from Synopsys, do you know when/if this
is going to be fixed?
> microblazeel | wavpack-5.1.0 | NOK | http://autobuild.buildroot.net/results/59b176eb0fa5660a6b2a81a880a2f8559e529c4b
import_id3.c:166:17: error: unknown type name 'wchar_t'
wchar_t *wide_string = malloc ((nchars + 1) * sizeof (wchar_t));
Need wchar support it seems. J?rg, you recently bumped this package,
could you have a look?
> arm | wget-1.19 | NOK | http://autobuild.buildroot.net/results/2c77cb25099f67f87af470528bb05732ad5ac299
> x86_64 | wget-1.19 | NOK | http://autobuild.buildroot.net/results/b62ac6fd5ce36453935c309e112262467cf0e3bf
> arm | wget-1.19 | NOK | http://autobuild.buildroot.net/results/439bf0b0d446b8da64eece7805c8b1e43b90f764
> sparc | wget-1.19 | NOK | http://autobuild.buildroot.net/results/330a4b81d008b3f2f82fcc8712f3109fe72f007d
> arm | wget-1.19 | NOK | http://autobuild.buildroot.net/results/4cc37a3f2ca8e79ca6d487da51e032411e466d70
> arm | wget-1.19 | NOK | http://autobuild.buildroot.net/results/8e52ea6d0353fe8ab4196b9f959740ab7cfacb87
> nios2 | wget-1.19 | NOK | http://autobuild.buildroot.net/results/ac99fadd3cd6590567836a0cf25a2ff5ac3ea4ab
Fixed by https://git.buildroot.org/buildroot/commit/?id=c36f0d65ad63589f1b21833ef53d429c018b6f8a.
> m68k | xfsprogs-4.8.0 | NOK | http://autobuild.buildroot.net/results/d48e61785d25d33106b7dab1b5cb200cf27d4044
FATAL ERROR: could not find a valid BLKID header.
Install the Block device ID development package.
Not sure.
> arm | xfsprogs-4.8.0 | NOK | http://autobuild.buildroot.net/results/202f0e7898b049b46c29646a57c8d9718cb3eae7
> arm | xfsprogs-4.8.0 | NOK | http://autobuild.buildroot.net/results/57975f401f39b673eeec304b4738cfb41a19ece7
Fixed by https://git.buildroot.org/buildroot/commit/?id=c557a22438647890e27c77bbf76f3a9f16d6d103
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 13:27 ` [Buildroot] Analysis of build " Thomas Petazzoni
@ 2017-02-14 14:51 ` Peter Korsgaard
2017-02-14 15:10 ` Thomas Petazzoni
2017-02-14 15:44 ` Philippe Proulx
` (7 subsequent siblings)
8 siblings, 1 reply; 25+ messages in thread
From: Peter Korsgaard @ 2017-02-14 14:51 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> arm | synergy-1.3.1 | NOK | http://autobuild.buildroot.net/results/d9ab699ba314f87a12b4982811ebfa1c3186a408
> CConfig.cpp: In member function 'CConfigReadContext::operator void*() const':
> CConfig.cpp:1851:9: error: cannot convert 'std::istream {aka std::basic_istream<char>}' to 'void*' in return
> Modern gcc issue ?
Yes, I believe so (this failures are with gcc 6.x). I had a quick look
yesterday, and our synergy package is ancient. It seems to have moved to
github and changed quite a bit since then.
https://github.com/symless/synergy/
The last release in the 1.3.x series is 1.3.8. I'll take a look and see
if that has fixed this issue.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 14:51 ` Peter Korsgaard
@ 2017-02-14 15:10 ` Thomas Petazzoni
2017-02-14 19:21 ` Peter Korsgaard
0 siblings, 1 reply; 25+ messages in thread
From: Thomas Petazzoni @ 2017-02-14 15:10 UTC (permalink / raw)
To: buildroot
Hello,
On Tue, 14 Feb 2017 15:51:47 +0100, Peter Korsgaard wrote:
> Yes, I believe so (this failures are with gcc 6.x). I had a quick look
> yesterday, and our synergy package is ancient. It seems to have moved to
> github and changed quite a bit since then.
>
> https://github.com/symless/synergy/
>
> The last release in the 1.3.x series is 1.3.8. I'll take a look and see
> if that has fixed this issue.
See:
[PATCH 1/1] package/synergy: bump to version 1.8.5
on the mailing list. But that's a rather big update, with somewhat
scary things.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 13:27 ` [Buildroot] Analysis of build " Thomas Petazzoni
2017-02-14 14:51 ` Peter Korsgaard
@ 2017-02-14 15:44 ` Philippe Proulx
2017-02-14 16:39 ` Yann E. MORIN
` (6 subsequent siblings)
8 siblings, 0 replies; 25+ messages in thread
From: Philippe Proulx @ 2017-02-14 15:44 UTC (permalink / raw)
To: buildroot
On Tue, Feb 14, 2017 at 8:27 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
> Hello,
>
> J?rg, Peter, Romain, Bernd, Gustavo, Carsten, Philippe, Yann, Fran?ois,
> Dagg, Baruch and ARC/Synopsys developers, there are some questions for
> you below.
>
> Thanks!
>
[...]
> Philippe, could you have a look ?
>
> > arm | lttng-libust-2.9.0 | NOK | http://autobuild.buildroot.net/results/72e9a6f39bb8e4da421926d5a73911760777e93b
>
> Musl issue. Philippe, same thing :-)
Yes, I'll try to invest some time in BR this week.
Phil
[...]
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 13:27 ` [Buildroot] Analysis of build " Thomas Petazzoni
2017-02-14 14:51 ` Peter Korsgaard
2017-02-14 15:44 ` Philippe Proulx
@ 2017-02-14 16:39 ` Yann E. MORIN
2017-02-14 20:02 ` Thomas Petazzoni
2017-02-14 18:02 ` Baruch Siach
` (5 subsequent siblings)
8 siblings, 1 reply; 25+ messages in thread
From: Yann E. MORIN @ 2017-02-14 16:39 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2017-02-14 14:27 +0100, Thomas Petazzoni spake thusly:
> > arm | mesa3d-demos-8.3.0 | NOK | http://autobuild.buildroot.net/results/6f197c643972e92f0b27b3afac7da7b4b1115f7e
>
> BR2_PACKAGE_PROVIDES_LIBGL="mesa3d"
> BR2_PACKAGE_PROVIDES_LIBEGL="rpi-userland"
> BR2_PACKAGE_PROVIDES_LIBGLES="rpi-userland"
>
> This seems like a quite messy configuration: we have mesa3d as the
> OpenGL provider, and rpi-userland as the OpenGLES/EGL provider. Yann,
> what do you think about this?
I believe this case does not make sense. We should protect against that.
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] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 13:27 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (2 preceding siblings ...)
2017-02-14 16:39 ` Yann E. MORIN
@ 2017-02-14 18:02 ` Baruch Siach
2017-02-14 19:37 ` Peter Korsgaard
2017-02-14 22:29 ` Thomas Petazzoni
` (4 subsequent siblings)
8 siblings, 1 reply; 25+ messages in thread
From: Baruch Siach @ 2017-02-14 18:02 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Tue, Feb 14, 2017 at 02:27:25PM +0100, Thomas Petazzoni wrote:
> > x86_64 | tcpreplay-4.1.2 | NOK | http://autobuild.buildroot.net/results/b3c31e803ff552a196ce5717372c09d6f64c91bf
>
> error: redefinition of 'struct ethhdr'
>
> I believe this has been fixed by the rebuild of the toolchains I
> deployed yesterday, which has the improvements done by Baruch. Baruch,
> could you confirm?
I confirmed the tcpreplay builds successfully with the newly built 2017.02-rc1
based x86-64-musl toolchain.
Thanks,
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 15:10 ` Thomas Petazzoni
@ 2017-02-14 19:21 ` Peter Korsgaard
2017-02-14 20:03 ` Thomas Petazzoni
0 siblings, 1 reply; 25+ messages in thread
From: Peter Korsgaard @ 2017-02-14 19:21 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> Hello,
> On Tue, 14 Feb 2017 15:51:47 +0100, Peter Korsgaard wrote:
>> Yes, I believe so (this failures are with gcc 6.x). I had a quick look
>> yesterday, and our synergy package is ancient. It seems to have moved to
>> github and changed quite a bit since then.
>>
>> https://github.com/symless/synergy/
>>
>> The last release in the 1.3.x series is 1.3.8. I'll take a look and see
>> if that has fixed this issue.
> See:
> [PATCH 1/1] package/synergy: bump to version 1.8.5
> on the mailing list. But that's a rather big update, with somewhat
> scary things.
Ahh yes. I was looking for something smaller/less risky for 2017.02
though.
I see this patch is marked as rejected. Do you know why/by who?
https://patchwork.ozlabs.org/patch/703714/
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 18:02 ` Baruch Siach
@ 2017-02-14 19:37 ` Peter Korsgaard
0 siblings, 0 replies; 25+ messages in thread
From: Peter Korsgaard @ 2017-02-14 19:37 UTC (permalink / raw)
To: buildroot
>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:
> Hi Thomas,
> On Tue, Feb 14, 2017 at 02:27:25PM +0100, Thomas Petazzoni wrote:
>> > x86_64 | tcpreplay-4.1.2 | NOK |
>> http://autobuild.buildroot.net/results/b3c31e803ff552a196ce5717372c09d6f64c91bf
>>
>> error: redefinition of 'struct ethhdr'
>>
>> I believe this has been fixed by the rebuild of the toolchains I
>> deployed yesterday, which has the improvements done by Baruch. Baruch,
>> could you confirm?
> I confirmed the tcpreplay builds successfully with the newly built 2017.02-rc1
> based x86-64-musl toolchain.
Ok, great!
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 16:39 ` Yann E. MORIN
@ 2017-02-14 20:02 ` Thomas Petazzoni
2017-02-14 20:05 ` Yann E. MORIN
0 siblings, 1 reply; 25+ messages in thread
From: Thomas Petazzoni @ 2017-02-14 20:02 UTC (permalink / raw)
To: buildroot
Hello,
On Tue, 14 Feb 2017 17:39:27 +0100, Yann E. MORIN wrote:
> On 2017-02-14 14:27 +0100, Thomas Petazzoni spake thusly:
> > > arm | mesa3d-demos-8.3.0 | NOK | http://autobuild.buildroot.net/results/6f197c643972e92f0b27b3afac7da7b4b1115f7e
> >
> > BR2_PACKAGE_PROVIDES_LIBGL="mesa3d"
> > BR2_PACKAGE_PROVIDES_LIBEGL="rpi-userland"
> > BR2_PACKAGE_PROVIDES_LIBGLES="rpi-userland"
> >
> > This seems like a quite messy configuration: we have mesa3d as the
> > OpenGL provider, and rpi-userland as the OpenGLES/EGL provider. Yann,
> > what do you think about this?
>
> I believe this case does not make sense. We should protect against that.
Indeed. The question is how :-)
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 19:21 ` Peter Korsgaard
@ 2017-02-14 20:03 ` Thomas Petazzoni
2017-02-14 20:21 ` Peter Korsgaard
0 siblings, 1 reply; 25+ messages in thread
From: Thomas Petazzoni @ 2017-02-14 20:03 UTC (permalink / raw)
To: buildroot
Hello,
On Tue, 14 Feb 2017 20:21:16 +0100, Peter Korsgaard wrote:
> Ahh yes. I was looking for something smaller/less risky for 2017.02
> though.
Yes, indeed something smaller/less risky would be nice.
> I see this patch is marked as rejected. Do you know why/by who?
>
> https://patchwork.ozlabs.org/patch/703714/
I remember having a quick look at the patch, but since I didn't send a
review, I don't see why I would have marked it as Rejected. Could have
been just a mistake I guess.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 20:02 ` Thomas Petazzoni
@ 2017-02-14 20:05 ` Yann E. MORIN
0 siblings, 0 replies; 25+ messages in thread
From: Yann E. MORIN @ 2017-02-14 20:05 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2017-02-14 21:02 +0100, Thomas Petazzoni spake thusly:
> On Tue, 14 Feb 2017 17:39:27 +0100, Yann E. MORIN wrote:
>
> > On 2017-02-14 14:27 +0100, Thomas Petazzoni spake thusly:
> > > > arm | mesa3d-demos-8.3.0 | NOK | http://autobuild.buildroot.net/results/6f197c643972e92f0b27b3afac7da7b4b1115f7e
> > >
> > > BR2_PACKAGE_PROVIDES_LIBGL="mesa3d"
> > > BR2_PACKAGE_PROVIDES_LIBEGL="rpi-userland"
> > > BR2_PACKAGE_PROVIDES_LIBGLES="rpi-userland"
> > >
> > > This seems like a quite messy configuration: we have mesa3d as the
> > > OpenGL provider, and rpi-userland as the OpenGLES/EGL provider. Yann,
> > > what do you think about this?
> >
> > I believe this case does not make sense. We should protect against that.
>
> Indeed. The question is how :-)
Working on it...
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] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 20:03 ` Thomas Petazzoni
@ 2017-02-14 20:21 ` Peter Korsgaard
0 siblings, 0 replies; 25+ messages in thread
From: Peter Korsgaard @ 2017-02-14 20:21 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> Hello,
> On Tue, 14 Feb 2017 20:21:16 +0100, Peter Korsgaard wrote:
>> Ahh yes. I was looking for something smaller/less risky for 2017.02
>> though.
> Yes, indeed something smaller/less risky would be nice.
>> I see this patch is marked as rejected. Do you know why/by who?
>>
>> https://patchwork.ozlabs.org/patch/703714/
> I remember having a quick look at the patch, but since I didn't send a
> review, I don't see why I would have marked it as Rejected. Could have
> been just a mistake I guess.
Ok. I've changed it back to the "New" state again so we don't forget
about it.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 13:27 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (3 preceding siblings ...)
2017-02-14 18:02 ` Baruch Siach
@ 2017-02-14 22:29 ` Thomas Petazzoni
2017-02-15 7:38 ` Peter Korsgaard
2017-02-15 2:45 ` Sam Bobroff
` (3 subsequent siblings)
8 siblings, 1 reply; 25+ messages in thread
From: Thomas Petazzoni @ 2017-02-14 22:29 UTC (permalink / raw)
To: buildroot
Hello,
On Tue, 14 Feb 2017 14:27:25 +0100, Thomas Petazzoni wrote:
> > arm | cbootimage-v1.7 | NOK | http://autobuild.buildroot.net/results/61bdfb7e0ff9628190d9eb86e40c4c90e768b8e2
> > arm | cbootimage-v1.7 | NOK | http://autobuild.buildroot.net/results/b78c03b85aef845ff57d499b40f52b476f8a760c
>
> Musl compatibility issue.
We merged a patch to disable cbootimage on musl.
> > i586 | cups-2.2.2 | NOK | http://autobuild.buildroot.net/results/486dea944d6ecba5c4e6e8ac664261c1909f4b4c
>
> The musl/i586/SSP issue.
I'm testing to simply disable SSP support with musl on i386. Will send
a patch shortly if that works.
> > powerpc | ddrescue-1.22 | NOK | http://autobuild.buildroot.net/results/4ac0754f1cc5ea934d6437e89d1f4906fb3fd0a8
>
> Missing <stdio.h> include in block.h I believe. Peter (Seiderer), could
> you send a patch to fix this?
Peter has sent a patch, and it was merged.
> > m68k | kmsxx-bd5f6471e619a6ba2987b... | NOK | http://autobuild.buildroot.net/results/2738e5fd446467b105f6dcca391500e3734e5a9b
>
> Missing magic gcc option, Waldemar will provide a fix.
Fixed by
https://git.buildroot.org/buildroot/commit/?id=82a935ae493b8159062c9c32b328c30ee130c5a8
> > sh4a | libraw-0.17.1 | NOK | http://autobuild.buildroot.net/results/908aef6c82d56060933713df217b6b2ba21a01b0
>
> error: 'SIZE_MAX' was not declared in this scope
>
> Missing header include I believe.
This one is annoying.
So libraw optionally depends on jasper, and it's when both are enabled
that the problem occurs.
The issue is that the jas_math.h header uses SIZE_MAX and other
definitions of <stdint.h>, but those definitions are not visible to C++
code, unless you define __STDC_LIMIT_MACROS.
So one would think "just define __STDC_LIMIT_MACROS before including
<stdint.h> in jas_math.h". Expect that libraw, before including jasper
headers, includes other headers that already include <stdint.h>. So by
the time jas_math.h includes <stdint.h>, it has already been included,
and therefore, the definition of __STDC_LIMIT_MACROS in jas_math.h has
no effect.
I'm not sure how to fix this. Adding __STDC_LIMIT_MACROS to the build
of libraw would fix it, but it's rather weird to have this
implementation "detail" of jasper creep in all the way to users of the
library.
> > i586 | libv4l-1.12.2 | NOK | http://autobuild.buildroot.net/results/b8b96c7bbf2147dacac62485cbfdbcfd758271a5
>
> ir-ctl.o: In function `parse_opt':
> ir-ctl.c:(.text+0xb06): undefined reference to `strndupa'
> ir-ctl.o: In function `lirc_record':
> ir-ctl.c:(.text+0xe01): undefined reference to `TEMP_FAILURE_RETRY'
> ir-ctl.o: In function `main':
> ir-ctl.c:(.text.startup+0x9a): undefined reference to `TEMP_FAILURE_RETRY'
> ir-ctl.c:(.text.startup+0xd7): undefined reference to `TEMP_FAILURE_RETRY'
> ir-ctl.c:(.text.startup+0x64a): undefined reference to `TEMP_FAILURE_RETRY'
>
> Musl related, perhaps?
Fixed by Peter Seiderer.
> > arm | mesa3d-demos-8.3.0 | NOK | http://autobuild.buildroot.net/results/6f197c643972e92f0b27b3afac7da7b4b1115f7e
>
> BR2_PACKAGE_PROVIDES_LIBGL="mesa3d"
> BR2_PACKAGE_PROVIDES_LIBEGL="rpi-userland"
> BR2_PACKAGE_PROVIDES_LIBGLES="rpi-userland"
>
> This seems like a quite messy configuration: we have mesa3d as the
> OpenGL provider, and rpi-userland as the OpenGLES/EGL provider. Yann,
> what do you think about this?
Yann has submitted a proposal to fix this.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 13:27 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (4 preceding siblings ...)
2017-02-14 22:29 ` Thomas Petazzoni
@ 2017-02-15 2:45 ` Sam Bobroff
2017-02-15 8:37 ` Thomas Petazzoni
2017-02-15 13:22 ` Gustavo Zacarias
` (2 subsequent siblings)
8 siblings, 1 reply; 25+ messages in thread
From: Sam Bobroff @ 2017-02-15 2:45 UTC (permalink / raw)
To: buildroot
On Tue, Feb 14, 2017 at 02:27:25PM +0100, Thomas Petazzoni wrote:
> Hello,
>
> J?rg, Peter, Romain, Bernd, Gustavo, Carsten, Philippe, Yann, Fran?ois,
> Dagg, Baruch and ARC/Synopsys developers, there are some questions for
> you below.
>
> Thanks!
>
[snip]
> > powerpc64 | libsvg-0.1.4 | NOK | http://autobuild.buildroot.net/results/f2d5b2459080bf9c67906b8b240150303bb61461
>
> /usr/lib64/libexpat.so: error adding symbols: File in wrong format
> collect2: error: ld returned 1 exit status
>
> It's picking some host library, which is wrong. Carsten, you're listed
> in the DEVELOPERS file for libsvg, could you have a look?
I've had a look at this, it seems to be that pkg-config is used to
locate libxml, but when expat is used instead it just adds '-lexpat' --
which can find the host library.
Unfortunately, the change needs to be in configure.in and AUTORECONF
fails. I've experimented with creating a patch to configure that does
what I believe autoreconf should do (adds a copy of the libxml
pkg-config code adjusted for expat). Does that seem a reasonable fix?
If so, I'll post it.
Cheers,
Sam.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 22:29 ` Thomas Petazzoni
@ 2017-02-15 7:38 ` Peter Korsgaard
2017-02-15 8:33 ` Thomas Petazzoni
0 siblings, 1 reply; 25+ messages in thread
From: Peter Korsgaard @ 2017-02-15 7:38 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> > sh4a | libraw-0.17.1 | NOK |
>> > http://autobuild.buildroot.net/results/908aef6c82d56060933713df217b6b2ba21a01b0
>>
>> error: 'SIZE_MAX' was not declared in this scope
>>
>> Missing header include I believe.
> This one is annoying.
> So libraw optionally depends on jasper, and it's when both are enabled
> that the problem occurs.
> The issue is that the jas_math.h header uses SIZE_MAX and other
> definitions of <stdint.h>, but those definitions are not visible to C++
> code, unless you define __STDC_LIMIT_MACROS.
> So one would think "just define __STDC_LIMIT_MACROS before including
> <stdint.h> in jas_math.h". Expect that libraw, before including jasper
> headers, includes other headers that already include <stdint.h>. So by
> the time jas_math.h includes <stdint.h>, it has already been included,
> and therefore, the definition of __STDC_LIMIT_MACROS in jas_math.h has
> no effect.
> I'm not sure how to fix this. Adding __STDC_LIMIT_MACROS to the build
> of libraw would fix it, but it's rather weird to have this
> implementation "detail" of jasper creep in all the way to users of the
> library.
I didn't look at libraw yet, but couldn't the jasper include just be
moved to the top of the file?
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-15 7:38 ` Peter Korsgaard
@ 2017-02-15 8:33 ` Thomas Petazzoni
2017-02-15 23:14 ` Arnout Vandecappelle
0 siblings, 1 reply; 25+ messages in thread
From: Thomas Petazzoni @ 2017-02-15 8:33 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 15 Feb 2017 08:38:07 +0100, Peter Korsgaard wrote:
> > I'm not sure how to fix this. Adding __STDC_LIMIT_MACROS to the build
> > of libraw would fix it, but it's rather weird to have this
> > implementation "detail" of jasper creep in all the way to users of the
> > library.
>
> I didn't look at libraw yet, but couldn't the jasper include just be
> moved to the top of the file?
Haven't tried that. Could be an option, but it still seems weird.
However, I had a second thought about this: according to
http://autobuild.buildroot.net/?reason=libraw-0.17.1, we only have this
issue with toolchains using rather old gcc versions:
- SH4 toolchain is using 4.7
- the Buildroot i686/pentium4 toolchain is using gcc 4.5
- the older build results on Blackfin were with the Analog Devices
toolchain, gcc 4.3 based
With more recent toolchains (starting with gcc 4.8) this issue does not
occur. Is it something that has changed in the C/C++ standard
implemented starting from 4.8 ? Or is it C library version related ?
Indeed in the SH4 toolchain, the stdint.h header only provides the
SIZE_MAX and related definitions if you're *not* in C++ *or*
__STDC_LIMIT_MACROS is defined. But on my system, stdint.h doesn't have
anything like that: SIZE_MAX and related macros are unconditionally
defined.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-15 2:45 ` Sam Bobroff
@ 2017-02-15 8:37 ` Thomas Petazzoni
0 siblings, 0 replies; 25+ messages in thread
From: Thomas Petazzoni @ 2017-02-15 8:37 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 15 Feb 2017 13:45:49 +1100, Sam Bobroff wrote:
> > > powerpc64 | libsvg-0.1.4 | NOK | http://autobuild.buildroot.net/results/f2d5b2459080bf9c67906b8b240150303bb61461
> >
> > /usr/lib64/libexpat.so: error adding symbols: File in wrong format
> > collect2: error: ld returned 1 exit status
> >
> > It's picking some host library, which is wrong. Carsten, you're listed
> > in the DEVELOPERS file for libsvg, could you have a look?
>
> I've had a look at this, it seems to be that pkg-config is used to
> locate libxml, but when expat is used instead it just adds '-lexpat' --
> which can find the host library.
Just passing -lexpat to the cross compiler does not lead the
cross-compiler to look in /usr/lib64. The cross-compiler normally only
looks in its sysroot for libraries.
So there must be some -L/usr/lib64 option that tells the cross-compiler
to look into this folder.
> Unfortunately, the change needs to be in configure.in and AUTORECONF
> fails. I've experimented with creating a patch to configure that does
> what I believe autoreconf should do (adds a copy of the libxml
> pkg-config code adjusted for expat). Does that seem a reasonable fix?
> If so, I'll post it.
Posting the patch would already give us some details on the conclusions
of your analysis. Not sure we will apply it as-is though.
What are the autoreconf issues? Can they be fixed easily?
BTW, do you have a minimal defconfig to reproduce the failure?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 13:27 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (5 preceding siblings ...)
2017-02-15 2:45 ` Sam Bobroff
@ 2017-02-15 13:22 ` Gustavo Zacarias
2017-02-16 20:34 ` Bernd Kuhls
2017-02-22 11:26 ` [Buildroot] [arc-buildroot] " Vlad Zakharov
8 siblings, 0 replies; 25+ messages in thread
From: Gustavo Zacarias @ 2017-02-15 13:22 UTC (permalink / raw)
To: buildroot
On 2017-02-14 10:27, Thomas Petazzoni wrote:
>> arm | libepoxy-v1.3.1 | NOK |
>> http://autobuild.buildroot.net/results/3912eaa022865ce81535fbb72a206577e32b506f
>> arm | libepoxy-v1.3.1 | NOK |
>> http://autobuild.buildroot.net/results/1e09ab626e3ecdd0467842b81200d96073af66e6
>> arm | libepoxy-v1.3.1 | NOK |
>> http://autobuild.buildroot.net/results/e2408c887dde0ad9f7120d2ab3e267da84c16484
>> arm | libepoxy-v1.3.1 | NOK |
>> http://autobuild.buildroot.net/results/7f2cdfbc125292de2427d16f9ae0b5ad971a24c2
>
> error: conflicting types for 'khronos_ssize_t'
>
> Gustavo, could you have a look ?
Hi.
Ugh, yet another problematic GL provider (odroid-mali), it's likely
related to some versions of khronos GL being, well, problematic, since i
faced the same problem with newer versions of webkitgtk for example.
I wonder if we should go the extra mile in patching this minor
nuissances since it's unlikely to get fixed upstream for these cases.
Regards.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-15 8:33 ` Thomas Petazzoni
@ 2017-02-15 23:14 ` Arnout Vandecappelle
2017-02-16 8:36 ` Thomas Petazzoni
0 siblings, 1 reply; 25+ messages in thread
From: Arnout Vandecappelle @ 2017-02-15 23:14 UTC (permalink / raw)
To: buildroot
On 15-02-17 09:33, Thomas Petazzoni wrote:
> Hello,
>
> On Wed, 15 Feb 2017 08:38:07 +0100, Peter Korsgaard wrote:
>
>> > I'm not sure how to fix this. Adding __STDC_LIMIT_MACROS to the build
>> > of libraw would fix it, but it's rather weird to have this
>> > implementation "detail" of jasper creep in all the way to users of the
>> > library.
>>
>> I didn't look at libraw yet, but couldn't the jasper include just be
>> moved to the top of the file?
>
> Haven't tried that. Could be an option, but it still seems weird.
>
> However, I had a second thought about this: according to
> http://autobuild.buildroot.net/?reason=libraw-0.17.1, we only have this
> issue with toolchains using rather old gcc versions:
>
> - SH4 toolchain is using 4.7
> - the Buildroot i686/pentium4 toolchain is using gcc 4.5
> - the older build results on Blackfin were with the Analog Devices
> toolchain, gcc 4.3 based
>
> With more recent toolchains (starting with gcc 4.8) this issue does not
> occur. Is it something that has changed in the C/C++ standard
> implemented starting from 4.8 ? Or is it C library version related ?
>
> Indeed in the SH4 toolchain, the stdint.h header only provides the
> SIZE_MAX and related definitions if you're *not* in C++ *or*
> __STDC_LIMIT_MACROS is defined. But on my system, stdint.h doesn't have
> anything like that: SIZE_MAX and related macros are unconditionally
> defined.
Indeed, the __STDC_LIMIT_MACROS definition was removed in glibc 2.18 (commit
1ef74943ce2f114c78b215af57c2ccc72ccdb0b7). That's why it only happens with old
external glibc toolchains.
Unfortunately we don't have a version symbol for glibc. But in this case, I
think the easy way out is to just add -D__STDC_LIMIT_MACROS to LIBRAW_CFLAGS
when jasper is selected. This macro isn't used anymore in recent glibc, so it
certainly doesn't hurt to define 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: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-15 23:14 ` Arnout Vandecappelle
@ 2017-02-16 8:36 ` Thomas Petazzoni
0 siblings, 0 replies; 25+ messages in thread
From: Thomas Petazzoni @ 2017-02-16 8:36 UTC (permalink / raw)
To: buildroot
Hello,
On Thu, 16 Feb 2017 00:14:53 +0100, Arnout Vandecappelle wrote:
> Indeed, the __STDC_LIMIT_MACROS definition was removed in glibc 2.18 (commit
> 1ef74943ce2f114c78b215af57c2ccc72ccdb0b7). That's why it only happens with old
> external glibc toolchains.
>
> Unfortunately we don't have a version symbol for glibc. But in this case, I
> think the easy way out is to just add -D__STDC_LIMIT_MACROS to LIBRAW_CFLAGS
> when jasper is selected. This macro isn't used anymore in recent glibc, so it
> certainly doesn't hurt to define it.
Good idea, so I've done this:
https://git.buildroot.org/buildroot/commit/?id=d246cf5fd01bb0d20a0e64194ffed514ea8dd0aa
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 13:27 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (6 preceding siblings ...)
2017-02-15 13:22 ` Gustavo Zacarias
@ 2017-02-16 20:34 ` Bernd Kuhls
2017-02-22 11:26 ` [Buildroot] [arc-buildroot] " Vlad Zakharov
8 siblings, 0 replies; 25+ messages in thread
From: Bernd Kuhls @ 2017-02-16 20:34 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Am Tue, 14 Feb 2017 14:27:25 +0100 schrieb Thomas Petazzoni:
>> i586 | libcec-4.0.2 | NOK | http://
autobuild.buildroot.net/results/95bbcebc8768d1be026a83d9437a9b206b94df20
>
> /usr/lib32/libstdc++.so.6: undefined reference to
`__towlower_l at GLIBC_2.1'
> /usr/lib32/libstdc++.so.6: undefined reference to `wmemchr at GLIBC_2.0'
> /usr/lib32/libstdc++.so.6: undefined reference to `fputs at GLIBC_2.0'
>
> It's incorrectly picking some host libraries, which is wrong. Bernd,
> you did the bump of libcec, could you fix this?
I think I found the reason but I have no idea to fix it, sorry.
libcec-4.0.2/CMakeCache.txt contains these lines:
p8-platform_DIR:PATH=/home/bernd/buildroot/buildroot/output/host/usr/i586-
buildroot-linux-musl/sysroot/usr/lib32/p8-platform
This CMake build step
[ 97%] Linking C executable cecc-client
is done by using these commands:
/home/buildroot/buildroot/output/host/usr/bin/i586-linux-gcc --sysroot=/
home/buildroot/buildroot/output/host/usr/i586-buildroot-linux-musl/
sysroot -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -
Os -DNDEBUG CMakeFiles/cecc-client.dir/cecc-client.c.o -o cecc-
client-4.0.2 -Wl,-rpath,/usr/lib32: -rdynamic /home/bernd/buildroot/
buildroot/output/host/usr/i586-buildroot-linux-musl/sysroot/usr/lib32/
libp8-platform.so -ldl
"-Wl,-rpath,/usr/lib32" is the reason for the linking error, imho.
Now the interesting solution:
$ cd /home/buildroot/buildroot/output/host/usr/i586-buildroot-linux-musl/
sysroot/usr/
$ LC_ALL=C ls -la
total 24
drwxr-xr-x 6 buildroot buildroot 4096 Feb 16 21:27 .
drwxr-xr-x 6 buildroot buildroot 4096 Feb 16 21:24 ..
drwxr-xr-x 2 buildroot buildroot 4096 Dec 3 16:55 bin
drwxr-xr-x 20 buildroot buildroot 4096 Feb 16 21:24 include
drwxr-xr-x 4 buildroot buildroot 4096 Feb 16 21:24 lib
lrwxrwxrwx 1 buildroot buildroot 3 Dec 3 16:55 lib32 -> lib
drwxr-xr-x 2 buildroot buildroot 4096 Dec 3 16:55 sbin
$ rm lib32
Now building libcec will work, most likely because the value of p8-
platform_DIR changed:
p8-platform_DIR:PATH=/home/bernd/buildroot/buildroot/output/host/usr/i586-
buildroot-linux-musl/sysroot/usr/lib/p8-platform
Regards, Bernd
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] [arc-buildroot] Analysis of build results for 2017-02-13
2017-02-14 13:27 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (7 preceding siblings ...)
2017-02-16 20:34 ` Bernd Kuhls
@ 2017-02-22 11:26 ` Vlad Zakharov
2017-02-22 12:48 ` Thomas Petazzoni
8 siblings, 1 reply; 25+ messages in thread
From: Vlad Zakharov @ 2017-02-22 11:26 UTC (permalink / raw)
To: buildroot
Hi all,?
sorry for the delay,
On Tue, 2017-02-14 at 14:27 +0100, Thomas Petazzoni wrote:
> >????????? arc |????????????????????? vlc-2.2.4 | NOK | http://autobuild.buildroot.net/results/b74/b7405a67745b68dcde9
> 07c1d8259851d68984694/?
>
> ARC toolchain issue. Developers from Synopsys, do you know when/if this
> is going to be fixed?
We are looking at the issue. I hope it will be solved rather wool but unfortunately I am sure fix will be ready before
BR release. So I can turn off this package now and then provide fix and turn the package on again. What do you think
about it?
Thanks.
--
Best regards,
Vlad Zakharov <vzakhar@synopsys.com>
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] [arc-buildroot] Analysis of build results for 2017-02-13
2017-02-22 11:26 ` [Buildroot] [arc-buildroot] " Vlad Zakharov
@ 2017-02-22 12:48 ` Thomas Petazzoni
2017-02-22 13:01 ` Vlad Zakharov
0 siblings, 1 reply; 25+ messages in thread
From: Thomas Petazzoni @ 2017-02-22 12:48 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 22 Feb 2017 11:26:00 +0000, Vlad Zakharov wrote:
> We are looking at the issue. I hope it will be solved rather wool but unfortunately I am sure fix will be ready before
> BR release.
I guess you meant "not sure" ?
> So I can turn off this package now and then provide fix and turn the
> package on again. What do you think about it?
That's OK for me. Can you send a patch doing so?
We also recently disabled the "trousers" package on ARC, also for a
toolchain reason.
Will you remember all the packages that we disabled due to an ARC
toolchain issue? Should we mark them with a special comment, so that
you can grep for it, like:
# ARC toolchain issue
depends on !BR2_arc
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] [arc-buildroot] Analysis of build results for 2017-02-13
2017-02-22 12:48 ` Thomas Petazzoni
@ 2017-02-22 13:01 ` Vlad Zakharov
0 siblings, 0 replies; 25+ messages in thread
From: Vlad Zakharov @ 2017-02-22 13:01 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Wed, 2017-02-22 at 13:48 +0100, Thomas Petazzoni wrote:
> Hello,
>
> On Wed, 22 Feb 2017 11:26:00 +0000, Vlad Zakharov wrote:
> >
> > We are looking at the issue. I hope it will be solved rather wool but unfortunately I am sure fix will be ready
> > before
> > BR release.
>
> I guess you meant "not sure" ?
You are right, it was a typo, I'm sorry.
>
> >
> > So I can turn off this package now and then provide fix and turn the
> > package on again. What do you think about it?
>
> That's OK for me. Can you send a patch doing so?
Sure, I will send it soon.
>
> We also recently disabled the "trousers" package on ARC, also for a
> toolchain reason.
>
> Will you remember all the packages that we disabled due to an ARC
> toolchain issue? Should we mark them with a special comment, so that
> you can grep for it, like:
>
> # ARC toolchain issue
> depends on !BR2_arc
We are trying to keep the list of packages disabled due to ARC toolchain failures.?
Nevertheless it sounds like a good idea - we won't miss anything.
>
> Thomas
--
Best regards,
Vlad Zakharov <vzakhar@synopsys.com>
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2017-02-22 13:01 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-14 7:28 [Buildroot] [autobuild.buildroot.net] Build results for 2017-02-13 Thomas Petazzoni
2017-02-14 13:27 ` [Buildroot] Analysis of build " Thomas Petazzoni
2017-02-14 14:51 ` Peter Korsgaard
2017-02-14 15:10 ` Thomas Petazzoni
2017-02-14 19:21 ` Peter Korsgaard
2017-02-14 20:03 ` Thomas Petazzoni
2017-02-14 20:21 ` Peter Korsgaard
2017-02-14 15:44 ` Philippe Proulx
2017-02-14 16:39 ` Yann E. MORIN
2017-02-14 20:02 ` Thomas Petazzoni
2017-02-14 20:05 ` Yann E. MORIN
2017-02-14 18:02 ` Baruch Siach
2017-02-14 19:37 ` Peter Korsgaard
2017-02-14 22:29 ` Thomas Petazzoni
2017-02-15 7:38 ` Peter Korsgaard
2017-02-15 8:33 ` Thomas Petazzoni
2017-02-15 23:14 ` Arnout Vandecappelle
2017-02-16 8:36 ` Thomas Petazzoni
2017-02-15 2:45 ` Sam Bobroff
2017-02-15 8:37 ` Thomas Petazzoni
2017-02-15 13:22 ` Gustavo Zacarias
2017-02-16 20:34 ` Bernd Kuhls
2017-02-22 11:26 ` [Buildroot] [arc-buildroot] " Vlad Zakharov
2017-02-22 12:48 ` Thomas Petazzoni
2017-02-22 13:01 ` Vlad Zakharov
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.