[Buildroot] Analysis of autobuild failures 18-19/11

[Thomas Petazzoni <thomas.petazzoni@free-electrons.com>]

Hello,

First of all, thanks a lot for doing this work!

On Sat, 19 Nov 2016 20:23:23 +0100, Arnout Vandecappelle wrote:


> http://autobuild.buildroot.net/results/f2a001031af381388cff71b4de1103fc11e08239
> xtensa	jack2-v1.9.10	uclibc	
> 
> > ../dbus/sigsegv.c: In function 'signal_segv':
> > ../dbus/sigsegv.c:110:20: error: 'NGREG' undeclared (first use in this function)
> >      for(i = 0; i < NGREG; i++)
> >                     ^
> > ../dbus/sigsegv.c:110:20: note: each undeclared identifier is reported only once for each function it appears in
> > ../dbus/sigsegv.c:119:38: error: 'mcontext_t {aka struct sigcontext}' has no member named 'gregs'
> >                  ucontext->uc_mcontext.gregs[i]  
> 
>  Lots of similar failures exist with uClibc, but only on xtensa and arc.
> Incomplete / incompatible struct sigcontext definition maybe? Waldemar?

On this one, I replied to Alexey's new patch on the topic. I had worked
on the issue back in May 2016, but didn't reach a fully tested solution.

> http://autobuild.buildroot.net/results/be3131fe5edc6b1462e49ec33ea0e6f74d4c3cd6
> x86_64 / core2	kvm-unit-tests-5731572b2ac2...	uclibc	
> 
> > x86/hyperv_clock.c: Assembler messages:
> > x86/hyperv_clock.c:21: Error: no instruction mnemonic suffix given and no register operands; can't size instruction  
> 
>  Inline assembly problem? Too old compiler (gcc 4.6)?

Yes, this is also my understand. Perhaps we need some
HOST_GCC_AT_LEAST option? I wasn't sure starting from which version it
was working. If it doesn't work with 4.6, maybe we can just tentatively
use AT_LEAST_4_7, and we see if we have more failures? Not very
scientific, but oh well.

> http://autobuild.buildroot.net/results/070ce21befbf3f0cd015ba0017b0a113ce985768
> arm / cortex-a9	kvmtool-bed2bd9e1fbef581909...	glibc	
> 
> >   LINK     guest/init
> > make[1]: *** [guest/init] Segmentation fault (core dumped)  
> 
>  Just two build failures like this, on two different machines. Parallel build
> issue maybe?

Hum, I think I had a look, and I was able to reproduce IIRC. I really
need to be better at taking notes about what I'm doing. I even think I
had found what the issue was.

> http://autobuild.buildroot.net/results/4fb4353bce614b64b30b05d06831e0d0f38a48dd
> bfin / bf532	libarchive-3.2.1	uclibc	static
> 
> > ./.libs/libarchive.a(archive_random.o): In function `_archive_random':
> > libarchive/archive_random.c:(.text+0x158): undefined reference to `_pthread_mutex_lock'
> > libarchive/archive_random.c:(.text+0x20a): undefined reference to `_pthread_mutex_unlock'  
> 
>  pthread static linking problem with the ADI toolchain. Probably solved with
> current uClibc-ng.

Let's kill this toolchain. I checked the other day the ADI toolchain
SourceForge site, and they don't have any newer version.


> http://autobuild.buildroot.net/results/a40682602d5bbeab38d2563f9dfdb04394a5fb01
> arm / cortex-m4	libffi-3.2.1	uclibc	static
> 
> > /bin/sh ./libtool    --mode=compile /home/buildroot/build/instance-0/output/host/usr/bin/arm-linux-gcc -DHAVE_CONFIG_H -I. -I..  -I. -I../include -Iinclude -I../src -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I. -I../include -Iinclude -I../src -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -Os   -Wl,-elf2flt -static -c -o src/arm/sysv.lo ../src/arm/sysv.S
> > libtool: compile:  /home/buildroot/build/instance-0/output/host/usr/bin/arm-linux-gcc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I. -I../include -Iinclude -I../src -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -Wl,-elf2flt -c ../src/arm/sysv.S -o src/arm/sysv.o
> > ../src/arm/sysv.S: Assembler messages:
> > ../src/arm/sysv.S:159: Error: selected processor does not support ARM opcodes
> > ../src/arm/sysv.S:161: Error: attempt to use an ARM instruction on a Thumb-only processor -- `stmfd sp!,{r0-r3,fp,lr}'
> > ../src/arm/sysv.S:163: Error: attempt to use an ARM instruction on a Thumb-only processor -- `mov fp,sp'
> > .....  
> 
>  ARM assembly should be disabled on a thumb-only processor. We just did
> something similar for tremor as well. Thomas?

There is no support in libffi for Thumb-only platform. Since adding
arch dependencies to libffi is really a nightmare (150+ reverse
dependencies), we added an exception to the autobuilder script. So this
build failure is just a reminder to tell the owner of the build machine
that triggered this failure to update his autobuild-run script.

I've done that just right now.

> http://autobuild.buildroot.net/results/0be5e6b6194df5261b5ee569100f9eb2c899b695
> powerpc / e500mc	lite-0.8.10	uclibc	static
> 
> > /bin/sh ../libtool --tag=CC   --mode=link /home/buildroot/build/instance-0/output/host/usr/bin/powerpc-linux-gcc  -Wall -O3 -pipe -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -Os  -static -Werror-implicit-function-declaration  -static -o lite_bench bench.o ../leck/libleck.la ../lite/liblite.la -L/home/buildroot/build/instance-0/output/host/usr/powerpc-buildroot-linux-uclibc/sysroot/usr/lib -ldirectfb -L/home/buildroot/build/instance-0/output/host/usr/powerpc-buildroot-linux-uclibc/sysroot/usr/lib   -lz -lfusion -L/home/buildroot/build/instance-0/output/host/usr/powerpc-buildroot-linux-uclibc/sysroot/usr/lib -ldirect -lpthread -L/home/buildroot/build/instance-0/output/host/usr/powerpc-buildroot-linux-uclibc/sysroot/usr/lib   ../leck/libleck.la ../lite/liblite.la -L/home/buildroot/build/instance-0/output/host/usr/powerpc-buildroot-linux-uclibc/sysroot/usr/lib -ldirectfb -L/home/buildroot/build/instance-0/output/host/usr/powerpc-buildroot-linux-uclibc/sy
 sr  
>  oot/usr/lib   -lz -lfusion -L/home/buildroot/build/instance-0/output/host/usr/powerpc-buildroot-linux-uclibc/sysroot/usr/lib -ldirect -lpthread -L/home/buildroot/build/instance-0/output/host/usr/powerpc-buildroot-linux-uclibc/sysroot/usr/lib  
> > /home/buildroot/build/instance-0/output/host/usr/bin/powerpc-linux-gcc -Wall -O3 -pipe -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -static -Werror-implicit-function-declaration -static -o lite_bench bench.o  -L/home/buildroot/build/instance-0/output/host/usr/powerpc-buildroot-linux-uclibc/sysroot/usr/lib ../leck/.libs/libleck.a /home/buildroot/build/instance-0/output/build/lite-0.8.10/lite/.libs/liblite.a ../lite/.libs/liblite.a /home/buildroot/build/instance-0/output/host/usr/powerpc-buildroot-linux-uclibc/sysroot/usr/lib/libdirectfb.a /home/buildroot/build/instance-0/output/build/directfb-1.7.7/lib/fusion/.libs/libfusion.a /home/buildroot/build/instance-0/output/host/usr/powerpc-buildroot-linux-uclibc/sysroot/usr/lib/libfusion.a /home/buildroot/build/instance-0/output/build/directfb-1.7.7/lib/direct/.libs/libdirect.a /home/buildroot/build/instance-0/output/host/usr/powerpc-buildroot-linux-uclibc/sysroot/usr/lib/libdirect.a -lz -lrt /home/buildro
 ot  
>  /build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/powerpc-buildroot-linux-uclibc/5.4.0/../../../../powerpc-buildroot-linux-uclibc/lib/libstdc++.so -lpthread   -Wl,--rpath -Wl,/home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/powerpc-buildroot-linux-uclibc/5.4.0/../../../../powerpc-buildroot-linux-uclibc/lib -Wl,--rpath -Wl,/home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/powerpc-buildroot-linux-uclibc/5.4.0/../../../../powerpc-buildroot-linux-uclibc/lib
> > libtool: link: warning: library `/home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/powerpc-buildroot-linux-uclibc/5.4.0/../../../../powerpc-buildroot-linux-uclibc/lib/libstdc++.la' was moved.
> > /home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/powerpc-buildroot-linux-uclibc/5.4.0/../../../../powerpc-buildroot-linux-uclibc/bin/ld: attempted static link of dynamic object `/home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/powerpc-buildroot-linux-uclibc/5.4.0/../../../../powerpc-buildroot-linux-uclibc/lib/libstdc++.so'
> > collect2: error: ld returned 1 exit status
> > Makefile:378: recipe for target 'lite_bench' failed  
> 
>  The linking with libstdc++.so is added by libtool and is caused by directfb.
> Not sure what is happening here. This isn't the same thing as for ppc64le, is it?

I'm not entirely sure about that one, but it could be the following
(usual problem) : your create a C program, that you compile with gcc,
but you link it with a C++ library. With dynamic linking, it all works
fine because your C++ library has a NEEDED on libstdc++.so, but it
fails badly with static linking.

There's no real way for your C application to know that one of the
library it links with is written in C++, so how can it know that it
should add -lstdc++ to the link command line, or alternatively use g++
instead of gcc?

I raised this problem to the pkg-config developers a while ago (see
https://lists.freedesktop.org/archives/pkg-config/2016-August/001053.html)
and there wasn't a very good proposal to solve this. My proposal is to
fix this by adding -lstdc++ in the Libs.private field of libraries
implemented in C++.


> http://autobuild.buildroot.net/results/ab240f93c6b2701c3df08b25d12a4b27b7a24451
> i686 / i686	mplayer-1.3.0	glibc	
> 
> > libavcodec/h264_cabac.c: In function 'decode_cabac_residual_nondc_internal.isra.5':
> > libavcodec/x86/h264_i386.h:144:5: error: 'asm' operand has impossible constraints
> >      __asm__ volatile(
> >      ^  
> 
>  I'm not really familiar with i386 assembly, but I suppose it's something that
> doesn't work on i686.

This one is for Bernd or Gustavo to have a look.

> http://autobuild.buildroot.net/results/0ad82cc30cebe0ce9ea08b354c1dd939c356cbd9
> mips64el / mips64	polarssl-1.2.19	uclibc	static
> 
> > /home/peko/autobuild/instance-1/output/host/usr/mips64el-buildroot-linux-uclibc/sysroot/usr/lib/../lib64/libcrypto.a(c_zlib.o): In function `zlib_stateful_expand_block':
> > c_zlib.c:(.text+0x78): undefined reference to `inflate'
> > c_zlib.c:(.text+0x80): undefined reference to `inflate'  
> 
>  The usual.

polarssl is supposed to go away (no longer maintained)

> http://autobuild.buildroot.net/results/845a1e990eae3cc8a148f846db4ac597ebaedb4a
> x86_64 / atom	python-libconfig-b271c3d9da...	musl	
> 
> > In file included from /home/dawncrow/buildroot-test/scripts/instance-0/output/host/usr/x86_64-buildroot-linux-musl/sysroot/usr/include/boost/python/instance_holder.hpp:11:0,
> >                  from /home/dawncrow/buildroot-test/scripts/instance-0/output/host/usr/x86_64-buildroot-linux-musl/sysroot/usr/include/boost/python/object/pointer_holder.hpp:14,
> >                  from /home/dawncrow/buildroot-test/scripts/instance-0/output/host/usr/x86_64-buildroot-linux-musl/sysroot/usr/include/boost/python/to_python_indirect.hpp:10,
> >                  from /home/dawncrow/buildroot-test/scripts/instance-0/output/host/usr/x86_64-buildroot-linux-musl/sysroot/usr/include/boost/python/converter/arg_to_python.hpp:10,
> >                  from /home/dawncrow/buildroot-test/scripts/instance-0/output/host/usr/x86_64-buildroot-linux-musl/sysroot/usr/include/boost/python/call.hpp:15,
> >                  from /home/dawncrow/buildroot-test/scripts/instance-0/output/host/usr/x86_64-buildroot-linux-musl/sysroot/usr/include/boost/python/object_core.hpp:14,
> >                  from /home/dawncrow/buildroot-test/scripts/instance-0/output/host/usr/x86_64-buildroot-linux-musl/sysroot/usr/include/boost/python/args.hpp:25,
> >                  from /home/dawncrow/buildroot-test/scripts/instance-0/output/host/usr/x86_64-buildroot-linux-musl/sysroot/usr/include/boost/python.hpp:11,
> >                  from src/pylibconfig.cc:1:
> > /home/dawncrow/buildroot-test/scripts/instance-0/output/host/usr/x86_64-buildroot-linux-musl/sysroot/usr/include/boost/python/type_id.hpp: In instantiation of 'boost::python::type_info boost::python::type_id() [with T = const volatile _IO_FILE&]':
> > /home/dawncrow/buildroot-test/scripts/instance-0/output/host/usr/x86_64-buildroot-linux-musl/sysroot/usr/include/boost/python/converter/registered.hpp:91:42:   required from 'const boost::python::converter::registration& boost::python::converter::detail::registry_lookup2(T& (*)()) [with T = const volatile _IO_FILE]'
> > /home/dawncrow/buildroot-test/scripts/instance-0/output/host/usr/x86_64-buildroot-linux-musl/sysroot/usr/include/boost/python/converter/registered.hpp:98:30:   required from 'const boost::python::converter::registration& boost::python::converter::detail::registry_lookup1(boost::type<Target>) [with T = const volatile _IO_FILE&]'
> > /home/dawncrow/buildroot-test/scripts/instance-0/output/host/usr/x86_64-buildroot-linux-musl/sysroot/usr/include/boost/python/converter/registered.hpp:109:80:   required from 'const boost::python::converter::registration& boost::python::converter::detail::registered_base<const volatile _IO_FILE&>::converters'
> > /home/dawncrow/buildroot-test/scripts/instance-0/output/host/usr/x86_64-buildroot-linux-musl/sysroot/usr/include/boost/python/converter/arg_from_python.hpp:269:61:   required from 'boost::python::converter::pointer_arg_from_python<T>::pointer_arg_from_python(PyObject*) [with T = _IO_FILE*; PyObject = _object]'
> > /home/dawncrow/buildroot-test/scripts/instance-0/output/host/usr/x86_64-buildroot-linux-musl/sysroot/usr/include/boost/python/arg_from_python.hpp:70:18:   required from 'boost::python::arg_from_python<T>::arg_from_python(PyObject*) [with T = _IO_FILE*; PyObject = _object]'
> > /home/dawncrow/buildroot-test/scripts/instance-0/output/host/usr/x86_64-buildroot-linux-musl/sysroot/usr/include/boost/preprocessor/iteration/detail/local.hpp:37:9:   required from 'PyObject* boost::python::detail::caller_arity<2u>::impl<F, Policies, Sig>::operator()(PyObject*, PyObject*) [with F = void (pyConfig::*)(_IO_FILE*); Policies = boost::python::default_call_policies; Sig = boost::mpl::vector3<void, pyConfig&, _IO_FILE*>; PyObject = _object]'
> > /home/dawncrow/buildroot-test/scripts/instance-0/output/host/usr/x86_64-buildroot-linux-musl/sysroot/usr/include/boost/python/object/py_function.hpp:38:33:   required from 'PyObject* boost::python::objects::caller_py_function_impl<Caller>::operator()(PyObject*, PyObject*) [with Caller = boost::python::detail::caller<void (pyConfig::*)(_IO_FILE*), boost::python::default_call_policies, boost::mpl::vector3<void, pyConfig&, _IO_FILE*> >; PyObject = _object]'
> > src/pylibconfig.cc:233:1:   required from here
> > /home/dawncrow/buildroot-test/scripts/instance-0/output/host/usr/x86_64-buildroot-linux-musl/sysroot/usr/include/boost/python/type_id.hpp:84:9: error: invalid use of incomplete type 'struct _IO_FILE'
> >          );
> >          ^  
> 
>  Missing #include in a boost header? Yegor?

This is a musl-only issue. _IO_FILE is only defined as an internal data
structure in musl, while uClibc/glibc expose its definition. I think
Boost Python is messing up with C library stuff it shouldn't have
access to.

This should be brought to the musl developers to see what they think
about it.


> http://autobuild.buildroot.net/results/e0f6c2549ed79a8f099eb87e5812749ccc3a85be
> i586 / pentium-mmx	ruby-2.3.1	musl	
> 
> > linking miniruby
> > array.o: In function `rb_ary_repeated_combination':
> > array.c:(.text+0x2c08): undefined reference to `__stack_chk_fail_local'
> > array.o: In function `rb_ary_repeated_permutation':
> > array.c:(.text+0x2de0): undefined reference to `__stack_chk_fail_local'
> > array.o: In function `rb_ary_combination':
> > array.c:(.text+0x2fc7): undefined reference to `__stack_chk_fail_local'
> > array.o: In function `rb_ary_permutation':
> > array.c:(.text+0x3254): undefined reference to `__stack_chk_fail_local'
> > array.o: In function `rb_ary_zip':
> > array.c:(.text+0x6421): undefined reference to `__stack_chk_fail_local'
> > bignum.o:bignum.c:(.text+0x1279): more undefined references to `__stack_chk_fail_local' follow
> > /home/rclinux/rc-buildroot-test/scripts/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/i586-buildroot-linux-musl/5.4.0/../../../../i586-buildroot-linux-musl/bin/ld: miniruby: hidden symbol `__stack_chk_fail_local' isn't defined
> > /home/rclinux/rc-buildroot-test/scripts/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/i586-buildroot-linux-musl/5.4.0/../../../../i586-buildroot-linux-musl/bin/ld: final link failed: Bad value  
> 
>  It is configured with --disable-libssp, not sure what's going on here...

There is an issue with supporting SSP on musl/i586. It's yet another
thing I started investigating but gave up. If I recall, some gcc
patches were needed or something. At least something that makes you
want to give up :)

> http://autobuild.buildroot.net/results/b2fe90ab02c3e0d9588f79499065635723824320
> i586 / pentium-mmx	stunnel-5.36	musl	
> 
> > stunnel-client.o: In function `connect_local':
> > client.c:(.text+0x536): undefined reference to `__stack_chk_fail_local'  
> 
>  Hm, looks awfully familiar :-)

Any package that wants SSP on musl/i586 fails this way.


> http://autobuild.buildroot.net/results/8c5d39e90fedac98cf9a9d5ac35c683efc3892b9
> microblazeel	vlc-2.2.4	uclibc	
> http://autobuild.buildroot.net/results/432d0fb0bd872aa334069af17a0f41f9a4eb9633
> microblazeel	vlc-2.2.4	uclibc	
> 
> > video_output/video_output.c: In function 'ThreadDisplayPicture':
> > video_output/video_output.c:1154:1: internal compiler error: in merge_overlapping_regs, at regrename.c:304
> >  }
> >  ^  
> 
>  ICE. Perhaps just disable vlc on microblaze?

Yeah, probably the most reasonable solution. Who is going to use VLC on
Microblaze anyway?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com