[Buildroot] [autobuild.buildroot.net] Build results for 2013-08-27

[Buildroot] [autobuild.buildroot.net] Build results for 2013-08-27

[Thomas Petazzoni]

Build statistics for 2013-08-27
===============================

        success : 79 
       failures : 32 
       timeouts : 0  
          TOTAL : 111

Classification of failures by reason
====================================

               libglib2-2.36.3 | 4 
               alsa-lib-1.0.26 | 3 
                 qt5base-5.0.2 | 2 
                  stunnel-4.55 | 2 
               qt5webkit-5.0.2 | 2 
                      gpsd-3.9 | 1 
                directfb-1.6.3 | 1 
                pulseaudio-4.0 | 1 
                   ncftp-3.2.5 | 1 
media-ctl-ac40b79f002a2315f... | 1 
              strongswan-5.0.4 | 1 
                libtirpc-0.2.2 | 1 
                      qt-4.8.5 | 1 
                busybox-1.21.1 | 1 
                     lua-5.1.5 | 1 
                pciutils-3.2.0 | 1 
                   cups-1.3.11 | 1 
                  nettle-2.7.1 | 1 
              e2fsprogs-1.42.8 | 1 
             tvheadend-5956233 | 1 
               w_scan-20130331 | 1 
                 rt-tests-0.83 | 1 
                      bash-4.2 | 1 
                  sysklogd-1.5 | 1 

Detail of failures
===================

    x86_64 |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/dafc9f0c237e98b9280e813ed8100ab913e629be/
      bfin |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/1d587ef565425b574aeb85e6e2bebd2322634868/
      bfin |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/a771c47b8d818245f8b66f128ea49db208fdfe52/
      i686 |                       bash-4.2 | NOK | http://autobuild.buildroot.net/results/b85caa22ddc13bdaaac25b9016fe902ade5027de/
       arm |                 busybox-1.21.1 | NOK | http://autobuild.buildroot.net/results/7673109f00d51a6072c23104ac82106962903e54/
   aarch64 |                    cups-1.3.11 | NOK | http://autobuild.buildroot.net/results/6c179dca4455e4cb651f9b6bce1b2604366431f4/
  mips64el |                 directfb-1.6.3 | NOK | http://autobuild.buildroot.net/results/fab819eee4002a9c392c48c1ebaca5c5b6555567/
microblaze |               e2fsprogs-1.42.8 | NOK | http://autobuild.buildroot.net/results/94661d9cb3e27579a09e4518f55dd8406d1cc502/
    x86_64 |                       gpsd-3.9 | NOK | http://autobuild.buildroot.net/results/d58be37b9b18b37eab4acec9a6bbe28863ef4d22/
  mips64el |                libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/8159d3a5e7ea17ef4c3ee732fb21941a017429db/
microblaze |                libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/519219ec8e4c4aa06baf3353cd2e37bf4fef9362/
  mips64el |                libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/0a19073440d22b36df05a54c9104c139cc6d376b/
      bfin |                libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/c3084342085371618f961c00cc866ae37b5e9453/
       arm |                 libtirpc-0.2.2 | NOK | http://autobuild.buildroot.net/results/1f51c9fce5d3e2758ccea8176406289a1bc069b5/
      bfin |                      lua-5.1.5 | NOK | http://autobuild.buildroot.net/results/760bfa75559ec1fe2a7060e9e6792c9789410f2c/
   powerpc | media-ctl-ac40b79f002a2315f... | NOK | http://autobuild.buildroot.net/results/7bcab9b94a81b89789dc1cabe9f6940ed4f5ea51/
      i686 |                    ncftp-3.2.5 | NOK | http://autobuild.buildroot.net/results/e2090822a32da8b70f0928644a03873a712f3c97/
microblaze |                   nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/b95477576f1d3a84951c70ddd158b75e9f19efbd/
   powerpc |                 pciutils-3.2.0 | NOK | http://autobuild.buildroot.net/results/9daf0f46642020591731e20d3bf9041ff6259846/
       arm |                 pulseaudio-4.0 | NOK | http://autobuild.buildroot.net/results/d859068bc4a7f2b406ca83b8e19fe8b60391c0ba/
       arm |                       qt-4.8.5 | NOK | http://autobuild.buildroot.net/results/b970d41df5fa8f63b7ee90e99e7a91846f6715e1/
       arm |                  qt5base-5.0.2 | NOK | http://autobuild.buildroot.net/results/3577a7221d429658b459507cd2430fc275be8564/
       arm |                  qt5base-5.0.2 | NOK | http://autobuild.buildroot.net/results/d268003b0a3402dde930a72ab467ee393b2ebe64/
      i686 |                qt5webkit-5.0.2 | NOK | http://autobuild.buildroot.net/results/4532e7835c0bc047266d74fa5144d1e67a367ae0/
       arm |                qt5webkit-5.0.2 | NOK | http://autobuild.buildroot.net/results/439ce2c3c33a92966808071d4fc7231d50453c79/
    mipsel |                  rt-tests-0.83 | NOK | http://autobuild.buildroot.net/results/41534b06b9bdf1a373f3fe4f4717c3bc8c9d7e1d/
    x86_64 |               strongswan-5.0.4 | NOK | http://autobuild.buildroot.net/results/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/
      mips |                   stunnel-4.55 | NOK | http://autobuild.buildroot.net/results/28527d8ec87d7c0e9d380682216a33ea192eee42/
      mips |                   stunnel-4.55 | NOK | http://autobuild.buildroot.net/results/876ea074ef53e020d7e72bc508aca834d2dda341/
   powerpc |                   sysklogd-1.5 | NOK | http://autobuild.buildroot.net/results/f037bf84f58ae293d5b26d5260e3a47a0ed36749/
  mips64el |              tvheadend-5956233 | NOK | http://autobuild.buildroot.net/results/a24bcf23cfc4e5d69ee29ef11397679eb8198468/
   powerpc |                w_scan-20130331 | NOK | http://autobuild.buildroot.net/results/f3a1c2245eab30a512fddda620c42b1cab1725bf/


-- 
http://autobuild.buildroot.net

[Buildroot] [autobuild.buildroot.net] Build results for 2013-08-27

[Thomas Petazzoni]

Peter,

On Wed, 28 Aug 2013 08:30:05 +0200 (CEST), Thomas Petazzoni wrote:

>        arm |                  qt5base-5.0.2 | NOK | http://autobuild.buildroot.net/results/d268003b0a3402dde930a72ab467ee393b2ebe64/

I believe this one should be fixed by the patch that Spenser has posted
at http://patchwork.ozlabs.org/patch/269662/. It should probably be
applied to 2013.08.

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Hello,

We don't have that many build failures today, so let's have a look
together at each of them and see what we can do about them.

>     x86_64 |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/dafc9f0c237e98b9280e813ed8100ab913e629be/

/home/test/test/3/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/usr/lib/../lib64/libc.a(vfork.os):
In function `__GI_vfork': (.text+0x0): multiple definition of `__vfork'
/home/test/test/3/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/usr/lib/../lib64/libpthread.a(pt-vfork.os):(.text+0x0):
first defined here collect2: ld returned 1 exit status

Is this some bug in uClibc ?

The toolchain is some old toolchain I've built quite some time ago with
Crosstool-NG. Maybe I should update it.

>       bfin |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/1d587ef565425b574aeb85e6e2bebd2322634868/
>       bfin |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/a771c47b8d818245f8b66f128ea49db208fdfe52/

That's the same problem: some parts of alsa-lib require dlopen()
functionality, but it isn't available for the FLAT-only bfin toolchain,
since it doesn't support shared library.

Should we mark all packages that use dlopen()
as !BR2_PREFER_STATIC_LIB ?

(Note: in the specific case of alsa-lib, maybe not the entire package
needs to be marked this way, but one of its suboptions).

>       i686 |                       bash-4.2 | NOK | http://autobuild.buildroot.net/results/b85caa22ddc13bdaaac25b9016fe902ade5027de/

./mksyntax -o syntax.c
make[1]: execvp: ./mksyntax: Permission denied
./mksignames lsignames.h

Strange. Missing executable permissions on this program? Why does it
happen only rarely?

>        arm |                 busybox-1.21.1 | NOK | http://autobuild.buildroot.net/results/7673109f00d51a6072c23104ac82106962903e54/


/home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-unknown-linux-uclibcgnueabi/4.6.4/../../../../arm-unknown-linux-uclibcgnueabi/bin/ld: error: busybox_unstripped uses VFP register arguments, libpwdgrp/lib.a(uidgid_get.o) does not
/home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-unknown-linux-uclibcgnueabi/4.6.4/../../../../arm-unknown-linux-uclibcgnueabi/bin/ld: failed to merge target specific data of file libpwdgrp/lib.a(uidgid_get.o)

Not sure what's going on here. We're mixing hardfp with softfp for
sure, but not sure why. The toolchain is also an old toolchain
generated a while ago with Crosstool-NG. I should probably update it
before looking into this.

>    aarch64 |                    cups-1.3.11 | NOK | http://autobuild.buildroot.net/results/6c179dca4455e4cb651f9b6bce1b2604366431f4/

{standard input}: Assembler messages:
{standard input}:7522: Error: immediate value out of range 0 to 255 at operand 2 -- `movi v14.8b,-1'

Seems like a deeply AArch64 problem, should be reported to the AArch64 people at Linaro.

>   mips64el |                 directfb-1.6.3 | NOK | http://autobuild.buildroot.net/results/fab819eee4002a9c392c48c1ebaca5c5b6555567/

(cd .libs/libdirectfb_dummy.a.tmp && /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ar x ../../.libs/libdirectfb_dummy.a)
/home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld -o libdirectfb_dummy.o -r .libs/libdirectfb_dummy.a.tmp/*.o
/home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: .libs/libdirectfb_dummy.a.tmp/dummy.o: ABI is incompatible with that of the selected emulation
/home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: failed to merge target specific data of file .libs/libdirectfb_dummy.a.tmp/dummy.o
/home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: Attempt to do relocatable link with elf64-tradlittlemips input and elf32-ntradlittlemips output
/home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: final link failed: File in wrong format

Still the same problem of mixing MIPS ABIs, because DirectFB is calling
"ld" directly and not "gcc" to do the link.

I had proposed a solution in
http://lists.busybox.net/pipermail/buildroot/2013-June/073399.html and
http://lists.busybox.net/pipermail/buildroot/2013-June/073400.html, but
Markos Chandras said that the upstream package should rather be fixed
to use gcc instead of ld for linking. So I guess we should fix DirectFB here.

> microblaze |               e2fsprogs-1.42.8 | NOK | http://autobuild.buildroot.net/results/94661d9cb3e27579a09e4518f55dd8406d1cc502/

../lib/libext2fs.so: undefined reference to `fallocate64'
collect2: ld returned 1 exit status

No largefile support in this toolchain? Something else?

>     x86_64 |                       gpsd-3.9 | NOK | http://autobuild.buildroot.net/results/d58be37b9b18b37eab4acec9a6bbe28863ef4d22/

scons: *** [gpsd] Implicit dependency `/home/test/test/2/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libm.so' not found, needed by target `gpsd'.

Not sure what's happening here. Surely if -lm was missing, we would be
seeing more build failures of gpsd, no?

>   mips64el |                libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/8159d3a5e7ea17ef4c3ee732fb21941a017429db/

/home/test/test/1/output/host/usr/mips64el-buildroot-linux-gnu/sysroot/usr/lib/libc.a(vfprintf.o): In function `_i18n_number_rewrite':
printf-parse.h:(.text.unlikely+0x338): relocation truncated to fit: R_MIPS_TLS_GOTTPREL against `_nl_current_LC_CTYPE'

No idea.

> microblaze |                libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/519219ec8e4c4aa06baf3353cd2e37bf4fef9362/

./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_or_4'
./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_sub_4'
./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_xor_4'
./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_add_4'
./.libs/libglib-2.0.so: undefined reference to `fallocate64'
./.libs/libglib-2.0.so: undefined reference to `__sync_bool_compare_and_swap_4'
./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_and_4'

Too old gcc?

>   mips64el |                libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/0a19073440d22b36df05a54c9104c139cc6d376b/

Same as the one above (relocation truncated to fit).

>       bfin |                libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/c3084342085371618f961c00cc866ae37b5e9453/

libglib uses fork(). I did post
http://patchwork.ozlabs.org/patch/226374/ a while ago.

>        arm |                 libtirpc-0.2.2 | NOK | http://autobuild.buildroot.net/results/1f51c9fce5d3e2758ccea8176406289a1bc069b5/

auth_none.c:46:21: fatal error: pthread.h: No such file or directory

libtirpc needs thread support. Originally, I was against adding the
BR2_TOOLCHAIN_HAS_THREADS dependency and thought we should fix libtirpc
instead. But I've changed my mind, I think we shouldn't diverge too
much from upstream (we already have large patches on libtirpc).

So I believe we should apply a refresh of
http://patchwork.ozlabs.org/patch/244409/, with some adjustments.

>       bfin |                      lua-5.1.5 | NOK | http://autobuild.buildroot.net/results/760bfa75559ec1fe2a7060e9e6792c9789410f2c/

loadlib.c:61:19: error: dlfcn.h: No such file or directory

Uses dlopen() functionality. Should we mark !BR2_PREFER_STATIC_LIB ?

>    powerpc | media-ctl-ac40b79f002a2315f... | NOK | http://autobuild.buildroot.net/results/7bcab9b94a81b89789dc1cabe9f6940ed4f5ea51/

Too old kernel headers in toolchain. Options:

 1/ Add an exception in the autobuilder script.

 2/ Modify media-ctl to integrate the necessary kernel headers and use
    them when not available from the toolchain.

I'm inclined to favor 1/.

>       i686 |                    ncftp-3.2.5 | NOK | http://autobuild.buildroot.net/results/e2090822a32da8b70f0928644a03873a712f3c97/

/usr/bin/install: cannot stat `/home/test/test/3/output/build/ncftp-3.2.5/bin/ncftpbookmarks': No such file or directory
make: *** [/home/test/test/3/output/build/ncftp-3.2.5/.stamp_target_installed] Error 1

Some binary is not generated as our .mk file expects. Should be trivial
to fix.

> microblaze |                   nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/b95477576f1d3a84951c70ddd158b75e9f19efbd/

sha512-compress.c: In function '_nettle_sha512_compress':
sha512-compress.c:180:1: internal compiler error: in reload, at reload1.c:1059
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

Oops. Not much we can do here.

Should we add an exception in the autobuilder scripts? Or an exception
directly within Buildroot between this package and the particular
Microblaze toolchain causing the issue?

>    powerpc |                 pciutils-3.2.0 | NOK | http://autobuild.buildroot.net/results/9daf0f46642020591731e20d3bf9041ff6259846/

/home/test/test/3/output/host/usr/bin/powerpc-linux-gnu-gcc   example.o lib/libpci.so.3.2.0  -o example
/home/test/test/3/output/host/usr/powerpc-buildroot-linux-gnu/sysroot/usr/lib/libkmod.so: undefined reference to `_Static_assert'

No idea, I haven't investigated.

>        arm |                 pulseaudio-4.0 | NOK | http://autobuild.buildroot.net/results/d859068bc4a7f2b406ca83b8e19fe8b60391c0ba/

/home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.7.3/include/arm_neon.h:32:2: error: #error You must enable NEON instructions (e.g. -mfloat-abi=softfp -mfpu=neon) to use arm_neon.h

Should be fixed by the recently committed
http://git.buildroot.net/buildroot/commit/?id=f09636710b14f1493de7c8cd24aaf3a5d1322389.

>        arm |                       qt-4.8.5 | NOK | http://autobuild.buildroot.net/results/b970d41df5fa8f63b7ee90e99e7a91846f6715e1/

The EGL functionality test failed!
 EGL is required for OpenGL ES to manage contexts & surfaces.
 You might need to modify the include and library search paths by editing
 QMAKE_INCDIR_EGL, QMAKE_LIBDIR_EGL and QMAKE_LIBS_EGL in
 /scratch/peko/build/qt-4.8.5/mkspecs/qws/linux-arm-g++.
make: *** [/scratch/peko/build/qt-4.8.5/.stamp_configured] Error 1

The OpenGL implementation being selected is BR2_PACKAGE_RPI_USERLAND.
Not sure why it doesn't find it. Needs investigation.

>        arm |                  qt5base-5.0.2 | NOK | http://autobuild.buildroot.net/results/3577a7221d429658b459507cd2430fc275be8564/

DirectFB disabled.
 DirectFB support cannot be enabled due to functionality tests!
 Turn on verbose messaging (-v) to ./configure to see the final report.
 If you believe this message is in error you may use the continue
 switch (-continue) to ./configure to continue.
make: *** [/scratch/peko/build/qt5base-5.0.2/.stamp_configured] Error 101

To be reproduced/investigated.

>        arm |                  qt5base-5.0.2 | NOK | http://autobuild.buildroot.net/results/d268003b0a3402dde930a72ab467ee393b2ebe64/

OpenGL ES 2.x disabled.
The OpenGL ES 2.0 functionality test failed!
 You might need to modify the include and library search paths by editing
 QMAKE_INCDIR_OPENGL_ES2, QMAKE_LIBDIR_OPENGL_ES2 and QMAKE_LIBS_OPENGL_ES2 in
 /home/test/test/1/output/build/qt5base-5.0.2/mkspecs/devices/linux-buildroot-g++.
make: *** [/home/test/test/1/output/build/qt5base-5.0.2/.stamp_configured] Error 1

As I pointed to Peter, this should be fixed by
http://patchwork.ozlabs.org/patch/269662/.

>       i686 |                qt5webkit-5.0.2 | NOK | http://autobuild.buildroot.net/results/4532e7835c0bc047266d74fa5144d1e67a367ae0/

cp -dpfr /home/test/test/2/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/qml/QtWebKit /home/test/test/2/output/target/usr/qml/
cp: cannot stat `/home/test/test/2/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/qml/QtWebKit': No such file or directory
make: *** [/home/test/test/2/output/build/qt5webkit-5.0.2/.stamp_target_installed] Error 1

This has been reported several times by users. Apparently, we can build
webkit without QML support, but this isn't correctly taken into account
in our qt5webkit.mk.

>        arm |                qt5webkit-5.0.2 | NOK | http://autobuild.buildroot.net/results/439ce2c3c33a92966808071d4fc7231d50453c79/

Project ERROR: Unknown module(s) in QT: gui

qt5webkit would need gui support in qt5base, which sounds logical.

>     mipsel |                  rt-tests-0.83 | NOK | http://autobuild.buildroot.net/results/41534b06b9bdf1a373f3fe4f4717c3bc8c9d7e1d/

src/cyclictest/cyclictest.c: In function 'timerthread':
src/cyclictest/cyclictest.c:638:9: error: 'union <anonymous>' has no member named '_tid'

Toolchain is a MIPS toolchain built with Buildroot 2013.05, so not old.

>     x86_64 |               strongswan-5.0.4 | NOK | http://autobuild.buildroot.net/results/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/

utils/backtrace.c:23:23: fatal error: execinfo.h: No such file or directory

uClibc doesn't have execinfo.h by default. Proper testing should be
added in strongswan code. J?r?me, can you have a look at this?

>       mips |                   stunnel-4.55 | NOK | http://autobuild.buildroot.net/results/28527d8ec87d7c0e9d380682216a33ea192eee42/

/home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-linux-gnu/4.7.3/../../../../mips-linux-gnu/bin/ld: note: 'pthread_setcancelstate@@GLIBC_2.0' is defined in DSO /home/test/test/2/output/host/usr/mips-buildroot-linux-gnu/sysroot/soft-float/lib/libc.so.6 so try adding it to the linker command line
/home/test/test/2/output/host/usr/mips-buildroot-linux-gnu/sysroot/soft-float/lib/libc.so.6: could not read symbols: Invalid operation

>       mips |                   stunnel-4.55 | NOK | http://autobuild.buildroot.net/results/876ea074ef53e020d7e72bc508aca834d2dda341/

Same problem.

>    powerpc |                   sysklogd-1.5 | NOK | http://autobuild.buildroot.net/results/f037bf84f58ae293d5b26d5260e3a47a0ed36749/

syslogd.c: In function 'main':
syslogd.c:1237:1: error: unrecognizable insn:
(insn 66 65 67 4 (set (subreg:SI (reg:V2SI 502) 0)
        (lo_sum:SI (reg:SI 503)
            (symbol_ref/f:SI ("*.LC98") [flags 0x82] <var_decl 0x55e10ae0 *.LC98>))) syslogd.c:885 -1
     (nil))
syslogd.c:1237:1: internal compiler error: in extract_insn, at recog.c:2109
Please submit a full bug report,

Ooh. That's an old toolchain built with Crosstool-NG. I should maybe
rebuild it with a more recent compiler.

>   mips64el |              tvheadend-5956233 | NOK | http://autobuild.buildroot.net/results/a24bcf23cfc4e5d69ee29ef11397679eb8198468/

src/v4l.c: In function 'v4l_adapter_check':
src/v4l.c:468:5: error: format '%llx' expects argument of type 'long long unsigned int', but argument 9 has type 'v4l2_std_id' [-Werror=format]
src/v4l.c:504:5: error: format '%llx' expects argument of type 'long long unsigned int', but argument 13 has type 'v4l2_std_id' [-Werror=format]
cc1: all warnings being treated as errors

tvheadend is built with -Werror, this is not good. Yann, can you change
this?

>    powerpc |                w_scan-20130331 | NOK | http://autobuild.buildroot.net/results/f3a1c2245eab30a512fddda620c42b1cab1725bf/

checking for linux/dvb/frontend.h usability (DVB-T2, DVB API >= v5.3)... no
*******************************************************
*** ERROR: w_scan requires linux DVB API v5.3 or higher.
*** Please update your linux dvb headers,
*** (usually /usr/include/linux/dvb).
*** EXITING!
*******************************************************
make: *** [/home/test/test/1/output/build/w_scan-20130331/.stamp_configured] Error 1

Does this means the kernel headers of the toolchain are too old? What
are the solutions to this?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Analysis of build failures

[Will Newton]

On Wed, Aug 28, 2013 at 8:08 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:

Hi Thomas,

>>    aarch64 |                    cups-1.3.11 | NOK | http://autobuild.buildroot.net/results/6c179dca4455e4cb651f9b6bce1b2604366431f4/
>
> {standard input}: Assembler messages:
> {standard input}:7522: Error: immediate value out of range 0 to 255 at operand 2 -- `movi v14.8b,-1'
>
> Seems like a deeply AArch64 problem, should be reported to the AArch64 people at Linaro.

That's a known issue that should be fixed in the most recent release.

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Dear Will Newton,

On Wed, 28 Aug 2013 08:17:55 +0100, Will Newton wrote:
> On Wed, Aug 28, 2013 at 8:08 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> 
> Hi Thomas,
> 
> >>    aarch64 |                    cups-1.3.11 | NOK | http://autobuild.buildroot.net/results/6c179dca4455e4cb651f9b6bce1b2604366431f4/
> >
> > {standard input}: Assembler messages:
> > {standard input}:7522: Error: immediate value out of range 0 to 255 at operand 2 -- `movi v14.8b,-1'
> >
> > Seems like a deeply AArch64 problem, should be reported to the AArch64 people at Linaro.
> 
> That's a known issue that should be fixed in the most recent release.

Great, thanks, I'll bump the Linaro toolchains soon.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Analysis of build failures

[Gustavo Zacarias]

On 08/28/2013 04:08 AM, Thomas Petazzoni wrote:

>>       bfin |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/1d587ef565425b574aeb85e6e2bebd2322634868/
>>       bfin |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/a771c47b8d818245f8b66f128ea49db208fdfe52/
> 
> That's the same problem: some parts of alsa-lib require dlopen()
> functionality, but it isn't available for the FLAT-only bfin toolchain,
> since it doesn't support shared library.
> 
> Should we mark all packages that use dlopen()
> as !BR2_PREFER_STATIC_LIB ?
> 
> (Note: in the specific case of alsa-lib, maybe not the entire package
> needs to be marked this way, but one of its suboptions).

IIRC it's some builtin (non-disableable) plugin that fails.
Since there's an alsa bump in the pipe i can take a look at it.

> 
>>       i686 |                       bash-4.2 | NOK | http://autobuild.buildroot.net/results/b85caa22ddc13bdaaac25b9016fe902ade5027de/
> 
> ./mksyntax -o syntax.c
> make[1]: execvp: ./mksyntax: Permission denied
> ./mksignames lsignames.h
> 
> Strange. Missing executable permissions on this program? Why does it
> happen only rarely?

umask afecting the build?

>> microblaze |                libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/519219ec8e4c4aa06baf3353cd2e37bf4fef9362/
> 
> ./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_or_4'
> ./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_sub_4'
> ./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_xor_4'
> ./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_add_4'
> ./.libs/libglib-2.0.so: undefined reference to `fallocate64'
> ./.libs/libglib-2.0.so: undefined reference to `__sync_bool_compare_and_swap_4'
> ./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_and_4'
> 
> Too old gcc?

Yes!

>>       bfin |                      lua-5.1.5 | NOK | http://autobuild.buildroot.net/results/760bfa75559ec1fe2a7060e9e6792c9789410f2c/
> 
> loadlib.c:61:19: error: dlfcn.h: No such file or directory
> 
> Uses dlopen() functionality. Should we mark !BR2_PREFER_STATIC_LIB ?

This is fixable by not defining LUA_USE_DLOPEN, which was the original
intention of the LUA_SHARED_LIBRARY knob which was removed in 76983349

>> microblaze |                   nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/b95477576f1d3a84951c70ddd158b75e9f19efbd/
> 
> sha512-compress.c: In function '_nettle_sha512_compress':
> sha512-compress.c:180:1: internal compiler error: in reload, at reload1.c:1059
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> 
> Oops. Not much we can do here.
> 
> Should we add an exception in the autobuilder scripts? Or an exception
> directly within Buildroot between this package and the particular
> Microblaze toolchain causing the issue?

It sounds rather harsh but maybe we should just remove microblaze builds
from the autobuilder - the toolchain is too broken, it fails with
openssl too for example.

>>    powerpc |                 pciutils-3.2.0 | NOK | http://autobuild.buildroot.net/results/9daf0f46642020591731e20d3bf9041ff6259846/
> 
> /home/test/test/3/output/host/usr/bin/powerpc-linux-gnu-gcc   example.o lib/libpci.so.3.2.0  -o example
> /home/test/test/3/output/host/usr/powerpc-buildroot-linux-gnu/sysroot/usr/lib/libkmod.so: undefined reference to `_Static_assert'
> 
> No idea, I haven't investigated.

Old gcc again.
We need the GCC_AT_LEAST_X_Y for these cases or just kill old gcc versions.

Regards.

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Hello,

Fran?ois, Spenser, you're Cc'ed due to a question below.

On Wed, 28 Aug 2013 08:00:40 -0300, Gustavo Zacarias wrote:
> On 08/28/2013 04:08 AM, Thomas Petazzoni wrote:
> 
> >>       bfin |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/1d587ef565425b574aeb85e6e2bebd2322634868/
> >>       bfin |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/a771c47b8d818245f8b66f128ea49db208fdfe52/
> > 
> > That's the same problem: some parts of alsa-lib require dlopen()
> > functionality, but it isn't available for the FLAT-only bfin toolchain,
> > since it doesn't support shared library.
> > 
> > Should we mark all packages that use dlopen()
> > as !BR2_PREFER_STATIC_LIB ?
> > 
> > (Note: in the specific case of alsa-lib, maybe not the entire package
> > needs to be marked this way, but one of its suboptions).
> 
> IIRC it's some builtin (non-disableable) plugin that fails.
> Since there's an alsa bump in the pipe i can take a look at it.

Good.

> >>       i686 |                       bash-4.2 | NOK | http://autobuild.buildroot.net/results/b85caa22ddc13bdaaac25b9016fe902ade5027de/
> > 
> > ./mksyntax -o syntax.c
> > make[1]: execvp: ./mksyntax: Permission denied
> > ./mksignames lsignames.h
> > 
> > Strange. Missing executable permissions on this program? Why does it
> > happen only rarely?
> 
> umask afecting the build?

I don't know, maybe.

> >> microblaze |                libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/519219ec8e4c4aa06baf3353cd2e37bf4fef9362/
> > 
> > ./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_or_4'
> > ./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_sub_4'
> > ./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_xor_4'
> > ./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_add_4'
> > ./.libs/libglib-2.0.so: undefined reference to `fallocate64'
> > ./.libs/libglib-2.0.so: undefined reference to `__sync_bool_compare_and_swap_4'
> > ./.libs/libglib-2.0.so: undefined reference to `__sync_fetch_and_and_4'
> > 
> > Too old gcc?
> 
> Yes!

This is annoying. I'm wondering if some of the glib code is not buggy
here, because the usage of those compiler intrinsics is normally
conditional in gatomic.h.

> >>       bfin |                      lua-5.1.5 | NOK | http://autobuild.buildroot.net/results/760bfa75559ec1fe2a7060e9e6792c9789410f2c/
> > 
> > loadlib.c:61:19: error: dlfcn.h: No such file or directory
> > 
> > Uses dlopen() functionality. Should we mark !BR2_PREFER_STATIC_LIB ?
> 
> This is fixable by not defining LUA_USE_DLOPEN, which was the original
> intention of the LUA_SHARED_LIBRARY knob which was removed in 76983349

Fran?ois, can you take care of this one?

> 
> >> microblaze |                   nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/b95477576f1d3a84951c70ddd158b75e9f19efbd/
> > 
> > sha512-compress.c: In function '_nettle_sha512_compress':
> > sha512-compress.c:180:1: internal compiler error: in reload, at reload1.c:1059
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See <http://gcc.gnu.org/bugs.html> for instructions.
> > 
> > Oops. Not much we can do here.
> > 
> > Should we add an exception in the autobuilder scripts? Or an exception
> > directly within Buildroot between this package and the particular
> > Microblaze toolchain causing the issue?
> 
> It sounds rather harsh but maybe we should just remove microblaze builds
> from the autobuilder - the toolchain is too broken, it fails with
> openssl too for example.

I don't really agree. If we support the architecture, then we should
support it, and therefore try to ensure that things are building. I
don't mind adding more !BR2_microblaze or exclude some toolchain
versions, but either we support Microblaze and have it in the
autobuilders, or we remove support for it.

Spenser, you're the one who added Microblaze support originally. We
have issues with the Microblaze toolchain. What can we do to get more
recent Microblaze toolchains, or get some support from Xilinx about our
issues?

> >>    powerpc |                 pciutils-3.2.0 | NOK | http://autobuild.buildroot.net/results/9daf0f46642020591731e20d3bf9041ff6259846/
> > 
> > /home/test/test/3/output/host/usr/bin/powerpc-linux-gnu-gcc   example.o lib/libpci.so.3.2.0  -o example
> > /home/test/test/3/output/host/usr/powerpc-buildroot-linux-gnu/sysroot/usr/lib/libkmod.so: undefined reference to `_Static_assert'
> > 
> > No idea, I haven't investigated.
> 
> Old gcc again.
> We need the GCC_AT_LEAST_X_Y for these cases or just kill old gcc versions.

_Static_assert was added in gcc 4.6, I don't think gcc 4.4 or 4.5 are
"too old". I'll cook a patch for kmod.

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Analysis of build failures

[Gustavo Zacarias]

On 08/28/2013 08:30 AM, Thomas Petazzoni wrote:
>>>>    powerpc |                 pciutils-3.2.0 | NOK | http://autobuild.buildroot.net/results/9daf0f46642020591731e20d3bf9041ff6259846/
>>>
>>> /home/test/test/3/output/host/usr/bin/powerpc-linux-gnu-gcc   example.o lib/libpci.so.3.2.0  -o example
>>> /home/test/test/3/output/host/usr/powerpc-buildroot-linux-gnu/sysroot/usr/lib/libkmod.so: undefined reference to `_Static_assert'
>>>
>>> No idea, I haven't investigated.
>>
>> Old gcc again.
>> We need the GCC_AT_LEAST_X_Y for these cases or just kill old gcc versions.
> 
> _Static_assert was added in gcc 4.6, I don't think gcc 4.4 or 4.5 are
> "too old". I'll cook a patch for kmod.

IIRC that's what gcc says but i think i've tested it and it was in >=4.4
Regards.

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Wed, 28 Aug 2013 08:34:22 -0300, Gustavo Zacarias wrote:
> On 08/28/2013 08:30 AM, Thomas Petazzoni wrote:
> >>>>    powerpc |                 pciutils-3.2.0 | NOK | http://autobuild.buildroot.net/results/9daf0f46642020591731e20d3bf9041ff6259846/
> >>>
> >>> /home/test/test/3/output/host/usr/bin/powerpc-linux-gnu-gcc   example.o lib/libpci.so.3.2.0  -o example
> >>> /home/test/test/3/output/host/usr/powerpc-buildroot-linux-gnu/sysroot/usr/lib/libkmod.so: undefined reference to `_Static_assert'
> >>>
> >>> No idea, I haven't investigated.
> >>
> >> Old gcc again.
> >> We need the GCC_AT_LEAST_X_Y for these cases or just kill old gcc versions.
> > 
> > _Static_assert was added in gcc 4.6, I don't think gcc 4.4 or 4.5 are
> > "too old". I'll cook a patch for kmod.
> 
> IIRC that's what gcc says but i think i've tested it and it was in >=4.4

The particular toolchain that caused the build failure is
BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_POWERPC201103, which is based on
gcc 4.5.2.

And according to the gcc documentation, it was added in 4.6, see
http://gcc.gnu.org/gcc-4.6/changes.html. It's also confirmed by
http://forums.gentoo.org/viewtopic-t-947998-start-0.html, which says
that the undefined reference to _Static_assert disappeared when moving
from 4.5 to 4.6.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Analysis of build failures

[Gustavo Zacarias]

On 08/28/2013 08:49 AM, Thomas Petazzoni wrote:
>> IIRC that's what gcc says but i think i've tested it and it was in >=4.4
> 
> The particular toolchain that caused the build failure is
> BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_POWERPC201103, which is based on
> gcc 4.5.2.
> 
> And according to the gcc documentation, it was added in 4.6, see
> http://gcc.gnu.org/gcc-4.6/changes.html. It's also confirmed by
> http://forums.gentoo.org/viewtopic-t-947998-start-0.html, which says
> that the undefined reference to _Static_assert disappeared when moving
> from 4.5 to 4.6.

Mixed up with sync_and_fetch stuff then which 4.4+ handles IIRC.
Regards.

[Buildroot] Analysis of build failures

[Thomas De Schampheleire]

Hi Thomas,

On Wed, Aug 28, 2013 at 9:08 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> We don't have that many build failures today, so let's have a look
> together at each of them and see what we can do about them.

Good idea! Ideally we can get them to 0, so that from that point
onwards any autobuild failure becomes a clear focus point.

[snip]

>
>>    powerpc | media-ctl-ac40b79f002a2315f... | NOK | http://autobuild.buildroot.net/results/7bcab9b94a81b89789dc1cabe9f6940ed4f5ea51/
>
> Too old kernel headers in toolchain. Options:
>
>  1/ Add an exception in the autobuilder script.
>
>  2/ Modify media-ctl to integrate the necessary kernel headers and use
>     them when not available from the toolchain.
>
> I'm inclined to favor 1/.

I once took a look at this. The media-ctl package already has some
copies of kernel headers to deal with older kernels. There was a check
in configure to detect this, IIRC. The stupid thing was that the
headers in the media-ctl sources would be applied unconditionally.
My intent was to patch media-ctl to provide also this missing header,
and cleanup the stupidity described. Unfortunately I didn't continue
this yet.

What exactly do you mean with approach 1/? Forcing a recent kernel
when building media-ctl?
That doesn't solve the problem for other users that try to enable
media-ctl on older kernels, right?

Best regards,
Thomas

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Wed, 28 Aug 2013 13:31:38 +0200, Thomas De Schampheleire wrote:

> > We don't have that many build failures today, so let's have a look
> > together at each of them and see what we can do about them.
> 
> Good idea! Ideally we can get them to 0, so that from that point
> onwards any autobuild failure becomes a clear focus point.

Agreed. Though we have to keep in mind that the release is in 3 days,
and after that 'next' will be merged in master, and we'll have plenty
of new autobuilder failures to look at.

> >>    powerpc | media-ctl-ac40b79f002a2315f... | NOK | http://autobuild.buildroot.net/results/7bcab9b94a81b89789dc1cabe9f6940ed4f5ea51/
> >
> > Too old kernel headers in toolchain. Options:
> >
> >  1/ Add an exception in the autobuilder script.
> >
> >  2/ Modify media-ctl to integrate the necessary kernel headers and use
> >     them when not available from the toolchain.
> >
> > I'm inclined to favor 1/.
> 
> I once took a look at this. The media-ctl package already has some
> copies of kernel headers to deal with older kernels. There was a check
> in configure to detect this, IIRC. The stupid thing was that the
> headers in the media-ctl sources would be applied unconditionally.
> My intent was to patch media-ctl to provide also this missing header,
> and cleanup the stupidity described. Unfortunately I didn't continue
> this yet.
> 
> What exactly do you mean with approach 1/? Forcing a recent kernel
> when building media-ctl?
> That doesn't solve the problem for other users that try to enable
> media-ctl on older kernels, right?

By 1/ I meant to not fix the problem, and only avoid it in the
autobuilders by making sure that when a non-suitable toolchain (too old
kernel headers) is used to build media-ctl, then we exclude media-ctl
from the build. I already have quite a few of such exclusions. What I
find not very nice is that the set of exclusions is not documented
anywhere, while they should be documented as "Known issues", or
something like that.

For reference, here is the current set of tweaks that I apply to the
randpackageconfig before starting the build. Note that when "return
False" is used, it means that the configuration is rejected and not
built, so a completely different random configuration will be tried.

    # Make sure Qt license is approved
    if "BR2_PACKAGE_QT=y\n" in config_items:
        if "# BR2_PACKAGE_QT_LICENSE_APPROVED is not set\n" in config_items:
            config_items.remove("# BR2_PACKAGE_QT_LICENSE_APPROVED is not set\n")
            config_items.append("BR2_PACKAGE_QT_LICENSE_APPROVED=y\n")
    if "BR2_PACKAGE_QT5BASE=y\n" in config_items:
        if "# BR2_PACKAGE_QT5BASE_LICENSE_APPROVED is not set\n" in config_items:
            config_items.remove("# BR2_PACKAGE_QT5BASE_LICENSE_APPROVED is not set\n")
            config_items.append("BR2_PACKAGE_QT5BASE_LICENSE_APPROVED=y\n")
    # Make sure LTP is not enabled when we have an uClibc toolchain
    if "BR2_PACKAGE_LTP_TESTSUITE=y\n" in config_items and \
            toolchain_is_uclibc(config_items):
        config_items.remove("BR2_PACKAGE_LTP_TESTSUITE=y\n")
    # Make sure xfsprogs is not enabled when we have an uClibc toolchain
    if "BR2_PACKAGE_XFSPROGS=y\n" in config_items and \
            toolchain_is_uclibc(config_items):
        config_items.remove("BR2_PACKAGE_XFSPROGS=y\n")
    # Make sure mrouted is not enabled when we have an uClibc toolchain
    if "BR2_PACKAGE_MROUTED=y\n" in config_items and \
            toolchain_is_uclibc(config_items):
        config_items.remove("BR2_PACKAGE_MROUTED=y\n")
    if 'BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/ctng-mips64-eglibc.tar.bz2"\n' in config_items and \
            "BR2_PACKAGE_SQUID=y\n" in config_items:
        # Reject this configuration
        return False
    if 'BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-mipsel-o32-full.tar.bz2"\n' in config_items and \
            "BR2_PACKAGE_SQUID=y\n" in config_items:
        # Reject this configuration
        return False
    if 'BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_MIPS44=y\n' in config_items and \
            "BR2_PACKAGE_SQUID=y\n" in config_items:
        # Reject this configuration
        return False
    if 'BR2_PACKAGE_CLASSPATH=y\n' in config_items:
        # Reject this configuration
        return False
    if 'BR2_sh2a=y\n' in config_items and  'BR2_PACKAGE_LIBFFI=y\n' in config_items:
        return False
    if 'BR2_arc=y\n' in config_items and  'BR2_PACKAGE_LIBFFI=y\n' in config_items:
        return False
    if 'BR2_PACKAGE_SUNXI_BOARDS=y\n' in config_items:
        config_items.remove("# BR2_PACKAGE_SUNXI_BOARDS_FEX_FILE is not set\n")
        config_items.append('BR2_PACKAGE_SUNXI_BOARDS_FEX_FILE="a10/hackberry.fex"\n')

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Analysis of build failures

[Thomas De Schampheleire]

On Wed, Aug 28, 2013 at 1:55 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Wed, 28 Aug 2013 13:31:38 +0200, Thomas De Schampheleire wrote:
>
>> > We don't have that many build failures today, so let's have a look
>> > together at each of them and see what we can do about them.
>>
>> Good idea! Ideally we can get them to 0, so that from that point
>> onwards any autobuild failure becomes a clear focus point.
>
> Agreed. Though we have to keep in mind that the release is in 3 days,
> and after that 'next' will be merged in master, and we'll have plenty
> of new autobuilder failures to look at.

I don't think we will be able to fix everything before the release. So
after next is merged in, we should try fixing the new problems as soon
as possible, in addition to the current ones.
Have you heard of the 'stop&fix' principle? The idea is that no new
patches are accepted when there are existing failures, and all
developers are expected to help in fixing the problem before doing
anything else.

>
>> >>    powerpc | media-ctl-ac40b79f002a2315f... | NOK | http://autobuild.buildroot.net/results/7bcab9b94a81b89789dc1cabe9f6940ed4f5ea51/
>> >
>> > Too old kernel headers in toolchain. Options:
>> >
>> >  1/ Add an exception in the autobuilder script.
>> >
>> >  2/ Modify media-ctl to integrate the necessary kernel headers and use
>> >     them when not available from the toolchain.
>> >
>> > I'm inclined to favor 1/.
>>
>> I once took a look at this. The media-ctl package already has some
>> copies of kernel headers to deal with older kernels. There was a check
>> in configure to detect this, IIRC. The stupid thing was that the
>> headers in the media-ctl sources would be applied unconditionally.
>> My intent was to patch media-ctl to provide also this missing header,
>> and cleanup the stupidity described. Unfortunately I didn't continue
>> this yet.
>>
>> What exactly do you mean with approach 1/? Forcing a recent kernel
>> when building media-ctl?
>> That doesn't solve the problem for other users that try to enable
>> media-ctl on older kernels, right?
>
> By 1/ I meant to not fix the problem, and only avoid it in the
> autobuilders by making sure that when a non-suitable toolchain (too old
> kernel headers) is used to build media-ctl, then we exclude media-ctl
> from the build. I already have quite a few of such exclusions. What I
> find not very nice is that the set of exclusions is not documented
> anywhere, while they should be documented as "Known issues", or
> something like that.

I think this can be a good solution. Some problems are either too
complex to fix in buildroot and are really problems of upstream
packages, or some problems are exhibited in such exotic configurations
that no-one really cares about, or problems are caused by old
toolchains/kernels that could be upgraded by the user.

In these cases, a 'Known issues' + autobuild check may be better than
leaving the autobuild fail continuously. Users that bump into such an
issue, and do want to have a solution, can bring up the issue on the
mailing list and help look for a real solution.

Of course it's not the solution to add each build failure to the known
issue, because then buildroot becomes useless. But I'm sure we can
have good judgement here by the community members.

>
> For reference, here is the current set of tweaks that I apply to the
> randpackageconfig before starting the build. Note that when "return
> False" is used, it means that the configuration is rejected and not
> built, so a completely different random configuration will be tried.
>
>     # Make sure Qt license is approved
>     if "BR2_PACKAGE_QT=y\n" in config_items:
>         if "# BR2_PACKAGE_QT_LICENSE_APPROVED is not set\n" in config_items:
>             config_items.remove("# BR2_PACKAGE_QT_LICENSE_APPROVED is not set\n")
>             config_items.append("BR2_PACKAGE_QT_LICENSE_APPROVED=y\n")
>     if "BR2_PACKAGE_QT5BASE=y\n" in config_items:
>         if "# BR2_PACKAGE_QT5BASE_LICENSE_APPROVED is not set\n" in config_items:
>             config_items.remove("# BR2_PACKAGE_QT5BASE_LICENSE_APPROVED is not set\n")
>             config_items.append("BR2_PACKAGE_QT5BASE_LICENSE_APPROVED=y\n")
>     # Make sure LTP is not enabled when we have an uClibc toolchain
>     if "BR2_PACKAGE_LTP_TESTSUITE=y\n" in config_items and \
>             toolchain_is_uclibc(config_items):
>         config_items.remove("BR2_PACKAGE_LTP_TESTSUITE=y\n")
>     # Make sure xfsprogs is not enabled when we have an uClibc toolchain
>     if "BR2_PACKAGE_XFSPROGS=y\n" in config_items and \
>             toolchain_is_uclibc(config_items):
>         config_items.remove("BR2_PACKAGE_XFSPROGS=y\n")
>     # Make sure mrouted is not enabled when we have an uClibc toolchain
>     if "BR2_PACKAGE_MROUTED=y\n" in config_items and \
>             toolchain_is_uclibc(config_items):
>         config_items.remove("BR2_PACKAGE_MROUTED=y\n")
>     if 'BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/ctng-mips64-eglibc.tar.bz2"\n' in config_items and \
>             "BR2_PACKAGE_SQUID=y\n" in config_items:
>         # Reject this configuration
>         return False
>     if 'BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-mipsel-o32-full.tar.bz2"\n' in config_items and \
>             "BR2_PACKAGE_SQUID=y\n" in config_items:
>         # Reject this configuration
>         return False
>     if 'BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_MIPS44=y\n' in config_items and \
>             "BR2_PACKAGE_SQUID=y\n" in config_items:
>         # Reject this configuration
>         return False
>     if 'BR2_PACKAGE_CLASSPATH=y\n' in config_items:
>         # Reject this configuration
>         return False
>     if 'BR2_sh2a=y\n' in config_items and  'BR2_PACKAGE_LIBFFI=y\n' in config_items:
>         return False
>     if 'BR2_arc=y\n' in config_items and  'BR2_PACKAGE_LIBFFI=y\n' in config_items:
>         return False
>     if 'BR2_PACKAGE_SUNXI_BOARDS=y\n' in config_items:
>         config_items.remove("# BR2_PACKAGE_SUNXI_BOARDS_FEX_FILE is not set\n")
>         config_items.append('BR2_PACKAGE_SUNXI_BOARDS_FEX_FILE="a10/hackberry.fex"\n')
>

Best regards,
Thomas

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Wed, 28 Aug 2013 15:13:40 +0200, Thomas De Schampheleire wrote:

> >> Good idea! Ideally we can get them to 0, so that from that point
> >> onwards any autobuild failure becomes a clear focus point.
> >
> > Agreed. Though we have to keep in mind that the release is in 3 days,
> > and after that 'next' will be merged in master, and we'll have plenty
> > of new autobuilder failures to look at.
> 
> I don't think we will be able to fix everything before the release. So
> after next is merged in, we should try fixing the new problems as soon
> as possible, in addition to the current ones.

Right, but isn't this what we are all continuously doing? :-)

> Have you heard of the 'stop&fix' principle? The idea is that no new
> patches are accepted when there are existing failures, and all
> developers are expected to help in fixing the problem before doing
> anything else.

I had never heard of it as a formal principle with the 'stop&fix' name,
but it obviously looks like a natural solution to try to get some
attention from the developers. I'm not sure we want to get this far,
especially since some of the issues are quite complex, need some
discussion, etc.

I'm also using the autobuilders to progressively 'push' for more
coverage of some specific use-cases. For example, in the past, there
were never BR2_PREFER_STATIC_LIB builds, and I introduced that a few
months ago. I knew it would generate a lot of new autobuilder failures,
but that was the only way to make sure this feature is properly
supported. And I think it actually worked: people have contributed a
lot of patches to progressively fix static build problems, and the
situation has improved a lot.

One of the next thing I'll probably add is random usage of ccache, to
catch problems such as the "$(CC)" problem you fixed this morning.

So if our goal is really 0 failures, it can certainly be achieved
easily by removing the most exotic configurations from the
autobuilders, but I'm not sure if it's really a desirable goal. On the
other side, having too many failures in the autobuilders is very
discouraging and nobody wants to fix failures when they are hundreds of
them.

> >> >>    powerpc | media-ctl-ac40b79f002a2315f... | NOK | http://autobuild.buildroot.net/results/7bcab9b94a81b89789dc1cabe9f6940ed4f5ea51/
> >> >
> >> > Too old kernel headers in toolchain. Options:
> >> >
> >> >  1/ Add an exception in the autobuilder script.
> >> >
> >> >  2/ Modify media-ctl to integrate the necessary kernel headers and use
> >> >     them when not available from the toolchain.
> >> >
> >> > I'm inclined to favor 1/.
> >>
> >> I once took a look at this. The media-ctl package already has some
> >> copies of kernel headers to deal with older kernels. There was a check
> >> in configure to detect this, IIRC. The stupid thing was that the
> >> headers in the media-ctl sources would be applied unconditionally.
> >> My intent was to patch media-ctl to provide also this missing header,
> >> and cleanup the stupidity described. Unfortunately I didn't continue
> >> this yet.
> >>
> >> What exactly do you mean with approach 1/? Forcing a recent kernel
> >> when building media-ctl?
> >> That doesn't solve the problem for other users that try to enable
> >> media-ctl on older kernels, right?
> >
> > By 1/ I meant to not fix the problem, and only avoid it in the
> > autobuilders by making sure that when a non-suitable toolchain (too old
> > kernel headers) is used to build media-ctl, then we exclude media-ctl
> > from the build. I already have quite a few of such exclusions. What I
> > find not very nice is that the set of exclusions is not documented
> > anywhere, while they should be documented as "Known issues", or
> > something like that.
> 
> I think this can be a good solution. Some problems are either too
> complex to fix in buildroot and are really problems of upstream
> packages, or some problems are exhibited in such exotic configurations
> that no-one really cares about, or problems are caused by old
> toolchains/kernels that could be upgraded by the user.
> 
> In these cases, a 'Known issues' + autobuild check may be better than
> leaving the autobuild fail continuously. Users that bump into such an
> issue, and do want to have a solution, can bring up the issue on the
> mailing list and help look for a real solution.
> 
> Of course it's not the solution to add each build failure to the known
> issue, because then buildroot becomes useless. But I'm sure we can
> have good judgement here by the community members.

I fully agree.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Analysis of build failures

[Markos Chandras]

Hi Thomas,

On 28 August 2013 08:08, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
>>   mips64el |                 directfb-1.6.3 | NOK | http://autobuild.buildroot.net/results/fab819eee4002a9c392c48c1ebaca5c5b6555567/
>
> (cd .libs/libdirectfb_dummy.a.tmp && /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ar x ../../.libs/libdirectfb_dummy.a)
> /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld -o libdirectfb_dummy.o -r .libs/libdirectfb_dummy.a.tmp/*.o
> /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: .libs/libdirectfb_dummy.a.tmp/dummy.o: ABI is incompatible with that of the selected emulation
> /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: failed to merge target specific data of file .libs/libdirectfb_dummy.a.tmp/dummy.o
> /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: Attempt to do relocatable link with elf64-tradlittlemips input and elf32-ntradlittlemips output
> /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: final link failed: File in wrong format
>
> Still the same problem of mixing MIPS ABIs, because DirectFB is calling
> "ld" directly and not "gcc" to do the link.
>
> I had proposed a solution in
> http://lists.busybox.net/pipermail/buildroot/2013-June/073399.html and
> http://lists.busybox.net/pipermail/buildroot/2013-June/073400.html, but
> Markos Chandras said that the upstream package should rather be fixed
> to use gcc instead of ld for linking. So I guess we should fix DirectFB here.
>

I will work on this and fix it properly. I will also submit a patch upstream.

-- 
Regards,
Markos Chandras

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Dear Markos Chandras,

On Wed, 28 Aug 2013 12:45:58 +0100, Markos Chandras wrote:
> Hi Thomas,
> 
> On 28 August 2013 08:08, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> >
> >>   mips64el |                 directfb-1.6.3 | NOK | http://autobuild.buildroot.net/results/fab819eee4002a9c392c48c1ebaca5c5b6555567/
> >
> > (cd .libs/libdirectfb_dummy.a.tmp && /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ar x ../../.libs/libdirectfb_dummy.a)
> > /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld -o libdirectfb_dummy.o -r .libs/libdirectfb_dummy.a.tmp/*.o
> > /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: .libs/libdirectfb_dummy.a.tmp/dummy.o: ABI is incompatible with that of the selected emulation
> > /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: failed to merge target specific data of file .libs/libdirectfb_dummy.a.tmp/dummy.o
> > /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: Attempt to do relocatable link with elf64-tradlittlemips input and elf32-ntradlittlemips output
> > /home/test/test/2/output/host/usr/bin/mips64el-unknown-linux-gnu-ld: final link failed: File in wrong format
> >
> > Still the same problem of mixing MIPS ABIs, because DirectFB is calling
> > "ld" directly and not "gcc" to do the link.
> >
> > I had proposed a solution in
> > http://lists.busybox.net/pipermail/buildroot/2013-June/073399.html and
> > http://lists.busybox.net/pipermail/buildroot/2013-June/073400.html, but
> > Markos Chandras said that the upstream package should rather be fixed
> > to use gcc instead of ld for linking. So I guess we should fix DirectFB here.
> 
> I will work on this and fix it properly. I will also submit a patch upstream.

Excellent, thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Analysis of build failures

[Arnout Vandecappelle]

On 08/28/13 09:08, Thomas Petazzoni wrote:
>>      x86_64 |                       gpsd-3.9 | NOK |http://autobuild.buildroot.net/results/d58be37b9b18b37eab4acec9a6bbe28863ef4d22/
> scons: *** [gpsd] Implicit dependency `/home/test/test/2/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libm.so' not found, needed by target `gpsd'.
>
> Not sure what's happening here. Surely if -lm was missing, we would be
> seeing more build failures of gpsd, no?

  This one should be fixed by 5628776c4a4d29d0715633ea463b64cc19e19c5a.


  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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Analysis of build failures

[Arnout Vandecappelle]

On 08/28/13 09:08, Thomas Petazzoni wrote:
>>        i686 |                       bash-4.2 | NOK |http://autobuild.buildroot.net/results/b85caa22ddc13bdaaac25b9016fe902ade5027de/
> ./mksyntax -o syntax.c
> make[1]: execvp: ./mksyntax: Permission denied
> ./mksignames lsignames.h
>
> Strange. Missing executable permissions on this program? Why does it
> happen only rarely?

  Parallel build problem. mksyntax is built twice, and is sometimes 
executed while it is being rebuilt. I can't immediately see the problem 
in the Makefile.in, though.

  Non-parallel build takes about the twice the time of the configure 
step, so I guess that's the easiest way out.

  Patch follows.

  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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Analysis of build failures

[Jérôme Pouiller]

Hi Thomas,

On 2013-08-28 09:08, Thomas Petazzoni wrote:
[...]
>>     x86_64 |               strongswan-5.0.4 | NOK | 
>> http://autobuild.buildroot.net/results/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/
>
> utils/backtrace.c:23:23: fatal error: execinfo.h: No such file or 
> directory
>
> uClibc doesn't have execinfo.h by default. Proper testing should be
> added in strongswan code. J?r?me, can you have a look at this?

I track down this error for some time but I can't reproduce it.

There is a test in ./configure that disable inclusion of execinfo.h if 
backtrace()
is not found. When re-run autobuilder configuration, this check is 
correctly
executed and execinfo.h is not included.

Is anyone else can reproduce it?

[...]


-- 
J?r?me Pouiller, Sysmic
Embedded Linux specialist
http://www.sysmic.fr

[Buildroot] Analysis of build failures

[Thomas De Schampheleire]

Hi J?r?me,

On Thu, Aug 29, 2013 at 3:17 PM, J?r?me Pouiller <jezz@sysmic.org> wrote:
> Hi Thomas,
>
> On 2013-08-28 09:08, Thomas Petazzoni wrote:
> [...]
>
>>>     x86_64 |               strongswan-5.0.4 | NOK |
>>> http://autobuild.buildroot.net/results/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/
>>
>>
>> utils/backtrace.c:23:23: fatal error: execinfo.h: No such file or
>> directory
>>
>> uClibc doesn't have execinfo.h by default. Proper testing should be
>> added in strongswan code. J?r?me, can you have a look at this?
>
>
> I track down this error for some time but I can't reproduce it.
>
> There is a test in ./configure that disable inclusion of execinfo.h if
> backtrace()
> is not found. When re-run autobuilder configuration, this check is correctly
> executed and execinfo.h is not included.
>
> Is anyone else can reproduce it?

I also cannot reproduce it. In my test build HAVE_BACKTRACE is set to
1 in config.h, and in the configure output I see:

checking for library containing backtrace... none required
checking for backtrace... yes


Thomas, can you save the strongswan build output somewhere, or check
the output of the above checks and the value of HAVE_BACKTRACE ?

Thanks,
Thomas

[Buildroot] Analysis of build failures

[Jérôme Pouiller]

On 2013-08-29 17:12, Thomas De Schampheleire wrote:
> On Thu, Aug 29, 2013 at 3:17 PM, J?r?me Pouiller <jezz@sysmic.org> 
> wrote:
>> On 2013-08-28 09:08, Thomas Petazzoni wrote:
>>>>     x86_64 |               strongswan-5.0.4 | NOK |
>>>> 
>>>> http://autobuild.buildroot.net/results/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/
>>>
>>>
>>> utils/backtrace.c:23:23: fatal error: execinfo.h: No such file or
>>> directory
>>>
>>> uClibc doesn't have execinfo.h by default. Proper testing should be
>>> added in strongswan code. J?r?me, can you have a look at this?
>>
>>
>> I track down this error for some time but I can't reproduce it.
>>
>> There is a test in ./configure that disable inclusion of execinfo.h 
>> if
>> backtrace()
>> is not found. When re-run autobuilder configuration, this check is 
>> correctly
>> executed and execinfo.h is not included.
>>
>> Is anyone else can reproduce it?
>
> I also cannot reproduce it. In my test build HAVE_BACKTRACE is set to
> 1 in config.h, and in the configure output I see:
>
> checking for library containing backtrace... none required
> checking for backtrace... yes
I have "checking for backtrace... no". I think, you can reproduce the 
bug with
this configuration.

On my side, I retry with patch called "Fix build reproducibility with 
Make 3.82"
I sent one hour ago.

-- 
J?r?me Pouiller, Sysmic
Embedded Linux specialist
http://www.sysmic.fr

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Thu, 29 Aug 2013 17:12:14 +0200, Thomas De Schampheleire wrote:

> Thomas, can you save the strongswan build output somewhere, or check
> the output of the above checks and the value of HAVE_BACKTRACE ?

So, in the failing case, for some reason, it detects that backtrace
support is available:

[...]
checking for library containing backtrace... none required
checking for backtrace... yes
[...]

Relevant config.log output:

configure:16457: /home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/usr/bin/x86_64-unknown-linux-uclibc-gcc -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -pipe -Os  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -L/usr/lib conftest.c  >&5
/home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-unknown-linux-uclibc/4.6.3/../../../../x86_64-unknown-linux-uclibc/bin/ld: warning: libc.so.0, needed by /home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-unknown-linux-uclibc/4.6.3/../../../../x86_64-unknown-linux-uclibc/lib/../lib64/libgcc_s.so, may conflict with libc.so.6
/home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/lib64/libc.so.0: warning: the `gets' function is dangerous and should not be used.
/home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/lib64/libc.so.0: warning: the `getpw' function is dangerous and should not be used.
/home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/lib64/libc.so.0: warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp'
/home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/lib64/libc.so.0: warning: the use of `tmpnam_r' is dangerous, better use `mkstemp'
/home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/lib64/libc.so.0: warning: warning: `siggetmask' is obsolete; `sigprocmask' is best
/home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/lib64/libc.so.0: warning: the use of `tmpnam' is dangerous, better use `mkstemp'
/home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot/lib64/libc.so.0: warning: the use of `tempnam' is dangerous, better use `mkstemp'
configure:16457: $? = 0
configure:16457: result: yes

I believe the problem is caused by the -L/usr/lib. Since both the
target and host have the same architecture (x86-64), it probably links
with the host C library for this test (which has backtrace support)
instead of the target C library (which doesn't have it).

It is caused by the AC_LIB_PREFIX macro that provides the
--with-lib-prefix and --without-lib-prefix options, and that by default
adds ${prefix}/lib and ${prefix}/include to LDFLAGS and CPPFLAGS
respectively.

I've just sent a patch that passes --without-lib-prefix, as it fixes
the build failure.

Thanks,

Thomas Petazzoni
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com