* [Buildroot] [autobuild.buildroot.net] Build results for 2017-10-30
@ 2017-10-31 7:00 Thomas Petazzoni
2017-10-31 22:05 ` [Buildroot] Analysis of build " Thomas Petazzoni
0 siblings, 1 reply; 43+ messages in thread
From: Thomas Petazzoni @ 2017-10-31 7:00 UTC (permalink / raw)
To: buildroot
Hello,
Build statistics for 2017-10-30
================================
successes : 131
failures : 57
timeouts : 4
TOTAL : 192
Classification of failures by reason
====================================
argp-standalone-1.3 | 10
boost-1.65.1 | 5
dbus-python-1.2.4 | 4
ffmpeg-3.3.5 | 4
gstreamer-0.10.36 | 3
host-uboot-tools-2017.07 | 3
core-dependencies | 2
host-erlang-rebar-2.6.4 | 2
jimtcl-0.75 | 2
nmap-7.60 | 2
opencv-2.4.13.3 | 2
openssh-7.6p1 | 2
tremor-19427 | 2
usb_modeswitch-2.5.0 | 2
busybox-1.27.2 | 1
cups-2.2.5 | 1
freerdp-2.0.0-rc0 | 1
gpm-1.20.7 | 1
host-gdb-arc-2017.09-rc1-gdb | 1
host-libevent-2.1.8-stable | 1
host-mono-5.2.0.224 | 1
jose-10 | 1
libidn-1.33 | 1
lttng-tools-2.9.5 | 1
lua-sdl2-v2.0.5-6.0 | 1
mp4v2-2.0.0 | 1
openobex-1.7.2 | 1
poppler-0.59.0 | 1
qt5declarative-5.9.2 | 1
stress-ng-0.06.15 | 1
Detail of failures
===================
arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/25e4ff4b8cecd88d56bd75fcdef64ad9affed959 | ORPH
arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/204d17c639e8a38648dbc15c4abbc0c6fe23370a | ORPH
arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/2ac87b1ea118366df4c816a13fa7cd02f8b10dc0 | ORPH
arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/a818230518d1197a9916019a955437fc3611ad33 | ORPH
arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/3663fc12c6d5908ba496efdfaa1ba24ed39f0104 | ORPH
arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/af51008cdc92645adb20664aa7b3c64d9ed4691e | ORPH
arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/e033f008b4731d41ec426884b45a591dda7adaf3 | ORPH
arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/1be95e26fd18e9772e42b5e6cb1e93fbac9c1c8a | ORPH
arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/c94d79b9eaecdb36e0894ae0f965ae39cdb35386 | ORPH
arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/53359e0fe1408f3816d3091b49462320239f39c1 | ORPH
bfin | boost-1.65.1 | NOK | http://autobuild.buildroot.net/results/5874155f0d722c004971bb9ae9df995f052744c6 |
arm | boost-1.65.1 | NOK | http://autobuild.buildroot.net/results/06bfcc0ba0ea9a125e89a54235348564d1a074a3 |
m68k | boost-1.65.1 | NOK | http://autobuild.buildroot.net/results/f2a0bd030cce31a7346f05442a2d16c462713768 |
m68k | boost-1.65.1 | NOK | http://autobuild.buildroot.net/results/38d80d117f346ed630b10b6cdc951ec9a9dd1576 |
bfin | boost-1.65.1 | NOK | http://autobuild.buildroot.net/results/19ddca30994e3acf223e54b91cfda9725838d71c |
arc | busybox-1.27.2 | NOK | http://autobuild.buildroot.net/results/2cb531b9f9c75bb5dae10c02f2afeca225c65947 | ORPH
arm | core-dependencies | NOK | http://autobuild.buildroot.net/results/30d398c5764350609ef37d158c665347caf9f134 |
arm | core-dependencies | NOK | http://autobuild.buildroot.net/results/5f5b5edb058efe976c003678e21bcc28a87cc828 |
arm | cups-2.2.5 | NOK | http://autobuild.buildroot.net/results/0f1cb8d72d0a78eb8b5c46548bc7c7bade93c674 | ORPH
powerpc64 | dbus-python-1.2.4 | NOK | http://autobuild.buildroot.net/results/1588d1a2fec77522857fd22e344b1a89ad04bb44 | ORPH
arm | dbus-python-1.2.4 | NOK | http://autobuild.buildroot.net/results/a1b68de766d13628380dfaa4e4db893a6c8e8af6 | ORPH
or1k | dbus-python-1.2.4 | NOK | http://autobuild.buildroot.net/results/bf1124aed79210f16acc08e056e744a0dc17b418 | ORPH
x86_64 | dbus-python-1.2.4 | NOK | http://autobuild.buildroot.net/results/8a7203b7473b5500b456344379dfa6d6bde4d52d | ORPH
arc | ffmpeg-3.3.5 | NOK | http://autobuild.buildroot.net/results/b8fd41b127ab7702a2b69998076d737ea2e092b5 |
arc | ffmpeg-3.3.5 | NOK | http://autobuild.buildroot.net/results/43c90fbad3662101ef4eb5958f73700d1ff57b38 |
arc | ffmpeg-3.3.5 | NOK | http://autobuild.buildroot.net/results/a152a190108986392346efbba001b9dd0bdc89bc |
arc | ffmpeg-3.3.5 | NOK | http://autobuild.buildroot.net/results/60d44246fe6a54b02b53564761807204b9a190d0 |
xtensa | freerdp-2.0.0-rc0 | NOK | http://autobuild.buildroot.net/results/81aa66ddd88919295ccb5f34b527b737627263a7 |
arc | gpm-1.20.7 | NOK | http://autobuild.buildroot.net/results/5a1404cf52c9547533a5b04c40d6118b43a07707 |
xtensa | gstreamer-0.10.36 | NOK | http://autobuild.buildroot.net/results/bb0a52f08ce07b3aa7301e69e9be12f3e45f45b2 | ORPH
arm | gstreamer-0.10.36 | NOK | http://autobuild.buildroot.net/results/0b6feb96ba877cb4f3b8c6a05c977a1c12805fac | ORPH
arm | gstreamer-0.10.36 | NOK | http://autobuild.buildroot.net/results/daa93d58840c77c980d040e2b740555dc3b36951 | ORPH
arm | host-erlang-rebar-2.6.4 | TIM | http://autobuild.buildroot.net/results/6c4c7b3094bd48a72786f5be3d760f0356557403 |
arm | host-erlang-rebar-2.6.4 | TIM | http://autobuild.buildroot.net/results/a17d5eb1aac01dab19412aa28d523625577730db |
arc | host-gdb-arc-2017.09-rc1-gdb | NOK | http://autobuild.buildroot.net/results/43eae264991aa369490236c7bd59c0b6a67fcf25 | ORPH
xtensa | host-libevent-2.1.8-stable | NOK | http://autobuild.buildroot.net/results/dfb5009ff4289086ff6ecf008d623cad92e7d1fe | ORPH
arm | host-mono-5.2.0.224 | NOK | http://autobuild.buildroot.net/results/51dcf8908157393a09ce772e6099e73fd0cd0ba2 |
arc | host-uboot-tools-2017.07 | NOK | http://autobuild.buildroot.net/results/9567703c95823be10400c0a330c3997a4cd6a62c | ORPH
arm | host-uboot-tools-2017.07 | NOK | http://autobuild.buildroot.net/results/e3ee47e30a01e68a80fcbef3178f8eb051fe509f | ORPH
sh4 | host-uboot-tools-2017.07 | NOK | http://autobuild.buildroot.net/results/7d60ebf31fd9df7a5fef7e7723859c32d7972f5b | ORPH
xtensa | jimtcl-0.75 | NOK | http://autobuild.buildroot.net/results/fb939428388a53dce3a141147e6bdca15cd9c9ea |
microblazeel | jimtcl-0.75 | NOK | http://autobuild.buildroot.net/results/d5328314675e47534658884a9b249cefcf237c40 |
powerpc | jose-10 | NOK | http://autobuild.buildroot.net/results/e5badaca8f078b84d3a2135634a96729a20f2a9b |
arc | libidn-1.33 | NOK | http://autobuild.buildroot.net/results/d3c3abf9966dd023923235c3879f521ba3a2daa5 | ORPH
arm | lttng-tools-2.9.5 | NOK | http://autobuild.buildroot.net/results/16791e9548715d06efe37cf99fb07e4e27d98383 |
microblazeel | lua-sdl2-v2.0.5-6.0 | NOK | http://autobuild.buildroot.net/results/46f93012342549c44e100522eea0852586311ef4 |
arm | mp4v2-2.0.0 | NOK | http://autobuild.buildroot.net/results/8be30492abe3345dc9411fe3e5636c4f8e4311ce |
xtensa | nmap-7.60 | NOK | http://autobuild.buildroot.net/results/9e636919c98cd31b5067c8306d0e481a672434cf | ORPH
mips64el | nmap-7.60 | NOK | http://autobuild.buildroot.net/results/912561f505ad10d1eaa96dbe247d5838e9968e14 | ORPH
mips64el | opencv-2.4.13.3 | NOK | http://autobuild.buildroot.net/results/b27d324331f6e351e95dd4742f4d0a50af60c590 |
mips64el | opencv-2.4.13.3 | NOK | http://autobuild.buildroot.net/results/44ed0be0bd94028b7b37e7bf21233adc1753d94b |
bfin | openobex-1.7.2 | NOK | http://autobuild.buildroot.net/results/78e033fe9f43845581a5d87b21a8451f67520e44 |
arm | openssh-7.6p1 | NOK | http://autobuild.buildroot.net/results/3dcd2ab22b75bf27afd963d57e31df5e0bdedcaa | ORPH
arm | openssh-7.6p1 | NOK | http://autobuild.buildroot.net/results/8cc30818a400c7a392a3de787cabc9cd8425495f | ORPH
m68k | poppler-0.59.0 | NOK | http://autobuild.buildroot.net/results/c35599e6bf09aebe456ea959d7c238f82090fc62 |
x86_64 | qt5declarative-5.9.2 | NOK | http://autobuild.buildroot.net/results/d9707cc2f47c6906b7e4872e185b7866301c3322 |
arc | stress-ng-0.06.15 | NOK | http://autobuild.buildroot.net/results/296b14584c200593f88af75cdda65c4ca03cd863 |
m68k | tremor-19427 | TIM | http://autobuild.buildroot.net/results/5bff9fbd24264b3515a669d585e10ef23127d569 |
mipsel | tremor-19427 | TIM | http://autobuild.buildroot.net/results/d1c8e74477797b597c38186343e4d6c69b05560d |
microblazeel | usb_modeswitch-2.5.0 | NOK | http://autobuild.buildroot.net/results/20a9a75f701ce70c2ae434085a85ad8d34adc67b | ORPH
arm | usb_modeswitch-2.5.0 | NOK | http://autobuild.buildroot.net/results/46844b028989808aa7340c14af22f2855ec803d8 | ORPH
--
http://autobuild.buildroot.net
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-10-31 7:00 [Buildroot] [autobuild.buildroot.net] Build results for 2017-10-30 Thomas Petazzoni
@ 2017-10-31 22:05 ` Thomas Petazzoni
2017-11-01 2:37 ` Matthew Weber
` (7 more replies)
0 siblings, 8 replies; 43+ messages in thread
From: Thomas Petazzoni @ 2017-10-31 22:05 UTC (permalink / raw)
To: buildroot
Hello,
Since Peter is about to release -rc1, it's time to restart with
analyzing the build failures we have. And we have *lots* of them!
Alexey, Yann, Adam, Peter (both Korsgaard and Seiderer?, Olivier,
Matthew, Johan, Angelo, J?rg, Samuel, Waldemar, Bernd and Baruch: there
are some questions/issues/topics for you below. Please read on! Thanks
for your support!
On Tue, 31 Oct 2017 08:00:13 +0100 (CET), Thomas Petazzoni wrote:
> arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/25e4ff4b8cecd88d56bd75fcdef64ad9affed959 | ORPH
> arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/204d17c639e8a38648dbc15c4abbc0c6fe23370a | ORPH
> arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/2ac87b1ea118366df4c816a13fa7cd02f8b10dc0 | ORPH
> arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/a818230518d1197a9916019a955437fc3611ad33 | ORPH
> arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/3663fc12c6d5908ba496efdfaa1ba24ed39f0104 | ORPH
> arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/af51008cdc92645adb20664aa7b3c64d9ed4691e | ORPH
> arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/e033f008b4731d41ec426884b45a591dda7adaf3 | ORPH
> arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/1be95e26fd18e9772e42b5e6cb1e93fbac9c1c8a | ORPH
> arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/c94d79b9eaecdb36e0894ae0f965ae39cdb35386 | ORPH
> arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/53359e0fe1408f3816d3091b49462320239f39c1 | ORPH
This is happening only on ARC. Why? Matt Weber proposed a patch,
https://patchwork.ozlabs.org/patch/832397/, but I am not terribly
convinced because it doesn't explain why this problem happens only on
ARC, and why it appeared suddenly.
Alexey, could you have a look ?
> bfin | boost-1.65.1 | NOK | http://autobuild.buildroot.net/results/5874155f0d722c004971bb9ae9df995f052744c6 |
> arm | boost-1.65.1 | NOK | http://autobuild.buildroot.net/results/06bfcc0ba0ea9a125e89a54235348564d1a074a3 |
> m68k | boost-1.65.1 | NOK | http://autobuild.buildroot.net/results/f2a0bd030cce31a7346f05442a2d16c462713768 |
> m68k | boost-1.65.1 | NOK | http://autobuild.buildroot.net/results/38d80d117f346ed630b10b6cdc951ec9a9dd1576 |
> bfin | boost-1.65.1 | NOK | http://autobuild.buildroot.net/results/19ddca30994e3acf223e54b91cfda9725838d71c |
All five issues are the same:
libs/fiber/src/numa/linux/pin_thread.cpp:31:39: error: '::pthread_setaffinity_np' has not been declared
if ( BOOST_UNLIKELY( 0 != ( err = ::pthread_setaffinity_np( ::pthread_self(), sizeof( set), & set) ) ) ) {
This is weird, because:
config BR2_PACKAGE_BOOST_FIBER
bool "boost-fiber"
depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL
So the fiber library shouldn't be built on toolchains that don't have
NPTL support.
Adam, since you bumped Boost, could you investigate this?
> arc | busybox-1.27.2 | NOK | http://autobuild.buildroot.net/results/2cb531b9f9c75bb5dae10c02f2afeca225c65947 | ORPH
CC console-tools/setlogcons.o
libbb/appletlib.c:206:8: error: 'NUM_APPLETS' undeclared (first use in this function); did you mean 'PF_APPLETALK'?
max = NUM_APPLETS;
What is going on here?!?
> arm | core-dependencies | NOK | http://autobuild.buildroot.net/results/30d398c5764350609ef37d158c665347caf9f134 |
> arm | core-dependencies | NOK | http://autobuild.buildroot.net/results/5f5b5edb058efe976c003678e21bcc28a87cc828 |
Your Buildroot configuration needs a compiler capable of building 32 bits binaries.
If you're running a Debian/Ubuntu distribution, install the gcc-multilib package.
For other distributions, refer to their documentation.
Peter, gcc112 is your autobuilder, and it's a ppc64 machine, which
probably explains the issue.
> arm | cups-2.2.5 | NOK | http://autobuild.buildroot.net/results/0f1cb8d72d0a78eb8b5c46548bc7c7bade93c674 | ORPH
ippserver.o: In function `ipp_print_job':
/accts/mlweber1/rclinux/target_build/instance-3/output/build/cups-2.2.5/test/ippserver.c:3881: undefined reference to `_cupsThreadDetach'
ippserver.o: In function `run_printer':
/accts/mlweber1/rclinux/target_build/instance-3/output/build/cups-2.2.5/test/ippserver.c:6812: undefined reference to `_cupsThreadDetach'
/accts/mlweber1/rclinux/target_build/instance-3/output/build/cups-2.2.5/test/ippserver.c:6830: undefined reference to `_cupsThreadDetach'
This happens with a toolchain that doesn't have thread support. So
either we make cups depend on the availability of thread support, or we
fix the problem in cups. Perhaps making cups depend on thread support
is the easiest option.
Olivier, could you have a look into this? Also, I realized you are not
listed in the DEVELOPERS file for the cups package, would you be OK to
add yourself there?
> powerpc64 | dbus-python-1.2.4 | NOK | http://autobuild.buildroot.net/results/1588d1a2fec77522857fd22e344b1a89ad04bb44 | ORPH
> arm | dbus-python-1.2.4 | NOK | http://autobuild.buildroot.net/results/a1b68de766d13628380dfaa4e4db893a6c8e8af6 | ORPH
> or1k | dbus-python-1.2.4 | NOK | http://autobuild.buildroot.net/results/bf1124aed79210f16acc08e056e744a0dc17b418 | ORPH
> x86_64 | dbus-python-1.2.4 | NOK | http://autobuild.buildroot.net/results/8a7203b7473b5500b456344379dfa6d6bde4d52d | ORPH
configure: PYTHON_INCLUDES overridden to: -I/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/host/powerpc64-buildroot-linux-gnu/sysroot/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/host/powerpc64-buildroot-linux-gnu/sysroot/usr/include/python3.6m -I/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/host/powerpc64-buildroot-linux-gnu/sysroot/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/host/powerpc64-buildroot-linux-gnu/sysroot/usr/include/python3.6m
checking whether those headers are sufficient... no
configure: error: could not find Python headers
Feels like the "building in /usr" issue, it would be fixed by
https://patchwork.ozlabs.org/patch/827751/.
> arc | ffmpeg-3.3.5 | NOK | http://autobuild.buildroot.net/results/b8fd41b127ab7702a2b69998076d737ea2e092b5 |
> arc | ffmpeg-3.3.5 | NOK | http://autobuild.buildroot.net/results/43c90fbad3662101ef4eb5958f73700d1ff57b38 |
> arc | ffmpeg-3.3.5 | NOK | http://autobuild.buildroot.net/results/a152a190108986392346efbba001b9dd0bdc89bc |
> arc | ffmpeg-3.3.5 | NOK | http://autobuild.buildroot.net/results/60d44246fe6a54b02b53564761807204b9a190d0 |
libavcodec/vp9dsp_template.c:1685:1: internal compiler error: Segmentation fault
Alexey, could you have a look ?
> xtensa | freerdp-2.0.0-rc0 | NOK | http://autobuild.buildroot.net/results/81aa66ddd88919295ccb5f34b527b737627263a7 |
CMake Error at channels/tsmf/client/gstreamer/CMakeLists.txt:21 (message):
GStreamer library not found, but required for TSMF module.
Adam, you recently bumped freerdp, could you please have a look?
> arc | gpm-1.20.7 | NOK | http://autobuild.buildroot.net/results/5a1404cf52c9547533a5b04c40d6118b43a07707 |
gpm-root.c:(.text.startup+0x1aa): undefined reference to `__sigemptyset'
gpm-root.c:(.text.startup+0x1aa): undefined reference to `__sigemptyset'
This is with the new glibc ARC toolchain. Alexey ? :-)
> xtensa | gstreamer-0.10.36 | NOK | http://autobuild.buildroot.net/results/bb0a52f08ce07b3aa7301e69e9be12f3e45f45b2 | ORPH
> arm | gstreamer-0.10.36 | NOK | http://autobuild.buildroot.net/results/0b6feb96ba877cb4f3b8c6a05c977a1c12805fac | ORPH
> arm | gstreamer-0.10.36 | NOK | http://autobuild.buildroot.net/results/daa93d58840c77c980d040e2b740555dc3b36951 | ORPH
/home/buildroot/autobuild/run/instance-3/output/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libgobject-2.0.a(libgobject_2_0_la-gmarshal.o): In function `g_cclosure_marshal_VOID__VOID':
gmarshal.c:(.text+0x0): multiple definition of `g_cclosure_marshal_VOID__VOID'
../gst/.libs/libgstreamer-0.10.a(libgstreamer_0.10_la-gstmarshal.o):/home/buildroot/autobuild/run/instance-3/output/build/gstreamer-0.10.36/gst/gstmarshal.c:60: first defined here
Static linking issue. Who volunteers to have a look? We don't even have
a person listed in the DEVELOPERS file for gstreamer.
> arm | host-erlang-rebar-2.6.4 | TIM | http://autobuild.buildroot.net/results/6c4c7b3094bd48a72786f5be3d760f0356557403 |
> arm | host-erlang-rebar-2.6.4 | TIM | http://autobuild.buildroot.net/results/a17d5eb1aac01dab19412aa28d523625577730db |
The infamous ./bootstrap issue that consumes 100% of the CPU before
timing out the build job. Johan, we really need to find a solution to
this problem. How can we proceed to debug this?
> arc | host-gdb-arc-2017.09-rc1-gdb | NOK | http://autobuild.buildroot.net/results/43eae264991aa369490236c7bd59c0b6a67fcf25 | ORPH
checking whether /usr/bin/g++ supports C++11 features with -h std=c++11... no
configure: error: *** A compiler with support for C++11 language features is required.
make[2]: *** [configure-gdb] Error 1
The ARC special version needs:
depends on BR2_HOST_GCC_AT_LEAST_4_8
depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8
Just like the gdb 8.0 version.
Yann, perhaps you could have a look at this ?
> xtensa | host-libevent-2.1.8-stable | NOK | http://autobuild.buildroot.net/results/dfb5009ff4289086ff6ecf008d623cad92e7d1fe | ORPH
/usr/include/openssl/kssl.h:150:5: error: unknown type name 'krb5_octet'
krb5_octet FAR *key;
I think we need to pass --disable-openssl when building host-libevent.
Who volunteers to have a look?
> arm | host-mono-5.2.0.224 | NOK | http://autobuild.buildroot.net/results/51dcf8908157393a09ce772e6099e73fd0cd0ba2 |
Unhandled Exception:
System.ExecutionEngineException: System.NullReferenceException: Object reference not set to an instance of an object ---> System.NullReferenceException: Object reference not set to an instance of an object
Angelo, could you have a look ?
> arc | host-uboot-tools-2017.07 | NOK | http://autobuild.buildroot.net/results/9567703c95823be10400c0a330c3997a4cd6a62c | ORPH
> arm | host-uboot-tools-2017.07 | NOK | http://autobuild.buildroot.net/results/e3ee47e30a01e68a80fcbef3178f8eb051fe509f | ORPH
> sh4 | host-uboot-tools-2017.07 | NOK | http://autobuild.buildroot.net/results/7d60ebf31fd9df7a5fef7e7723859c32d7972f5b | ORPH
The libfdt/python issue. Matt Weber has proposed a patch to fix it:
https://patchwork.ozlabs.org/patch/827287/, however I have some
questions/concerns about it.
> xtensa | jimtcl-0.75 | NOK | http://autobuild.buildroot.net/results/fb939428388a53dce3a141147e6bdca15cd9c9ea |
> microblazeel | jimtcl-0.75 | NOK | http://autobuild.buildroot.net/results/d5328314675e47534658884a9b249cefcf237c40 |
Error: /home/peko/autobuild/instance-2/output/build/jimtcl-0.75/autosetup/config.guess: unable to guess system type
Peter: another ppc64 as host system issue I believe. Could you have a look ?
> powerpc | jose-10 | NOK | http://autobuild.buildroot.net/results/e5badaca8f078b84d3a2135634a96729a20f2a9b |
hsh.c: In function 'hsh':
hsh.c:28:21: error: declaration of 'hsh' shadows a global declaration [-Werror=shadow]
hsh.c:26:1: error: shadowed declaration is here [-Werror=shadow]
Should be fairly easy to fix. Peter, jose is a package you have added.
Could you have a look?
> arc | libidn-1.33 | NOK | http://autobuild.buildroot.net/results/d3c3abf9966dd023923235c3879f521ba3a2daa5 | ORPH
strerror.c: In function 'rpl_strerror':
strerror.c:44:21: warning: implicit declaration of function 'strerror_override'; did you mean 'strerror_r'? [-Wimplicit-function-declaration]
const char *msg = strerror_override (n);
^~~~~~~~~~~~~~~~~
This so far only happened on ARC, with uClibc. Alexey ?
> arm | lttng-tools-2.9.5 | NOK | http://autobuild.buildroot.net/results/16791e9548715d06efe37cf99fb07e4e27d98383 |
Yet again:
prog.c:24:7: warning: implicit declaration of function 'dlmopen' [-Wimplicit-function-declaration]
h1 = dlmopen(LM_ID_BASE, "libfoo.so", RTLD_LAZY);
I'll try to have a look tomorrow.
> microblazeel | lua-sdl2-v2.0.5-6.0 | NOK | http://autobuild.buildroot.net/results/46f93012342549c44e100522eea0852586311ef4 |
I have a fix for this one, it's easy. I'll send it shortly.
> arm | mp4v2-2.0.0 | NOK | http://autobuild.buildroot.net/results/8be30492abe3345dc9411fe3e5636c4f8e4311ce |
src/rtphint.cpp:342:35: error: ISO C++ forbids comparison between pointer and integer [-fpermissive]
if (pSlash != '\0') {
Would be fixed by
http://pkgs.fedoraproject.org/cgit/rpms/libmp4v2.git/tree/0004-Fix-GCC7-build.patch.
J?rg, mp4v2 is your package, could you have a look? :-)
> xtensa | nmap-7.60 | NOK | http://autobuild.buildroot.net/results/9e636919c98cd31b5067c8306d0e481a672434cf | ORPH
> mips64el | nmap-7.60 | NOK | http://autobuild.buildroot.net/results/912561f505ad10d1eaa96dbe247d5838e9968e14 | ORPH
xtensa-linux-g++.br_real: error: libssh2/lib/libssh2.a: No such file or directory
Who volunteers to have a look?
> mips64el | opencv-2.4.13.3 | NOK | http://autobuild.buildroot.net/results/b27d324331f6e351e95dd4742f4d0a50af60c590 |
> mips64el | opencv-2.4.13.3 | NOK | http://autobuild.buildroot.net/results/44ed0be0bd94028b7b37e7bf21233adc1753d94b |
CMake Error at cmake/OpenCVCompilerOptions.cmake:21 (else):
A duplicate ELSE command was found inside an IF block.
Call Stack (most recent call first):
CMakeLists.txt:437 (include)
Should be easy to fix. Samuel, do you think you will find some time to
have a look at this?
> bfin | openobex-1.7.2 | NOK | http://autobuild.buildroot.net/results/78e033fe9f43845581a5d87b21a8451f67520e44 |
/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/build/openobex-1.7.2/lib/obex_transport_sock.c:(.text+0x5f6): undefined reference to `accept4'
Not sure what's going on. accept4() not wired in Linux or uClibc for
Blackfin? Something else? Waldemar, could you have a look?
> arm | openssh-7.6p1 | NOK | http://autobuild.buildroot.net/results/3dcd2ab22b75bf27afd963d57e31df5e0bdedcaa | ORPH
> arm | openssh-7.6p1 | NOK | http://autobuild.buildroot.net/results/8cc30818a400c7a392a3de787cabc9cd8425495f | ORPH
getpagesize.c:(.text+0x0): multiple definition of `getpagesize'
openbsd-compat//libopenbsd-compat.a(bsd-getpagesize.o):bsd-getpagesize.c:(.text+0x0): first defined here
Would be fixed by http://patchwork.ozlabs.org/patch/832199/.
> m68k | poppler-0.59.0 | NOK | http://autobuild.buildroot.net/results/c35599e6bf09aebe456ea959d7c238f82090fc62 |
/usr/lfs/v0/rc-buildroot-test/scripts/instance-0/output/host/opt/ext-toolchain/m68k-buildroot-uclinux-uclibc/bin/ld.real: cannot find -lopenjp2
Bernd, you recently bumped openjpeg. Could you have a look ?
> x86_64 | qt5declarative-5.9.2 | NOK | http://autobuild.buildroot.net/results/d9707cc2f47c6906b7e4872e185b7866301c3322 |
logo.h:52:11: error: 'GLfloat' does not name a type
const GLfloat *constData() const { return m_data.constData(); }
Not sure what's going on. I don't see which package is the OpenGL
provider. Peter (Seiderer), do you have an idea ?
> arc | stress-ng-0.06.15 | NOK | http://autobuild.buildroot.net/results/296b14584c200593f88af75cdda65c4ca03cd863 |
stress-fp-error.c: In function 'stress_fp_error':
stress-fp-error.c:100:10: error: 'FE_INVALID' undeclared (first use in this function); did you mean 'EINVAL'?
EDOM, FE_INVALID);
^~~~~~~~~~
We already exclude nios2, we should probably exclude ARC as well.
Alexey, do you confirm?
See:
# fenv.h lacks FE_INVALID, FE_OVERFLOW & FE_UNDERFLOW on nios2
depends on !BR2_nios2
> m68k | tremor-19427 | TIM | http://autobuild.buildroot.net/results/5bff9fbd24264b3515a669d585e10ef23127d569 |
> mipsel | tremor-19427 | TIM | http://autobuild.buildroot.net/results/d1c8e74477797b597c38186343e4d6c69b05560d |
SVN repo is dead, and it locks up the build until we time out? Doesn't
look great. Yann? :-)
> microblazeel | usb_modeswitch-2.5.0 | NOK | http://autobuild.buildroot.net/results/20a9a75f701ce70c2ae434085a85ad8d34adc67b | ORPH
> arm | usb_modeswitch-2.5.0 | NOK | http://autobuild.buildroot.net/results/46844b028989808aa7340c14af22f2855ec803d8 | ORPH
>
Not sure. Is it just:
make[2]: *** [jim/libjim.a] Error 1
make[2]: *** Waiting for unfinished jobs....
usb_modeswitch.c: In function 'checkSuccess':
usb_modeswitch.c:1579:7: warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (i == CheckSuccess-1) {
That makes the build fail?
Baruch, you are the last person who bumped this package, could you have a look?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-10-31 22:05 ` [Buildroot] Analysis of build " Thomas Petazzoni
@ 2017-11-01 2:37 ` Matthew Weber
2017-11-01 9:45 ` Thomas Petazzoni
2017-11-01 10:17 ` Samuel Martin
` (6 subsequent siblings)
7 siblings, 1 reply; 43+ messages in thread
From: Matthew Weber @ 2017-11-01 2:37 UTC (permalink / raw)
To: buildroot
Thomas, Alexey,
On Tue, Oct 31, 2017 at 5:05 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> Since Peter is about to release -rc1, it's time to restart with
> analyzing the build failures we have. And we have *lots* of them!
>
> Alexey, Yann, Adam, Peter (both Korsgaard and Seiderer?, Olivier,
> Matthew, Johan, Angelo, J?rg, Samuel, Waldemar, Bernd and Baruch: there
> are some questions/issues/topics for you below. Please read on! Thanks
> for your support!
>
> On Tue, 31 Oct 2017 08:00:13 +0100 (CET), Thomas Petazzoni wrote:
>
>> arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/25e4ff4b8cecd88d56bd75fcdef64ad9affed959 | ORPH
>> arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/204d17c639e8a38648dbc15c4abbc0c6fe23370a | ORPH
>> arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/2ac87b1ea118366df4c816a13fa7cd02f8b10dc0 | ORPH
>> arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/a818230518d1197a9916019a955437fc3611ad33 | ORPH
>> arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/3663fc12c6d5908ba496efdfaa1ba24ed39f0104 | ORPH
>> arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/af51008cdc92645adb20664aa7b3c64d9ed4691e | ORPH
>> arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/e033f008b4731d41ec426884b45a591dda7adaf3 | ORPH
>> arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/1be95e26fd18e9772e42b5e6cb1e93fbac9c1c8a | ORPH
>> arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/c94d79b9eaecdb36e0894ae0f965ae39cdb35386 | ORPH
>> arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/53359e0fe1408f3816d3091b49462320239f39c1 | ORPH
>
> This is happening only on ARC. Why? Matt Weber proposed a patch,
> https://patchwork.ozlabs.org/patch/832397/, but I am not terribly
> convinced because it doesn't explain why this problem happens only on
> ARC, and why it appeared suddenly.
I kicked off a test build reverting the following commit. We'll see
in the morning if it changed the behavior or the pass/fail. (ie bump
from GCC 6.x to 7.x)
5bd21f991f3 Evgeniy Didin 2017-09-21 21:28:28
One interesting thing to notes is the test-pkg is using a external ARC
GCC6 uclibc toolchain and the failing builds are all internal
toolchain and GCC 7.
>
> Alexey, could you have a look ?
>
>> bfin | boost-1.65.1 | NOK | http://autobuild.buildroot.net/results/5874155f0d722c004971bb9ae9df995f052744c6 |
>> arm | boost-1.65.1 | NOK | http://autobuild.buildroot.net/results/06bfcc0ba0ea9a125e89a54235348564d1a074a3 |
>> m68k | boost-1.65.1 | NOK | http://autobuild.buildroot.net/results/f2a0bd030cce31a7346f05442a2d16c462713768 |
>> m68k | boost-1.65.1 | NOK | http://autobuild.buildroot.net/results/38d80d117f346ed630b10b6cdc951ec9a9dd1576 |
>> bfin | boost-1.65.1 | NOK | http://autobuild.buildroot.net/results/19ddca30994e3acf223e54b91cfda9725838d71c |
>
> All five issues are the same:
>
> libs/fiber/src/numa/linux/pin_thread.cpp:31:39: error: '::pthread_setaffinity_np' has not been declared
> if ( BOOST_UNLIKELY( 0 != ( err = ::pthread_setaffinity_np( ::pthread_self(), sizeof( set), & set) ) ) ) {
>
> This is weird, because:
>
> config BR2_PACKAGE_BOOST_FIBER
> bool "boost-fiber"
> depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL
>
> So the fiber library shouldn't be built on toolchains that don't have
> NPTL support.
>
> Adam, since you bumped Boost, could you investigate this?
>
>> arc | busybox-1.27.2 | NOK | http://autobuild.buildroot.net/results/2cb531b9f9c75bb5dae10c02f2afeca225c65947 | ORPH
>
>
> CC console-tools/setlogcons.o
> libbb/appletlib.c:206:8: error: 'NUM_APPLETS' undeclared (first use in this function); did you mean 'PF_APPLETALK'?
> max = NUM_APPLETS;
>
> What is going on here?!?
>
>> arm | core-dependencies | NOK | http://autobuild.buildroot.net/results/30d398c5764350609ef37d158c665347caf9f134 |
>> arm | core-dependencies | NOK | http://autobuild.buildroot.net/results/5f5b5edb058efe976c003678e21bcc28a87cc828 |
>
> Your Buildroot configuration needs a compiler capable of building 32 bits binaries.
> If you're running a Debian/Ubuntu distribution, install the gcc-multilib package.
> For other distributions, refer to their documentation.
>
> Peter, gcc112 is your autobuilder, and it's a ppc64 machine, which
> probably explains the issue.
>
>> arm | cups-2.2.5 | NOK | http://autobuild.buildroot.net/results/0f1cb8d72d0a78eb8b5c46548bc7c7bade93c674 | ORPH
>
>
> ippserver.o: In function `ipp_print_job':
> /accts/mlweber1/rclinux/target_build/instance-3/output/build/cups-2.2.5/test/ippserver.c:3881: undefined reference to `_cupsThreadDetach'
> ippserver.o: In function `run_printer':
> /accts/mlweber1/rclinux/target_build/instance-3/output/build/cups-2.2.5/test/ippserver.c:6812: undefined reference to `_cupsThreadDetach'
> /accts/mlweber1/rclinux/target_build/instance-3/output/build/cups-2.2.5/test/ippserver.c:6830: undefined reference to `_cupsThreadDetach'
>
> This happens with a toolchain that doesn't have thread support. So
> either we make cups depend on the availability of thread support, or we
> fix the problem in cups. Perhaps making cups depend on thread support
> is the easiest option.
>
> Olivier, could you have a look into this? Also, I realized you are not
> listed in the DEVELOPERS file for the cups package, would you be OK to
> add yourself there?
>
>> powerpc64 | dbus-python-1.2.4 | NOK | http://autobuild.buildroot.net/results/1588d1a2fec77522857fd22e344b1a89ad04bb44 | ORPH
>> arm | dbus-python-1.2.4 | NOK | http://autobuild.buildroot.net/results/a1b68de766d13628380dfaa4e4db893a6c8e8af6 | ORPH
>> or1k | dbus-python-1.2.4 | NOK | http://autobuild.buildroot.net/results/bf1124aed79210f16acc08e056e744a0dc17b418 | ORPH
>> x86_64 | dbus-python-1.2.4 | NOK | http://autobuild.buildroot.net/results/8a7203b7473b5500b456344379dfa6d6bde4d52d | ORPH
>
> configure: PYTHON_INCLUDES overridden to: -I/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/host/powerpc64-buildroot-linux-gnu/sysroot/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/host/powerpc64-buildroot-linux-gnu/sysroot/usr/include/python3.6m -I/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/host/powerpc64-buildroot-linux-gnu/sysroot/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/host/powerpc64-buildroot-linux-gnu/sysroot/usr/include/python3.6m
> checking whether those headers are sufficient... no
> configure: error: could not find Python headers
>
> Feels like the "building in /usr" issue, it would be fixed by
> https://patchwork.ozlabs.org/patch/827751/.
>
>> arc | ffmpeg-3.3.5 | NOK | http://autobuild.buildroot.net/results/b8fd41b127ab7702a2b69998076d737ea2e092b5 |
>> arc | ffmpeg-3.3.5 | NOK | http://autobuild.buildroot.net/results/43c90fbad3662101ef4eb5958f73700d1ff57b38 |
>> arc | ffmpeg-3.3.5 | NOK | http://autobuild.buildroot.net/results/a152a190108986392346efbba001b9dd0bdc89bc |
>> arc | ffmpeg-3.3.5 | NOK | http://autobuild.buildroot.net/results/60d44246fe6a54b02b53564761807204b9a190d0 |
>
> libavcodec/vp9dsp_template.c:1685:1: internal compiler error: Segmentation fault
>
> Alexey, could you have a look ?
>
>> xtensa | freerdp-2.0.0-rc0 | NOK | http://autobuild.buildroot.net/results/81aa66ddd88919295ccb5f34b527b737627263a7 |
>
>
> CMake Error at channels/tsmf/client/gstreamer/CMakeLists.txt:21 (message):
> GStreamer library not found, but required for TSMF module.
>
> Adam, you recently bumped freerdp, could you please have a look?
>
>> arc | gpm-1.20.7 | NOK | http://autobuild.buildroot.net/results/5a1404cf52c9547533a5b04c40d6118b43a07707 |
>
> gpm-root.c:(.text.startup+0x1aa): undefined reference to `__sigemptyset'
> gpm-root.c:(.text.startup+0x1aa): undefined reference to `__sigemptyset'
>
> This is with the new glibc ARC toolchain. Alexey ? :-)
>
>> xtensa | gstreamer-0.10.36 | NOK | http://autobuild.buildroot.net/results/bb0a52f08ce07b3aa7301e69e9be12f3e45f45b2 | ORPH
>> arm | gstreamer-0.10.36 | NOK | http://autobuild.buildroot.net/results/0b6feb96ba877cb4f3b8c6a05c977a1c12805fac | ORPH
>> arm | gstreamer-0.10.36 | NOK | http://autobuild.buildroot.net/results/daa93d58840c77c980d040e2b740555dc3b36951 | ORPH
>
>
> /home/buildroot/autobuild/run/instance-3/output/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libgobject-2.0.a(libgobject_2_0_la-gmarshal.o): In function `g_cclosure_marshal_VOID__VOID':
> gmarshal.c:(.text+0x0): multiple definition of `g_cclosure_marshal_VOID__VOID'
> ../gst/.libs/libgstreamer-0.10.a(libgstreamer_0.10_la-gstmarshal.o):/home/buildroot/autobuild/run/instance-3/output/build/gstreamer-0.10.36/gst/gstmarshal.c:60: first defined here
>
> Static linking issue. Who volunteers to have a look? We don't even have
> a person listed in the DEVELOPERS file for gstreamer.
>
>> arm | host-erlang-rebar-2.6.4 | TIM | http://autobuild.buildroot.net/results/6c4c7b3094bd48a72786f5be3d760f0356557403 |
>> arm | host-erlang-rebar-2.6.4 | TIM | http://autobuild.buildroot.net/results/a17d5eb1aac01dab19412aa28d523625577730db |
>
> The infamous ./bootstrap issue that consumes 100% of the CPU before
> timing out the build job. Johan, we really need to find a solution to
> this problem. How can we proceed to debug this?
>
>> arc | host-gdb-arc-2017.09-rc1-gdb | NOK | http://autobuild.buildroot.net/results/43eae264991aa369490236c7bd59c0b6a67fcf25 | ORPH
>
> checking whether /usr/bin/g++ supports C++11 features with -h std=c++11... no
> configure: error: *** A compiler with support for C++11 language features is required.
> make[2]: *** [configure-gdb] Error 1
>
> The ARC special version needs:
>
> depends on BR2_HOST_GCC_AT_LEAST_4_8
> depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8
>
> Just like the gdb 8.0 version.
>
> Yann, perhaps you could have a look at this ?
>
>> xtensa | host-libevent-2.1.8-stable | NOK | http://autobuild.buildroot.net/results/dfb5009ff4289086ff6ecf008d623cad92e7d1fe | ORPH
>
> /usr/include/openssl/kssl.h:150:5: error: unknown type name 'krb5_octet'
> krb5_octet FAR *key;
>
> I think we need to pass --disable-openssl when building host-libevent.
> Who volunteers to have a look?
>
>> arm | host-mono-5.2.0.224 | NOK | http://autobuild.buildroot.net/results/51dcf8908157393a09ce772e6099e73fd0cd0ba2 |
>
> Unhandled Exception:
> System.ExecutionEngineException: System.NullReferenceException: Object reference not set to an instance of an object ---> System.NullReferenceException: Object reference not set to an instance of an object
>
> Angelo, could you have a look ?
>
>> arc | host-uboot-tools-2017.07 | NOK | http://autobuild.buildroot.net/results/9567703c95823be10400c0a330c3997a4cd6a62c | ORPH
>> arm | host-uboot-tools-2017.07 | NOK | http://autobuild.buildroot.net/results/e3ee47e30a01e68a80fcbef3178f8eb051fe509f | ORPH
>> sh4 | host-uboot-tools-2017.07 | NOK | http://autobuild.buildroot.net/results/7d60ebf31fd9df7a5fef7e7723859c32d7972f5b | ORPH
>
> The libfdt/python issue. Matt Weber has proposed a patch to fix it:
> https://patchwork.ozlabs.org/patch/827287/, however I have some
> questions/concerns about it.
Should we just wait for the November uboot release that resolves the
underlying design issue upstream?
>
>> xtensa | jimtcl-0.75 | NOK | http://autobuild.buildroot.net/results/fb939428388a53dce3a141147e6bdca15cd9c9ea |
>> microblazeel | jimtcl-0.75 | NOK | http://autobuild.buildroot.net/results/d5328314675e47534658884a9b249cefcf237c40 |
>
> Error: /home/peko/autobuild/instance-2/output/build/jimtcl-0.75/autosetup/config.guess: unable to guess system type
>
> Peter: another ppc64 as host system issue I believe. Could you have a look ?
>
>> powerpc | jose-10 | NOK | http://autobuild.buildroot.net/results/e5badaca8f078b84d3a2135634a96729a20f2a9b |
>
> hsh.c: In function 'hsh':
> hsh.c:28:21: error: declaration of 'hsh' shadows a global declaration [-Werror=shadow]
> hsh.c:26:1: error: shadowed declaration is here [-Werror=shadow]
>
> Should be fairly easy to fix. Peter, jose is a package you have added.
> Could you have a look?
>
>> arc | libidn-1.33 | NOK | http://autobuild.buildroot.net/results/d3c3abf9966dd023923235c3879f521ba3a2daa5 | ORPH
>
>
> strerror.c: In function 'rpl_strerror':
> strerror.c:44:21: warning: implicit declaration of function 'strerror_override'; did you mean 'strerror_r'? [-Wimplicit-function-declaration]
> const char *msg = strerror_override (n);
> ^~~~~~~~~~~~~~~~~
>
> This so far only happened on ARC, with uClibc. Alexey ?
>
>> arm | lttng-tools-2.9.5 | NOK | http://autobuild.buildroot.net/results/16791e9548715d06efe37cf99fb07e4e27d98383 |
>
> Yet again:
>
> prog.c:24:7: warning: implicit declaration of function 'dlmopen' [-Wimplicit-function-declaration]
> h1 = dlmopen(LM_ID_BASE, "libfoo.so", RTLD_LAZY);
>
> I'll try to have a look tomorrow.
>
>> microblazeel | lua-sdl2-v2.0.5-6.0 | NOK | http://autobuild.buildroot.net/results/46f93012342549c44e100522eea0852586311ef4 |
>
> I have a fix for this one, it's easy. I'll send it shortly.
>
>> arm | mp4v2-2.0.0 | NOK | http://autobuild.buildroot.net/results/8be30492abe3345dc9411fe3e5636c4f8e4311ce |
>
> src/rtphint.cpp:342:35: error: ISO C++ forbids comparison between pointer and integer [-fpermissive]
> if (pSlash != '\0') {
>
> Would be fixed by
> http://pkgs.fedoraproject.org/cgit/rpms/libmp4v2.git/tree/0004-Fix-GCC7-build.patch.
> J?rg, mp4v2 is your package, could you have a look? :-)
>
>> xtensa | nmap-7.60 | NOK | http://autobuild.buildroot.net/results/9e636919c98cd31b5067c8306d0e481a672434cf | ORPH
>> mips64el | nmap-7.60 | NOK | http://autobuild.buildroot.net/results/912561f505ad10d1eaa96dbe247d5838e9968e14 | ORPH
>
> xtensa-linux-g++.br_real: error: libssh2/lib/libssh2.a: No such file or directory
>
> Who volunteers to have a look?
>
>> mips64el | opencv-2.4.13.3 | NOK | http://autobuild.buildroot.net/results/b27d324331f6e351e95dd4742f4d0a50af60c590 |
>> mips64el | opencv-2.4.13.3 | NOK | http://autobuild.buildroot.net/results/44ed0be0bd94028b7b37e7bf21233adc1753d94b |
>
> CMake Error at cmake/OpenCVCompilerOptions.cmake:21 (else):
> A duplicate ELSE command was found inside an IF block.
> Call Stack (most recent call first):
> CMakeLists.txt:437 (include)
>
> Should be easy to fix. Samuel, do you think you will find some time to
> have a look at this?
>
>> bfin | openobex-1.7.2 | NOK | http://autobuild.buildroot.net/results/78e033fe9f43845581a5d87b21a8451f67520e44 |
>
> /usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/build/openobex-1.7.2/lib/obex_transport_sock.c:(.text+0x5f6): undefined reference to `accept4'
>
> Not sure what's going on. accept4() not wired in Linux or uClibc for
> Blackfin? Something else? Waldemar, could you have a look?
>
>> arm | openssh-7.6p1 | NOK | http://autobuild.buildroot.net/results/3dcd2ab22b75bf27afd963d57e31df5e0bdedcaa | ORPH
>> arm | openssh-7.6p1 | NOK | http://autobuild.buildroot.net/results/8cc30818a400c7a392a3de787cabc9cd8425495f | ORPH
>
> getpagesize.c:(.text+0x0): multiple definition of `getpagesize'
> openbsd-compat//libopenbsd-compat.a(bsd-getpagesize.o):bsd-getpagesize.c:(.text+0x0): first defined here
>
> Would be fixed by http://patchwork.ozlabs.org/patch/832199/.
>
>> m68k | poppler-0.59.0 | NOK | http://autobuild.buildroot.net/results/c35599e6bf09aebe456ea959d7c238f82090fc62 |
>
> /usr/lfs/v0/rc-buildroot-test/scripts/instance-0/output/host/opt/ext-toolchain/m68k-buildroot-uclinux-uclibc/bin/ld.real: cannot find -lopenjp2
>
> Bernd, you recently bumped openjpeg. Could you have a look ?
>
>> x86_64 | qt5declarative-5.9.2 | NOK | http://autobuild.buildroot.net/results/d9707cc2f47c6906b7e4872e185b7866301c3322 |
>
> logo.h:52:11: error: 'GLfloat' does not name a type
> const GLfloat *constData() const { return m_data.constData(); }
>
> Not sure what's going on. I don't see which package is the OpenGL
> provider. Peter (Seiderer), do you have an idea ?
>
>> arc | stress-ng-0.06.15 | NOK | http://autobuild.buildroot.net/results/296b14584c200593f88af75cdda65c4ca03cd863 |
>
> stress-fp-error.c: In function 'stress_fp_error':
> stress-fp-error.c:100:10: error: 'FE_INVALID' undeclared (first use in this function); did you mean 'EINVAL'?
> EDOM, FE_INVALID);
> ^~~~~~~~~~
>
> We already exclude nios2, we should probably exclude ARC as well.
> Alexey, do you confirm?
>
> See:
>
> # fenv.h lacks FE_INVALID, FE_OVERFLOW & FE_UNDERFLOW on nios2
> depends on !BR2_nios2
>
>> m68k | tremor-19427 | TIM | http://autobuild.buildroot.net/results/5bff9fbd24264b3515a669d585e10ef23127d569 |
>> mipsel | tremor-19427 | TIM | http://autobuild.buildroot.net/results/d1c8e74477797b597c38186343e4d6c69b05560d |
>
> SVN repo is dead, and it locks up the build until we time out? Doesn't
> look great. Yann? :-)
>
>> microblazeel | usb_modeswitch-2.5.0 | NOK | http://autobuild.buildroot.net/results/20a9a75f701ce70c2ae434085a85ad8d34adc67b | ORPH
>> arm | usb_modeswitch-2.5.0 | NOK | http://autobuild.buildroot.net/results/46844b028989808aa7340c14af22f2855ec803d8 | ORPH
>>
>
> Not sure. Is it just:
>
>
> make[2]: *** [jim/libjim.a] Error 1
> make[2]: *** Waiting for unfinished jobs....
> usb_modeswitch.c: In function 'checkSuccess':
> usb_modeswitch.c:1579:7: warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized]
> if (i == CheckSuccess-1) {
>
> That makes the build fail?
>
> Baruch, you are the last person who bumped this package, could you have a look?
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Matthew L Weber / Pr Software Engineer
Airborne Information Systems / Security Systems and Software / Secure Platforms
MS 131-100, C Ave NE, Cedar Rapids, IA, 52498, USA
www.rockwellcollins.com
Note: Any Export License Required Information and License Restricted
Third Party Intellectual Property (TPIP) content must be encrypted and
sent to matthew.weber at corp.rockwellcollins.com.
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-01 2:37 ` Matthew Weber
@ 2017-11-01 9:45 ` Thomas Petazzoni
2017-11-01 10:01 ` Alexey Brodkin
2017-11-01 13:24 ` Matthew Weber
0 siblings, 2 replies; 43+ messages in thread
From: Thomas Petazzoni @ 2017-11-01 9:45 UTC (permalink / raw)
To: buildroot
Hello,
On Tue, 31 Oct 2017 21:37:28 -0500, Matthew Weber wrote:
> > This is happening only on ARC. Why? Matt Weber proposed a patch,
> > https://patchwork.ozlabs.org/patch/832397/, but I am not terribly
> > convinced because it doesn't explain why this problem happens only on
> > ARC, and why it appeared suddenly.
>
> I kicked off a test build reverting the following commit. We'll see
> in the morning if it changed the behavior or the pass/fail. (ie bump
> from GCC 6.x to 7.x)
> 5bd21f991f3 Evgeniy Didin 2017-09-21 21:28:28
OK, we'll see the result.
> One interesting thing to notes is the test-pkg is using a external ARC
> GCC6 uclibc toolchain and the failing builds are all internal
> toolchain and GCC 7.
Yes. But we have other toolchains tested by test-pkg that use gcc 7.x,
so I'm surprised the problem doesn't pop up on other architectures.
> >> arc | host-uboot-tools-2017.07 | NOK | http://autobuild.buildroot.net/results/9567703c95823be10400c0a330c3997a4cd6a62c | ORPH
> >> arm | host-uboot-tools-2017.07 | NOK | http://autobuild.buildroot.net/results/e3ee47e30a01e68a80fcbef3178f8eb051fe509f | ORPH
> >> sh4 | host-uboot-tools-2017.07 | NOK | http://autobuild.buildroot.net/results/7d60ebf31fd9df7a5fef7e7723859c32d7972f5b | ORPH
> >
> > The libfdt/python issue. Matt Weber has proposed a patch to fix it:
> > https://patchwork.ozlabs.org/patch/827287/, however I have some
> > questions/concerns about it.
>
> Should we just wait for the November uboot release that resolves the
> underlying design issue upstream?
No, because we want to fix this problem before the next Buildroot
release in November.
Unrelated note: when you're replying to only a few parts of a lengthy
e-mail, it's good practice to delete the parts of the e-mail that are
not relevant. See what I did here :)
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-01 9:45 ` Thomas Petazzoni
@ 2017-11-01 10:01 ` Alexey Brodkin
2017-11-01 10:24 ` Thomas Petazzoni
2017-11-01 13:24 ` Matthew Weber
1 sibling, 1 reply; 43+ messages in thread
From: Alexey Brodkin @ 2017-11-01 10:01 UTC (permalink / raw)
To: buildroot
Hi Thomas, Matthew,
On Wed, 2017-11-01 at 10:45 +0100, Thomas Petazzoni wrote:
> Hello,
>
> On Tue, 31 Oct 2017 21:37:28 -0500, Matthew Weber wrote:
>
> >
> > >
> > > This is happening only on ARC. Why? Matt Weber proposed a patch,
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_832397_&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656e
> > > ViXO7breS55ytWkhpk5R81I&m=TIK4hy7KeHKzHVuof5f5an0Z8AexpTLUombe2nPAH8Y&s=9PIyZnaKCbGWuYkmizNBoKWkNQZ90OFwPSaZUl4-FTQ&e=, but I am not terribly
> > > convinced because it doesn't explain why this problem happens only on
> > > ARC, and why it appeared suddenly.??
> >
> > I kicked off a test build reverting the following commit.??We'll see
> > in the morning if it changed the behavior or the pass/fail.??(ie bump
> > from GCC 6.x to 7.x)
> > 5bd21f991f3 Evgeniy Didin?????2017-09-21 21:28:28
>
> OK, we'll see the result.
>
> >
> > One interesting thing to notes is the test-pkg is using a external ARC
> > GCC6 uclibc toolchain??and the failing builds are all internal
> > toolchain and GCC 7.
>
> Yes. But we have other toolchains tested by test-pkg that use gcc 7.x,
> so I'm surprised the problem doesn't pop up on other architectures.
As a matter of fact the same problem happens on ARM if GCC 7 is used.
That's my defconfig:
--------------------------->8---------------------
BR2_arm=y
BR2_GCC_VERSION_7_X=y
--------------------------->8---------------------
Now:
--------------------------->8---------------------
make argp-standalone
...
.../output/build/argp-standalone-1.3/argp-help.c:1217: undefined reference to `argp_fmtstream_set_wmargin'
.../output/build/argp-standalone-1.3/argp-help.c:1199: undefined reference to `argp_fmtstream_puts'
collect2: error: ld returned 1 exit status
--------------------------->8---------------------
Speaking about a fix for this problem I guess more elegant could be:
--------------------------->8---------------------
?argp-fmtstream.h | 2 +-
?1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/argp-fmtstream.h b/argp-fmtstream.h
index 2dd0925..cb0bead 100644
--- a/argp-fmtstream.h
+++ b/argp-fmtstream.h
@@ -215,7 +215,7 @@ extern int __argp_fmtstream_ensure (argp_fmtstream_t __fs, size_t __amount);
?#if defined(__GNUC__) && !defined(__GNUC_STDC_INLINE__)
?#define ARGP_FS_EI extern inline
?#else
-#define ARGP_FS_EI inline
+#define ARGP_FS_EI inline __attribute__((__always_inline__))
?#endif
?#endif
--------------------------->8---------------------
If that looks fine to you guys Eugeniy will send out that fix.
-Alexey
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-10-31 22:05 ` [Buildroot] Analysis of build " Thomas Petazzoni
2017-11-01 2:37 ` Matthew Weber
@ 2017-11-01 10:17 ` Samuel Martin
2017-11-01 13:40 ` Thomas Petazzoni
2017-11-01 18:03 ` Baruch Siach
` (5 subsequent siblings)
7 siblings, 1 reply; 43+ messages in thread
From: Samuel Martin @ 2017-11-01 10:17 UTC (permalink / raw)
To: buildroot
Thomas, all,
On Tue, Oct 31, 2017 at 11:05 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> Since Peter is about to release -rc1, it's time to restart with
> analyzing the build failures we have. And we have *lots* of them!
>
> Alexey, Yann, Adam, Peter (both Korsgaard and Seiderer?, Olivier,
> Matthew, Johan, Angelo, J?rg, Samuel, Waldemar, Bernd and Baruch: there
> are some questions/issues/topics for you below. Please read on! Thanks
> for your support!
>
[...]
>> mips64el | opencv-2.4.13.3 | NOK | http://autobuild.buildroot.net/results/b27d324331f6e351e95dd4742f4d0a50af60c590 |
>> mips64el | opencv-2.4.13.3 | NOK | http://autobuild.buildroot.net/results/44ed0be0bd94028b7b37e7bf21233adc1753d94b |
>
> CMake Error at cmake/OpenCVCompilerOptions.cmake:21 (else):
> A duplicate ELSE command was found inside an IF block.
> Call Stack (most recent call first):
> CMakeLists.txt:437 (include)
>
> Should be easy to fix. Samuel, do you think you will find some time to
> have a look at this?
I was about to check on these failures when the abo were off for
maintainance yesterday.
Hopefully I should have time to look into this by the end of the week.
>
>> bfin | openobex-1.7.2 | NOK | http://autobuild.buildroot.net/results/78e033fe9f43845581a5d87b21a8451f67520e44 |
>
> /usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/build/openobex-1.7.2/lib/obex_transport_sock.c:(.text+0x5f6): undefined reference to `accept4'
>
> Not sure what's going on. accept4() not wired in Linux or uClibc for
> Blackfin? Something else? Waldemar, could you have a look?
>
I have a pending patch for openobex,.
It seems accept4 is not available in uclibc for blackfin architecture [1].
Grepping at the git log, similar issues were fixed by disabling the
package on blackfin target.
Regards,
[1] https://cgit.openadk.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/common/bits/kernel-features.h#n452
--
Samuel
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-01 10:01 ` Alexey Brodkin
@ 2017-11-01 10:24 ` Thomas Petazzoni
2017-11-01 10:31 ` Alexey Brodkin
2017-11-02 2:31 ` Waldemar Brodkorb
0 siblings, 2 replies; 43+ messages in thread
From: Thomas Petazzoni @ 2017-11-01 10:24 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 1 Nov 2017 10:01:14 +0000, Alexey Brodkin wrote:
> As a matter of fact the same problem happens on ARM if GCC 7 is used.
> That's my defconfig:
> --------------------------->8---------------------
> BR2_arm=y
> BR2_GCC_VERSION_7_X=y
> --------------------------->8---------------------
I was surprised because our configuration
https://git.buildroot.org/buildroot/tree/support/config-fragments/autobuild/br-arm-cortex-a9-glibc.config
is using gcc 7.x. But what I missed is that it's a glibc configuration,
and argp-standalone is only available for !glibc configurations.
So that explains it all.
> --------------------------->8---------------------
> make argp-standalone
> ...
> .../output/build/argp-standalone-1.3/argp-help.c:1217: undefined reference to `argp_fmtstream_set_wmargin'
> .../output/build/argp-standalone-1.3/argp-help.c:1199: undefined reference to `argp_fmtstream_puts'
> collect2: error: ld returned 1 exit status
> --------------------------->8---------------------
>
> Speaking about a fix for this problem I guess more elegant could be:
> --------------------------->8---------------------
> ?argp-fmtstream.h | 2 +-
> ?1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/argp-fmtstream.h b/argp-fmtstream.h
> index 2dd0925..cb0bead 100644
> --- a/argp-fmtstream.h
> +++ b/argp-fmtstream.h
> @@ -215,7 +215,7 @@ extern int __argp_fmtstream_ensure (argp_fmtstream_t __fs, size_t __amount);
> ?#if defined(__GNUC__) && !defined(__GNUC_STDC_INLINE__)
> ?#define ARGP_FS_EI extern inline
> ?#else
> -#define ARGP_FS_EI inline
> +#define ARGP_FS_EI inline __attribute__((__always_inline__))
> ?#endif
> ?#endif
> --------------------------->8---------------------
>
> If that looks fine to you guys Eugeniy will send out that fix.
The gnu89-inline solution is the one also used by Alpine Linux,
https://git.alpinelinux.org/cgit/aports/tree/main/argp-standalone/gnu89-inline.patch,
so I believe it's good enough.
I'll apply Matt's patch after changing the commit log.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-01 10:24 ` Thomas Petazzoni
@ 2017-11-01 10:31 ` Alexey Brodkin
2017-11-02 2:31 ` Waldemar Brodkorb
1 sibling, 0 replies; 43+ messages in thread
From: Alexey Brodkin @ 2017-11-01 10:31 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Wed, 2017-11-01 at 11:24 +0100, Thomas Petazzoni wrote:
> Hello,
>
> On Wed, 1 Nov 2017 10:01:14 +0000, Alexey Brodkin wrote:
>
> >
> > As a matter of fact the same problem happens on ARM if GCC 7 is used.
> > That's my defconfig:
> > --------------------------->8---------------------??
> > BR2_arm=y
> > BR2_GCC_VERSION_7_X=y
> > --------------------------->8---------------------??
>
> I was surprised because our configuration
> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.buildroot.org_buildroot_tree_support_config-2Dfragments_autobuild_br-2Darm-2Dcortex-2Da9-2D
> glibc.config&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=D6TKGDpqB5e36c8k5ttLo5TXKPAy6Rr2V__fIe0SZqQ&s=sg5deMW
> ka2kFKeMD8y3oFAtgzJyDn_y_x65wnnLaKII&e=
> is using gcc 7.x. But what I missed is that it's a glibc configuration,
> and argp-standalone is only available for !glibc configurations.
>
> So that explains it all.
>
> >
> > --------------------------->8---------------------??
> > make argp-standalone
> > ...
> > .../output/build/argp-standalone-1.3/argp-help.c:1217: undefined reference to `argp_fmtstream_set_wmargin'
> > .../output/build/argp-standalone-1.3/argp-help.c:1199: undefined reference to `argp_fmtstream_puts'
> > collect2: error: ld returned 1 exit status
> > --------------------------->8---------------------??
> >
> > Speaking about a fix for this problem I guess more elegant could be:
> > --------------------------->8---------------------??
> > ?argp-fmtstream.h | 2 +-
> > ?1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/argp-fmtstream.h b/argp-fmtstream.h
> > index 2dd0925..cb0bead 100644
> > --- a/argp-fmtstream.h
> > +++ b/argp-fmtstream.h
> > @@ -215,7 +215,7 @@ extern int __argp_fmtstream_ensure (argp_fmtstream_t __fs, size_t __amount);
> > ?#if defined(__GNUC__) && !defined(__GNUC_STDC_INLINE__)
> > ?#define ARGP_FS_EI extern inline
> > ?#else
> > -#define ARGP_FS_EI inline
> > +#define ARGP_FS_EI inline __attribute__((__always_inline__))
> > ?#endif
> > ?#endif
> > --------------------------->8---------------------??
> >
> > If that looks fine to you guys Eugeniy will send out that fix.
>
> The gnu89-inline solution is the one also used by Alpine Linux,
> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.alpinelinux.org_cgit_aports_tree_main_argp-2Dstandalone_gnu89-2Dinline.patch&d=DwIFaQ&c=DPL
> 6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=D6TKGDpqB5e36c8k5ttLo5TXKPAy6Rr2V__fIe0SZqQ&s=-1-
> MxhKi0bKT4Dj7I80GTQU7mRcVDN2pI3ofvT8IrAM&e=,
> so I believe it's good enough.
>
> I'll apply Matt's patch after changing the commit log.
Cool, that's fine by me.
Thanks for doing that anyways!
-Alexey
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-01 9:45 ` Thomas Petazzoni
2017-11-01 10:01 ` Alexey Brodkin
@ 2017-11-01 13:24 ` Matthew Weber
2017-11-01 13:37 ` Thomas Petazzoni
1 sibling, 1 reply; 43+ messages in thread
From: Matthew Weber @ 2017-11-01 13:24 UTC (permalink / raw)
To: buildroot
Thomas,
On Wed, Nov 1, 2017 at 4:45 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Tue, 31 Oct 2017 21:37:28 -0500, Matthew Weber wrote:
>
<snip>
>> >> arc | host-uboot-tools-2017.07 | NOK | http://autobuild.buildroot.net/results/9567703c95823be10400c0a330c3997a4cd6a62c | ORPH
>> >> arm | host-uboot-tools-2017.07 | NOK | http://autobuild.buildroot.net/results/e3ee47e30a01e68a80fcbef3178f8eb051fe509f | ORPH
>> >> sh4 | host-uboot-tools-2017.07 | NOK | http://autobuild.buildroot.net/results/7d60ebf31fd9df7a5fef7e7723859c32d7972f5b | ORPH
>> >
>> > The libfdt/python issue. Matt Weber has proposed a patch to fix it:
>> > https://patchwork.ozlabs.org/patch/827287/, however I have some
>> > questions/concerns about it.
>>
>> Should we just wait for the November uboot release that resolves the
>> underlying design issue upstream?
>
> No, because we want to fix this problem before the next Buildroot
> release in November.
>
I'll work on pulling in this patchset from upstream. It looks like it
was reviewed but missed the merge window for 2017.11.
https://lists.denx.de/pipermail/u-boot/2017-October/309560.html
Matt
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-01 13:24 ` Matthew Weber
@ 2017-11-01 13:37 ` Thomas Petazzoni
0 siblings, 0 replies; 43+ messages in thread
From: Thomas Petazzoni @ 2017-11-01 13:37 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 1 Nov 2017 08:24:54 -0500, Matthew Weber wrote:
> I'll work on pulling in this patchset from upstream. It looks like it
> was reviewed but missed the merge window for 2017.11.
> https://lists.denx.de/pipermail/u-boot/2017-October/309560.html
The patch "pylibfdt: move pylibfdt to scripts/dtc/pylibfdt and refactor
makefile" is really large, I'm not sure we want this one in Buildroot.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-01 10:17 ` Samuel Martin
@ 2017-11-01 13:40 ` Thomas Petazzoni
0 siblings, 0 replies; 43+ messages in thread
From: Thomas Petazzoni @ 2017-11-01 13:40 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 1 Nov 2017 11:17:33 +0100, Samuel Martin wrote:
> >> mips64el | opencv-2.4.13.3 | NOK | http://autobuild.buildroot.net/results/b27d324331f6e351e95dd4742f4d0a50af60c590 |
> >> mips64el | opencv-2.4.13.3 | NOK | http://autobuild.buildroot.net/results/44ed0be0bd94028b7b37e7bf21233adc1753d94b |
> >
> > CMake Error at cmake/OpenCVCompilerOptions.cmake:21 (else):
> > A duplicate ELSE command was found inside an IF block.
> > Call Stack (most recent call first):
> > CMakeLists.txt:437 (include)
> >
> > Should be easy to fix. Samuel, do you think you will find some time to
> > have a look at this?
>
> I was about to check on these failures when the abo were off for
> maintainance yesterday.
> Hopefully I should have time to look into this by the end of the week.
Thanks!
> >> bfin | openobex-1.7.2 | NOK | http://autobuild.buildroot.net/results/78e033fe9f43845581a5d87b21a8451f67520e44 |
> >
> > /usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/build/openobex-1.7.2/lib/obex_transport_sock.c:(.text+0x5f6): undefined reference to `accept4'
> >
> > Not sure what's going on. accept4() not wired in Linux or uClibc for
> > Blackfin? Something else? Waldemar, could you have a look?
>
> I have a pending patch for openobex,.
> It seems accept4 is not available in uclibc for blackfin architecture [1].
> Grepping at the git log, similar issues were fixed by disabling the
> package on blackfin target.
>
>
> Regards,
>
> [1] https://cgit.openadk.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/common/bits/kernel-features.h#n452
This is weird, because even major architectures like ARM are not listed
as part of the architectures that have accept4. But I don't even see
this __ASSUME_ACCEPT4 used anywhere.
Waldmear ?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-10-31 22:05 ` [Buildroot] Analysis of build " Thomas Petazzoni
2017-11-01 2:37 ` Matthew Weber
2017-11-01 10:17 ` Samuel Martin
@ 2017-11-01 18:03 ` Baruch Siach
2017-11-02 10:54 ` Peter Korsgaard
2017-11-02 10:46 ` Peter Korsgaard
` (4 subsequent siblings)
7 siblings, 1 reply; 43+ messages in thread
From: Baruch Siach @ 2017-11-01 18:03 UTC (permalink / raw)
To: buildroot
Hi Thomas, Peter,
On Tue, Oct 31, 2017 at 11:05:19PM +0100, Thomas Petazzoni wrote:
> > microblazeel | usb_modeswitch-2.5.0 | NOK | http://autobuild.buildroot.net/results/20a9a75f701ce70c2ae434085a85ad8d34adc67b | ORPH
> > arm | usb_modeswitch-2.5.0 | NOK | http://autobuild.buildroot.net/results/46844b028989808aa7340c14af22f2855ec803d8 | ORPH
>
> Not sure. Is it just:
>
> make[2]: *** [jim/libjim.a] Error 1
> make[2]: *** Waiting for unfinished jobs....
> usb_modeswitch.c: In function 'checkSuccess':
> usb_modeswitch.c:1579:7: warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized]
> if (i == CheckSuccess-1) {
>
> That makes the build fail?
No. The cause is a few lines above that:
UNAME_MACHINE = ppc64le
UNAME_RELEASE = 3.10.0-514.10.2.el7.ppc64le
UNAME_SYSTEM = Linux
UNAME_VERSION = #1 SMP Fri Mar 3 16:16:38 GMT 2017
child process exited abnormally
while executing
[...]
make[2]: *** [jim/libjim.a] Error 1
make[2]: *** Waiting for unfinished jobs....
> Baruch, you are the last person who bumped this package, could you have a look?
The autobuilder indicates[1] that it only fails on Peter's gcc112 Powerpc
host. Debugging this requires access to a Powerpc host.
[1] http://autobuild.buildroot.net/?reason=usb_modeswitch-2.5.0
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] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-01 10:24 ` Thomas Petazzoni
2017-11-01 10:31 ` Alexey Brodkin
@ 2017-11-02 2:31 ` Waldemar Brodkorb
2017-11-02 8:06 ` Thomas Petazzoni
1 sibling, 1 reply; 43+ messages in thread
From: Waldemar Brodkorb @ 2017-11-02 2:31 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Thomas Petazzoni wrote,
> Hello,
>
> On Wed, 1 Nov 2017 10:01:14 +0000, Alexey Brodkin wrote:
>
> > As a matter of fact the same problem happens on ARM if GCC 7 is used.
> > That's my defconfig:
> > --------------------------->8---------------------
> > BR2_arm=y
> > BR2_GCC_VERSION_7_X=y
> > --------------------------->8---------------------
>
> I was surprised because our configuration
> https://git.buildroot.org/buildroot/tree/support/config-fragments/autobuild/br-arm-cortex-a9-glibc.config
> is using gcc 7.x. But what I missed is that it's a glibc configuration,
> and argp-standalone is only available for !glibc configurations.
>
> So that explains it all.
Just as a sidenote, uClibc-ng does include argp support
if enabled via UCLIBC_HAS_ARGP. Is argp-standalone used for musl
toolchains, too?
best regards
Waldemar
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-02 2:31 ` Waldemar Brodkorb
@ 2017-11-02 8:06 ` Thomas Petazzoni
0 siblings, 0 replies; 43+ messages in thread
From: Thomas Petazzoni @ 2017-11-02 8:06 UTC (permalink / raw)
To: buildroot
Hello,
On Thu, 2 Nov 2017 03:31:31 +0100, Waldemar Brodkorb wrote:
> > I was surprised because our configuration
> > https://git.buildroot.org/buildroot/tree/support/config-fragments/autobuild/br-arm-cortex-a9-glibc.config
> > is using gcc 7.x. But what I missed is that it's a glibc configuration,
> > and argp-standalone is only available for !glibc configurations.
> >
> > So that explains it all.
>
> Just as a sidenote, uClibc-ng does include argp support
> if enabled via UCLIBC_HAS_ARGP. Is argp-standalone used for musl
> toolchains, too?
Yes, we also use it for musl, so it makes to keep it as a separate
library I believe.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-10-31 22:05 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (2 preceding siblings ...)
2017-11-01 18:03 ` Baruch Siach
@ 2017-11-02 10:46 ` Peter Korsgaard
2017-11-02 17:43 ` Yann E. MORIN
` (3 subsequent siblings)
7 siblings, 0 replies; 43+ messages in thread
From: Peter Korsgaard @ 2017-11-02 10:46 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> arm | core-dependencies | NOK |
>> http://autobuild.buildroot.net/results/30d398c5764350609ef37d158c665347caf9f134
>> |
>> arm | core-dependencies | NOK |
>> http://autobuild.buildroot.net/results/5f5b5edb058efe976c003678e21bcc28a87cc828
>> |
> Your Buildroot configuration needs a compiler capable of building 32 bits binaries.
> If you're running a Debian/Ubuntu distribution, install the gcc-multilib package.
> For other distributions, refer to their documentation.
> Peter, gcc112 is your autobuilder, and it's a ppc64 machine, which
> probably explains the issue.
Indeed. Packages should depend on x86(-64) hostarch before selecting any
of the BR2_HOSTARCH_NEEDS_IA32_* symbols. I have sent a patch series
fixing this.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-01 18:03 ` Baruch Siach
@ 2017-11-02 10:54 ` Peter Korsgaard
2017-11-03 22:31 ` Peter Korsgaard
0 siblings, 1 reply; 43+ messages in thread
From: Peter Korsgaard @ 2017-11-02 10:54 UTC (permalink / raw)
To: buildroot
>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:
Hi,
> make[2]: *** [jim/libjim.a] Error 1
> make[2]: *** Waiting for unfinished jobs....
>> Baruch, you are the last person who bumped this package, could you have a look?
> The autobuilder indicates[1] that it only fails on Peter's gcc112 Powerpc
> host. Debugging this requires access to a Powerpc host.
You can request an account on the cfarm machines here:
https://cfarm.tetaneutral.net/users/new/
But I have just started a manual build on gcc112 to debug what the issue
is.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-10-31 22:05 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (3 preceding siblings ...)
2017-11-02 10:46 ` Peter Korsgaard
@ 2017-11-02 17:43 ` Yann E. MORIN
2017-11-02 18:08 ` Yann E. MORIN
2017-11-02 20:04 ` Thomas Petazzoni
2017-11-02 22:21 ` Thomas Petazzoni
` (2 subsequent siblings)
7 siblings, 2 replies; 43+ messages in thread
From: Yann E. MORIN @ 2017-11-02 17:43 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2017-10-31 23:05 +0100, Thomas Petazzoni spake thusly:
[--SNIP--]
> > arc | host-gdb-arc-2017.09-rc1-gdb | NOK | http://autobuild.buildroot.net/results/43eae264991aa369490236c7bd59c0b6a67fcf25 | ORPH
>
> checking whether /usr/bin/g++ supports C++11 features with -h std=c++11... no
> configure: error: *** A compiler with support for C++11 language features is required.
> make[2]: *** [configure-gdb] Error 1
>
> The ARC special version needs:
>
> depends on BR2_HOST_GCC_AT_LEAST_4_8
> depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8
>
> Just like the gdb 8.0 version.
>
> Yann, perhaps you could have a look at this ?
I'm not sure how I got dragged into an ARC-related issue... ;-]
But here, we're speaking about the host-gdb, and that one is not
protected:
config BR2_PACKAGE_HOST_GDB
bool "Build cross gdb for the host"
# When the external toolchain gdbserver is used, we shouldn't
# allow to build a cross-gdb, as the one of the external
# toolchain should be used.
depends on !BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY
depends on !((BR2_arm || BR2_armeb) && BR2_BINFMT_FLAT)
depends on !BR2_microblaze
depends on !BR2_nios2
depends on !BR2_or1k
help
Build a cross gdb that runs on the host machine and debugs
programs running on the target. It requires 'gdbserver'
installed on the target, see BR2_PACKAGE_GDB_SERVER to
enable it.
[--SNIP--]
config BR2_GDB_VERSION
string
default "arc-2017.09-rc1-gdb" if BR2_arc
And on that autobuilder, the host gcc is a 4.7 (toward the top of the
file): http://autobuild.buildroot.org/results/43eae264991aa369490236c7bd59c0b6a67fcf25/config
So, we'd need to add:
config BR2_PACKAGE_HOST_GDB
depends on BR2_HOST_GCC_AT_LEAST_4_8 || !BR2_arc
or something like that?
> > m68k | tremor-19427 | TIM | http://autobuild.buildroot.net/results/5bff9fbd24264b3515a669d585e10ef23127d569 |
> > mipsel | tremor-19427 | TIM | http://autobuild.buildroot.net/results/d1c8e74477797b597c38186343e4d6c69b05560d |
>
> SVN repo is dead, and it locks up the build until we time out? Doesn't
> look great. Yann? :-)
Not sure why I got fragged into an SVN-related issue... ;-]
The repository is not dead from here, though:
$ svn ls http://svn.xiph.org/trunk/Tremor
Redirecting to URL 'https://svn.xiph.org/trunk/Tremor':
Error validating server certificate for 'https://svn.xiph.org:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: xiph.org
- Valid: from Mar 31 21:45:50 2016 GMT until Mar 31 21:45:50 2018 GMT
- Issuer: StartCom Class 2 IV Server CA, StartCom Certification
Authority, StartCom Ltd., IL
- Fingerprint:
B9:AF:55:63:87:0A:45:9C:BD:B9:39:43:08:DA:7C:CA:87:20:BF:11
(R)eject, accept (t)emporarily or accept (p)ermanently? t
CHANGELOG
COPYING
[...]
But there is an https redirect, and the certificate is not recognised
somehow (my Firefox has no problem with it, though)...
We should probably at least add '--non-interactive' to have it at least
fail if it needs to prompt.
We could also make use of '--trust-server-cert-failures=ARG' where ARG
is one of 'unknown-ca', 'cn-mismatch', 'expired', 'not-yet-valid' or
'other'. But I am a bit reluctant at silently quiesce certificate
errors...
Your call.
> > microblazeel | usb_modeswitch-2.5.0 | NOK | http://autobuild.buildroot.net/results/20a9a75f701ce70c2ae434085a85ad8d34adc67b | ORPH
> > arm | usb_modeswitch-2.5.0 | NOK | http://autobuild.buildroot.net/results/46844b028989808aa7340c14af22f2855ec803d8 | ORPH
> >
>
> Not sure. Is it just:
>
>
> make[2]: *** [jim/libjim.a] Error 1
> make[2]: *** Waiting for unfinished jobs....
> usb_modeswitch.c: In function 'checkSuccess':
> usb_modeswitch.c:1579:7: warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized]
> if (i == CheckSuccess-1) {
>
> That makes the build fail?
The problem is higher in the stack:
autosetup/system.tcl:203 /home/peko/autobuild/instance-2/output/build/usb_modeswitch-2.5.0/jim/autosetup/config.guess: unable to guess system type
Regards,
Yann E. MORIN.
> Baruch, you are the last person who bumped this package, could you have a look?
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
.-----------------.--------------------.------------------.--------------------.
| 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] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-02 17:43 ` Yann E. MORIN
@ 2017-11-02 18:08 ` Yann E. MORIN
2017-11-02 20:04 ` Thomas Petazzoni
1 sibling, 0 replies; 43+ messages in thread
From: Yann E. MORIN @ 2017-11-02 18:08 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2017-11-02 18:43 +0100, Yann E. MORIN spake thusly:
> Thomas, All,
>
> On 2017-10-31 23:05 +0100, Thomas Petazzoni spake thusly:
> [--SNIP--]
> > > arc | host-gdb-arc-2017.09-rc1-gdb | NOK | http://autobuild.buildroot.net/results/43eae264991aa369490236c7bd59c0b6a67fcf25 | ORPH
> >
> > checking whether /usr/bin/g++ supports C++11 features with -h std=c++11... no
> > configure: error: *** A compiler with support for C++11 language features is required.
> > make[2]: *** [configure-gdb] Error 1
> >
> > The ARC special version needs:
Arg, I misread that; in my head I read s/needs/has/. Not sure why...
> > depends on BR2_HOST_GCC_AT_LEAST_4_8
> > depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8
Exactly what I did... Patch on its way (finalising commit log now).
Regards,
Yann E. MORIN.
> > Just like the gdb 8.0 version.
> >
> > Yann, perhaps you could have a look at this ?
>
> I'm not sure how I got dragged into an ARC-related issue... ;-]
>
> But here, we're speaking about the host-gdb, and that one is not
> protected:
>
> config BR2_PACKAGE_HOST_GDB
> bool "Build cross gdb for the host"
> # When the external toolchain gdbserver is used, we shouldn't
> # allow to build a cross-gdb, as the one of the external
> # toolchain should be used.
> depends on !BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY
> depends on !((BR2_arm || BR2_armeb) && BR2_BINFMT_FLAT)
> depends on !BR2_microblaze
> depends on !BR2_nios2
> depends on !BR2_or1k
> help
> Build a cross gdb that runs on the host machine and debugs
> programs running on the target. It requires 'gdbserver'
> installed on the target, see BR2_PACKAGE_GDB_SERVER to
> enable it.
>
> [--SNIP--]
>
> config BR2_GDB_VERSION
> string
> default "arc-2017.09-rc1-gdb" if BR2_arc
>
> And on that autobuilder, the host gcc is a 4.7 (toward the top of the
> file): http://autobuild.buildroot.org/results/43eae264991aa369490236c7bd59c0b6a67fcf25/config
>
> So, we'd need to add:
>
> config BR2_PACKAGE_HOST_GDB
> depends on BR2_HOST_GCC_AT_LEAST_4_8 || !BR2_arc
>
> or something like that?
>
> > > m68k | tremor-19427 | TIM | http://autobuild.buildroot.net/results/5bff9fbd24264b3515a669d585e10ef23127d569 |
> > > mipsel | tremor-19427 | TIM | http://autobuild.buildroot.net/results/d1c8e74477797b597c38186343e4d6c69b05560d |
> >
> > SVN repo is dead, and it locks up the build until we time out? Doesn't
> > look great. Yann? :-)
>
> Not sure why I got fragged into an SVN-related issue... ;-]
>
> The repository is not dead from here, though:
>
> $ svn ls http://svn.xiph.org/trunk/Tremor
> Redirecting to URL 'https://svn.xiph.org/trunk/Tremor':
> Error validating server certificate for 'https://svn.xiph.org:443':
> - The certificate is not issued by a trusted authority. Use the
> fingerprint to validate the certificate manually!
> Certificate information:
> - Hostname: xiph.org
> - Valid: from Mar 31 21:45:50 2016 GMT until Mar 31 21:45:50 2018 GMT
> - Issuer: StartCom Class 2 IV Server CA, StartCom Certification
> Authority, StartCom Ltd., IL
> - Fingerprint:
> B9:AF:55:63:87:0A:45:9C:BD:B9:39:43:08:DA:7C:CA:87:20:BF:11
> (R)eject, accept (t)emporarily or accept (p)ermanently? t
> CHANGELOG
> COPYING
> [...]
>
> But there is an https redirect, and the certificate is not recognised
> somehow (my Firefox has no problem with it, though)...
>
> We should probably at least add '--non-interactive' to have it at least
> fail if it needs to prompt.
>
> We could also make use of '--trust-server-cert-failures=ARG' where ARG
> is one of 'unknown-ca', 'cn-mismatch', 'expired', 'not-yet-valid' or
> 'other'. But I am a bit reluctant at silently quiesce certificate
> errors...
>
> Your call.
>
> > > microblazeel | usb_modeswitch-2.5.0 | NOK | http://autobuild.buildroot.net/results/20a9a75f701ce70c2ae434085a85ad8d34adc67b | ORPH
> > > arm | usb_modeswitch-2.5.0 | NOK | http://autobuild.buildroot.net/results/46844b028989808aa7340c14af22f2855ec803d8 | ORPH
> > >
> >
> > Not sure. Is it just:
> >
> >
> > make[2]: *** [jim/libjim.a] Error 1
> > make[2]: *** Waiting for unfinished jobs....
> > usb_modeswitch.c: In function 'checkSuccess':
> > usb_modeswitch.c:1579:7: warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized]
> > if (i == CheckSuccess-1) {
> >
> > That makes the build fail?
>
> The problem is higher in the stack:
>
> autosetup/system.tcl:203 /home/peko/autobuild/instance-2/output/build/usb_modeswitch-2.5.0/jim/autosetup/config.guess: unable to guess system type
>
> Regards,
> Yann E. MORIN.
>
> > Baruch, you are the last person who bumped this package, could you have a look?
> >
> > Thanks!
> >
> > Thomas
> > --
> > Thomas Petazzoni, CTO, Free Electrons
> > Embedded Linux and Kernel engineering
> > http://free-electrons.com
>
> --
> .-----------------.--------------------.------------------.--------------------.
> | 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. |
> '------------------------------^-------^------------------^--------------------'
--
.-----------------.--------------------.------------------.--------------------.
| 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] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-02 17:43 ` Yann E. MORIN
2017-11-02 18:08 ` Yann E. MORIN
@ 2017-11-02 20:04 ` Thomas Petazzoni
2017-11-02 20:55 ` Yann E. MORIN
1 sibling, 1 reply; 43+ messages in thread
From: Thomas Petazzoni @ 2017-11-02 20:04 UTC (permalink / raw)
To: buildroot
Hello,
On Thu, 2 Nov 2017 18:43:38 +0100, Yann E. MORIN wrote:
> > The ARC special version needs:
> >
> > depends on BR2_HOST_GCC_AT_LEAST_4_8
> > depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8
> >
> > Just like the gdb 8.0 version.
> >
> > Yann, perhaps you could have a look at this ?
>
> I'm not sure how I got dragged into an ARC-related issue... ;-]
It's a Config.in dependency issue, you're the expert in that field! :-)*
[snip]
I'll look at the patch you have sent.
> > > m68k | tremor-19427 | TIM | http://autobuild.buildroot.net/results/5bff9fbd24264b3515a669d585e10ef23127d569 |
> > > mipsel | tremor-19427 | TIM | http://autobuild.buildroot.net/results/d1c8e74477797b597c38186343e4d6c69b05560d |
> >
> > SVN repo is dead, and it locks up the build until we time out? Doesn't
> > look great. Yann? :-)
>
> Not sure why I got fragged into an SVN-related issue... ;-]
>
> The repository is not dead from here, though:
>
> $ svn ls http://svn.xiph.org/trunk/Tremor
> Redirecting to URL 'https://svn.xiph.org/trunk/Tremor':
> Error validating server certificate for 'https://svn.xiph.org:443':
> - The certificate is not issued by a trusted authority. Use the
> fingerprint to validate the certificate manually!
> Certificate information:
> - Hostname: xiph.org
> - Valid: from Mar 31 21:45:50 2016 GMT until Mar 31 21:45:50 2018 GMT
> - Issuer: StartCom Class 2 IV Server CA, StartCom Certification
> Authority, StartCom Ltd., IL
> - Fingerprint:
> B9:AF:55:63:87:0A:45:9C:BD:B9:39:43:08:DA:7C:CA:87:20:BF:11
> (R)eject, accept (t)emporarily or accept (p)ermanently? t
> CHANGELOG
> COPYING
> [...]
>
> But there is an https redirect, and the certificate is not recognised
> somehow (my Firefox has no problem with it, though)...
>
> We should probably at least add '--non-interactive' to have it at least
> fail if it needs to prompt.
It is not normal that we timeout. Instead, we should gracefully
fallback on using http://sources.buildroot.net/tremor-19427.tar.gz
instead.
> We could also make use of '--trust-server-cert-failures=ARG' where ARG
> is one of 'unknown-ca', 'cn-mismatch', 'expired', 'not-yet-valid' or
> 'other'. But I am a bit reluctant at silently quiesce certificate
> errors...
No, I just want the svn command to fail, and fallback to the backup
mirror, if that is possible.
> > > microblazeel | usb_modeswitch-2.5.0 | NOK | http://autobuild.buildroot.net/results/20a9a75f701ce70c2ae434085a85ad8d34adc67b | ORPH
> > > arm | usb_modeswitch-2.5.0 | NOK | http://autobuild.buildroot.net/results/46844b028989808aa7340c14af22f2855ec803d8 | ORPH
> > >
> >
> > Not sure. Is it just:
> >
> >
> > make[2]: *** [jim/libjim.a] Error 1
> > make[2]: *** Waiting for unfinished jobs....
> > usb_modeswitch.c: In function 'checkSuccess':
> > usb_modeswitch.c:1579:7: warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized]
> > if (i == CheckSuccess-1) {
> >
> > That makes the build fail?
>
> The problem is higher in the stack:
>
> autosetup/system.tcl:203 /home/peko/autobuild/instance-2/output/build/usb_modeswitch-2.5.0/jim/autosetup/config.guess: unable to guess system type
That Peter's gcc112 build machine that strikes again I guess.
Peter ?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-02 20:04 ` Thomas Petazzoni
@ 2017-11-02 20:55 ` Yann E. MORIN
0 siblings, 0 replies; 43+ messages in thread
From: Yann E. MORIN @ 2017-11-02 20:55 UTC (permalink / raw)
To: buildroot
Thomas, Andr?, All,
Andr?, I'm dragging you into the discussion because we're seeing build
failures that only occur on your autobuilder (at least for now), see
below...
On 2017-11-02 21:04 +0100, Thomas Petazzoni spake thusly:
> On Thu, 2 Nov 2017 18:43:38 +0100, Yann E. MORIN wrote:
[--SNIP--]
> > > > m68k | tremor-19427 | TIM | http://autobuild.buildroot.net/results/5bff9fbd24264b3515a669d585e10ef23127d569 |
> > > > mipsel | tremor-19427 | TIM | http://autobuild.buildroot.net/results/d1c8e74477797b597c38186343e4d6c69b05560d |
> > >
> > > SVN repo is dead, and it locks up the build until we time out? Doesn't
> > > look great. Yann? :-)
> > The repository is not dead from here, though:
> >
> > $ svn ls http://svn.xiph.org/trunk/Tremor
> > Redirecting to URL 'https://svn.xiph.org/trunk/Tremor':
> > Error validating server certificate for 'https://svn.xiph.org:443':
> > - The certificate is not issued by a trusted authority. Use the
> > fingerprint to validate the certificate manually!
> > Certificate information:
> > - Hostname: xiph.org
> > - Valid: from Mar 31 21:45:50 2016 GMT until Mar 31 21:45:50 2018 GMT
> > - Issuer: StartCom Class 2 IV Server CA, StartCom Certification
> > Authority, StartCom Ltd., IL
> > - Fingerprint:
> > B9:AF:55:63:87:0A:45:9C:BD:B9:39:43:08:DA:7C:CA:87:20:BF:11
> > (R)eject, accept (t)emporarily or accept (p)ermanently? t
> > CHANGELOG
> > COPYING
> > [...]
> >
> > But there is an https redirect, and the certificate is not recognised
> > somehow (my Firefox has no problem with it, though)...
> >
> > We should probably at least add '--non-interactive' to have it at least
> > fail if it needs to prompt.
>
> It is not normal that we timeout. Instead, we should gracefully
> fallback on using http://sources.buildroot.net/tremor-19427.tar.gz
> instead.
> > We could also make use of '--trust-server-cert-failures=ARG' where ARG
> > is one of 'unknown-ca', 'cn-mismatch', 'expired', 'not-yet-valid' or
> > 'other'. But I am a bit reluctant at silently quiesce certificate
> > errors...
>
> No, I just want the svn command to fail, and fallback to the backup
> mirror, if that is possible.
The problem I have is that I can not reproduce the timeout, because it
does work for me here, so I can't even test a fix... :-/
All I have is a prompt about a failure on a certificate...
$ http_proxy= https_proxy= LD_PRELOAD= BR2_DL_DIR=$(pwd)/yem-dl time make tremor-source </dev/null
umask 0022 && make -C /home/ymorin/dev/buildroot/buildroot O=/home/ymorin/dev/buildroot/O/. tremor-source
>>> tremor 19427 Downloading
Redirecting to URL 'https://svn.xiph.org/trunk/Tremor':
svn: E170013: Unable to connect to a repository at URL 'https://svn.xiph.org/trunk/Tremor'
svn: E230001: Server SSL certificate verification failed: issuer is not trusted
--2017-11-02 21:50:41-- http://sources.buildroot.net/tremor-19427.tar.gz
Resolving sources.buildroot.net (sources.buildroot.net)... 176.9.16.109
Connecting to sources.buildroot.net (sources.buildroot.net)|176.9.16.109|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 150071 (147K) [application/x-gzip]
Saving to: ?/home/ymorin/dev/buildroot/O/build/.tremor-19427.tar.gz.kyXsJx/output?
/home/ymorin/dev/buildroot 100%[======================================>] 146,55K 824KB/s in 0,2s
2017-11-02 21:50:41 (824 KB/s) - ?/home/ymorin/dev/buildroot/O/build/.tremor-19427.tar.gz.kyXsJx/output? saved [150071/150071]
WARNING: no hash file for tremor-19427.tar.gz
3.16user 0.20system 0:04.56elapsed 73%CPU (0avgtext+0avgdata 100384maxresident)k
0inputs+760outputs (0major+132897minor)pagefaults 0swaps
So it looks like it is working when stdin is not a tty...
But all tremor failures happen on Andr?'s machine, so maybe there is a
other error condition on his side?
http://autobuild.buildroot.org/?reason=tremor-19427
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] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-10-31 22:05 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (4 preceding siblings ...)
2017-11-02 17:43 ` Yann E. MORIN
@ 2017-11-02 22:21 ` Thomas Petazzoni
2017-11-02 22:30 ` Alexey Brodkin
` (2 more replies)
2017-11-02 22:22 ` Alexey Brodkin
2017-11-08 12:49 ` Johan Oudinet
7 siblings, 3 replies; 43+ messages in thread
From: Thomas Petazzoni @ 2017-11-02 22:21 UTC (permalink / raw)
To: buildroot
Hello,
Quick feedback on all the build issues.
On Tue, 31 Oct 2017 23:05:19 +0100, Thomas Petazzoni wrote:
> On Tue, 31 Oct 2017 08:00:13 +0100 (CET), Thomas Petazzoni wrote:
>
> > arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/25e4ff4b8cecd88d56bd75fcdef64ad9affed959 | ORPH
> > arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/204d17c639e8a38648dbc15c4abbc0c6fe23370a | ORPH
> > arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/2ac87b1ea118366df4c816a13fa7cd02f8b10dc0 | ORPH
> > arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/a818230518d1197a9916019a955437fc3611ad33 | ORPH
> > arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/3663fc12c6d5908ba496efdfaa1ba24ed39f0104 | ORPH
> > arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/af51008cdc92645adb20664aa7b3c64d9ed4691e | ORPH
> > arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/e033f008b4731d41ec426884b45a591dda7adaf3 | ORPH
> > arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/1be95e26fd18e9772e42b5e6cb1e93fbac9c1c8a | ORPH
> > arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/c94d79b9eaecdb36e0894ae0f965ae39cdb35386 | ORPH
> > arc | argp-standalone-1.3 | NOK | http://autobuild.buildroot.net/results/53359e0fe1408f3816d3091b49462320239f39c1 | ORPH
>
> This is happening only on ARC. Why? Matt Weber proposed a patch,
> https://patchwork.ozlabs.org/patch/832397/, but I am not terribly
> convinced because it doesn't explain why this problem happens only on
> ARC, and why it appeared suddenly.
>
> Alexey, could you have a look ?
These have now been fixed by
https://git.buildroot.org/buildroot/commit/?id=f0b65bd90ce4429d6b7e952ce7de2d5f92a2dd26.
They were not ARC related in the end.
> > bfin | boost-1.65.1 | NOK | http://autobuild.buildroot.net/results/5874155f0d722c004971bb9ae9df995f052744c6 |
> > arm | boost-1.65.1 | NOK | http://autobuild.buildroot.net/results/06bfcc0ba0ea9a125e89a54235348564d1a074a3 |
> > m68k | boost-1.65.1 | NOK | http://autobuild.buildroot.net/results/f2a0bd030cce31a7346f05442a2d16c462713768 |
> > m68k | boost-1.65.1 | NOK | http://autobuild.buildroot.net/results/38d80d117f346ed630b10b6cdc951ec9a9dd1576 |
> > bfin | boost-1.65.1 | NOK | http://autobuild.buildroot.net/results/19ddca30994e3acf223e54b91cfda9725838d71c |
>
> All five issues are the same:
>
> libs/fiber/src/numa/linux/pin_thread.cpp:31:39: error: '::pthread_setaffinity_np' has not been declared
> if ( BOOST_UNLIKELY( 0 != ( err = ::pthread_setaffinity_np( ::pthread_self(), sizeof( set), & set) ) ) ) {
>
> This is weird, because:
>
> config BR2_PACKAGE_BOOST_FIBER
> bool "boost-fiber"
> depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL
>
> So the fiber library shouldn't be built on toolchains that don't have
> NPTL support.
>
> Adam, since you bumped Boost, could you investigate this?
This still needs to be investigated. Adam?
> > arc | busybox-1.27.2 | NOK | http://autobuild.buildroot.net/results/2cb531b9f9c75bb5dae10c02f2afeca225c65947 | ORPH
>
>
> CC console-tools/setlogcons.o
> libbb/appletlib.c:206:8: error: 'NUM_APPLETS' undeclared (first use in this function); did you mean 'PF_APPLETALK'?
> max = NUM_APPLETS;
>
> What is going on here?!?
It still occurred only once,
http://autobuild.buildroot.net/?reason=busybox-1.27.2. Not sure what
this means.
> > arm | core-dependencies | NOK | http://autobuild.buildroot.net/results/30d398c5764350609ef37d158c665347caf9f134 |
> > arm | core-dependencies | NOK | http://autobuild.buildroot.net/results/5f5b5edb058efe976c003678e21bcc28a87cc828 |
>
> Your Buildroot configuration needs a compiler capable of building 32 bits binaries.
> If you're running a Debian/Ubuntu distribution, install the gcc-multilib package.
> For other distributions, refer to their documentation.
>
> Peter, gcc112 is your autobuilder, and it's a ppc64 machine, which
> probably explains the issue.
Peter has submitted a patch series fixing some (all?) of those issues,
but I have some questions/concerns about some of the patches, which I
have already shared by replying to those patches.
> > arm | cups-2.2.5 | NOK | http://autobuild.buildroot.net/results/0f1cb8d72d0a78eb8b5c46548bc7c7bade93c674 | ORPH
>
>
> ippserver.o: In function `ipp_print_job':
> /accts/mlweber1/rclinux/target_build/instance-3/output/build/cups-2.2.5/test/ippserver.c:3881: undefined reference to `_cupsThreadDetach'
> ippserver.o: In function `run_printer':
> /accts/mlweber1/rclinux/target_build/instance-3/output/build/cups-2.2.5/test/ippserver.c:6812: undefined reference to `_cupsThreadDetach'
> /accts/mlweber1/rclinux/target_build/instance-3/output/build/cups-2.2.5/test/ippserver.c:6830: undefined reference to `_cupsThreadDetach'
>
> This happens with a toolchain that doesn't have thread support. So
> either we make cups depend on the availability of thread support, or we
> fix the problem in cups. Perhaps making cups depend on thread support
> is the easiest option.
>
> Olivier, could you have a look into this? Also, I realized you are not
> listed in the DEVELOPERS file for the cups package, would you be OK to
> add yourself there?
Fixed by:
https://git.buildroot.org/buildroot/commit/?id=f04f2023fcf28aea133cef25466631f9e9f9ce7f
>
> > powerpc64 | dbus-python-1.2.4 | NOK | http://autobuild.buildroot.net/results/1588d1a2fec77522857fd22e344b1a89ad04bb44 | ORPH
> > arm | dbus-python-1.2.4 | NOK | http://autobuild.buildroot.net/results/a1b68de766d13628380dfaa4e4db893a6c8e8af6 | ORPH
> > or1k | dbus-python-1.2.4 | NOK | http://autobuild.buildroot.net/results/bf1124aed79210f16acc08e056e744a0dc17b418 | ORPH
> > x86_64 | dbus-python-1.2.4 | NOK | http://autobuild.buildroot.net/results/8a7203b7473b5500b456344379dfa6d6bde4d52d | ORPH
>
> configure: PYTHON_INCLUDES overridden to: -I/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/host/powerpc64-buildroot-linux-gnu/sysroot/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/host/powerpc64-buildroot-linux-gnu/sysroot/usr/include/python3.6m -I/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/host/powerpc64-buildroot-linux-gnu/sysroot/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/host/powerpc64-buildroot-linux-gnu/sysroot/usr/include/python3.6m
> checking whether those headers are sufficient... no
> configure: error: could not find Python headers
>
> Feels like the "building in /usr" issue, it would be fixed by
> https://patchwork.ozlabs.org/patch/827751/.
Still need to look into this.
> > arc | ffmpeg-3.3.5 | NOK | http://autobuild.buildroot.net/results/b8fd41b127ab7702a2b69998076d737ea2e092b5 |
> > arc | ffmpeg-3.3.5 | NOK | http://autobuild.buildroot.net/results/43c90fbad3662101ef4eb5958f73700d1ff57b38 |
> > arc | ffmpeg-3.3.5 | NOK | http://autobuild.buildroot.net/results/a152a190108986392346efbba001b9dd0bdc89bc |
> > arc | ffmpeg-3.3.5 | NOK | http://autobuild.buildroot.net/results/60d44246fe6a54b02b53564761807204b9a190d0 |
>
> libavcodec/vp9dsp_template.c:1685:1: internal compiler error: Segmentation fault
>
> Alexey, could you have a look ?
Alexey, this continues to happen:
http://autobuild.buildroot.net/?reason=ffmpeg-3.3.5. Should we disable
this package on ARC ?
> > xtensa | freerdp-2.0.0-rc0 | NOK | http://autobuild.buildroot.net/results/81aa66ddd88919295ccb5f34b527b737627263a7 |
>
>
> CMake Error at channels/tsmf/client/gstreamer/CMakeLists.txt:21 (message):
> GStreamer library not found, but required for TSMF module.
>
> Adam, you recently bumped freerdp, could you please have a look?
Adam?
> > arc | gpm-1.20.7 | NOK | http://autobuild.buildroot.net/results/5a1404cf52c9547533a5b04c40d6118b43a07707 |
>
> gpm-root.c:(.text.startup+0x1aa): undefined reference to `__sigemptyset'
> gpm-root.c:(.text.startup+0x1aa): undefined reference to `__sigemptyset'
>
> This is with the new glibc ARC toolchain. Alexey ? :-)
Not ARC related, but glibc 2.26 related apparently. Fixed by
https://git.buildroot.org/buildroot/commit/?id=11a5a9d3570ca59f03b6f04ace1c0a30190695c9.
>
> > xtensa | gstreamer-0.10.36 | NOK | http://autobuild.buildroot.net/results/bb0a52f08ce07b3aa7301e69e9be12f3e45f45b2 | ORPH
> > arm | gstreamer-0.10.36 | NOK | http://autobuild.buildroot.net/results/0b6feb96ba877cb4f3b8c6a05c977a1c12805fac | ORPH
> > arm | gstreamer-0.10.36 | NOK | http://autobuild.buildroot.net/results/daa93d58840c77c980d040e2b740555dc3b36951 | ORPH
>
>
> /home/buildroot/autobuild/run/instance-3/output/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libgobject-2.0.a(libgobject_2_0_la-gmarshal.o): In function `g_cclosure_marshal_VOID__VOID':
> gmarshal.c:(.text+0x0): multiple definition of `g_cclosure_marshal_VOID__VOID'
> ../gst/.libs/libgstreamer-0.10.a(libgstreamer_0.10_la-gstmarshal.o):/home/buildroot/autobuild/run/instance-3/output/build/gstreamer-0.10.36/gst/gstmarshal.c:60: first defined here
>
> Static linking issue. Who volunteers to have a look? We don't even have
> a person listed in the DEVELOPERS file for gstreamer.
Still unfixed. Anyone?
> > arm | host-erlang-rebar-2.6.4 | TIM | http://autobuild.buildroot.net/results/6c4c7b3094bd48a72786f5be3d760f0356557403 |
> > arm | host-erlang-rebar-2.6.4 | TIM | http://autobuild.buildroot.net/results/a17d5eb1aac01dab19412aa28d523625577730db |
>
> The infamous ./bootstrap issue that consumes 100% of the CPU before
> timing out the build job. Johan, we really need to find a solution to
> this problem. How can we proceed to debug this?
Still unfixed.
> > arc | host-gdb-arc-2017.09-rc1-gdb | NOK | http://autobuild.buildroot.net/results/43eae264991aa369490236c7bd59c0b6a67fcf25 | ORPH
>
> checking whether /usr/bin/g++ supports C++11 features with -h std=c++11... no
> configure: error: *** A compiler with support for C++11 language features is required.
> make[2]: *** [configure-gdb] Error 1
>
> The ARC special version needs:
>
> depends on BR2_HOST_GCC_AT_LEAST_4_8
> depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8
>
> Just like the gdb 8.0 version.
>
> Yann, perhaps you could have a look at this ?
Fixed by
https://git.buildroot.org/buildroot/commit/?id=445340685f1c8118513355a5d96f683cb2af85e2.
>
> > xtensa | host-libevent-2.1.8-stable | NOK | http://autobuild.buildroot.net/results/dfb5009ff4289086ff6ecf008d623cad92e7d1fe | ORPH
>
> /usr/include/openssl/kssl.h:150:5: error: unknown type name 'krb5_octet'
> krb5_octet FAR *key;
>
> I think we need to pass --disable-openssl when building host-libevent.
> Who volunteers to have a look?
Still unfixed.
>
> > arm | host-mono-5.2.0.224 | NOK | http://autobuild.buildroot.net/results/51dcf8908157393a09ce772e6099e73fd0cd0ba2 |
>
> Unhandled Exception:
> System.ExecutionEngineException: System.NullReferenceException: Object reference not set to an instance of an object ---> System.NullReferenceException: Object reference not set to an instance of an object
>
> Angelo, could you have a look ?
Still unfixed.
> > arc | host-uboot-tools-2017.07 | NOK | http://autobuild.buildroot.net/results/9567703c95823be10400c0a330c3997a4cd6a62c | ORPH
> > arm | host-uboot-tools-2017.07 | NOK | http://autobuild.buildroot.net/results/e3ee47e30a01e68a80fcbef3178f8eb051fe509f | ORPH
> > sh4 | host-uboot-tools-2017.07 | NOK | http://autobuild.buildroot.net/results/7d60ebf31fd9df7a5fef7e7723859c32d7972f5b | ORPH
>
> The libfdt/python issue. Matt Weber has proposed a patch to fix it:
> https://patchwork.ozlabs.org/patch/827287/, however I have some
> questions/concerns about it.
Fixed by
https://git.buildroot.org/buildroot/commit/?id=0bcd09ffcabbcce74ed00bc38620f71a34a59b45.
>
> > xtensa | jimtcl-0.75 | NOK | http://autobuild.buildroot.net/results/fb939428388a53dce3a141147e6bdca15cd9c9ea |
> > microblazeel | jimtcl-0.75 | NOK | http://autobuild.buildroot.net/results/d5328314675e47534658884a9b249cefcf237c40 |
>
> Error: /home/peko/autobuild/instance-2/output/build/jimtcl-0.75/autosetup/config.guess: unable to guess system type
>
> Peter: another ppc64 as host system issue I believe. Could you have a look ?
Peter is looking into it.
> > powerpc | jose-10 | NOK | http://autobuild.buildroot.net/results/e5badaca8f078b84d3a2135634a96729a20f2a9b |
>
> hsh.c: In function 'hsh':
> hsh.c:28:21: error: declaration of 'hsh' shadows a global declaration [-Werror=shadow]
> hsh.c:26:1: error: shadowed declaration is here [-Werror=shadow]
>
> Should be fairly easy to fix. Peter, jose is a package you have added.
> Could you have a look?
Still unfixed.
> > arc | libidn-1.33 | NOK | http://autobuild.buildroot.net/results/d3c3abf9966dd023923235c3879f521ba3a2daa5 | ORPH
>
>
> strerror.c: In function 'rpl_strerror':
> strerror.c:44:21: warning: implicit declaration of function 'strerror_override'; did you mean 'strerror_r'? [-Wimplicit-function-declaration]
> const char *msg = strerror_override (n);
> ^~~~~~~~~~~~~~~~~
>
> This so far only happened on ARC, with uClibc. Alexey ?
Fixed by
https://git.buildroot.org/buildroot/commit/?id=11ed80169ca788d2b9ac448fb545485c44876be9.
> > arm | lttng-tools-2.9.5 | NOK | http://autobuild.buildroot.net/results/16791e9548715d06efe37cf99fb07e4e27d98383 |
>
> Yet again:
>
> prog.c:24:7: warning: implicit declaration of function 'dlmopen' [-Wimplicit-function-declaration]
> h1 = dlmopen(LM_ID_BASE, "libfoo.so", RTLD_LAZY);
>
> I'll try to have a look tomorrow.
Still unfixed.
> > microblazeel | lua-sdl2-v2.0.5-6.0 | NOK | http://autobuild.buildroot.net/results/46f93012342549c44e100522eea0852586311ef4 |
>
> I have a fix for this one, it's easy. I'll send it shortly.
Fixed by
https://git.buildroot.org/buildroot/commit/?id=8161a2f5367534a92978dd455bd736ff3f630abf.
> > arm | mp4v2-2.0.0 | NOK | http://autobuild.buildroot.net/results/8be30492abe3345dc9411fe3e5636c4f8e4311ce |
>
> src/rtphint.cpp:342:35: error: ISO C++ forbids comparison between pointer and integer [-fpermissive]
> if (pSlash != '\0') {
>
> Would be fixed by
> http://pkgs.fedoraproject.org/cgit/rpms/libmp4v2.git/tree/0004-Fix-GCC7-build.patch.
> J?rg, mp4v2 is your package, could you have a look? :-)
Still unfixed.
> > xtensa | nmap-7.60 | NOK | http://autobuild.buildroot.net/results/9e636919c98cd31b5067c8306d0e481a672434cf | ORPH
> > mips64el | nmap-7.60 | NOK | http://autobuild.buildroot.net/results/912561f505ad10d1eaa96dbe247d5838e9968e14 | ORPH
>
> xtensa-linux-g++.br_real: error: libssh2/lib/libssh2.a: No such file or directory
>
> Who volunteers to have a look?
Fixed by
https://git.buildroot.org/buildroot/commit/?id=302ab5ed258c366dfc3853954ef9ec20b22661ce.
> > mips64el | opencv-2.4.13.3 | NOK | http://autobuild.buildroot.net/results/b27d324331f6e351e95dd4742f4d0a50af60c590 |
> > mips64el | opencv-2.4.13.3 | NOK | http://autobuild.buildroot.net/results/44ed0be0bd94028b7b37e7bf21233adc1753d94b |
>
> CMake Error at cmake/OpenCVCompilerOptions.cmake:21 (else):
> A duplicate ELSE command was found inside an IF block.
> Call Stack (most recent call first):
> CMakeLists.txt:437 (include)
>
> Should be easy to fix. Samuel, do you think you will find some time to
> have a look at this?
Fixed by
https://git.buildroot.org/buildroot/commit/?id=dd609b38325d0b8949dcb6677b4e8ba020932b0c.
> > bfin | openobex-1.7.2 | NOK | http://autobuild.buildroot.net/results/78e033fe9f43845581a5d87b21a8451f67520e44 |
>
> /usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/build/openobex-1.7.2/lib/obex_transport_sock.c:(.text+0x5f6): undefined reference to `accept4'
>
> Not sure what's going on. accept4() not wired in Linux or uClibc for
> Blackfin? Something else? Waldemar, could you have a look?
Fixed by
https://git.buildroot.org/buildroot/commit/?id=93a86b4dec9e73fbe0e186cdde8fb04a36a44762.
But the issue will continue to pop up in the autobuilders until I
rebuild the toolchains. I'm waiting for -rc1 to be released to rebuild
all the toolchains.
> > arm | openssh-7.6p1 | NOK | http://autobuild.buildroot.net/results/3dcd2ab22b75bf27afd963d57e31df5e0bdedcaa | ORPH
> > arm | openssh-7.6p1 | NOK | http://autobuild.buildroot.net/results/8cc30818a400c7a392a3de787cabc9cd8425495f | ORPH
>
> getpagesize.c:(.text+0x0): multiple definition of `getpagesize'
> openbsd-compat//libopenbsd-compat.a(bsd-getpagesize.o):bsd-getpagesize.c:(.text+0x0): first defined here
>
> Would be fixed by http://patchwork.ozlabs.org/patch/832199/.
Fixed by
https://git.buildroot.org/buildroot/commit/?id=cc856401e8ac6a2c7a8767737b73dde933a5798a.
> > m68k | poppler-0.59.0 | NOK | http://autobuild.buildroot.net/results/c35599e6bf09aebe456ea959d7c238f82090fc62 |
>
> /usr/lfs/v0/rc-buildroot-test/scripts/instance-0/output/host/opt/ext-toolchain/m68k-buildroot-uclinux-uclibc/bin/ld.real: cannot find -lopenjp2
>
> Bernd, you recently bumped openjpeg. Could you have a look ?
Fixed by
https://git.buildroot.org/buildroot/commit/?id=84ec4f15ebbc3fb0691c7775766864c5a5039ff5
> > x86_64 | qt5declarative-5.9.2 | NOK | http://autobuild.buildroot.net/results/d9707cc2f47c6906b7e4872e185b7866301c3322 |
>
> logo.h:52:11: error: 'GLfloat' does not name a type
> const GLfloat *constData() const { return m_data.constData(); }
>
> Not sure what's going on. I don't see which package is the OpenGL
> provider. Peter (Seiderer), do you have an idea ?
Still unfixed.
> > arc | stress-ng-0.06.15 | NOK | http://autobuild.buildroot.net/results/296b14584c200593f88af75cdda65c4ca03cd863 |
>
> stress-fp-error.c: In function 'stress_fp_error':
> stress-fp-error.c:100:10: error: 'FE_INVALID' undeclared (first use in this function); did you mean 'EINVAL'?
> EDOM, FE_INVALID);
> ^~~~~~~~~~
>
> We already exclude nios2, we should probably exclude ARC as well.
> Alexey, do you confirm?
Alexey, I've disabled stress-ng on ARC. If you get to fix the <fenv.h>
support in glibc, we can re-enable it.
Fixed by
https://git.buildroot.org/buildroot/commit/?id=7a4fd532b7e5012b532c842639e3b82f751f0f7c.
> > m68k | tremor-19427 | TIM | http://autobuild.buildroot.net/results/5bff9fbd24264b3515a669d585e10ef23127d569 |
> > mipsel | tremor-19427 | TIM | http://autobuild.buildroot.net/results/d1c8e74477797b597c38186343e4d6c69b05560d |
>
> SVN repo is dead, and it locks up the build until we time out? Doesn't
> look great. Yann? :-)
Yann is investigating, but it only happens on Andr?'s autobuilder, so
we will need Andr?'s help.
> > microblazeel | usb_modeswitch-2.5.0 | NOK | http://autobuild.buildroot.net/results/20a9a75f701ce70c2ae434085a85ad8d34adc67b | ORPH
> > arm | usb_modeswitch-2.5.0 | NOK | http://autobuild.buildroot.net/results/46844b028989808aa7340c14af22f2855ec803d8 | ORPH
> >
>
> Not sure. Is it just:
>
>
> make[2]: *** [jim/libjim.a] Error 1
> make[2]: *** Waiting for unfinished jobs....
> usb_modeswitch.c: In function 'checkSuccess':
> usb_modeswitch.c:1579:7: warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized]
> if (i == CheckSuccess-1) {
>
> That makes the build fail?
Seems like it's related to jimtcl as well?
Overall, we had 57 build failures, we fixed 27 of them. Still 30 of
them need to be fixed!
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-10-31 22:05 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (5 preceding siblings ...)
2017-11-02 22:21 ` Thomas Petazzoni
@ 2017-11-02 22:22 ` Alexey Brodkin
2017-11-08 12:49 ` Johan Oudinet
7 siblings, 0 replies; 43+ messages in thread
From: Alexey Brodkin @ 2017-11-02 22:22 UTC (permalink / raw)
To: buildroot
Hi Thomas, all,
On Tue, 2017-10-31 at 23:05 +0100, Thomas Petazzoni wrote:
> Hello,
>
> Since Peter is about to release -rc1, it's time to restart with
> analyzing the build failures we have. And we have *lots* of them!
>
> Alexey, Yann, Adam, Peter (both Korsgaard and Seiderer?, Olivier,
> Matthew, Johan, Angelo, J?rg, Samuel, Waldemar, Bernd and Baruch: there
> are some questions/issues/topics for you below. Please read on! Thanks
> for your support!
>
> On Tue, 31 Oct 2017 08:00:13 +0100 (CET), Thomas Petazzoni wrote:
>
> >
> > ?????????arc |????????????argp-standalone-1.3 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_25e4ff4b
> > 8cecd88d56bd75fcdef64ad9affed959&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=hZO4_8arB3eZyrTFDhTVVi85JDCAAue
> > opOxxi907gBc&s=XUTmUXwkQXl7ItG7N1pAWJWWunjRW1a2hsS1Upv0lWE&e= | ORPH
> > ?????????arc |????????????argp-standalone-1.3 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_204d17c6
> > 39e8a38648dbc15c4abbc0c6fe23370a&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=hZO4_8arB3eZyrTFDhTVVi85JDCAAue
> > opOxxi907gBc&s=HL8z6zOQffOxiiX1czQjUU8pikqgfTMFgtIBq3G-ixQ&e= | ORPH
> > ?????????arc |????????????argp-standalone-1.3 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_2ac87b1e
> > a118366df4c816a13fa7cd02f8b10dc0&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=hZO4_8arB3eZyrTFDhTVVi85JDCAAue
> > opOxxi907gBc&s=yBmhKi6AYzEyuO-WaHu0fHqGmzlyJgl3KXWPCl0tsh0&e= | ORPH
> > ?????????arc |????????????argp-standalone-1.3 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_a8182305
> > 18d1197a9916019a955437fc3611ad33&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=hZO4_8arB3eZyrTFDhTVVi85JDCAAue
> > opOxxi907gBc&s=JMOmKsbn1vTp53Q5q39CsST6KFnNhkFauWdNkyVl_iw&e= | ORPH
> > ?????????arc |????????????argp-standalone-1.3 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_3663fc12
> > c6d5908ba496efdfaa1ba24ed39f0104&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=hZO4_8arB3eZyrTFDhTVVi85JDCAAue
> > opOxxi907gBc&s=iEcyGr6eFDZ-9hHPX7g1BcysNT5qDxuwBZy4gpsbJXo&e= | ORPH
> > ?????????arc |????????????argp-standalone-1.3 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_af51008c
> > dc92645adb20664aa7b3c64d9ed4691e&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=hZO4_8arB3eZyrTFDhTVVi85JDCAAue
> > opOxxi907gBc&s=9Uf-zfKhAegRJeyRtrWb3HUvc8dZ901Co6vHy-hwc28&e= | ORPH
> > ?????????arc |????????????argp-standalone-1.3 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_e033f008
> > b4731d41ec426884b45a591dda7adaf3&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=hZO4_8arB3eZyrTFDhTVVi85JDCAAue
> > opOxxi907gBc&s=K8H84AAU-DHT7MmwR1d5U_pvnGG-REgwVbGh-naaIYA&e= | ORPH
> > ?????????arc |????????????argp-standalone-1.3 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_1be95e26
> > fd18e9772e42b5e6cb1e93fbac9c1c8a&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=hZO4_8arB3eZyrTFDhTVVi85JDCAAue
> > opOxxi907gBc&s=Knq_fhDUA-YrWC4cXJVWJOOtgnFOgh6J6P2_F6INXi8&e= | ORPH
> > ?????????arc |????????????argp-standalone-1.3 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_c94d79b9
> > eaecdb36e0894ae0f965ae39cdb35386&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=hZO4_8arB3eZyrTFDhTVVi85JDCAAue
> > opOxxi907gBc&s=UQFmD5p76KTZkmOcBq7d36CJzAehnMuYfRSfnTF2PRk&e= | ORPH
> > ?????????arc |????????????argp-standalone-1.3 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_53359e0f
> > e1408f3816d3091b49462320239f39c1&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=hZO4_8arB3eZyrTFDhTVVi85JDCAAue
> > opOxxi907gBc&s=ZzDicS_Crt1xGsB8xZ3Z2tQcu4fKhMo2zqwUvPnwk50&e= | ORPH
>
> This is happening only on ARC. Why? Matt Weber proposed a patch,
> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_832397_&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO
> 7breS55ytWkhpk5R81I&m=hZO4_8arB3eZyrTFDhTVVi85JDCAAueopOxxi907gBc&s=rMdyDsEHNFQ-ca0a1D67Ic1kVPjq4-unagbYg0C6Mok&e=, but I am not terribly
> convinced because it doesn't explain why this problem happens only on
> ARC, and why it appeared suddenly.
>
> Alexey, could you have a look ?
I think this one should be resolved by now with
https://git.buildroot.net/buildroot/commit/?id=f0b65bd90ce4429d6b7e952ce7de2d5f92a2dd26
> >
> > ?????????arc |?????????????????busybox-1.27.2 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_2cb531b9
> > f9c75bb5dae10c02f2afeca225c65947&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=hZO4_8arB3eZyrTFDhTVVi85JDCAAue
> > opOxxi907gBc&s=Ir0fG31YiZk9D95bMFzGXx7Q2AKRAL-d-Hum3EtXl1s&e= | ORPH
>
>
> ? CC??????console-tools/setlogcons.o
> libbb/appletlib.c:206:8: error: 'NUM_APPLETS' undeclared (first use in this function); did you mean 'PF_APPLETALK'?
> ? max = NUM_APPLETS;
>
> What is going on here?!?
That's a strange one, so far I was not able to reproduce it locally,
but will look at it a bit more next week.
What's especially strange it was the one and only failure on "busybox" package
out of many others that completed successfully, see?http://autobuild.buildroot.net/?reason=busybox-1.27.2
So maybe just forget about it and see how it goes.
What do you think?
> >
> > ?????????arc |???????????????????ffmpeg-3.3.5 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_b8fd41b1
> > 27ab7702a2b69998076d737ea2e092b5&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=hZO4_8arB3eZyrTFDhTVVi85JDCAAue
> > opOxxi907gBc&s=irBg_ngSq1BL0E8H8ke9CcAZiMztKusLOzpZqmsGT6Q&e= |?????
> > ?????????arc |???????????????????ffmpeg-3.3.5 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_43c90fba
> > d3662101ef4eb5958f73700d1ff57b38&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=hZO4_8arB3eZyrTFDhTVVi85JDCAAue
> > opOxxi907gBc&s=BWFrdyvhvf4vtkT4icRZjJWRaRnRqXiZmQrZx3kSYhA&e= |?????
> > ?????????arc |???????????????????ffmpeg-3.3.5 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_a152a190
> > 108986392346efbba001b9dd0bdc89bc&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=hZO4_8arB3eZyrTFDhTVVi85JDCAAue
> > opOxxi907gBc&s=WXHFzHjT7t0qzy564h8rSXoRhdVBkW38VUWkLh5fOq4&e= |?????
> > ?????????arc |???????????????????ffmpeg-3.3.5 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_60d44246
> > fe6a54b02b53564761807204b9a190d0&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=hZO4_8arB3eZyrTFDhTVVi85JDCAAue
> > opOxxi907gBc&s=5NaYvqtFNK7_7r2I3FuyzrJnnAcXgOF78PFKW9RbNaw&e= |?????
>
> libavcodec/vp9dsp_template.c:1685:1: internal compiler error: Segmentation fault
>
> Alexey, could you have a look ?
This one should be fixed with arc-2017.09-release, see Eugeniy's patch here:
http://patchwork.ozlabs.org/patch/832948/
> >
> > ?????????arc |?????????????????????gpm-1.20.7 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_5a1404cf
> > 52c9547533a5b04c40d6118b43a07707&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=hZO4_8arB3eZyrTFDhTVVi85JDCAAue
> > opOxxi907gBc&s=Jv3gwPg1yH8fq_Iv8OfoLAiijUqkLUJHWh86gCTaceA&e= |?????
>
> gpm-root.c:(.text.startup+0x1aa): undefined reference to `__sigemptyset'
> gpm-root.c:(.text.startup+0x1aa): undefined reference to `__sigemptyset'
>
> This is with the new glibc ARC toolchain. Alexey ? :-)
Interesting, I'll look at it soonish.
> >
> > ?????????arc |???host-gdb-arc-2017.09-rc1-gdb | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_43eae264
> > 991aa369490236c7bd59c0b6a67fcf25&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=hZO4_8arB3eZyrTFDhTVVi85JDCAAue
> > opOxxi907gBc&s=Y89IzZE-HfAMONW-pw3Tpzx8pSDDRYJQO0GwD6tvGnU&e= | ORPH
>
> checking whether /usr/bin/g++ supports C++11 features with -h std=c++11... no
> configure: error: *** A compiler with support for C++11 language features is required.
> make[2]: *** [configure-gdb] Error 1
>
> The ARC special version needs:
>
> ????????depends on BR2_HOST_GCC_AT_LEAST_4_8
> ????????depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8
>
> Just like the gdb 8.0 version.
>
> Yann, perhaps you could have a look at this ?
Yann got this fixed, kudos to you man!
> > ? ? ? ? ?arc |????????????????????libidn-1.33 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_d3c3abf9
> > 966dd023923235c3879f521ba3a2daa5&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=hZO4_8arB3eZyrTFDhTVVi85JDCAAue
> > opOxxi907gBc&s=xapCcPSpcJeTqcB8nolmkeAJ46vcjscSHEYykCOVU_g&e= | ORPH
>
>
> strerror.c: In function 'rpl_strerror':
> strerror.c:44:21: warning: implicit declaration of function 'strerror_override'; did you mean 'strerror_r'? [-Wimplicit-function-declaration]
> ???const char *msg = strerror_override (n);
> ?????????????????????^~~~~~~~~~~~~~~~~
>
> This so far only happened on ARC, with uClibc. Alexey ?
I think we saw something similar, let me check what's going on there.
> > ?????????arc |??????????????stress-ng-0.06.15 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_296b1458
> > 4c200593f88af75cdda65c4ca03cd863&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=hZO4_8arB3eZyrTFDhTVVi85JDCAAue
> > opOxxi907gBc&s=Nq4o0HO39fDCbz8RLExATVcmn_x5cdJwIZZl5UqwMm4&e= |?????
>
> stress-fp-error.c: In function 'stress_fp_error':
> stress-fp-error.c:100:10: error: 'FE_INVALID' undeclared (first use in this function); did you mean 'EINVAL'?
> ????EDOM, FE_INVALID);
> ??????????^~~~~~~~~~
>
> We already exclude nios2, we should probably exclude ARC as well.
> Alexey, do you confirm?
>
> See:
>
> ????????# fenv.h lacks FE_INVALID, FE_OVERFLOW & FE_UNDERFLOW on nios2
> ????????depends on !BR2_nios2
Let me first see what is that and if something is really missing.
I mean why we don't have?FE_INVALID & friends defined.
-Alexey
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-02 22:21 ` Thomas Petazzoni
@ 2017-11-02 22:30 ` Alexey Brodkin
2017-11-03 11:17 ` Angelo Compagnucci
2017-11-04 22:18 ` Arnout Vandecappelle
2 siblings, 0 replies; 43+ messages in thread
From: Alexey Brodkin @ 2017-11-02 22:30 UTC (permalink / raw)
To: buildroot
Hi Thomas, all,
On Thu, 2017-11-02 at 23:21 +0100, Thomas Petazzoni wrote:
> Hello,
>
> Quick feedback on all the build issues.
>
> On Tue, 31 Oct 2017 23:05:19 +0100, Thomas Petazzoni wrote:
>
> >
> > On Tue, 31 Oct 2017 08:00:13 +0100 (CET), Thomas Petazzoni wrote:
> >
> > > ? ? ? ? ?arc |?????????????????busybox-1.27.2 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_2cb531
> > > b9f9c75bb5dae10c02f2afeca225c65947&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=SAoW0E6nimRIdKo5CmAKyfsXXQO
> > > z_SQmi2vzF0vzHlU&s=ZI69s1d8Fhd0U0CQ_OKm3nRZMN96MGVA18cf7tkNTqg&e= | ORPH??
> >
> >
> > ? CC??????console-tools/setlogcons.o
> > libbb/appletlib.c:206:8: error: 'NUM_APPLETS' undeclared (first use in this function); did you mean 'PF_APPLETALK'?
> > ? max = NUM_APPLETS;
> >
> > What is going on here?!?
>
> It still occurred only once,
> https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_-3Freason-3Dbusybox-2D1.27.2&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSS
> Ees0GFDDl656eViXO7breS55ytWkhpk5R81I&m=SAoW0E6nimRIdKo5CmAKyfsXXQOz_SQmi2vzF0vzHlU&s=wzUJlrejybSwFO6Qu3hTo_4dl74GCFzSh_RgSlNUAbY&e=. Not sure what
> this means.
As I just wrote let's not spend too much time on this one before we see more manifestations.
> > > ?????????arc |???????????????????ffmpeg-3.3.5 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-
> > > 3A__autobuild.buildroot.net_results_b8fd41b127ab7702a2b69998076d737ea2e092b5&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55
> > > ytWkhpk5R81I&m=SAoW0E6nimRIdKo5CmAKyfsXXQOz_SQmi2vzF0vzHlU&s=id9_4gCi8sNYG1DOhijn81A1Q54eebDnpM1PyF0n3RQ&e= |?????
> > > ?????????arc |???????????????????ffmpeg-3.3.5 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_43c90f
> > > bad3662101ef4eb5958f73700d1ff57b38&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=SAoW0E6nimRIdKo5CmAKyfsXXQO
> > > z_SQmi2vzF0vzHlU&s=jQSJNcBcuOTAEj4CB77TeJherexKlUNtXrlf6NAS4MU&e= |?????
> > > ?????????arc |???????????????????ffmpeg-3.3.5 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_a152a1
> > > 90108986392346efbba001b9dd0bdc89bc&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=SAoW0E6nimRIdKo5CmAKyfsXXQO
> > > z_SQmi2vzF0vzHlU&s=KF6aCgUc-UaJozlh0VzdCWa7_6K5deiQzaatTTvXPs8&e= |?????
> > > ?????????arc |???????????????????ffmpeg-3.3.5 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_60d442
> > > 46fe6a54b02b53564761807204b9a190d0&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=SAoW0E6nimRIdKo5CmAKyfsXXQO
> > > z_SQmi2vzF0vzHlU&s=F9ANvupxEY3G1UFbyoeVY8IN30fn5d92A8cRAsN1d6I&e= |???????
> >
> > libavcodec/vp9dsp_template.c:1685:1: internal compiler error: Segmentation fault
> >
> > Alexey, could you have a look ?
>
> Alexey, this continues to happen:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_-3Freason-3Dffmpeg-2D3.3.5&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEe
> s0GFDDl656eViXO7breS55ytWkhpk5R81I&m=SAoW0E6nimRIdKo5CmAKyfsXXQOz_SQmi2vzF0vzHlU&s=3_daceeHk2UEFoExTryReYH8JdlkdARTaxBDDQVNuf4&e=. Should we disable
> this package on ARC ?
Please not disable ffmpeg for ARC :)
The fix is in ARC tools update [the one to the final release].
> > > ?????????arc |??????????????stress-ng-0.06.15 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_296b14
> > > 584c200593f88af75cdda65c4ca03cd863&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=SAoW0E6nimRIdKo5CmAKyfsXXQO
> > > z_SQmi2vzF0vzHlU&s=TMAIAi0joOmhtuYC0EOziiVpJPEqM-9kDTxX6WI40Io&e= |???????
> >
> > stress-fp-error.c: In function 'stress_fp_error':
> > stress-fp-error.c:100:10: error: 'FE_INVALID' undeclared (first use in this function); did you mean 'EINVAL'?
> > ????EDOM, FE_INVALID);
> > ??????????^~~~~~~~~~
> >
> > We already exclude nios2, we should probably exclude ARC as well.
> > Alexey, do you confirm?
>
> Alexey, I've disabled stress-ng on ARC. If you get to fix the <fenv.h>
> support in glibc, we can re-enable it.
Sure, sounds like a plan!
So it looks like so far we don't have any critical failures for ARC and
the only thing to look at is "stress-ng".
Thanks for all the help with fixing our issues!
-Alexey
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-02 22:21 ` Thomas Petazzoni
2017-11-02 22:30 ` Alexey Brodkin
@ 2017-11-03 11:17 ` Angelo Compagnucci
2017-11-03 13:38 ` Thomas Petazzoni
2017-11-04 22:18 ` Arnout Vandecappelle
2 siblings, 1 reply; 43+ messages in thread
From: Angelo Compagnucci @ 2017-11-03 11:17 UTC (permalink / raw)
To: buildroot
>
>>
>> > arm | host-mono-5.2.0.224 | NOK | http://autobuild.buildroot.net/results/51dcf8908157393a09ce772e6099e73fd0cd0ba2 |
>>
>> Unhandled Exception:
>> System.ExecutionEngineException: System.NullReferenceException: Object reference not set to an instance of an object ---> System.NullReferenceException: Object reference not set to an instance of an object
>>
>> Angelo, could you have a look ?
>
> Still unfixed.
Unfortunately I cannot reproduce the problem. Could be something
transient? It has not crashed anymore in the last few days.
I'm preparing the bump of the package btw.
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-03 11:17 ` Angelo Compagnucci
@ 2017-11-03 13:38 ` Thomas Petazzoni
2017-11-03 13:46 ` Angelo Compagnucci
0 siblings, 1 reply; 43+ messages in thread
From: Thomas Petazzoni @ 2017-11-03 13:38 UTC (permalink / raw)
To: buildroot
Hello,
On Fri, 3 Nov 2017 12:17:37 +0100, Angelo Compagnucci wrote:
> >> Unhandled Exception:
> >> System.ExecutionEngineException: System.NullReferenceException: Object reference not set to an instance of an object ---> System.NullReferenceException: Object reference not set to an instance of an object
> >>
> >> Angelo, could you have a look ?
> >
> > Still unfixed.
>
> Unfortunately I cannot reproduce the problem. Could be something
> transient? It has not crashed anymore in the last few days.
No, it's not a transient issue, as I've been able to reproduce a
similar (but not identical) crash. The thing is that it fails when
building on a ppc64le machine (the gcc112 autobuilder instance). I just
reproduced it:
Unhandled Exception:
System.ExecutionEngineException: System.IndexOutOfRangeException: Index was outside the bounds of the array. ---> System.IndexOutOfRangeException: Index was outside the bounds of the array.
--- End of inner exception stack trace ---
[...]
So it seems like host-mono doesn't build on a ppc64le machine. Looking
at the host-monolite tarball, I see it's a bunch of .dll built for x86.
Is this supposed to work on other architectures as well?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-03 13:38 ` Thomas Petazzoni
@ 2017-11-03 13:46 ` Angelo Compagnucci
2017-11-03 13:52 ` Thomas Petazzoni
0 siblings, 1 reply; 43+ messages in thread
From: Angelo Compagnucci @ 2017-11-03 13:46 UTC (permalink / raw)
To: buildroot
Hello,
2017-11-03 14:38 GMT+01:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Hello,
>
> On Fri, 3 Nov 2017 12:17:37 +0100, Angelo Compagnucci wrote:
>
>> >> Unhandled Exception:
>> >> System.ExecutionEngineException: System.NullReferenceException: Object reference not set to an instance of an object ---> System.NullReferenceException: Object reference not set to an instance of an object
>> >>
>> >> Angelo, could you have a look ?
>> >
>> > Still unfixed.
>>
>> Unfortunately I cannot reproduce the problem. Could be something
>> transient? It has not crashed anymore in the last few days.
>
> No, it's not a transient issue, as I've been able to reproduce a
> similar (but not identical) crash. The thing is that it fails when
> building on a ppc64le machine (the gcc112 autobuilder instance). I just
> reproduced it:
>
> Unhandled Exception:
> System.ExecutionEngineException: System.IndexOutOfRangeException: Index was outside the bounds of the array. ---> System.IndexOutOfRangeException: Index was outside the bounds of the array.
> --- End of inner exception stack trace ---
> [...]
This is really strange. This error means that the code inside a mono
vm running program is failing, so mono is running correctly!
>
> So it seems like host-mono doesn't build on a ppc64le machine. Looking
> at the host-monolite tarball, I see it's a bunch of .dll built for x86.
> Is this supposed to work on other architectures as well?
Yes it is. host-mono it's used to bootstrap the mono compilation for
the target so it must run on the host architecture.
IMHO seems like something related to memory, mono changed so much in
the latests releases and it uses much more memory during the
compilation. I cannot reproduce the bug on my setup with 16GB of RAM
and the config that fails on the autobuilder.
Could you give me the config you are using?
Thanks!
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Profile: http://it.linkedin.com/in/compagnucciangelo
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-03 13:46 ` Angelo Compagnucci
@ 2017-11-03 13:52 ` Thomas Petazzoni
2017-11-03 14:18 ` Angelo Compagnucci
0 siblings, 1 reply; 43+ messages in thread
From: Thomas Petazzoni @ 2017-11-03 13:52 UTC (permalink / raw)
To: buildroot
Hello,
On Fri, 3 Nov 2017 14:46:15 +0100, Angelo Compagnucci wrote:
> > Unhandled Exception:
> > System.ExecutionEngineException: System.IndexOutOfRangeException: Index was outside the bounds of the array. ---> System.IndexOutOfRangeException: Index was outside the bounds of the array.
> > --- End of inner exception stack trace ---
> > [...]
>
> This is really strange. This error means that the code inside a mono
> vm running program is failing, so mono is running correctly!
>
> >
> > So it seems like host-mono doesn't build on a ppc64le machine. Looking
> > at the host-monolite tarball, I see it's a bunch of .dll built for x86.
> > Is this supposed to work on other architectures as well?
>
> Yes it is. host-mono it's used to bootstrap the mono compilation for
> the target so it must run on the host architecture.
I don't follow you here.
gcc112 is a ppc64le machine, and I'm cross-compiling for ARM.
Is it possible for those x86 .dll provided by monolite to be used on a
ppc64le machine ?
> IMHO seems like something related to memory, mono changed so much in
> the latests releases and it uses much more memory during the
> compilation. I cannot reproduce the bug on my setup with 16GB of RAM
> and the config that fails on the autobuilder.
The ppc64le machine that causes the failure has 256GB of RAM.
> Could you give me the config you are using?
It's just:
BR2_arm=y
BR2_PACKAGE_MONO=y
But you won't be able to reproduce the problem on your PC, because your
PC is x86-64, and the build failure seems to be specific to building on
ppc64le.
Do you have an account on the gcc compile farm ?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-03 13:52 ` Thomas Petazzoni
@ 2017-11-03 14:18 ` Angelo Compagnucci
2017-11-03 14:28 ` Thomas Petazzoni
0 siblings, 1 reply; 43+ messages in thread
From: Angelo Compagnucci @ 2017-11-03 14:18 UTC (permalink / raw)
To: buildroot
Dear Thomas Petazzoni,
2017-11-03 14:52 GMT+01:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Hello,
>
> On Fri, 3 Nov 2017 14:46:15 +0100, Angelo Compagnucci wrote:
>
>> > Unhandled Exception:
>> > System.ExecutionEngineException: System.IndexOutOfRangeException: Index was outside the bounds of the array. ---> System.IndexOutOfRangeException: Index was outside the bounds of the array.
>> > --- End of inner exception stack trace ---
>> > [...]
>>
>> This is really strange. This error means that the code inside a mono
>> vm running program is failing, so mono is running correctly!
>>
>> >
>> > So it seems like host-mono doesn't build on a ppc64le machine. Looking
>> > at the host-monolite tarball, I see it's a bunch of .dll built for x86.
>> > Is this supposed to work on other architectures as well?
>>
>> Yes it is. host-mono it's used to bootstrap the mono compilation for
>> the target so it must run on the host architecture.
>
> I don't follow you here.
>
> gcc112 is a ppc64le machine, and I'm cross-compiling for ARM.
>
> Is it possible for those x86 .dll provided by monolite to be used on a
> ppc64le machine ?
Sorry for not having proof reading your initial message, I was not
aware buildroot was running on a ppc64le machine.
In theory, monolite is target agnostic cause is a subset of mono
libraries needed to compile the rest. Alse the main executable is
written in mono (mcs.exe).
The file command erroneously reports that the dlls are for windows
(probably deducing it from the dll extension) but are indeed dll for
the mono runtime.
So in theory it should work.
At least, it is working, cause the message you receive is from a
running mono runtime. The problem is probably elsewhere.
>> IMHO seems like something related to memory, mono changed so much in
>> the latests releases and it uses much more memory during the
>> compilation. I cannot reproduce the bug on my setup with 16GB of RAM
>> and the config that fails on the autobuilder.
>
> The ppc64le machine that causes the failure has 256GB of RAM.
>
>> Could you give me the config you are using?
>
> It's just:
>
> BR2_arm=y
> BR2_PACKAGE_MONO=y
>
> But you won't be able to reproduce the problem on your PC, because your
> PC is x86-64, and the build failure seems to be specific to building on
> ppc64le.
>
> Do you have an account on the gcc compile farm ?
Of course no. I don't think I can help here. If the problem persists,
probably the best way is to disable mono when the host is ppc64le.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Profile: http://it.linkedin.com/in/compagnucciangelo
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-03 14:18 ` Angelo Compagnucci
@ 2017-11-03 14:28 ` Thomas Petazzoni
2017-11-03 14:35 ` Angelo Compagnucci
0 siblings, 1 reply; 43+ messages in thread
From: Thomas Petazzoni @ 2017-11-03 14:28 UTC (permalink / raw)
To: buildroot
Hello,
On Fri, 3 Nov 2017 15:18:24 +0100, Angelo Compagnucci wrote:
> > But you won't be able to reproduce the problem on your PC, because your
> > PC is x86-64, and the build failure seems to be specific to building on
> > ppc64le.
> >
> > Do you have an account on the gcc compile farm ?
>
> Of course no.
You could ask for one, see https://cfarm.tetaneutral.net/users/new/.
> I don't think I can help here. If the problem persists,
> probably the best way is to disable mono when the host is ppc64le.
Which host platforms does mono support? Should we enable it only for
x86/x86-64 build machines?
Do you think you could report this issue upstream?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-03 14:28 ` Thomas Petazzoni
@ 2017-11-03 14:35 ` Angelo Compagnucci
2017-11-03 14:41 ` Thomas Petazzoni
0 siblings, 1 reply; 43+ messages in thread
From: Angelo Compagnucci @ 2017-11-03 14:35 UTC (permalink / raw)
To: buildroot
Dear Thomas Petazzoni,
2017-11-03 15:28 GMT+01:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Hello,
>
> On Fri, 3 Nov 2017 15:18:24 +0100, Angelo Compagnucci wrote:
>
>> > But you won't be able to reproduce the problem on your PC, because your
>> > PC is x86-64, and the build failure seems to be specific to building on
>> > ppc64le.
>> >
>> > Do you have an account on the gcc compile farm ?
>>
>> Of course no.
>
> You could ask for one, see https://cfarm.tetaneutral.net/users/new/.
Wonderful! I'll do in minutes!
>
>> I don't think I can help here. If the problem persists,
>> probably the best way is to disable mono when the host is ppc64le.
>
> Which host platforms does mono support? Should we enable it only for
> x86/x86-64 build machines?
Mono supports PPC architectures at least stating to the documentation [1]
> Do you think you could report this issue upstream?
I don't think this should be reported as a bug. Mono is running while
that error happens, so the problem is somewhere in a library or
similar.
I'll investigate more when the account on the farm will be enabled.
I'm just sending a mono bump upstream and hopefully the new version
will solve the problem. Do you think I'm late?
Sincerely, Angelo
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
[1] http://www.mono-project.com/docs/about-mono/supported-platforms/
--
Profile: http://it.linkedin.com/in/compagnucciangelo
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-03 14:35 ` Angelo Compagnucci
@ 2017-11-03 14:41 ` Thomas Petazzoni
0 siblings, 0 replies; 43+ messages in thread
From: Thomas Petazzoni @ 2017-11-03 14:41 UTC (permalink / raw)
To: buildroot
Hello,
On Fri, 3 Nov 2017 15:35:14 +0100, Angelo Compagnucci wrote:
> > You could ask for one, see https://cfarm.tetaneutral.net/users/new/.
>
> Wonderful! I'll do in minutes!
Good :)
Once your account is enabled, log in to gcc112, and build my two lines
defconfig, and you'll see the problem :)
> > Do you think you could report this issue upstream?
>
> I don't think this should be reported as a bug. Mono is running while
> that error happens, so the problem is somewhere in a library or
> similar.
> I'll investigate more when the account on the farm will be enabled.
>
> I'm just sending a mono bump upstream and hopefully the new version
> will solve the problem. Do you think I'm late?
Yes, you're late, as we're in November, so -rc1 should have already
been released. But since Peter only intends to release -rc1 this
week-end, it's still OK to merge some version bumps. But hurry up,
tomorrow might be too late! :-)
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-02 10:54 ` Peter Korsgaard
@ 2017-11-03 22:31 ` Peter Korsgaard
0 siblings, 0 replies; 43+ messages in thread
From: Peter Korsgaard @ 2017-11-03 22:31 UTC (permalink / raw)
To: buildroot
>>>>> "Peter" == Peter Korsgaard <peter@korsgaard.com> writes:
>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:
> Hi,
>> make[2]: *** [jim/libjim.a] Error 1
>> make[2]: *** Waiting for unfinished jobs....
>>> Baruch, you are the last person who bumped this package, could you have a look?
>> The autobuilder indicates[1] that it only fails on Peter's gcc112 Powerpc
>> host. Debugging this requires access to a Powerpc host.
> You can request an account on the cfarm machines here:
> https://cfarm.tetaneutral.net/users/new/
> But I have just started a manual build on gcc112 to debug what the issue
> is.
It was because jimtcl used an old config.guess without ppc64le support
and we weren't passing the correct --host / --build arguments. I've send
a patch series fixing this:
https://patchwork.ozlabs.org/project/buildroot/list/?series=11854
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-02 22:21 ` Thomas Petazzoni
2017-11-02 22:30 ` Alexey Brodkin
2017-11-03 11:17 ` Angelo Compagnucci
@ 2017-11-04 22:18 ` Arnout Vandecappelle
2017-11-04 22:20 ` Thomas Petazzoni
2017-11-09 20:58 ` Alexey Brodkin
2 siblings, 2 replies; 43+ messages in thread
From: Arnout Vandecappelle @ 2017-11-04 22:18 UTC (permalink / raw)
To: buildroot
On 02-11-17 23:21, Thomas Petazzoni wrote:
>>> xtensa | gstreamer-0.10.36 | NOK | http://autobuild.buildroot.net/results/bb0a52f08ce07b3aa7301e69e9be12f3e45f45b2 | ORPH
>>> arm | gstreamer-0.10.36 | NOK | http://autobuild.buildroot.net/results/0b6feb96ba877cb4f3b8c6a05c977a1c12805fac | ORPH
>>> arm | gstreamer-0.10.36 | NOK | http://autobuild.buildroot.net/results/daa93d58840c77c980d040e2b740555dc3b36951 | ORPH
>>
>> /home/buildroot/autobuild/run/instance-3/output/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libgobject-2.0.a(libgobject_2_0_la-gmarshal.o): In function `g_cclosure_marshal_VOID__VOID':
>> gmarshal.c:(.text+0x0): multiple definition of `g_cclosure_marshal_VOID__VOID'
>> ../gst/.libs/libgstreamer-0.10.a(libgstreamer_0.10_la-gstmarshal.o):/home/buildroot/autobuild/run/instance-3/output/build/gstreamer-0.10.36/gst/gstmarshal.c:60: first defined here
>>
>> Static linking issue. Who volunteers to have a look? We don't even have
>> a person listed in the DEVELOPERS file for gstreamer.
> Still unfixed. Anyone?
I don't think anybody is motivated to maintain the now severely deprecated
gstreamer0.10. maybe it's time to remove it? Or at
least, we could remove it from static.
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] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-04 22:18 ` Arnout Vandecappelle
@ 2017-11-04 22:20 ` Thomas Petazzoni
2017-11-04 22:36 ` Peter Korsgaard
2017-11-09 20:58 ` Alexey Brodkin
1 sibling, 1 reply; 43+ messages in thread
From: Thomas Petazzoni @ 2017-11-04 22:20 UTC (permalink / raw)
To: buildroot
Hello,
On Sat, 4 Nov 2017 23:18:52 +0100, Arnout Vandecappelle wrote:
> >> Static linking issue. Who volunteers to have a look? We don't even have
> >> a person listed in the DEVELOPERS file for gstreamer.
> > Still unfixed. Anyone?
>
> I don't think anybody is motivated to maintain the now severely deprecated
> gstreamer0.10. maybe it's time to remove it? Or at
> least, we could remove it from static.
I wouldn't mind removing it.
Peter? Your call?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-04 22:20 ` Thomas Petazzoni
@ 2017-11-04 22:36 ` Peter Korsgaard
2017-11-05 14:40 ` Thomas Petazzoni
0 siblings, 1 reply; 43+ messages in thread
From: Peter Korsgaard @ 2017-11-04 22:36 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> Hello,
> On Sat, 4 Nov 2017 23:18:52 +0100, Arnout Vandecappelle wrote:
>> >> Static linking issue. Who volunteers to have a look? We don't even have
>> >> a person listed in the DEVELOPERS file for gstreamer.
>> > Still unfixed. Anyone?
>>
>> I don't think anybody is motivated to maintain the now severely deprecated
>> gstreamer0.10. maybe it's time to remove it? Or at
>> least, we could remove it from static.
> I wouldn't mind removing it.
> Peter? Your call?
If the only thing broken about it is static linking then I think I would
prefer to just mark it as !static for now.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-04 22:36 ` Peter Korsgaard
@ 2017-11-05 14:40 ` Thomas Petazzoni
2017-11-05 19:36 ` Peter Korsgaard
0 siblings, 1 reply; 43+ messages in thread
From: Thomas Petazzoni @ 2017-11-05 14:40 UTC (permalink / raw)
To: buildroot
Hello,
On Sat, 04 Nov 2017 23:36:19 +0100, Peter Korsgaard wrote:
> > I wouldn't mind removing it.
>
> > Peter? Your call?
>
> If the only thing broken about it is static linking then I think I would
> prefer to just mark it as !static for now.
There are only a few packages that select BR2_PACKAGE_GSTREAMER, so it
should be quite easy to do.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-05 14:40 ` Thomas Petazzoni
@ 2017-11-05 19:36 ` Peter Korsgaard
2017-11-05 22:35 ` Thomas Petazzoni
0 siblings, 1 reply; 43+ messages in thread
From: Peter Korsgaard @ 2017-11-05 19:36 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> Hello,
> On Sat, 04 Nov 2017 23:36:19 +0100, Peter Korsgaard wrote:
>> > I wouldn't mind removing it.
>>
>> > Peter? Your call?
>>
>> If the only thing broken about it is static linking then I think I would
>> prefer to just mark it as !static for now.
> There are only a few packages that select BR2_PACKAGE_GSTREAMER, so it
> should be quite easy to do.
Great - Will you send patches for it or do you want me to handle it?
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-05 19:36 ` Peter Korsgaard
@ 2017-11-05 22:35 ` Thomas Petazzoni
0 siblings, 0 replies; 43+ messages in thread
From: Thomas Petazzoni @ 2017-11-05 22:35 UTC (permalink / raw)
To: buildroot
Hello,
On Sun, 05 Nov 2017 20:36:24 +0100, Peter Korsgaard wrote:
> > There are only a few packages that select BR2_PACKAGE_GSTREAMER, so it
> > should be quite easy to do.
>
> Great - Will you send patches for it or do you want me to handle it?
I see Arnout already sent the patch :)
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-10-31 22:05 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (6 preceding siblings ...)
2017-11-02 22:22 ` Alexey Brodkin
@ 2017-11-08 12:49 ` Johan Oudinet
2017-11-08 16:16 ` Matthew Weber
7 siblings, 1 reply; 43+ messages in thread
From: Johan Oudinet @ 2017-11-08 12:49 UTC (permalink / raw)
To: buildroot
Hi Thomas, all,
On Tue, Oct 31, 2017 at 11:05 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
>> arm | host-erlang-rebar-2.6.4 | TIM | http://autobuild.buildroot.net/results/6c4c7b3094bd48a72786f5be3d760f0356557403 |
>> arm | host-erlang-rebar-2.6.4 | TIM | http://autobuild.buildroot.net/results/a17d5eb1aac01dab19412aa28d523625577730db |
>
> The infamous ./bootstrap issue that consumes 100% of the CPU before
> timing out the build job. Johan, we really need to find a solution to
> this problem. How can we proceed to debug this?
>
The bootstrap file is an erlang script:
#!/usr/bin/env escript
When trying to reproduce this bug, I see it prints "No beam files
found". As this message is printed quite early in this script, I guess
the problem is in loading escript from the host. Unfortunately, I
wasn't able to reproduce this bug on my machine, so this is only a
guess.
Is it possible to execute ./bootstrap --help from this machine? If the
problem is in loading escript, it should lead to the same timeout
error.
By the way, it looks like rebar build tool is moving to rebar3. I'm
afraid we may have to support both until all erlang projects have
moved to rebar3 :-(
--
Johan
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-08 12:49 ` Johan Oudinet
@ 2017-11-08 16:16 ` Matthew Weber
2017-11-08 17:33 ` Yann E. MORIN
0 siblings, 1 reply; 43+ messages in thread
From: Matthew Weber @ 2017-11-08 16:16 UTC (permalink / raw)
To: buildroot
Johan,
On Wed, Nov 8, 2017 at 6:49 AM, Johan Oudinet <johan.oudinet@gmail.com> wrote:
> Hi Thomas, all,
>
> On Tue, Oct 31, 2017 at 11:05 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>>
>>> arm | host-erlang-rebar-2.6.4 | TIM | http://autobuild.buildroot.net/results/6c4c7b3094bd48a72786f5be3d760f0356557403 |
>>> arm | host-erlang-rebar-2.6.4 | TIM | http://autobuild.buildroot.net/results/a17d5eb1aac01dab19412aa28d523625577730db |
>>
>> The infamous ./bootstrap issue that consumes 100% of the CPU before
>> timing out the build job. Johan, we really need to find a solution to
>> this problem. How can we proceed to debug this?
>>
>
> The bootstrap file is an erlang script:
> #!/usr/bin/env escript
>
> When trying to reproduce this bug, I see it prints "No beam files
> found". As this message is printed quite early in this script, I guess
> the problem is in loading escript from the host. Unfortunately, I
> wasn't able to reproduce this bug on my machine, so this is only a
> guess.
> Is it possible to execute ./bootstrap --help from this machine? If the
> problem is in loading escript, it should lead to the same timeout
> error.
>
I ran the same build on that machine ( make clean host-erlang-rebar ).
It ran without error and printed the following early in the build
step.
make[1]: Entering directory
`/usr/lfs/v0/rc-buildroot/output/build/host-erlang-rebar-2.6.4'
./bootstrap
No beam files found.
Recompile: src/rebar
Recompile: src/rebar_abnfc_compiler
As a note, that machine doesn't have escript, ie I go into the
host-erlang-rebar folder and if I run the bootstrap --help I get a
escript error (which is expected).
./bootstrap --help
/usr/bin/env: escript: No such file or directory
I'll run the complete build a few times and see if anything pops up.
Matt
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-08 16:16 ` Matthew Weber
@ 2017-11-08 17:33 ` Yann E. MORIN
2017-11-08 19:35 ` Matthew Weber
0 siblings, 1 reply; 43+ messages in thread
From: Yann E. MORIN @ 2017-11-08 17:33 UTC (permalink / raw)
To: buildroot
Matthew, Johan, All,
On 2017-11-08 10:16 -0600, Matthew Weber spake thusly:
> On Wed, Nov 8, 2017 at 6:49 AM, Johan Oudinet <johan.oudinet@gmail.com> wrote:
> > Hi Thomas, all,
> >
> > On Tue, Oct 31, 2017 at 11:05 PM, Thomas Petazzoni
> > <thomas.petazzoni@free-electrons.com> wrote:
> >>
> >>> arm | host-erlang-rebar-2.6.4 | TIM | http://autobuild.buildroot.net/results/6c4c7b3094bd48a72786f5be3d760f0356557403 |
> >>> arm | host-erlang-rebar-2.6.4 | TIM | http://autobuild.buildroot.net/results/a17d5eb1aac01dab19412aa28d523625577730db |
> >>
> >> The infamous ./bootstrap issue that consumes 100% of the CPU before
> >> timing out the build job. Johan, we really need to find a solution to
> >> this problem. How can we proceed to debug this?
> >>
> >
> > The bootstrap file is an erlang script:
> > #!/usr/bin/env escript
> >
> > When trying to reproduce this bug, I see it prints "No beam files
> > found". As this message is printed quite early in this script, I guess
> > the problem is in loading escript from the host. Unfortunately, I
> > wasn't able to reproduce this bug on my machine, so this is only a
> > guess.
> > Is it possible to execute ./bootstrap --help from this machine? If the
> > problem is in loading escript, it should lead to the same timeout
> > error.
> >
>
> I ran the same build on that machine ( make clean host-erlang-rebar ).
> It ran without error and printed the following early in the build
> step.
We've already concluded that this error does not always happen,
unfortunately. IIRC, it however happenned on almost all the
autobuilders, so it probably is not related to the host machine.
Thomas and I tried to reproduce on our respective autobuilders, to no
avail... IIRC, I even had a loop that ran more than 100 times.
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] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-08 17:33 ` Yann E. MORIN
@ 2017-11-08 19:35 ` Matthew Weber
0 siblings, 0 replies; 43+ messages in thread
From: Matthew Weber @ 2017-11-08 19:35 UTC (permalink / raw)
To: buildroot
Yann,
On Wed, Nov 8, 2017 at 11:33 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Matthew, Johan, All,
>
> On 2017-11-08 10:16 -0600, Matthew Weber spake thusly:
>> On Wed, Nov 8, 2017 at 6:49 AM, Johan Oudinet <johan.oudinet@gmail.com> wrote:
>> > Hi Thomas, all,
>> >
>> > On Tue, Oct 31, 2017 at 11:05 PM, Thomas Petazzoni
<snip>
>
> We've already concluded that this error does not always happen,
> unfortunately. IIRC, it however happenned on almost all the
> autobuilders, so it probably is not related to the host machine.
>
> Thomas and I tried to reproduce on our respective autobuilders, to no
> avail... IIRC, I even had a loop that ran more than 100 times.
I started a loop this morning. I'll probably kill it then at this point.
Matt
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] Analysis of build results for 2017-10-30
2017-11-04 22:18 ` Arnout Vandecappelle
2017-11-04 22:20 ` Thomas Petazzoni
@ 2017-11-09 20:58 ` Alexey Brodkin
1 sibling, 0 replies; 43+ messages in thread
From: Alexey Brodkin @ 2017-11-09 20:58 UTC (permalink / raw)
To: buildroot
Hi Arnout, all,
On Sat, 2017-11-04 at 23:18 +0100, Arnout Vandecappelle wrote:
>
> On 02-11-17 23:21, Thomas Petazzoni wrote:
> >
> > >
> > > >
> > > > ??????xtensa |??????????????gstreamer-0.10.36 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_bb0a
> > > > 52f08ce07b3aa7301e69e9be12f3e45f45b2&d=DwICaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=bxm7ZLS5r81sWj9rWEsiJn_
> > > > rSsv1Mfe5T84KNX1CRG0&s=wgLWUJPnpM3-vhJwsAf9C1kw-28fPmiLgwernFG53Os&e= | ORPH
> > > > ?????????arm |??????????????gstreamer-0.10.36 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_0b6f
> > > > eb96ba877cb4f3b8c6a05c977a1c12805fac&d=DwICaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=bxm7ZLS5r81sWj9rWEsiJn_
> > > > rSsv1Mfe5T84KNX1CRG0&s=HLGKmbzIk0bAWu_92_b8Rzw06K63PBIq9aCMXbh_F4A&e= | ORPH
> > > > ?????????arm |??????????????gstreamer-0.10.36 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_daa9
> > > > 3d58840c77c980d040e2b740555dc3b36951&d=DwICaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=bxm7ZLS5r81sWj9rWEsiJn_
> > > > rSsv1Mfe5T84KNX1CRG0&s=Lo_r127mCwwF8YBowPsNYpatJV0gawzbjO5Og7OWBds&e= | ORPH??
> > >
> > > /home/buildroot/autobuild/run/instance-3/output/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libgobject-2.0.a(libgobject_2_0_la-
> > > gmarshal.o): In function `g_cclosure_marshal_VOID__VOID':
> > > gmarshal.c:(.text+0x0): multiple definition of `g_cclosure_marshal_VOID__VOID'
> > > ../gst/.libs/libgstreamer-0.10.a(libgstreamer_0.10_la-gstmarshal.o):/home/buildroot/autobuild/run/instance-3/output/build/gstreamer-
> > > 0.10.36/gst/gstmarshal.c:60: first defined here
> > >
> > > Static linking issue. Who volunteers to have a look? We don't even have
> > > a person listed in the DEVELOPERS file for gstreamer.
> > Still unfixed. Anyone?
>
> ?I don't think anybody is motivated to maintain the now severely deprecated
> gstreamer0.10. maybe it's time to remove it? Or at
> least, we could remove it from static.
I remember gstreamer-0.10 was used in some of our internal projects so
I'd prefer to keep it in Buildroot, though I don't care about static builds
so OK with removal of it from static builds.
-Alexey
^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2017-11-09 20:58 UTC | newest]
Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-31 7:00 [Buildroot] [autobuild.buildroot.net] Build results for 2017-10-30 Thomas Petazzoni
2017-10-31 22:05 ` [Buildroot] Analysis of build " Thomas Petazzoni
2017-11-01 2:37 ` Matthew Weber
2017-11-01 9:45 ` Thomas Petazzoni
2017-11-01 10:01 ` Alexey Brodkin
2017-11-01 10:24 ` Thomas Petazzoni
2017-11-01 10:31 ` Alexey Brodkin
2017-11-02 2:31 ` Waldemar Brodkorb
2017-11-02 8:06 ` Thomas Petazzoni
2017-11-01 13:24 ` Matthew Weber
2017-11-01 13:37 ` Thomas Petazzoni
2017-11-01 10:17 ` Samuel Martin
2017-11-01 13:40 ` Thomas Petazzoni
2017-11-01 18:03 ` Baruch Siach
2017-11-02 10:54 ` Peter Korsgaard
2017-11-03 22:31 ` Peter Korsgaard
2017-11-02 10:46 ` Peter Korsgaard
2017-11-02 17:43 ` Yann E. MORIN
2017-11-02 18:08 ` Yann E. MORIN
2017-11-02 20:04 ` Thomas Petazzoni
2017-11-02 20:55 ` Yann E. MORIN
2017-11-02 22:21 ` Thomas Petazzoni
2017-11-02 22:30 ` Alexey Brodkin
2017-11-03 11:17 ` Angelo Compagnucci
2017-11-03 13:38 ` Thomas Petazzoni
2017-11-03 13:46 ` Angelo Compagnucci
2017-11-03 13:52 ` Thomas Petazzoni
2017-11-03 14:18 ` Angelo Compagnucci
2017-11-03 14:28 ` Thomas Petazzoni
2017-11-03 14:35 ` Angelo Compagnucci
2017-11-03 14:41 ` Thomas Petazzoni
2017-11-04 22:18 ` Arnout Vandecappelle
2017-11-04 22:20 ` Thomas Petazzoni
2017-11-04 22:36 ` Peter Korsgaard
2017-11-05 14:40 ` Thomas Petazzoni
2017-11-05 19:36 ` Peter Korsgaard
2017-11-05 22:35 ` Thomas Petazzoni
2017-11-09 20:58 ` Alexey Brodkin
2017-11-02 22:22 ` Alexey Brodkin
2017-11-08 12:49 ` Johan Oudinet
2017-11-08 16:16 ` Matthew Weber
2017-11-08 17:33 ` Yann E. MORIN
2017-11-08 19:35 ` Matthew Weber
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.