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

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

[Thomas Petazzoni]

Build statistics for 2013-11-08
===============================

        success : 77 
       failures : 48 
       timeouts : 0  
          TOTAL : 125

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

zmqpp-31220ca4a0fb43a0848d7... | 4 
                 qt5base-5.1.1 | 3 
                 libnspr-4.9.6 | 2 
               libglib2-2.36.3 | 2 
             alsa-utils-1.0.26 | 2 
                 binutils-2.22 | 2 
                  nettle-2.7.1 | 2 
          host-protobuf-c-0.15 | 2 
                      icu-51.2 | 2 
        gst1-plugins-bad-1.2.0 | 2 
                libiscsi-1.6.0 | 2 
                pulseaudio-4.0 | 1 
             util-linux-2.23.2 | 1 
                openssl-1.0.1e | 1 
ti-utils-06dbdb2727354b5f3a... | 1 
                  boost-1.54.0 | 1 
                      qt-4.8.5 | 1 
                  aespipe-2.4c | 1 
ne10-88c18f02199947b2c8b577... | 1 
                busybox-1.21.1 | 1 
               audiofile-0.3.6 | 1 
               libcap-ng-0.7.3 | 1 
                    php-5.3.27 | 1 
          openpgm-5.1.118~dfsg | 1 
                 fdk-aac-0.1.2 | 1 
                     gmp-5.1.3 | 1 
                 mplayer-1.1.1 | 1 
               alsa-lib-1.0.26 | 1 
                  tstools-1_11 | 1 
                  libv4l-0.8.9 | 1 
                  zeromq-3.2.4 | 1 
                 cdrkit-1.1.11 | 1 
              fontconfig-2.6.0 | 1 
                valgrind-3.8.1 | 1 

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

      mips |                   aespipe-2.4c | NOK | http://autobuild.buildroot.net/results/da0268df99b9bf920d88121e7c3d33d41a57d951/
       arm |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/983828bd27a521020e42e58cce9393e6b8d23502/
   powerpc |              alsa-utils-1.0.26 | NOK | http://autobuild.buildroot.net/results/1c6a33e75fe0617e01d7413cdfd5fbd466f822d4/
       arm |              alsa-utils-1.0.26 | NOK | http://autobuild.buildroot.net/results/6123186a66bbea833ab2fa980346f16825b22d21/
       arm |                audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/6aff0a6b9c7b2890cc069868b041ed74e549933b/
    xtensa |                  binutils-2.22 | NOK | http://autobuild.buildroot.net/results/11de6f161585c12148c1b2b4fc8ab830183edfe9/
    xtensa |                  binutils-2.22 | NOK | http://autobuild.buildroot.net/results/2d3d255b2d3ae1456a377dbc03f695b7adf010e8/
      bfin |                   boost-1.54.0 | NOK | http://autobuild.buildroot.net/results/84f9d9d2b6b5356984c6d59aad5e28b3e7847651/
       arm |                 busybox-1.21.1 | NOK | http://autobuild.buildroot.net/results/116d13f7489981c39c3759eaf8302be4d795f339/
    xtensa |                  cdrkit-1.1.11 | NOK | http://autobuild.buildroot.net/results/0315c117986f3aac8c0719d744cb47ee03738ee9/
    mipsel |                  fdk-aac-0.1.2 | NOK | http://autobuild.buildroot.net/results/cb87635832f4a1128f174a25c264f716399c52d4/
      bfin |               fontconfig-2.6.0 | NOK | http://autobuild.buildroot.net/results/8579cb481e86dcae0988379c5781bd00f4e70809/
      mips |                      gmp-5.1.3 | NOK | http://autobuild.buildroot.net/results/69b0804cbfbb24c70f90435a37fb56a118247a57/
       arm |         gst1-plugins-bad-1.2.0 | NOK | http://autobuild.buildroot.net/results/b99eb6a9067cee885da88bff64ee447c37e31e0c/
       arm |         gst1-plugins-bad-1.2.0 | NOK | http://autobuild.buildroot.net/results/b320bb61650c58e9c855e3136f5f6d7bf5e4ef56/
    x86_64 |           host-protobuf-c-0.15 | NOK | http://autobuild.buildroot.net/results/5d163e750808f2fdd8098cb58240bada12b770a9/
  mips64el |           host-protobuf-c-0.15 | NOK | http://autobuild.buildroot.net/results/038340dfbbbedbcfcb98ad5dbf828bc03fe26af6/
      bfin |                       icu-51.2 | NOK | http://autobuild.buildroot.net/results/e0a1130feb1784b3d4fefe1224943d93409a3494/
      bfin |                       icu-51.2 | NOK | http://autobuild.buildroot.net/results/85c082a693ef795cecf0ef9204b7c9c0850d4b74/
     avr32 |                libcap-ng-0.7.3 | NOK | http://autobuild.buildroot.net/results/3df16d60f6bbb679129cd568df4440be6f35cd9f/
microblaze |                libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/6f0066f56f10d3f17023e698fd3ba1bd2d00c4c1/
microblaze |                libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/79d2df836063167f12f5bba177297a041bb7c16f/
  mips64el |                 libiscsi-1.6.0 | NOK | http://autobuild.buildroot.net/results/39e8e0ebbeb196276492b928b41cc0b0fe1e9ec3/
  mips64el |                 libiscsi-1.6.0 | NOK | http://autobuild.buildroot.net/results/efb87b17c49170f6377631371438911b18029cea/
     nios2 |                  libnspr-4.9.6 | NOK | http://autobuild.buildroot.net/results/8c01fdaac7afa00bd1117c79ae047344242d1463/
     nios2 |                  libnspr-4.9.6 | NOK | http://autobuild.buildroot.net/results/a418145d72e92f64956518bb2786e33dadd08a86/
   aarch64 |                   libv4l-0.8.9 | NOK | http://autobuild.buildroot.net/results/4de7dc58e826d1dd60add2821f774c9c5f5a2a71/
       arm |                  mplayer-1.1.1 | NOK | http://autobuild.buildroot.net/results/8f946e28b11b2ab1ba0d9688286c665488de0486/
       arm | ne10-88c18f02199947b2c8b577... | NOK | http://autobuild.buildroot.net/results/3631f7e9dad9fab356d31160ac95b7d0fec70ce2/
microblaze |                   nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/82acbea862ee0bb5288ab498d86772bc475d3a53/
       arm |                   nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/88ea0cc0815f865e1a144d39231fdc9b47e689b0/
      bfin |           openpgm-5.1.118~dfsg | NOK | http://autobuild.buildroot.net/results/120b7de960a04def5c53b59644eefc598bd0a1d4/
microblaze |                 openssl-1.0.1e | NOK | http://autobuild.buildroot.net/results/f313ac3233a8ed5b3087936c1cd8408a00fdf2bb/
   aarch64 |                     php-5.3.27 | NOK | http://autobuild.buildroot.net/results/08d3255303f7ceda8a1ecfcf56ad665f00829632/
       arc |                 pulseaudio-4.0 | NOK | http://autobuild.buildroot.net/results/281ff1c8046b7e93759c5f51995f34788e717fad/
   powerpc |                       qt-4.8.5 | NOK | http://autobuild.buildroot.net/results/0ee61f71e61f2215a15e4655a4e22d0521334c35/
      i686 |                  qt5base-5.1.1 | NOK | http://autobuild.buildroot.net/results/bbe7d79da059fdf67fb29880b8539ca2320ba86d/
       arm |                  qt5base-5.1.1 | NOK | http://autobuild.buildroot.net/results/37613281f21895716ceaf64654e175148d7f543c/
      i686 |                  qt5base-5.1.1 | NOK | http://autobuild.buildroot.net/results/555278227680e90737e6dbe0a6dcc035507150aa/
       arc | ti-utils-06dbdb2727354b5f3a... | NOK | http://autobuild.buildroot.net/results/63d294574b053aa4e2148fbc3185c5594d925ae9/
    x86_64 |                   tstools-1_11 | NOK | http://autobuild.buildroot.net/results/ce02d7fb9ae3aa06eaf53db39cbef27c051b525d/
     avr32 |              util-linux-2.23.2 | NOK | http://autobuild.buildroot.net/results/2ba1bd78f4303ef2f543a4e4fa65d1b68ba3a765/
       arm |                 valgrind-3.8.1 | NOK | http://autobuild.buildroot.net/results/f174541ac06aeeac82b8399686a8d4371532760d/
     avr32 |                   zeromq-3.2.4 | NOK | http://autobuild.buildroot.net/results/5cdf3e58df0df184f2ae1f2896c44f3f0f41c94d/
       arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/64494152b75037a1194312a2a408eb7ecb6b56c8/
       arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/75f2cc531892e649599681433f62a1d76e5736c9/
       arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/65783df07ebb447f7561cb84b1bcf581a3084748/
       arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/14d441c5f3a50f61cd5a872711d09fda4e5f8bbd/


-- 
http://autobuild.buildroot.net

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

[Will Newton]

On Sat, Nov 9, 2013 at 7:30 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Build statistics for 2013-11-08
> ===============================
>
>         success : 77
>        failures : 48
>        timeouts : 0
>           TOTAL : 125
>
> Classification of failures by reason
> ====================================
>
> zmqpp-31220ca4a0fb43a0848d7... | 4
>                  qt5base-5.1.1 | 3
>                  libnspr-4.9.6 | 2
>                libglib2-2.36.3 | 2
>              alsa-utils-1.0.26 | 2
>                  binutils-2.22 | 2
>                   nettle-2.7.1 | 2
>           host-protobuf-c-0.15 | 2
>                       icu-51.2 | 2
>         gst1-plugins-bad-1.2.0 | 2
>                 libiscsi-1.6.0 | 2
>                 pulseaudio-4.0 | 1
>              util-linux-2.23.2 | 1
>                 openssl-1.0.1e | 1
> ti-utils-06dbdb2727354b5f3a... | 1
>                   boost-1.54.0 | 1
>                       qt-4.8.5 | 1
>                   aespipe-2.4c | 1
> ne10-88c18f02199947b2c8b577... | 1
>                 busybox-1.21.1 | 1
>                audiofile-0.3.6 | 1
>                libcap-ng-0.7.3 | 1
>                     php-5.3.27 | 1
>           openpgm-5.1.118~dfsg | 1
>                  fdk-aac-0.1.2 | 1
>                      gmp-5.1.3 | 1
>                  mplayer-1.1.1 | 1
>                alsa-lib-1.0.26 | 1
>                   tstools-1_11 | 1
>                   libv4l-0.8.9 | 1
>                   zeromq-3.2.4 | 1
>                  cdrkit-1.1.11 | 1
>               fontconfig-2.6.0 | 1
>                 valgrind-3.8.1 | 1
>
> Detail of failures
> ===================
>
>       mips |                   aespipe-2.4c | NOK | http://autobuild.buildroot.net/results/da0268df99b9bf920d88121e7c3d33d41a57d951/
>        arm |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/983828bd27a521020e42e58cce9393e6b8d23502/

Hi Thomas,

Do you know what is going on with the binary arm toolchain above? It
looks like the toolchain is configured wrongly, it also has "linaro"
and "uclibc" in the tarball name which is a strange combination. ;-)

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

[Thomas Petazzoni]

Dear Will Newton,

On Sat, 9 Nov 2013 14:53:00 +0000, Will Newton wrote:

> >        arm |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/983828bd27a521020e42e58cce9393e6b8d23502/
> 
> Hi Thomas,
> 
> Do you know what is going on with the binary arm toolchain above? It
> looks like the toolchain is configured wrongly, it also has "linaro"
> and "uclibc" in the tarball name which is a strange combination. ;-)

It has both uclibc and Linaro in the tarball name because this
toolchain uses gcc-linaro, but the uClibc library. So having both in
the same tarball name makes sense in this situation :-)

Regarding the toolchain, it is indeed funky. The compiler was built
with --with-float=hard, so it should be EABIhf, but the corresponding
Buildroot configuration was declaring it as being EABI.

However, switching to EABIhf in the Buildroot configuration doesn't
work either: Buildroot checks whether the crt1.o of the toolchain is
indeed built hard-float as a way of verifying that the toolchain is
indeed EABIhf. And it turns out that it's not the case for this
toolchain.

Moreover, while it was built --with-float=hard, the tuple contains
gnueabi and not gnueabihf. I guess this is all due to the fact that
this toolchain was built with the old 1.15.2 Crosstool-NG, and it's
probably time to update my ct-ng toolchains.

For the timing being, I've simply removed this toolchain from the
autobuilders.

Thanks for the report!

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

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Hello all,

If you're Cc'ed on this e-mail, it means that there is a question for
you below. Here is a summary of who should look at what problems (note
that some problems are not affected to anyone, either because the
reason is unknown or because there is no clear "owner" for the problem):

Markos Chandras			aespipe, fdk-aac, gmp, libiscsi
Sonic Zhang, Aaron Wu		boost, icu, openpgm
Chris Zankel			cdrkit
Peter Korsgaard			gst1-plugins-bad, pulseaudio
Gustavo Zacarias		protobuf-c, mplayer, nettle (ARM), php
Simon Dawson			libcap-ng, util-linux, zeromq, zmqpp
Spenser Gilliland		libglib2, nettle (Microblaze), openssl
Ezequiel Garcia			libnspr
Mischa Jonker			pulseaudio, ti-utils
Fatih A??c?			qt5base
Tzu-Jung Lee			tstools

Thanks!

Thomas

On Sat,  9 Nov 2013 08:30:28 +0100 (CET), Thomas Petazzoni wrote:

> Detail of failures
> ===================
> 
>       mips |                   aespipe-2.4c | NOK | http://autobuild.buildroot.net/results/da0268df99b9bf920d88121e7c3d33d41a57d951/

Unknown problem (error: C compiler cannot create executables). Markos,
as our MIPS guy, can you have a look at this one?

>        arm |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/983828bd27a521020e42e58cce9393e6b8d23502/

It was a wrong toolchain configuration, with a weird toolchain.
I've removed the toolchain from the autobuilders.

>    powerpc |              alsa-utils-1.0.26 | NOK | http://autobuild.buildroot.net/results/1c6a33e75fe0617e01d7413cdfd5fbd466f822d4/

Missing link against -lrt for static linking.

>        arm |              alsa-utils-1.0.26 | NOK | http://autobuild.buildroot.net/results/6123186a66bbea833ab2fa980346f16825b22d21/

checking for snd_ctl_open in -lasound... no
configure: error: No linkable libasound was found.
make: *** [/home/test/test/3/output/build/alsa-utils-1.0.26/.stamp_configured] Error 1

Weird, don't know what's happening here.

>        arm |                audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/6aff0a6b9c7b2890cc069868b041ed74e549933b/

This was my funky toolchain (same as alsa-lib problem above). Toolchain
removed from the autobuilders.

>     xtensa |                  binutils-2.22 | NOK | http://autobuild.buildroot.net/results/11de6f161585c12148c1b2b4fc8ab830183edfe9/
>     xtensa |                  binutils-2.22 | NOK | http://autobuild.buildroot.net/results/2d3d255b2d3ae1456a377dbc03f695b7adf010e8/

This is fixed by http://patchwork.ozlabs.org/patch/289532/, which
hasn't been committed yet. It will also require a rebuild of the
toolchain in the autobuilders.

Peter, can you commit this patch?

>       bfin |                   boost-1.54.0 | NOK | http://autobuild.buildroot.net/results/84f9d9d2b6b5356984c6d59aad5e28b3e7847651/

Don't know what's going on. Sonic, Aaron, can you have a look?

>        arm |                 busybox-1.21.1 | NOK | http://autobuild.buildroot.net/results/116d13f7489981c39c3759eaf8302be4d795f339/

This was my weird toolchain (same problem as alsa-lib). Toolchain
removed from the autobuilders.

>     xtensa |                  cdrkit-1.1.11 | NOK | http://autobuild.buildroot.net/results/0315c117986f3aac8c0719d744cb47ee03738ee9/

[ 58%] Building C object libhfs_iso/CMakeFiles/hfs_iso.dir/record.o
../libusal/libusal.a(scsi-remote.o):(.literal+0xe0): undefined reference to `valloc'

Chris, can you have a look at this one, since it's apparently a
Xtensa-specific problem?

>     mipsel |                  fdk-aac-0.1.2 | NOK | http://autobuild.buildroot.net/results/cb87635832f4a1128f174a25c264f716399c52d4/

MIPS specific problem. We're building for mips1, but fdk-aac uses some
instructions not available on mips1. Maybe we should only enable
fdk-aac for some more capable variant of MIPS instruction sets.

Markos, can you have a look at this one?

>       bfin |               fontconfig-2.6.0 | NOK | http://autobuild.buildroot.net/results/8579cb481e86dcae0988379c5781bd00f4e70809/

fontconfig forgets to link against libpng. Anyone willing to fix this?

>       mips |                      gmp-5.1.3 | NOK | http://autobuild.buildroot.net/results/69b0804cbfbb24c70f90435a37fb56a118247a57/

configure: error: could not find a working compiler, see config.log for details

Markos, can you have a look?

>        arm |         gst1-plugins-bad-1.2.0 | NOK | http://autobuild.buildroot.net/results/b99eb6a9067cee885da88bff64ee447c37e31e0c/
>        arm |         gst1-plugins-bad-1.2.0 | NOK | http://autobuild.buildroot.net/results/b320bb61650c58e9c855e3136f5f6d7bf5e4ef56/

Same problem in both cases, related to the DirectFB plugin. Peter, you
are the one taking care of Gstreamer most of the time, can you have a
look into this?

>     x86_64 |           host-protobuf-c-0.15 | NOK | http://autobuild.buildroot.net/results/5d163e750808f2fdd8098cb58240bada12b770a9/
>   mips64el |           host-protobuf-c-0.15 | NOK | http://autobuild.buildroot.net/results/038340dfbbbedbcfcb98ad5dbf828bc03fe26af6/

Weird compilation problem, seems really caused by an issue in
protobuf-c itself. Gustavo, you're the one who added protobuf-c, can
you have a look at this?

>       bfin |                       icu-51.2 | NOK | http://autobuild.buildroot.net/results/e0a1130feb1784b3d4fefe1224943d93409a3494/
>       bfin |                       icu-51.2 | NOK | http://autobuild.buildroot.net/results/85c082a693ef795cecf0ef9204b7c9c0850d4b74/

Problem building icu on Blackfin:

*** ERROR - configure could not detect your platform

Sonic, Zhang, can you have a look into this?

>      avr32 |                libcap-ng-0.7.3 | NOK | http://autobuild.buildroot.net/results/3df16d60f6bbb679129cd568df4440be6f35cd9f/

The missing TLS problem on AVR32. We still haven't found the solution
to handle this one. As I've suggested previously, I would simply make
TLS support unconditional in Buildroot as soon as thread support is
enabled, and then mark libcap-ng as not available on AVR32. Of course,
if you have an external toolchain without TLS support, you're on your
own.

> microblaze |                libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/6f0066f56f10d3f17023e698fd3ba1bd2d00c4c1/
> microblaze |                libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/79d2df836063167f12f5bba177297a041bb7c16f/

Missing compiler intrinsics and fallocate in the Microblaze toolchain.
We're waiting for Spenser Gilliland to finish the Microblaze internal
toolchain support, so that we can ditch the crappy Microblaze external
toolchains.

>   mips64el |                 libiscsi-1.6.0 | NOK | http://autobuild.buildroot.net/results/39e8e0ebbeb196276492b928b41cc0b0fe1e9ec3/
>   mips64el |                 libiscsi-1.6.0 | NOK | http://autobuild.buildroot.net/results/efb87b17c49170f6377631371438911b18029cea/

The usual problem of ld being used instead of gcc, causing problem on
mips64el. However, you can't do partial linking with gcc, so a libtool
fix is needed.

Markos, I know you've identified the libtool fix for this. Could you
backport it on top of libtool 2.4.2 (that we have in Buildroot), add it
as a patch in package/libtool/, and then mark LIBISCSI_AUTORECONF =
YES so that the libtool stuff gets regenerated with a known-working
version?

>      nios2 |                  libnspr-4.9.6 | NOK | http://autobuild.buildroot.net/results/8c01fdaac7afa00bd1117c79ae047344242d1463/
>      nios2 |                  libnspr-4.9.6 | NOK | http://autobuild.buildroot.net/results/a418145d72e92f64956518bb2786e33dadd08a86/

NIOS2 support missing in libnspr. Ezequiel, can you look into this?
Normally, adding an architecture support in libnspr is really easy, so
adding a patch to libnspr should be feasible. 

>    aarch64 |                   libv4l-0.8.9 | NOK | http://autobuild.buildroot.net/results/4de7dc58e826d1dd60add2821f774c9c5f5a2a71/

Package needs to be bumped, I have already started working on this.

>        arm |                  mplayer-1.1.1 | NOK | http://autobuild.buildroot.net/results/8f946e28b11b2ab1ba0d9688286c665488de0486/

libmpeg2/motion_comp_arm_s.S: Assembler messages:
libmpeg2/motion_comp_arm_s.S:29: Error: selected processor does not support ARM mode `pld [r1]'
libmpeg2/motion_comp_arm_s.S:39: Error: selected processor does not support ARM mode `pld [r1]'

That's an ARMv4t configuration. Maybe building mplayer on ARMv4t is not
possible. Adding a bunch of depends on !BR2_arm<something> is probably
the solution here. Gustavo, maybe?

>        arm | ne10-88c18f02199947b2c8b577... | NOK | http://autobuild.buildroot.net/results/3631f7e9dad9fab356d31160ac95b7d0fec70ce2/

Needs NEON support apparently. Should be something for me.

> microblaze |                   nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/82acbea862ee0bb5288ab498d86772bc475d3a53/
>        arm |                   nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/88ea0cc0815f865e1a144d39231fdc9b47e689b0/

On Microblaze, a compiler error. Should be fixed by the internal
toolchain support for Microblaze. Waiting for Spenser on this :)

On ARM, the failure is due to nettle tests requiring C++ support. It
would be good to disable the compilation of those tests. Gustavo,
you're the one looking after nettle in general, can you look into this?

>       bfin |           openpgm-5.1.118~dfsg | NOK | http://autobuild.buildroot.net/results/120b7de960a04def5c53b59644eefc598bd0a1d4/

Blackfin does not have getifaddrs():

getifaddrs.c:853:3: error: #error "Unsupported interface enumeration on this platform."

Not sure how to handle this uClibc configuration difference, except by
adding "depends on !" to exclude the specific Blackfin toolchains
causing problems.

> microblaze |                 openssl-1.0.1e | NOK | http://autobuild.buildroot.net/results/f313ac3233a8ed5b3087936c1cd8408a00fdf2bb/

Compiler error. Spenser, we need your patches!

>    aarch64 |                     php-5.3.27 | NOK | http://autobuild.buildroot.net/results/08d3255303f7ceda8a1ecfcf56ad665f00829632/

/usr/include/bits/predefs.h:20:3: error: #error "Never use <bits/predefs.h> directly; include <features.h> instead."
 # error "Never use <bits/predefs.h> directly; include <features.h> instead."

Gustavo, you like PHP, no ? :-)

>        arc |                 pulseaudio-4.0 | NOK | http://autobuild.buildroot.net/results/281ff1c8046b7e93759c5f51995f34788e717fad/

checking for atomic_ops.h... no
configure: error: *** libatomic-ops headers not found
make: *** [/home/test/test/1/output/build/pulseaudio-4.0/.stamp_configured] Error 1

For some reason, on ARC, atomic_ops is needed. Why not on other
architectures? Peter, Mischa, any idea?

>    powerpc |                       qt-4.8.5 | NOK | http://autobuild.buildroot.net/results/0ee61f71e61f2215a15e4655a4e22d0521334c35/

Will be fixed by my patch that prevents building parts of Qt on some
unsupported architectures.

>       i686 |                  qt5base-5.1.1 | NOK | http://autobuild.buildroot.net/results/bbe7d79da059fdf67fb29880b8539ca2320ba86d/
>        arm |                  qt5base-5.1.1 | NOK | http://autobuild.buildroot.net/results/37613281f21895716ceaf64654e175148d7f543c/
>       i686 |                  qt5base-5.1.1 | NOK | http://autobuild.buildroot.net/results/555278227680e90737e6dbe0a6dcc035507150aa/

For
http://autobuild.buildroot.net/results/37613281f21895716ceaf64654e175148d7f543c/build-end.log,
Samuel has already sent a patch
(http://patchwork.ozlabs.org/patch/289999/). The other two ones:

  http://autobuild.buildroot.net/results/555278227680e90737e6dbe0a6dcc035507150aa/build-end.log
  (sqlite problem)

  http://autobuild.buildroot.net/results/bbe7d79da059fdf67fb29880b8539ca2320ba86d/build-end.log
  (inlining problem)

are not fixed. Fatih, would you mind having a look?

>        arc | ti-utils-06dbdb2727354b5f3a... | NOK | http://autobuild.buildroot.net/results/63d294574b053aa4e2148fbc3185c5594d925ae9/

{standard input}: Assembler messages:
{standard input}:1680: Error: missing operand
{standard input}:1680: Error: junk at end of line: `@plt_tx_bip.part.8'

ARC toolchain problem, for Mischa.

>     x86_64 |                   tstools-1_11 | NOK | http://autobuild.buildroot.net/results/ce02d7fb9ae3aa06eaf53db39cbef27c051b525d/

Should use gcc for linking and not ld + missing -lm. Tzu-Jung Lee,
you're the one who added tstools, can you have a look at this problem?

>      avr32 |              util-linux-2.23.2 | NOK | http://autobuild.buildroot.net/results/2ba1bd78f4303ef2f543a4e4fa65d1b68ba3a765/

Missing fallocate on avr32. Simon, what is the proposal to solve this?
Add fallocate support to 0.9.31 ?

>        arm |                 valgrind-3.8.1 | NOK | http://autobuild.buildroot.net/results/f174541ac06aeeac82b8399686a8d4371532760d/

/tmp/cceJNtCh.s: Assembler messages:
/tmp/cceJNtCh.s:200: Error: r15 not allowed here -- `str r15,[r3,#+0]'
make[4]: *** [libcoregrind_arm_linux_a-m_libcassert.o] Error 1
make[4]: *** Waiting for unfinished jobs....

Not sure what's going on here. Anyone to have a look?

>      avr32 |                   zeromq-3.2.4 | NOK | http://autobuild.buildroot.net/results/5cdf3e58df0df184f2ae1f2896c44f3f0f41c94d/

Missing compiler intrinsics on AVR32. Problem already in the process of
being solved (Simon, Alexander).

>        arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/64494152b75037a1194312a2a408eb7ecb6b56c8/
>        arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/75f2cc531892e649599681433f62a1d76e5736c9/
>        arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/65783df07ebb447f7561cb84b1bcf581a3084748/
>        arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/14d441c5f3a50f61cd5a872711d09fda4e5f8bbd/

Forgets to link against pthread. Simon, can you link into this?

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

[Buildroot] Analysis of build failures

[Gustavo Zacarias]

On 11/09/2013 03:15 PM, Thomas Petazzoni wrote:

>>     x86_64 |           host-protobuf-c-0.15 | NOK | http://autobuild.buildroot.net/results/5d163e750808f2fdd8098cb58240bada12b770a9/
>>   mips64el |           host-protobuf-c-0.15 | NOK | http://autobuild.buildroot.net/results/038340dfbbbedbcfcb98ad5dbf828bc03fe26af6/
> 
> Weird compilation problem, seems really caused by an issue in
> protobuf-c itself. Gustavo, you're the one who added protobuf-c, can
> you have a look at this?

What's the host gcc version / distribution?
I suspect that's at work since the only dep for protobuf-c is
host-protobuf and the host toolchain.

>>        arm |                  mplayer-1.1.1 | NOK | http://autobuild.buildroot.net/results/8f946e28b11b2ab1ba0d9688286c665488de0486/
> 
> libmpeg2/motion_comp_arm_s.S: Assembler messages:
> libmpeg2/motion_comp_arm_s.S:29: Error: selected processor does not support ARM mode `pld [r1]'
> libmpeg2/motion_comp_arm_s.S:39: Error: selected processor does not support ARM mode `pld [r1]'
> 
> That's an ARMv4t configuration. Maybe building mplayer on ARMv4t is not
> possible. Adding a bunch of depends on !BR2_arm<something> is probably
> the solution here. Gustavo, maybe?

Likely the best option, there's probably not much point in using mplayer
on anything lower than ARMv6 IMHO (or maybe v5 with hard FP) for
performance reasons.
I'll disable it for anything lower than v5.

>> microblaze |                   nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/82acbea862ee0bb5288ab498d86772bc475d3a53/
>>        arm |                   nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/88ea0cc0815f865e1a144d39231fdc9b47e689b0/
> 
> On Microblaze, a compiler error. Should be fixed by the internal
> toolchain support for Microblaze. Waiting for Spenser on this :)
> 
> On ARM, the failure is due to nettle tests requiring C++ support. It
> would be good to disable the compilation of those tests. Gustavo,
> you're the one looking after nettle in general, can you look into this?

Actually it's a problem with static linking with C++ since the nettle
test that uses C++ is conditional on AC_PROG_CXX and works happily fine
without static linking.

The problem is that you're not handling static libs in
package/gcc/gcc-final/gcc-final.mk from HOST_GCC_FINAL_USR_LIBS, only
shared ones, hence libstdc++.a is missing since it's not copied anywhere
else (from the gcc packaging, might have been that way too before it).
No happy C++ for static users :(

Care to concoct a patch or shall i?

>>    aarch64 |                     php-5.3.27 | NOK | http://autobuild.buildroot.net/results/08d3255303f7ceda8a1ecfcf56ad665f00829632/
> 
> /usr/include/bits/predefs.h:20:3: error: #error "Never use <bits/predefs.h> directly; include <features.h> instead."
>  # error "Never use <bits/predefs.h> directly; include <features.h> instead."
> 
> Gustavo, you like PHP, no ? :-)

You keep assuming i like things because i tweak/touch them :)
PHP isn't to blame here, don't pick on the big kid, predefs.h isn't even
mentioned in any of the files of the whole php tarball.
Guess it's the toolchain or some package that's used by php, i'll look
into it but really aarch64 on a gut feeling i'll say it's the toolchain.

Regards.

[Buildroot] Analysis of build failures

[Baruch Siach]

Hi Thomas,

On Sat, Nov 09, 2013 at 07:15:43PM +0100, Thomas Petazzoni wrote:
> If you're Cc'ed on this e-mail, it means that there is a question for
> you below. Here is a summary of who should look at what problems (note
> that some problems are not affected to anyone, either because the
> reason is unknown or because there is no clear "owner" for the problem):
> 
> Markos Chandras			aespipe, fdk-aac, gmp, libiscsi
> Sonic Zhang, Aaron Wu		boost, icu, openpgm
> Chris Zankel			cdrkit
> Peter Korsgaard			gst1-plugins-bad, pulseaudio
> Gustavo Zacarias		protobuf-c, mplayer, nettle (ARM), php
> Simon Dawson			libcap-ng, util-linux, zeromq, zmqpp
> Spenser Gilliland		libglib2, nettle (Microblaze), openssl
> Ezequiel Garcia			libnspr
> Mischa Jonker			pulseaudio, ti-utils
> Fatih A??c?			qt5base
> Tzu-Jung Lee			tstools
> 
[snip]
> >     xtensa |                  cdrkit-1.1.11 | NOK | 
> >     http://autobuild.buildroot.net/results/0315c117986f3aac8c0719d744cb47ee03738ee9/
> 
> [ 58%] Building C object libhfs_iso/CMakeFiles/hfs_iso.dir/record.o
> ../libusal/libusal.a(scsi-remote.o):(.literal+0xe0): undefined reference to `valloc'
> 
> Chris, can you have a look at this one, since it's apparently a
> Xtensa-specific problem?

uClibc valloc() depends on UCLIBC_SUSV2_LEGACY which is not enabled in the 
default uClibc config. Should we enable it?

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Dear Baruch Siach,

On Sun, 10 Nov 2013 08:25:25 +0200, Baruch Siach wrote:

> > Chris, can you have a look at this one, since it's apparently a
> > Xtensa-specific problem?
> 
> uClibc valloc() depends on UCLIBC_SUSV2_LEGACY which is not enabled in the 
> default uClibc config. Should we enable it?

Yes. The UCLIBC_SUSV2_LEGACY symbol was added after 0.9.33.2, so it
explains why only Xtensa (which uses the uClibc snapshot version) is
affected. Maybe we can replace the valloc() call with posix_memalign()
and send the patch upstream to cdrkit?

Also, can you sync up with Chris to provide a patch that makes Xtensa
not use a snapshot version, but a fixed version of uClibc (based on a
git commit, for example) ? The snapshot version we currently use is
really bad, because depending on when you run the build, you will get
different build results. This is really not how Buildroot should work:
snapshot versions are only provided for expert users who want to test
the latest versions of uClibc, such versions shouldn't be used as the
default.

Thanks!

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

[Buildroot] Analysis of build failures

[Simon Dawson]

Hi Thomas,

On 9 November 2013 18:15, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>>      avr32 |                libcap-ng-0.7.3 | NOK | http://autobuild.buildroot.net/results/3df16d60f6bbb679129cd568df4440be6f35cd9f/
>
> The missing TLS problem on AVR32. We still haven't found the solution
> to handle this one. As I've suggested previously, I would simply make
> TLS support unconditional in Buildroot as soon as thread support is
> enabled, and then mark libcap-ng as not available on AVR32. Of course,
> if you have an external toolchain without TLS support, you're on your
> own.

As you say, we still don't appear to have reached a consensus of
opinion on how to solve this.

>>      avr32 |              util-linux-2.23.2 | NOK | http://autobuild.buildroot.net/results/2ba1bd78f4303ef2f543a4e4fa65d1b68ba3a765/
>
> Missing fallocate on avr32. Simon, what is the proposal to solve this?
> Add fallocate support to 0.9.31 ?

Yes, I'm working on backporting fallocate support to 0.9.31 now.

>>      avr32 |                   zeromq-3.2.4 | NOK | http://autobuild.buildroot.net/results/5cdf3e58df0df184f2ae1f2896c44f3f0f41c94d/
>
> Missing compiler intrinsics on AVR32. Problem already in the process of
> being solved (Simon, Alexander).

I think Alexander's patches have been applied now.

>>        arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/64494152b75037a1194312a2a408eb7ecb6b56c8/
>>        arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/75f2cc531892e649599681433f62a1d76e5736c9/
>>        arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/65783df07ebb447f7561cb84b1bcf581a3084748/
>>        arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/14d441c5f3a50f61cd5a872711d09fda4e5f8bbd/
>
> Forgets to link against pthread. Simon, can you link into this?

Yes, I'll have a look when I get a chance.

Simon.

[Buildroot] Analysis of build failures

[Baruch Siach]

Hi Thomas,

On Sun, Nov 10, 2013 at 09:43:19AM +0100, Thomas Petazzoni wrote:
> On Sun, 10 Nov 2013 08:25:25 +0200, Baruch Siach wrote:
> > uClibc valloc() depends on UCLIBC_SUSV2_LEGACY which is not enabled in the 
> > default uClibc config. Should we enable it?
> 
> Yes. The UCLIBC_SUSV2_LEGACY symbol was added after 0.9.33.2, so it
> explains why only Xtensa (which uses the uClibc snapshot version) is
> affected.

I see if I can cook up a patch.

> Maybe we can replace the valloc() call with posix_memalign()
> and send the patch upstream to cdrkit?

cdrkit has not see a release in more than 3 years. There are probably other 
packages making use of the obsolete valloc() routine, so I guess we want to 
enable UCLIBC_SUSV2_LEGACY anyway.

> Also, can you sync up with Chris to provide a patch that makes Xtensa
> not use a snapshot version, but a fixed version of uClibc (based on a
> git commit, for example) ? The snapshot version we currently use is
> really bad, because depending on when you run the build, you will get
> different build results. This is really not how Buildroot should work:
> snapshot versions are only provided for expert users who want to test
> the latest versions of uClibc, such versions shouldn't be used as the
> default.

The original patch of Chris adding xtensa support (75720db3, xtensa: add 
support for the Xtensa architecture) just disabled all other uClibc version 
for xtensa. The uClibc snapshot just became the version of choice by default.  
As far as I know any recent master branch commit id could reasonably be used.  
Should we add an "xtensa only" uClibc version, like the "avr32 only (0.9.31)" 
version that we now have? Hasn't Bernhard Reutner-Fischer declared some kind 
of -rc in the uclibc mailing list 
(http://lists.uclibc.org/pipermail/uclibc/2013-November/048069.html)?

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Dear Simon Dawson,

On Sun, 10 Nov 2013 10:32:29 +0000, Simon Dawson wrote:

> > The missing TLS problem on AVR32. We still haven't found the solution
> > to handle this one. As I've suggested previously, I would simply make
> > TLS support unconditional in Buildroot as soon as thread support is
> > enabled, and then mark libcap-ng as not available on AVR32. Of course,
> > if you have an external toolchain without TLS support, you're on your
> > own.
> 
> As you say, we still don't appear to have reached a consensus of
> opinion on how to solve this.

Peter, can we agree on the following solution for this:

 (1) Remove BR2_GCC_ENABLE_TLS, and enable TLS support unconditionally,
     except when thread support is not enabled.

 (2) Everywhere, assume that TLS support is always available when we
     have thread support. If it's not the case (such as AVR32), mark
     the package as "depends on !<architecture>".

Another solution is to add a config knob for the external toolchains.

> >>      avr32 |              util-linux-2.23.2 | NOK | http://autobuild.buildroot.net/results/2ba1bd78f4303ef2f543a4e4fa65d1b68ba3a765/
> >
> > Missing fallocate on avr32. Simon, what is the proposal to solve this?
> > Add fallocate support to 0.9.31 ?
> 
> Yes, I'm working on backporting fallocate support to 0.9.31 now.

Great.

> >>      avr32 |                   zeromq-3.2.4 | NOK | http://autobuild.buildroot.net/results/5cdf3e58df0df184f2ae1f2896c44f3f0f41c94d/
> >
> > Missing compiler intrinsics on AVR32. Problem already in the process of
> > being solved (Simon, Alexander).
> 
> I think Alexander's patches have been applied now.

Yes.

> >>        arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/64494152b75037a1194312a2a408eb7ecb6b56c8/
> >>        arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/75f2cc531892e649599681433f62a1d76e5736c9/
> >>        arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/65783df07ebb447f7561cb84b1bcf581a3084748/
> >>        arm | zmqpp-31220ca4a0fb43a0848d7... | NOK | http://autobuild.buildroot.net/results/14d441c5f3a50f61cd5a872711d09fda4e5f8bbd/
> >
> > Forgets to link against pthread. Simon, can you link into this?
> 
> Yes, I'll have a look when I get a chance.

Thanks!

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

[Buildroot] Analysis of build failures

[Gustavo Zacarias]

On 11/09/2013 03:15 PM, Thomas Petazzoni wrote:

>>     mipsel |                  fdk-aac-0.1.2 | NOK | http://autobuild.buildroot.net/results/cb87635832f4a1128f174a25c264f716399c52d4/
> 
> MIPS specific problem. We're building for mips1, but fdk-aac uses some
> instructions not available on mips1. Maybe we should only enable
> fdk-aac for some more capable variant of MIPS instruction sets.
> 
> Markos, can you have a look at this one?

Why not just ditch MIPS1 & MIPS2 ISAs like we did with generic ARM?
AFAIK (and Markos feel free to chime in) those aren't used in anything
modern these days, just in very very old SGI machines that didn't run
linux as far as i know.
Even MIPS3's usefulness is doubtful.
I've looked into the source and the asm optimizations are so messy that
it hurts to look at, and don't seem to be easily disabled.
Regards.

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Sun, 10 Nov 2013 07:57:07 -0300, Gustavo Zacarias wrote:

> >>     mipsel |                  fdk-aac-0.1.2 | NOK | http://autobuild.buildroot.net/results/cb87635832f4a1128f174a25c264f716399c52d4/
> > 
> > MIPS specific problem. We're building for mips1, but fdk-aac uses some
> > instructions not available on mips1. Maybe we should only enable
> > fdk-aac for some more capable variant of MIPS instruction sets.
> > 
> > Markos, can you have a look at this one?
> 
> Why not just ditch MIPS1 & MIPS2 ISAs like we did with generic ARM?
> AFAIK (and Markos feel free to chime in) those aren't used in anything
> modern these days, just in very very old SGI machines that didn't run
> linux as far as i know.
> Even MIPS3's usefulness is doubtful.

I don't have a very good vision of the MIPS space, but if Markos
agrees, I'm definitely fine with not supporting old MIPS processors
that are never used with Linux.

> I've looked into the source and the asm optimizations are so messy that
> it hurts to look at, and don't seem to be easily disabled.

Well, my idea was certainly not to fix fdk-aac itself, but simply add a
bunch of 'depends on !BR2_mips<something>' to avoid the problematic
platforms.

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

[Buildroot] Analysis of build failures

[Simon Dawson]

Hi Thomas,

On 10 November 2013 10:46, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On Sun, 10 Nov 2013 10:32:29 +0000, Simon Dawson wrote:
>> Yes, I'm working on backporting fallocate support to 0.9.31 now.
>
> Great.

Unfortunately, there is no fallocate syscall on avr32. So I think I'll
have to revert to my original plan to disable fallocate in the
util-linux package for avr32.

Simon.

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Dear Simon Dawson,

On Sun, 10 Nov 2013 11:21:14 +0000, Simon Dawson wrote:

> Unfortunately, there is no fallocate syscall on avr32. So I think I'll
> have to revert to my original plan to disable fallocate in the
> util-linux package for avr32.

Ok. I guess there will be a bunch of packages that use fallocate(), so
we'll have to mark them !BR2_avr32, or find some other trick.

Thanks,

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

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Dear Baruch Siach,

On Sun, 10 Nov 2013 12:32:35 +0200, Baruch Siach wrote:

> > Yes. The UCLIBC_SUSV2_LEGACY symbol was added after 0.9.33.2, so it
> > explains why only Xtensa (which uses the uClibc snapshot version) is
> > affected.
> 
> I see if I can cook up a patch.
> 
> > Maybe we can replace the valloc() call with posix_memalign()
> > and send the patch upstream to cdrkit?
> 
> cdrkit has not see a release in more than 3 years. There are probably other 
> packages making use of the obsolete valloc() routine, so I guess we want to 
> enable UCLIBC_SUSV2_LEGACY anyway.

Fine with me.

> > Also, can you sync up with Chris to provide a patch that makes Xtensa
> > not use a snapshot version, but a fixed version of uClibc (based on a
> > git commit, for example) ? The snapshot version we currently use is
> > really bad, because depending on when you run the build, you will get
> > different build results. This is really not how Buildroot should work:
> > snapshot versions are only provided for expert users who want to test
> > the latest versions of uClibc, such versions shouldn't be used as the
> > default.
> 
> The original patch of Chris adding xtensa support (75720db3, xtensa: add 
> support for the Xtensa architecture) just disabled all other uClibc version 
> for xtensa. The uClibc snapshot just became the version of choice by default.  
> As far as I know any recent master branch commit id could reasonably be used.  
> Should we add an "xtensa only" uClibc version, like the "avr32 only (0.9.31)" 
> version that we now have? Hasn't Bernhard Reutner-Fischer declared some kind 
> of -rc in the uclibc mailing list 
> (http://lists.uclibc.org/pipermail/uclibc/2013-November/048069.html)?

Well, seeing the activity of uClibc, I wouldn't expect an -rc version
or a stable reason any time soon.

Therefore, adding a Xtensa specific uClibc version, pinned to a
specific Git commit, seems like the best option for now.

Thanks,

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

[Buildroot] Analysis of build failures

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

>> > The missing TLS problem on AVR32. We still haven't found the solution
>> > to handle this one. As I've suggested previously, I would simply make
>> > TLS support unconditional in Buildroot as soon as thread support is
>> > enabled, and then mark libcap-ng as not available on AVR32. Of course,
>> > if you have an external toolchain without TLS support, you're on your
>> > own.
>> 
>> As you say, we still don't appear to have reached a consensus of
>> opinion on how to solve this.

> Peter, can we agree on the following solution for this:

>  (1) Remove BR2_GCC_ENABLE_TLS, and enable TLS support unconditionally,
>      except when thread support is not enabled.

>  (2) Everywhere, assume that TLS support is always available when we
>      have thread support. If it's not the case (such as AVR32), mark
>      the package as "depends on !<architecture>".

Yes, sounds sensible.

-- 
Bye, Peter Korsgaard

[Buildroot] Analysis of build failures

[Chris Zankel]

Hi Thomas,

On 11/9/13, 10:15 AM, Thomas Petazzoni wrote:
>
>>      xtensa |                  cdrkit-1.1.11 | NOK | http://autobuild.buildroot.net/results/0315c117986f3aac8c0719d744cb47ee03738ee9/
> [ 58%] Building C object libhfs_iso/CMakeFiles/hfs_iso.dir/record.o
> ../libusal/libusal.a(scsi-remote.o):(.literal+0xe0): undefined reference to `valloc'
>
> Chris, can you have a look at this one, since it's apparently a
> Xtensa-specific problem?
Looks that Baruch already found the issue (cdrkit has a very similar issue):

> cdrkit has not see a release in more than 3 years. There are probably other
> packages making use of the obsolete valloc() routine, so I guess we want to
> enable UCLIBC_SUSV2_LEGACY anyway.

I haven't seen a patch yet, so will also work on it and should have it soon.

(I'm a bit surprised to get all those errors as binutils currently 
doesn't build. Are you using an older toolchain, or are these packages 
not dependent on the final binutils build?)

Thanks,
-Chris

[Buildroot] Analysis of build failures

[Fatih Aşıcı]

On Saturday 09 November 2013 20:15:43 Thomas Petazzoni wrote:
> >       i686 |                  qt5base-5.1.1 | NOK | http://autobuild.buildroot.net/results/bbe7d79da059fdf67fb29880b8539ca2320ba86d/
> >        arm |                  qt5base-5.1.1 | NOK | http://autobuild.buildroot.net/results/37613281f21895716ceaf64654e175148d7f543c/
> >       i686 |                  qt5base-5.1.1 | NOK | http://autobuild.buildroot.net/results/555278227680e90737e6dbe0a6dcc035507150aa/
> 
> For
> http://autobuild.buildroot.net/results/37613281f21895716ceaf64654e175148d7f543c/build-end.log,
> Samuel has already sent a patch
> (http://patchwork.ozlabs.org/patch/289999/). The other two ones:
> 
>   http://autobuild.buildroot.net/results/555278227680e90737e6dbe0a6dcc035507150aa/build-end.log
>   (sqlite problem)

Needs posix_fallocate() which is not available in the test toolchain.

>   http://autobuild.buildroot.net/results/bbe7d79da059fdf67fb29880b8539ca2320ba86d/build-end.log
>   (inlining problem)

It seems this is fixed in GCC 4.7.3 [1].

> are not fixed. Fatih, would you mind having a look?
> 

Is there a method to solve such cases with custom external toolchains?

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54988

[Buildroot] Analysis of build failures

[Markos Chandras]

On 11/11/2013 09:18 AM, Markos Chandras wrote:
> Hi,>
>>> Detail of failures
>>> ===================
>>>
>>>        mips |                   aespipe-2.4c | NOK |
>>> http://autobuild.buildroot.net/results/da0268df99b9bf920d88121e7c3d33d41a57d951/
>>>
>>
>> Unknown problem (error: C compiler cannot create executables). Markos,
>> as our MIPS guy, can you have a look at this one?
>
> Ok I will
>
>>
>>>      mipsel |                  fdk-aac-0.1.2 | NOK |
>>> http://autobuild.buildroot.net/results/cb87635832f4a1128f174a25c264f716399c52d4/
>>>
>>
>> MIPS specific problem. We're building for mips1, but fdk-aac uses some
>> instructions not available on mips1. Maybe we should only enable
>> fdk-aac for some more capable variant of MIPS instruction sets.
>
> This needs for 'your-peter' branch to be merged first which contains the
> change from -mtune->-march for MIPS. I checked and that branch was still
> not merged so this will have to wait.
>
>>
>>>        mips |                      gmp-5.1.3 | NOK |
>>> http://autobuild.buildroot.net/results/69b0804cbfbb24c70f90435a37fb56a118247a57/
>>>
>>
>> configure: error: could not find a working compiler, see config.log
>> for details
>>
>> Markos, can you have a look?
> Yep
>
>>
>>>         arm |         gst1-plugins-bad-1.2.0 | NOK |
>>> http://autobuild.buildroot.net/results/b99eb6a9067cee885da88bff64ee447c37e31e0c/
>>>
>>>         arm |         gst1-plugins-bad-1.2.0 | NOK |
>>> http://autobuild.buildroot.net/results/b320bb61650c58e9c855e3136f5f6d7bf5e4ef56/
>>>
>>
>> Same problem in both cases, related to the DirectFB plugin. Peter, you
>> are the one taking care of Gstreamer most of the time, can you have a
>> look into this?
>>
>>>      x86_64 |           host-protobuf-c-0.15 | NOK |
>>> http://autobuild.buildroot.net/results/5d163e750808f2fdd8098cb58240bada12b770a9/
>>>
>>>    mips64el |           host-protobuf-c-0.15 | NOK |
>>> http://autobuild.buildroot.net/results/038340dfbbbedbcfcb98ad5dbf828bc03fe26af6/
>>>
>>
>> Weird compilation problem, seems really caused by an issue in
>> protobuf-c itself. Gustavo, you're the one who added protobuf-c, can
>> you have a look at this?
>>
>>>        bfin |                       icu-51.2 | NOK |
>>> http://autobuild.buildroot.net/results/e0a1130feb1784b3d4fefe1224943d93409a3494/
>>>
>>>        bfin |                       icu-51.2 | NOK |
>>> http://autobuild.buildroot.net/results/85c082a693ef795cecf0ef9204b7c9c0850d4b74/
>>>
>>
>> Problem building icu on Blackfin:
>>
>> *** ERROR - configure could not detect your platform
>>
>> Sonic, Zhang, can you have a look into this?
>>
>>>       avr32 |                libcap-ng-0.7.3 | NOK |
>>> http://autobuild.buildroot.net/results/3df16d60f6bbb679129cd568df4440be6f35cd9f/
>>>
>>
>> The missing TLS problem on AVR32. We still haven't found the solution
>> to handle this one. As I've suggested previously, I would simply make
>> TLS support unconditional in Buildroot as soon as thread support is
>> enabled, and then mark libcap-ng as not available on AVR32. Of course,
>> if you have an external toolchain without TLS support, you're on your
>> own.
>>
>>> microblaze |                libglib2-2.36.3 | NOK |
>>> http://autobuild.buildroot.net/results/6f0066f56f10d3f17023e698fd3ba1bd2d00c4c1/
>>>
>>> microblaze |                libglib2-2.36.3 | NOK |
>>> http://autobuild.buildroot.net/results/79d2df836063167f12f5bba177297a041bb7c16f/
>>>
>>
>> Missing compiler intrinsics and fallocate in the Microblaze toolchain.
>> We're waiting for Spenser Gilliland to finish the Microblaze internal
>> toolchain support, so that we can ditch the crappy Microblaze external
>> toolchains.
>>
>>>    mips64el |                 libiscsi-1.6.0 | NOK |
>>> http://autobuild.buildroot.net/results/39e8e0ebbeb196276492b928b41cc0b0fe1e9ec3/
>>>
>>>    mips64el |                 libiscsi-1.6.0 | NOK |
>>> http://autobuild.buildroot.net/results/efb87b17c49170f6377631371438911b18029cea/
>>>
>>
>> The usual problem of ld being used instead of gcc, causing problem on
>> mips64el. However, you can't do partial linking with gcc, so a libtool
>> fix is needed.
>>
>> Markos, I know you've identified the libtool fix for this. Could you
>> backport it on top of libtool 2.4.2 (that we have in Buildroot), add it
>> as a patch in package/libtool/, and then mark LIBISCSI_AUTORECONF =
>> YES so that the libtool stuff gets regenerated with a known-working
>> version?
>
> Yes it is on my TODO list. I tried beackporting it to Gentoo but it does
> not apply cleanly as it is. So it needs a little bit a work (not
> anything serious as far as I can tell)
>

Apologies if you got the message twice. The e-mail client messed up the 
buildroot address.

-- 
markos

[Buildroot] Analysis of build failures

[Gustavo Zacarias]

On 11/11/2013 09:26 AM, Fatih A??c? wrote:

> Probably the following change will fix it:
> 
> --- a/src/3rdparty/sqlite/sqlite3.c
> +++ b/src/3rdparty/sqlite/sqlite3.c
> @@ -22938,7 +22938,8 @@ SQLITE_PRIVATE const char *sqlite3OpcodeName(int i){
>  /* Use posix_fallocate() if it is available
>  */
>  #if !defined(HAVE_POSIX_FALLOCATE) \
> -      && (_XOPEN_SOURCE >= 600 || _POSIX_C_SOURCE >= 200112L)
> +      && (_XOPEN_SOURCE >= 600 || _POSIX_C_SOURCE >= 200112L) \
> +      && !defined(__UCLIBC__)
>  # define HAVE_POSIX_FALLOCATE 1
>  #endif
>  
> 
> 
> sqlite3's own build system (which is not available in qt) checks if 
> posix_fallocate() is available. I wonder if there is a special reason for 
> providing an option to use the built-in sqlite.

There was a bug in sqlite 3.7.17 with this, see
http://git.buildroot.net/buildroot/commit/package/sqlite?id=316f991729c423c9a49a955d3747ff31ad7a0068
It's fixed now, but a similar solution might be appropiate.
Newer uClibc versions might have posix_fallocate so excluding uClibc
might not be appropiate in the future.
Regards.

[Buildroot] Analysis of build failures

[Peter Korsgaard]

>>>>> "Markos" == Markos Chandras <Markos.Chandras@imgtec.com> writes:

Hi,

>>> mipsel |                  fdk-aac-0.1.2 | NOK | http://autobuild.buildroot.net/results/cb87635832f4a1128f174a25c264f716399c52d4/
>> 
>> MIPS specific problem. We're building for mips1, but fdk-aac uses some
>> instructions not available on mips1. Maybe we should only enable
>> fdk-aac for some more capable variant of MIPS instruction sets.

> This needs for 'your-peter' branch to be merged first which contains
> the change from -mtune->-march for MIPS. I checked and that branch was
> still not merged so this will have to wait.

But it is?

http://git.buildroot.net/buildroot/commit/?id=f60dafe06833a17540608d1c8172

-- 
Bye, Peter Korsgaard

[Buildroot] Analysis of build failures

[Markos Chandras]

On 11/11/2013 09:46 AM, Peter Korsgaard wrote:
>>>>>> "Markos" == Markos Chandras <Markos.Chandras@imgtec.com> writes:
>
> Hi,
>
>>>> mipsel |                  fdk-aac-0.1.2 | NOK | http://autobuild.buildroot.net/results/cb87635832f4a1128f174a25c264f716399c52d4/
>>>
>>> MIPS specific problem. We're building for mips1, but fdk-aac uses some
>>> instructions not available on mips1. Maybe we should only enable
>>> fdk-aac for some more capable variant of MIPS instruction sets.
>
>> This needs for 'your-peter' branch to be merged first which contains
>> the change from -mtune->-march for MIPS. I checked and that branch was
>> still not merged so this will have to wait.
>
> But it is?
>
> http://git.buildroot.net/buildroot/commit/?id=f60dafe06833a17540608d1c8172
>

Yes sorry I didn't notice :)

-- 
markos

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Dear Chris Zankel,

On Sun, 10 Nov 2013 21:33:16 -0800, Chris Zankel wrote:

> (I'm a bit surprised to get all those errors as binutils currently 
> doesn't build. Are you using an older toolchain, or are these packages 
> not dependent on the final binutils build?)

The binutils issues you're seeing are while building native binutils
for the target, not when building cross-binutils for the cross
compilation toolchain. Building the cross-binutils works ok, because
they are built against the build machine C library, which is glibc and
therefore has obstack stuff.

Best regards,

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

[Buildroot] Analysis of build failures

[Will Newton]

On Sat, Nov 9, 2013 at 6:15 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello all,
>
> If you're Cc'ed on this e-mail, it means that there is a question for
> you below. Here is a summary of who should look at what problems (note
> that some problems are not affected to anyone, either because the
> reason is unknown or because there is no clear "owner" for the problem):
>
> Markos Chandras                 aespipe, fdk-aac, gmp, libiscsi
> Sonic Zhang, Aaron Wu           boost, icu, openpgm
> Chris Zankel                    cdrkit
> Peter Korsgaard                 gst1-plugins-bad, pulseaudio
> Gustavo Zacarias                protobuf-c, mplayer, nettle (ARM), php
> Simon Dawson                    libcap-ng, util-linux, zeromq, zmqpp
> Spenser Gilliland               libglib2, nettle (Microblaze), openssl
> Ezequiel Garcia                 libnspr
> Mischa Jonker                   pulseaudio, ti-utils
> Fatih A??c?                     qt5base
> Tzu-Jung Lee                    tstools
>
> Thanks!
>
> Thomas
>
> On Sat,  9 Nov 2013 08:30:28 +0100 (CET), Thomas Petazzoni wrote:
>
>> Detail of failures
>> ===================
>>
>>       mips |                   aespipe-2.4c | NOK | http://autobuild.buildroot.net/results/da0268df99b9bf920d88121e7c3d33d41a57d951/
>
> Unknown problem (error: C compiler cannot create executables). Markos,
> as our MIPS guy, can you have a look at this one?
>
>>        arm |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/983828bd27a521020e42e58cce9393e6b8d23502/
>
> It was a wrong toolchain configuration, with a weird toolchain.
> I've removed the toolchain from the autobuilders.
>
>>    powerpc |              alsa-utils-1.0.26 | NOK | http://autobuild.buildroot.net/results/1c6a33e75fe0617e01d7413cdfd5fbd466f822d4/
>
> Missing link against -lrt for static linking.
>
>>        arm |              alsa-utils-1.0.26 | NOK | http://autobuild.buildroot.net/results/6123186a66bbea833ab2fa980346f16825b22d21/
>
> checking for snd_ctl_open in -lasound... no
> configure: error: No linkable libasound was found.
> make: *** [/home/test/test/3/output/build/alsa-utils-1.0.26/.stamp_configured] Error 1
>
> Weird, don't know what's happening here.
>
>>        arm |                audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/6aff0a6b9c7b2890cc069868b041ed74e549933b/
>
> This was my funky toolchain (same as alsa-lib problem above). Toolchain
> removed from the autobuilders.
>
>>     xtensa |                  binutils-2.22 | NOK | http://autobuild.buildroot.net/results/11de6f161585c12148c1b2b4fc8ab830183edfe9/
>>     xtensa |                  binutils-2.22 | NOK | http://autobuild.buildroot.net/results/2d3d255b2d3ae1456a377dbc03f695b7adf010e8/
>
> This is fixed by http://patchwork.ozlabs.org/patch/289532/, which
> hasn't been committed yet. It will also require a rebuild of the
> toolchain in the autobuilders.
>
> Peter, can you commit this patch?
>
>>       bfin |                   boost-1.54.0 | NOK | http://autobuild.buildroot.net/results/84f9d9d2b6b5356984c6d59aad5e28b3e7847651/
>
> Don't know what's going on. Sonic, Aaron, can you have a look?
>
>>        arm |                 busybox-1.21.1 | NOK | http://autobuild.buildroot.net/results/116d13f7489981c39c3759eaf8302be4d795f339/
>
> This was my weird toolchain (same problem as alsa-lib). Toolchain
> removed from the autobuilders.
>
>>     xtensa |                  cdrkit-1.1.11 | NOK | http://autobuild.buildroot.net/results/0315c117986f3aac8c0719d744cb47ee03738ee9/
>
> [ 58%] Building C object libhfs_iso/CMakeFiles/hfs_iso.dir/record.o
> ../libusal/libusal.a(scsi-remote.o):(.literal+0xe0): undefined reference to `valloc'
>
> Chris, can you have a look at this one, since it's apparently a
> Xtensa-specific problem?
>
>>     mipsel |                  fdk-aac-0.1.2 | NOK | http://autobuild.buildroot.net/results/cb87635832f4a1128f174a25c264f716399c52d4/
>
> MIPS specific problem. We're building for mips1, but fdk-aac uses some
> instructions not available on mips1. Maybe we should only enable
> fdk-aac for some more capable variant of MIPS instruction sets.
>
> Markos, can you have a look at this one?
>
>>       bfin |               fontconfig-2.6.0 | NOK | http://autobuild.buildroot.net/results/8579cb481e86dcae0988379c5781bd00f4e70809/
>
> fontconfig forgets to link against libpng. Anyone willing to fix this?
>
>>       mips |                      gmp-5.1.3 | NOK | http://autobuild.buildroot.net/results/69b0804cbfbb24c70f90435a37fb56a118247a57/
>
> configure: error: could not find a working compiler, see config.log for details
>
> Markos, can you have a look?
>
>>        arm |         gst1-plugins-bad-1.2.0 | NOK | http://autobuild.buildroot.net/results/b99eb6a9067cee885da88bff64ee447c37e31e0c/
>>        arm |         gst1-plugins-bad-1.2.0 | NOK | http://autobuild.buildroot.net/results/b320bb61650c58e9c855e3136f5f6d7bf5e4ef56/
>
> Same problem in both cases, related to the DirectFB plugin. Peter, you
> are the one taking care of Gstreamer most of the time, can you have a
> look into this?
>
>>     x86_64 |           host-protobuf-c-0.15 | NOK | http://autobuild.buildroot.net/results/5d163e750808f2fdd8098cb58240bada12b770a9/
>>   mips64el |           host-protobuf-c-0.15 | NOK | http://autobuild.buildroot.net/results/038340dfbbbedbcfcb98ad5dbf828bc03fe26af6/
>
> Weird compilation problem, seems really caused by an issue in
> protobuf-c itself. Gustavo, you're the one who added protobuf-c, can
> you have a look at this?
>
>>       bfin |                       icu-51.2 | NOK | http://autobuild.buildroot.net/results/e0a1130feb1784b3d4fefe1224943d93409a3494/
>>       bfin |                       icu-51.2 | NOK | http://autobuild.buildroot.net/results/85c082a693ef795cecf0ef9204b7c9c0850d4b74/
>
> Problem building icu on Blackfin:
>
> *** ERROR - configure could not detect your platform
>
> Sonic, Zhang, can you have a look into this?
>
>>      avr32 |                libcap-ng-0.7.3 | NOK | http://autobuild.buildroot.net/results/3df16d60f6bbb679129cd568df4440be6f35cd9f/
>
> The missing TLS problem on AVR32. We still haven't found the solution
> to handle this one. As I've suggested previously, I would simply make
> TLS support unconditional in Buildroot as soon as thread support is
> enabled, and then mark libcap-ng as not available on AVR32. Of course,
> if you have an external toolchain without TLS support, you're on your
> own.
>
>> microblaze |                libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/6f0066f56f10d3f17023e698fd3ba1bd2d00c4c1/
>> microblaze |                libglib2-2.36.3 | NOK | http://autobuild.buildroot.net/results/79d2df836063167f12f5bba177297a041bb7c16f/
>
> Missing compiler intrinsics and fallocate in the Microblaze toolchain.
> We're waiting for Spenser Gilliland to finish the Microblaze internal
> toolchain support, so that we can ditch the crappy Microblaze external
> toolchains.
>
>>   mips64el |                 libiscsi-1.6.0 | NOK | http://autobuild.buildroot.net/results/39e8e0ebbeb196276492b928b41cc0b0fe1e9ec3/
>>   mips64el |                 libiscsi-1.6.0 | NOK | http://autobuild.buildroot.net/results/efb87b17c49170f6377631371438911b18029cea/
>
> The usual problem of ld being used instead of gcc, causing problem on
> mips64el. However, you can't do partial linking with gcc, so a libtool
> fix is needed.
>
> Markos, I know you've identified the libtool fix for this. Could you
> backport it on top of libtool 2.4.2 (that we have in Buildroot), add it
> as a patch in package/libtool/, and then mark LIBISCSI_AUTORECONF =
> YES so that the libtool stuff gets regenerated with a known-working
> version?
>
>>      nios2 |                  libnspr-4.9.6 | NOK | http://autobuild.buildroot.net/results/8c01fdaac7afa00bd1117c79ae047344242d1463/
>>      nios2 |                  libnspr-4.9.6 | NOK | http://autobuild.buildroot.net/results/a418145d72e92f64956518bb2786e33dadd08a86/
>
> NIOS2 support missing in libnspr. Ezequiel, can you look into this?
> Normally, adding an architecture support in libnspr is really easy, so
> adding a patch to libnspr should be feasible.
>
>>    aarch64 |                   libv4l-0.8.9 | NOK | http://autobuild.buildroot.net/results/4de7dc58e826d1dd60add2821f774c9c5f5a2a71/
>
> Package needs to be bumped, I have already started working on this.
>
>>        arm |                  mplayer-1.1.1 | NOK | http://autobuild.buildroot.net/results/8f946e28b11b2ab1ba0d9688286c665488de0486/
>
> libmpeg2/motion_comp_arm_s.S: Assembler messages:
> libmpeg2/motion_comp_arm_s.S:29: Error: selected processor does not support ARM mode `pld [r1]'
> libmpeg2/motion_comp_arm_s.S:39: Error: selected processor does not support ARM mode `pld [r1]'
>
> That's an ARMv4t configuration. Maybe building mplayer on ARMv4t is not
> possible. Adding a bunch of depends on !BR2_arm<something> is probably
> the solution here. Gustavo, maybe?
>
>>        arm | ne10-88c18f02199947b2c8b577... | NOK | http://autobuild.buildroot.net/results/3631f7e9dad9fab356d31160ac95b7d0fec70ce2/
>
> Needs NEON support apparently. Should be something for me.
>
>> microblaze |                   nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/82acbea862ee0bb5288ab498d86772bc475d3a53/
>>        arm |                   nettle-2.7.1 | NOK | http://autobuild.buildroot.net/results/88ea0cc0815f865e1a144d39231fdc9b47e689b0/
>
> On Microblaze, a compiler error. Should be fixed by the internal
> toolchain support for Microblaze. Waiting for Spenser on this :)
>
> On ARM, the failure is due to nettle tests requiring C++ support. It
> would be good to disable the compilation of those tests. Gustavo,
> you're the one looking after nettle in general, can you look into this?
>
>>       bfin |           openpgm-5.1.118~dfsg | NOK | http://autobuild.buildroot.net/results/120b7de960a04def5c53b59644eefc598bd0a1d4/
>
> Blackfin does not have getifaddrs():
>
> getifaddrs.c:853:3: error: #error "Unsupported interface enumeration on this platform."
>
> Not sure how to handle this uClibc configuration difference, except by
> adding "depends on !" to exclude the specific Blackfin toolchains
> causing problems.
>
>> microblaze |                 openssl-1.0.1e | NOK | http://autobuild.buildroot.net/results/f313ac3233a8ed5b3087936c1cd8408a00fdf2bb/
>
> Compiler error. Spenser, we need your patches!
>
>>    aarch64 |                     php-5.3.27 | NOK | http://autobuild.buildroot.net/results/08d3255303f7ceda8a1ecfcf56ad665f00829632/
>
> /usr/include/bits/predefs.h:20:3: error: #error "Never use <bits/predefs.h> directly; include <features.h> instead."
>  # error "Never use <bits/predefs.h> directly; include <features.h> instead."
>
> Gustavo, you like PHP, no ? :-)
>
>>        arc |                 pulseaudio-4.0 | NOK | http://autobuild.buildroot.net/results/281ff1c8046b7e93759c5f51995f34788e717fad/
>
> checking for atomic_ops.h... no
> configure: error: *** libatomic-ops headers not found
> make: *** [/home/test/test/1/output/build/pulseaudio-4.0/.stamp_configured] Error 1
>
> For some reason, on ARC, atomic_ops is needed. Why not on other
> architectures? Peter, Mischa, any idea?
>
>>    powerpc |                       qt-4.8.5 | NOK | http://autobuild.buildroot.net/results/0ee61f71e61f2215a15e4655a4e22d0521334c35/
>
> Will be fixed by my patch that prevents building parts of Qt on some
> unsupported architectures.
>
>>       i686 |                  qt5base-5.1.1 | NOK | http://autobuild.buildroot.net/results/bbe7d79da059fdf67fb29880b8539ca2320ba86d/
>>        arm |                  qt5base-5.1.1 | NOK | http://autobuild.buildroot.net/results/37613281f21895716ceaf64654e175148d7f543c/
>>       i686 |                  qt5base-5.1.1 | NOK | http://autobuild.buildroot.net/results/555278227680e90737e6dbe0a6dcc035507150aa/
>
> For
> http://autobuild.buildroot.net/results/37613281f21895716ceaf64654e175148d7f543c/build-end.log,
> Samuel has already sent a patch
> (http://patchwork.ozlabs.org/patch/289999/). The other two ones:
>
>   http://autobuild.buildroot.net/results/555278227680e90737e6dbe0a6dcc035507150aa/build-end.log
>   (sqlite problem)
>
>   http://autobuild.buildroot.net/results/bbe7d79da059fdf67fb29880b8539ca2320ba86d/build-end.log
>   (inlining problem)
>
> are not fixed. Fatih, would you mind having a look?
>
>>        arc | ti-utils-06dbdb2727354b5f3a... | NOK | http://autobuild.buildroot.net/results/63d294574b053aa4e2148fbc3185c5594d925ae9/
>
> {standard input}: Assembler messages:
> {standard input}:1680: Error: missing operand
> {standard input}:1680: Error: junk at end of line: `@plt_tx_bip.part.8'
>
> ARC toolchain problem, for Mischa.
>
>>     x86_64 |                   tstools-1_11 | NOK | http://autobuild.buildroot.net/results/ce02d7fb9ae3aa06eaf53db39cbef27c051b525d/
>
> Should use gcc for linking and not ld + missing -lm. Tzu-Jung Lee,
> you're the one who added tstools, can you have a look at this problem?
>
>>      avr32 |              util-linux-2.23.2 | NOK | http://autobuild.buildroot.net/results/2ba1bd78f4303ef2f543a4e4fa65d1b68ba3a765/
>
> Missing fallocate on avr32. Simon, what is the proposal to solve this?
> Add fallocate support to 0.9.31 ?
>
>>        arm |                 valgrind-3.8.1 | NOK | http://autobuild.buildroot.net/results/f174541ac06aeeac82b8399686a8d4371532760d/
>
> /tmp/cceJNtCh.s: Assembler messages:
> /tmp/cceJNtCh.s:200: Error: r15 not allowed here -- `str r15,[r3,#+0]'
> make[4]: *** [libcoregrind_arm_linux_a-m_libcassert.o] Error 1
> make[4]: *** Waiting for unfinished jobs....
>
> Not sure what's going on here. Anyone to have a look?

valgrind uses inline assembly that is not Thumb compatible. It seems
it isn't expected to build it in Thumb mode (although it emulates
Thumb mode). It might be quite simple to fix but would need
coordination with upstream etc.

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Dear Fatih A??c?,

On Mon, 11 Nov 2013 11:14:51 +0200, Fatih A??c? wrote:

> >   http://autobuild.buildroot.net/results/555278227680e90737e6dbe0a6dcc035507150aa/build-end.log
> >   (sqlite problem)
> 
> Needs posix_fallocate() which is not available in the test toolchain.

Except that posix_fallocate() is not available in uClibc. It is indeed
available in the internal toolchain backend, due to a patch that we
have added, but we cannot assume it will be available in external
uClibc toolchains that may not have the same of patches applied.

Moreover, the sqlite3.c code in Qt seems to have some code to handle
the absence of posix_fallocate():

#if defined(HAVE_POSIX_FALLOCATE) && HAVE_POSIX_FALLOCATE
  { "fallocate",    (sqlite3_syscall_ptr)posix_fallocate,  0 },
#else
  { "fallocate",    (sqlite3_syscall_ptr)0,                0 },
#endif

It would be nice to have a look at why HAVE_POSIX_FALLOCATE is defined
even though posix_fallocate() is not available.

> >   http://autobuild.buildroot.net/results/bbe7d79da059fdf67fb29880b8539ca2320ba86d/build-end.log
> >   (inlining problem)
> 
> It seems this is fixed in GCC 4.7.3 [1].

Ok.

> > are not fixed. Fatih, would you mind having a look?
> > 
> 
> Is there a method to solve such cases with custom external toolchains?

No, there isn't a really good way. Possibilities are:

 (1) Add an exception to my autobuilder scripts, and document this
    exception (i.e gcc version <foo> fails to build qt5base).

 (2) Rebuild the toolchain with a newer ct-ng and therefore a newer
     gcc, and forget about the problem :-) I anyway desperately need to
     rebuild the Crosstool-NG toolchains used in the autobuilders.

Best regards,

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

[Buildroot] Analysis of build failures

[Baruch Siach]

Hi Thomas,

On Mon, Nov 11, 2013 at 10:58:30AM +0100, Thomas Petazzoni wrote:
> On Sun, 10 Nov 2013 21:33:16 -0800, Chris Zankel wrote:
> > (I'm a bit surprised to get all those errors as binutils currently doesn't 
> > build. Are you using an older toolchain, or are these packages not 
> > dependent on the final binutils build?)
> 
> The binutils issues you're seeing are while building native binutils
> for the target, not when building cross-binutils for the cross
> compilation toolchain. Building the cross-binutils works ok, because
> they are built against the build machine C library, which is glibc and
> therefore has obstack stuff.

Why do we need binutils on target?

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Dear Baruch Siach,

On Mon, 11 Nov 2013 12:10:53 +0200, Baruch Siach wrote:

> On Mon, Nov 11, 2013 at 10:58:30AM +0100, Thomas Petazzoni wrote:
> > On Sun, 10 Nov 2013 21:33:16 -0800, Chris Zankel wrote:
> > > (I'm a bit surprised to get all those errors as binutils currently doesn't 
> > > build. Are you using an older toolchain, or are these packages not 
> > > dependent on the final binutils build?)
> > 
> > The binutils issues you're seeing are while building native binutils
> > for the target, not when building cross-binutils for the cross
> > compilation toolchain. Building the cross-binutils works ok, because
> > they are built against the build machine C library, which is glibc and
> > therefore has obstack stuff.
> 
> Why do we need binutils on target?

$ git grep "select BR2_PACKAGE_BINUTILS"
package/dropwatch/Config.in:	select BR2_PACKAGE_BINUTILS
package/oprofile/Config.in:	select BR2_PACKAGE_BINUTILS

So we need it for dropwatch and oprofile. In fact, what is needed is
not the full binutils (i.e the binutils programs), but the libbfd
library which is part of the binutils tarball.

Best regards,

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

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Dear Will Newton,

On Mon, 11 Nov 2013 10:01:17 +0000, Will Newton wrote:

> >>        arm |                 valgrind-3.8.1 | NOK | http://autobuild.buildroot.net/results/f174541ac06aeeac82b8399686a8d4371532760d/
> >
> > /tmp/cceJNtCh.s: Assembler messages:
> > /tmp/cceJNtCh.s:200: Error: r15 not allowed here -- `str r15,[r3,#+0]'
> > make[4]: *** [libcoregrind_arm_linux_a-m_libcassert.o] Error 1
> > make[4]: *** Waiting for unfinished jobs....
> >
> > Not sure what's going on here. Anyone to have a look?
> 
> valgrind uses inline assembly that is not Thumb compatible. It seems
> it isn't expected to build it in Thumb mode (although it emulates
> Thumb mode). It might be quite simple to fix but would need
> coordination with upstream etc.

Are you talking about Thumb, or Thumb-2 ? Because here the
configuration has:

BR2_arm=y
BR2_cortex_a8=y
BR2_TARGET_OPTIMIZATION="-mthumb"

so it's an ARMv7-A with -mthumb, so that means Thumb-2, right?

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

[Buildroot] Analysis of build failures

[Baruch Siach]

Hi Thomas,

On Mon, Nov 11, 2013 at 11:15:46AM +0100, Thomas Petazzoni wrote:
> On Mon, 11 Nov 2013 12:10:53 +0200, Baruch Siach wrote:
> > On Mon, Nov 11, 2013 at 10:58:30AM +0100, Thomas Petazzoni wrote:
> > > On Sun, 10 Nov 2013 21:33:16 -0800, Chris Zankel wrote:
> > > > (I'm a bit surprised to get all those errors as binutils currently doesn't 
> > > > build. Are you using an older toolchain, or are these packages not 
> > > > dependent on the final binutils build?)
> > > 
> > > The binutils issues you're seeing are while building native binutils
> > > for the target, not when building cross-binutils for the cross
> > > compilation toolchain. Building the cross-binutils works ok, because
> > > they are built against the build machine C library, which is glibc and
> > > therefore has obstack stuff.
> > 
> > Why do we need binutils on target?
> 
> $ git grep "select BR2_PACKAGE_BINUTILS"
> package/dropwatch/Config.in:	select BR2_PACKAGE_BINUTILS
> package/oprofile/Config.in:	select BR2_PACKAGE_BINUTILS
> 
> So we need it for dropwatch and oprofile. In fact, what is needed is
> not the full binutils (i.e the binutils programs), but the libbfd
> library which is part of the binutils tarball.

This is strange. More than half of xtensa autobuilds used to fail on target 
binutils before Chris' obstack fix. Does this mean that all failing configs 
had dropwatch or oprofile enabled?

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] Analysis of build failures

[Will Newton]

On Mon, Nov 11, 2013 at 10:17 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Will Newton,
>
> On Mon, 11 Nov 2013 10:01:17 +0000, Will Newton wrote:
>
>> >>        arm |                 valgrind-3.8.1 | NOK | http://autobuild.buildroot.net/results/f174541ac06aeeac82b8399686a8d4371532760d/
>> >
>> > /tmp/cceJNtCh.s: Assembler messages:
>> > /tmp/cceJNtCh.s:200: Error: r15 not allowed here -- `str r15,[r3,#+0]'
>> > make[4]: *** [libcoregrind_arm_linux_a-m_libcassert.o] Error 1
>> > make[4]: *** Waiting for unfinished jobs....
>> >
>> > Not sure what's going on here. Anyone to have a look?
>>
>> valgrind uses inline assembly that is not Thumb compatible. It seems
>> it isn't expected to build it in Thumb mode (although it emulates
>> Thumb mode). It might be quite simple to fix but would need
>> coordination with upstream etc.
>
> Are you talking about Thumb, or Thumb-2 ? Because here the
> configuration has:
>
> BR2_arm=y
> BR2_cortex_a8=y
> BR2_TARGET_OPTIMIZATION="-mthumb"
>
> so it's an ARMv7-A with -mthumb, so that means Thumb-2, right?

Yes, Thumb-2. Only those crazy microcontroller guys care about Thumb-1. ;-)

ARM ARM A8.8.203 is the relevant page, Thumb-2 cannot store pc/r15
directly. It should be possible to use a temporary to achieve the same
effect but it would need thorough testing.

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Dear Baruch Siach,

On Mon, 11 Nov 2013 12:20:50 +0200, Baruch Siach wrote:

> > > Why do we need binutils on target?
> > 
> > $ git grep "select BR2_PACKAGE_BINUTILS"
> > package/dropwatch/Config.in:	select BR2_PACKAGE_BINUTILS
> > package/oprofile/Config.in:	select BR2_PACKAGE_BINUTILS
> > 
> > So we need it for dropwatch and oprofile. In fact, what is needed is
> > not the full binutils (i.e the binutils programs), but the libbfd
> > library which is part of the binutils tarball.
> 
> This is strange. More than half of xtensa autobuilds used to fail on target 
> binutils before Chris' obstack fix. Does this mean that all failing configs 
> had dropwatch or oprofile enabled?

Or that they had BR2_PACKAGE_BINUTILS enabled itself. So I took my poor
SQL knowledge and came up with the following query to answer your
question:

select results.id,status,builddate,identifier,arch,reason,results_config.name,results_config.value
	from results
	inner join results_config on results.id=results_config.resultid
	where
		results.arch='xtensa' and
		results.reason like 'binutils%' and
		results.builddate >= '2013-10-01' and
		(results_config.name='BR2_PACKAGE_BINUTILS' or results_config.name='BR2_PACKAGE_DROPWATCH' or results_config.name='BR2_PACKAGE_OPROFILE');

which gives the list of xtensa build results that failed on binutils,
since October 1st, and for each of those builds, give the value of the
binutils, dropwatch and oprofile options. So in the below table, you
have 3 consecutive lines for a given build, each of those 3 lines
corresponding to dropwatch,oprofile and binutils. As you can see, for
each of those builds, BR2_PACKAGE_BINUTILS was always set to 'y', and
sometimes either or both of oprofile and dropwatch were also enabled.

I kind of like the type of questions I can now answer by having the
full set of config options for each build part of the SQL database :-)

+-------+--------+---------------------+------------------------------------------+--------+-----------------+-----------------------+-------+
| id    | status | builddate           | identifier                               | arch   | reason          | name                  | value |
+-------+--------+---------------------+------------------------------------------+--------+-----------------+-----------------------+-------+
| 71059 |      1 | 2013-10-01 20:48:10 | 0cd166469449b2fa224277a1be6997af8ff2488d | xtensa | binutils-2.21.1 | BR2_PACKAGE_DROPWATCH |       |
| 71059 |      1 | 2013-10-01 20:48:10 | 0cd166469449b2fa224277a1be6997af8ff2488d | xtensa | binutils-2.21.1 | BR2_PACKAGE_OPROFILE  | y     |
| 71059 |      1 | 2013-10-01 20:48:10 | 0cd166469449b2fa224277a1be6997af8ff2488d | xtensa | binutils-2.21.1 | BR2_PACKAGE_BINUTILS  | y     |
| 71076 |      1 | 2013-10-01 23:09:35 | 2cfd80795aa9c7556e572f8d344c4f512c80f232 | xtensa | binutils-2.21.1 | BR2_PACKAGE_DROPWATCH |       |
| 71076 |      1 | 2013-10-01 23:09:35 | 2cfd80795aa9c7556e572f8d344c4f512c80f232 | xtensa | binutils-2.21.1 | BR2_PACKAGE_OPROFILE  | y     |
| 71076 |      1 | 2013-10-01 23:09:35 | 2cfd80795aa9c7556e572f8d344c4f512c80f232 | xtensa | binutils-2.21.1 | BR2_PACKAGE_BINUTILS  | y     |
| 71161 |      1 | 2013-10-02 19:13:40 | 8244788b518211947cd850e97ab80c43426a07a3 | xtensa | binutils-2.21.1 | BR2_PACKAGE_DROPWATCH |       |
| 71161 |      1 | 2013-10-02 19:13:40 | 8244788b518211947cd850e97ab80c43426a07a3 | xtensa | binutils-2.21.1 | BR2_PACKAGE_OPROFILE  | y     |
| 71161 |      1 | 2013-10-02 19:13:40 | 8244788b518211947cd850e97ab80c43426a07a3 | xtensa | binutils-2.21.1 | BR2_PACKAGE_BINUTILS  | y     |
| 71218 |      1 | 2013-10-03 03:40:15 | 6c0cb311739fb0ea3b835c946090296bf3c8eb5f | xtensa | binutils-2.21.1 | BR2_PACKAGE_DROPWATCH |       |
| 71218 |      1 | 2013-10-03 03:40:15 | 6c0cb311739fb0ea3b835c946090296bf3c8eb5f | xtensa | binutils-2.21.1 | BR2_PACKAGE_OPROFILE  | y     |
| 71218 |      1 | 2013-10-03 03:40:15 | 6c0cb311739fb0ea3b835c946090296bf3c8eb5f | xtensa | binutils-2.21.1 | BR2_PACKAGE_BINUTILS  | y     |
| 71494 |      1 | 2013-10-05 02:37:45 | cdd334ae490646c6367315668fff68feee03a4a2 | xtensa | binutils-2.21.1 | BR2_PACKAGE_DROPWATCH | y     |
| 71494 |      1 | 2013-10-05 02:37:45 | cdd334ae490646c6367315668fff68feee03a4a2 | xtensa | binutils-2.21.1 | BR2_PACKAGE_OPROFILE  |       |
| 71494 |      1 | 2013-10-05 02:37:45 | cdd334ae490646c6367315668fff68feee03a4a2 | xtensa | binutils-2.21.1 | BR2_PACKAGE_BINUTILS  | y     |
| 71534 |      1 | 2013-10-05 10:12:54 | 9d6f624cd22fcf2cf113dfd3a3097c88f5e77612 | xtensa | binutils-2.21.1 | BR2_PACKAGE_DROPWATCH |       |
| 71534 |      1 | 2013-10-05 10:12:54 | 9d6f624cd22fcf2cf113dfd3a3097c88f5e77612 | xtensa | binutils-2.21.1 | BR2_PACKAGE_OPROFILE  | y     |
| 71534 |      1 | 2013-10-05 10:12:54 | 9d6f624cd22fcf2cf113dfd3a3097c88f5e77612 | xtensa | binutils-2.21.1 | BR2_PACKAGE_BINUTILS  | y     |
| 71606 |      1 | 2013-10-05 20:32:09 | 436f1f897efb09bfc910b88b7396deaa9c67e158 | xtensa | binutils-2.21.1 | BR2_PACKAGE_DROPWATCH | y     |
| 71606 |      1 | 2013-10-05 20:32:09 | 436f1f897efb09bfc910b88b7396deaa9c67e158 | xtensa | binutils-2.21.1 | BR2_PACKAGE_OPROFILE  |       |
| 71606 |      1 | 2013-10-05 20:32:09 | 436f1f897efb09bfc910b88b7396deaa9c67e158 | xtensa | binutils-2.21.1 | BR2_PACKAGE_BINUTILS  | y     |
| 71831 |      1 | 2013-10-07 16:06:10 | a6f8c67f60b13bab89c8bd2ca88d3407eead2b61 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 71831 |      1 | 2013-10-07 16:06:10 | a6f8c67f60b13bab89c8bd2ca88d3407eead2b61 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 71831 |      1 | 2013-10-07 16:06:10 | a6f8c67f60b13bab89c8bd2ca88d3407eead2b61 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 71926 |      1 | 2013-10-08 09:12:43 | b46524626cab681167253d68c45f0eed091a347c | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 71926 |      1 | 2013-10-08 09:12:43 | b46524626cab681167253d68c45f0eed091a347c | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 71926 |      1 | 2013-10-08 09:12:43 | b46524626cab681167253d68c45f0eed091a347c | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 72116 |      1 | 2013-10-09 14:52:26 | 98f65001a4a1dc1382630c232ffb43514f7482c5 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 72116 |      1 | 2013-10-09 14:52:26 | 98f65001a4a1dc1382630c232ffb43514f7482c5 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 72116 |      1 | 2013-10-09 14:52:26 | 98f65001a4a1dc1382630c232ffb43514f7482c5 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 72123 |      1 | 2013-10-09 15:40:15 | 45d1546b5dab74dc9e9a52d6c9ad1f3f2957eae4 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 72123 |      1 | 2013-10-09 15:40:15 | 45d1546b5dab74dc9e9a52d6c9ad1f3f2957eae4 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  | y     |
| 72123 |      1 | 2013-10-09 15:40:15 | 45d1546b5dab74dc9e9a52d6c9ad1f3f2957eae4 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 72140 |      1 | 2013-10-09 18:32:06 | d90aa26a8ac309694f5dbf3fc546f6d6c9af434c | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 72140 |      1 | 2013-10-09 18:32:06 | d90aa26a8ac309694f5dbf3fc546f6d6c9af434c | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 72140 |      1 | 2013-10-09 18:32:06 | d90aa26a8ac309694f5dbf3fc546f6d6c9af434c | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 72148 |      1 | 2013-10-09 19:15:32 | f31b2093399685498ee92873517bfa65ea366860 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH | y     |
| 72148 |      1 | 2013-10-09 19:15:32 | f31b2093399685498ee92873517bfa65ea366860 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 72148 |      1 | 2013-10-09 19:15:32 | f31b2093399685498ee92873517bfa65ea366860 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 72295 |      1 | 2013-10-10 21:50:50 | 38a1dea49373fd4f4da95621f716f8c9324e0d0c | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 72295 |      1 | 2013-10-10 21:50:50 | 38a1dea49373fd4f4da95621f716f8c9324e0d0c | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  | y     |
| 72295 |      1 | 2013-10-10 21:50:50 | 38a1dea49373fd4f4da95621f716f8c9324e0d0c | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 72404 |      1 | 2013-10-11 18:52:26 | 6d5754d10af24d8e9528878548be1d4f25a1f730 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 72404 |      1 | 2013-10-11 18:52:26 | 6d5754d10af24d8e9528878548be1d4f25a1f730 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 72404 |      1 | 2013-10-11 18:52:26 | 6d5754d10af24d8e9528878548be1d4f25a1f730 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 72540 |      1 | 2013-10-12 18:07:08 | bf8614dbfd930f0fd1678cf97da8cd125b0502c6 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 72540 |      1 | 2013-10-12 18:07:08 | bf8614dbfd930f0fd1678cf97da8cd125b0502c6 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  | y     |
| 72540 |      1 | 2013-10-12 18:07:08 | bf8614dbfd930f0fd1678cf97da8cd125b0502c6 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 72691 |      1 | 2013-10-13 19:50:44 | d3ce520b2ee273c7dde62ec8527ba9ac9ed11a9e | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH | y     |
| 72691 |      1 | 2013-10-13 19:50:44 | d3ce520b2ee273c7dde62ec8527ba9ac9ed11a9e | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  | y     |
| 72691 |      1 | 2013-10-13 19:50:44 | d3ce520b2ee273c7dde62ec8527ba9ac9ed11a9e | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 72889 |      1 | 2013-10-15 00:03:02 | 02c9b14ab7cd784fb09b9bc02ade6238b3761588 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 72889 |      1 | 2013-10-15 00:03:02 | 02c9b14ab7cd784fb09b9bc02ade6238b3761588 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  | y     |
| 72889 |      1 | 2013-10-15 00:03:02 | 02c9b14ab7cd784fb09b9bc02ade6238b3761588 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 72944 |      1 | 2013-10-15 12:30:11 | 8c20156bb4d8be909ae1367e1e8e043867d477ae | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH | y     |
| 72944 |      1 | 2013-10-15 12:30:11 | 8c20156bb4d8be909ae1367e1e8e043867d477ae | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 72944 |      1 | 2013-10-15 12:30:11 | 8c20156bb4d8be909ae1367e1e8e043867d477ae | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 72990 |      1 | 2013-10-15 18:36:49 | 1fa265c9cdda8c79cf3ccf9fa9ca6cfaff160bd8 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH | y     |
| 72990 |      1 | 2013-10-15 18:36:49 | 1fa265c9cdda8c79cf3ccf9fa9ca6cfaff160bd8 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 72990 |      1 | 2013-10-15 18:36:49 | 1fa265c9cdda8c79cf3ccf9fa9ca6cfaff160bd8 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 73068 |      1 | 2013-10-16 11:21:00 | 52b30beeec9af53dcaee98c1e6ab430b8328f7a3 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH | y     |
| 73068 |      1 | 2013-10-16 11:21:00 | 52b30beeec9af53dcaee98c1e6ab430b8328f7a3 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  | y     |
| 73068 |      1 | 2013-10-16 11:21:00 | 52b30beeec9af53dcaee98c1e6ab430b8328f7a3 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 73157 |      1 | 2013-10-16 21:39:23 | 3af486e2291d5f18ce6c22404a1f7e1e6d8546a1 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 73157 |      1 | 2013-10-16 21:39:23 | 3af486e2291d5f18ce6c22404a1f7e1e6d8546a1 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  | y     |
| 73157 |      1 | 2013-10-16 21:39:23 | 3af486e2291d5f18ce6c22404a1f7e1e6d8546a1 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 73248 |      1 | 2013-10-17 10:41:08 | cfbbae2f39385582fcd4dcf3d7a6f8d065208ff3 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 73248 |      1 | 2013-10-17 10:41:08 | cfbbae2f39385582fcd4dcf3d7a6f8d065208ff3 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  | y     |
| 73248 |      1 | 2013-10-17 10:41:08 | cfbbae2f39385582fcd4dcf3d7a6f8d065208ff3 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 73490 |      1 | 2013-10-18 20:35:00 | 63a8f4d34ef97a7ac1ec0fce4d6425827f4de5fd | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH | y     |
| 73490 |      1 | 2013-10-18 20:35:00 | 63a8f4d34ef97a7ac1ec0fce4d6425827f4de5fd | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 73490 |      1 | 2013-10-18 20:35:00 | 63a8f4d34ef97a7ac1ec0fce4d6425827f4de5fd | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 73566 |      1 | 2013-10-19 06:34:07 | df47ef18beab5ea00d880ef25922e688fe93ca88 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH | y     |
| 73566 |      1 | 2013-10-19 06:34:07 | df47ef18beab5ea00d880ef25922e688fe93ca88 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 73566 |      1 | 2013-10-19 06:34:07 | df47ef18beab5ea00d880ef25922e688fe93ca88 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 73697 |      1 | 2013-10-20 03:52:11 | 615495c9a3d55e2c3f46d3cc86678453ecd95ec6 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 73697 |      1 | 2013-10-20 03:52:11 | 615495c9a3d55e2c3f46d3cc86678453ecd95ec6 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  | y     |
| 73697 |      1 | 2013-10-20 03:52:11 | 615495c9a3d55e2c3f46d3cc86678453ecd95ec6 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 73732 |      1 | 2013-10-20 09:11:20 | 4a73f7380d493359ca1593a5c6a5cc8d11fb7cf7 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 73732 |      1 | 2013-10-20 09:11:20 | 4a73f7380d493359ca1593a5c6a5cc8d11fb7cf7 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 73732 |      1 | 2013-10-20 09:11:20 | 4a73f7380d493359ca1593a5c6a5cc8d11fb7cf7 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 73812 |      1 | 2013-10-20 21:59:28 | 1fefa8b4fc1dc22e3667b25b0d93d3f30424629f | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 73812 |      1 | 2013-10-20 21:59:28 | 1fefa8b4fc1dc22e3667b25b0d93d3f30424629f | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  | y     |
| 73812 |      1 | 2013-10-20 21:59:28 | 1fefa8b4fc1dc22e3667b25b0d93d3f30424629f | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 73979 |      1 | 2013-10-22 01:58:24 | 3318ee1e074b9e9fca9e2815e220313cc9a00021 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 73979 |      1 | 2013-10-22 01:58:24 | 3318ee1e074b9e9fca9e2815e220313cc9a00021 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  | y     |
| 73979 |      1 | 2013-10-22 01:58:24 | 3318ee1e074b9e9fca9e2815e220313cc9a00021 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 74121 |      1 | 2013-10-22 23:34:05 | c9581efea42eb4a6d14952d616ae2cf049c3ed47 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 74121 |      1 | 2013-10-22 23:34:05 | c9581efea42eb4a6d14952d616ae2cf049c3ed47 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 74121 |      1 | 2013-10-22 23:34:05 | c9581efea42eb4a6d14952d616ae2cf049c3ed47 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 74141 |      1 | 2013-10-23 04:03:55 | fdc5d439987d988cb14f58726443f2bb41d0b1cb | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH | y     |
| 74141 |      1 | 2013-10-23 04:03:55 | fdc5d439987d988cb14f58726443f2bb41d0b1cb | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 74141 |      1 | 2013-10-23 04:03:55 | fdc5d439987d988cb14f58726443f2bb41d0b1cb | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 74322 |      1 | 2013-10-24 13:02:54 | 7b0798f139e81b054e72c08cc16ff337bbe36a2b | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 74322 |      1 | 2013-10-24 13:02:54 | 7b0798f139e81b054e72c08cc16ff337bbe36a2b | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 74322 |      1 | 2013-10-24 13:02:54 | 7b0798f139e81b054e72c08cc16ff337bbe36a2b | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 74386 |      1 | 2013-10-24 22:30:39 | 7806239e9e9161f03d3e658dcf18090b21eb8e65 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 74386 |      1 | 2013-10-24 22:30:39 | 7806239e9e9161f03d3e658dcf18090b21eb8e65 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  | y     |
| 74386 |      1 | 2013-10-24 22:30:39 | 7806239e9e9161f03d3e658dcf18090b21eb8e65 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 74420 |      1 | 2013-10-25 06:19:41 | f3f9fedfc92b125fa2dbe10c5e3f72db3fdfb7a9 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH | y     |
| 74420 |      1 | 2013-10-25 06:19:41 | f3f9fedfc92b125fa2dbe10c5e3f72db3fdfb7a9 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  | y     |
| 74420 |      1 | 2013-10-25 06:19:41 | f3f9fedfc92b125fa2dbe10c5e3f72db3fdfb7a9 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 74424 |      1 | 2013-10-25 07:05:26 | 687a233c574de8c95ddb9187b8fdd72be0d07902 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 74424 |      1 | 2013-10-25 07:05:26 | 687a233c574de8c95ddb9187b8fdd72be0d07902 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 74424 |      1 | 2013-10-25 07:05:26 | 687a233c574de8c95ddb9187b8fdd72be0d07902 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 74469 |      1 | 2013-10-25 15:38:14 | d232d06b5ab9a7b1c5a4d76a79b3794cde8e2274 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 74469 |      1 | 2013-10-25 15:38:14 | d232d06b5ab9a7b1c5a4d76a79b3794cde8e2274 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  | y     |
| 74469 |      1 | 2013-10-25 15:38:14 | d232d06b5ab9a7b1c5a4d76a79b3794cde8e2274 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 74625 |      1 | 2013-10-26 21:12:23 | 9782922ab3fbda9471043d08efb88da1fcb1024a | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 74625 |      1 | 2013-10-26 21:12:23 | 9782922ab3fbda9471043d08efb88da1fcb1024a | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  | y     |
| 74625 |      1 | 2013-10-26 21:12:23 | 9782922ab3fbda9471043d08efb88da1fcb1024a | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 74984 |      1 | 2013-10-30 01:22:40 | 39ac33c0e325d5e8009337f0cfc83dc364e9c463 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH | y     |
| 74984 |      1 | 2013-10-30 01:22:40 | 39ac33c0e325d5e8009337f0cfc83dc364e9c463 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 74984 |      1 | 2013-10-30 01:22:40 | 39ac33c0e325d5e8009337f0cfc83dc364e9c463 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 75346 |      1 | 2013-11-01 19:16:34 | 6f209b4e3e6eade884eb37c5c761b42e83e3da74 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 75346 |      1 | 2013-11-01 19:16:34 | 6f209b4e3e6eade884eb37c5c761b42e83e3da74 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  | y     |
| 75346 |      1 | 2013-11-01 19:16:34 | 6f209b4e3e6eade884eb37c5c761b42e83e3da74 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 75411 |      1 | 2013-11-02 04:36:54 | d16d73a716ca0f3e6c16fe23ef748707495eb787 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH | y     |
| 75411 |      1 | 2013-11-02 04:36:54 | d16d73a716ca0f3e6c16fe23ef748707495eb787 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  | y     |
| 75411 |      1 | 2013-11-02 04:36:54 | d16d73a716ca0f3e6c16fe23ef748707495eb787 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 75489 |      1 | 2013-11-02 19:51:45 | 32b011100f96d3462d98b365591bf2422f4d3ec3 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 75489 |      1 | 2013-11-02 19:51:45 | 32b011100f96d3462d98b365591bf2422f4d3ec3 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  | y     |
| 75489 |      1 | 2013-11-02 19:51:45 | 32b011100f96d3462d98b365591bf2422f4d3ec3 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 75497 |      1 | 2013-11-02 21:18:31 | 3939930a693ab7f244ed81d295898fad15f60700 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH | y     |
| 75497 |      1 | 2013-11-02 21:18:31 | 3939930a693ab7f244ed81d295898fad15f60700 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 75497 |      1 | 2013-11-02 21:18:31 | 3939930a693ab7f244ed81d295898fad15f60700 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 75660 |      1 | 2013-11-03 23:41:57 | e514a5122b2524453dff8d5617be4b8de65c544c | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH | y     |
| 75660 |      1 | 2013-11-03 23:41:57 | e514a5122b2524453dff8d5617be4b8de65c544c | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 75660 |      1 | 2013-11-03 23:41:57 | e514a5122b2524453dff8d5617be4b8de65c544c | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 75689 |      1 | 2013-11-04 04:04:59 | 02796a47a03fc36ce1dfa476a6145be47f283a18 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 75689 |      1 | 2013-11-04 04:04:59 | 02796a47a03fc36ce1dfa476a6145be47f283a18 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 75689 |      1 | 2013-11-04 04:04:59 | 02796a47a03fc36ce1dfa476a6145be47f283a18 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 75704 |      1 | 2013-11-04 06:42:55 | f30943e20af19b5c7eba642febc8018c2a60a9fe | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 75704 |      1 | 2013-11-04 06:42:55 | f30943e20af19b5c7eba642febc8018c2a60a9fe | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  | y     |
| 75704 |      1 | 2013-11-04 06:42:55 | f30943e20af19b5c7eba642febc8018c2a60a9fe | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 75758 |      1 | 2013-11-04 16:29:13 | 7dafb56700cb86bd4c20e397cd6e6d568229be2d | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 75758 |      1 | 2013-11-04 16:29:13 | 7dafb56700cb86bd4c20e397cd6e6d568229be2d | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  | y     |
| 75758 |      1 | 2013-11-04 16:29:13 | 7dafb56700cb86bd4c20e397cd6e6d568229be2d | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 76035 |      1 | 2013-11-07 01:02:15 | 1bb18ff3037e5b73e7b504e14bfd396d42917c5b | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH | y     |
| 76035 |      1 | 2013-11-07 01:02:15 | 1bb18ff3037e5b73e7b504e14bfd396d42917c5b | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 76035 |      1 | 2013-11-07 01:02:15 | 1bb18ff3037e5b73e7b504e14bfd396d42917c5b | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 76084 |      1 | 2013-11-07 13:35:59 | 6a5f5cbf6e3f59f7563b6f7d0f59a56a2fdbe8dc | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 76084 |      1 | 2013-11-07 13:35:59 | 6a5f5cbf6e3f59f7563b6f7d0f59a56a2fdbe8dc | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 76084 |      1 | 2013-11-07 13:35:59 | 6a5f5cbf6e3f59f7563b6f7d0f59a56a2fdbe8dc | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 76200 |      1 | 2013-11-08 13:43:54 | 2d3d255b2d3ae1456a377dbc03f695b7adf010e8 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH | y     |
| 76200 |      1 | 2013-11-08 13:43:54 | 2d3d255b2d3ae1456a377dbc03f695b7adf010e8 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 76200 |      1 | 2013-11-08 13:43:54 | 2d3d255b2d3ae1456a377dbc03f695b7adf010e8 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 76219 |      1 | 2013-11-08 16:54:15 | 11de6f161585c12148c1b2b4fc8ab830183edfe9 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 76219 |      1 | 2013-11-08 16:54:15 | 11de6f161585c12148c1b2b4fc8ab830183edfe9 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  | y     |
| 76219 |      1 | 2013-11-08 16:54:15 | 11de6f161585c12148c1b2b4fc8ab830183edfe9 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 76361 |      1 | 2013-11-09 18:53:59 | a476260a0fff7ae7502e858b30943d9067fb1214 | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 76361 |      1 | 2013-11-09 18:53:59 | a476260a0fff7ae7502e858b30943d9067fb1214 | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 76361 |      1 | 2013-11-09 18:53:59 | a476260a0fff7ae7502e858b30943d9067fb1214 | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
| 76463 |      1 | 2013-11-10 14:13:26 | 4f6f05293c61906b169ddfcd9a239cc9393b626e | xtensa | binutils-2.22   | BR2_PACKAGE_DROPWATCH |       |
| 76463 |      1 | 2013-11-10 14:13:26 | 4f6f05293c61906b169ddfcd9a239cc9393b626e | xtensa | binutils-2.22   | BR2_PACKAGE_OPROFILE  |       |
| 76463 |      1 | 2013-11-10 14:13:26 | 4f6f05293c61906b169ddfcd9a239cc9393b626e | xtensa | binutils-2.22   | BR2_PACKAGE_BINUTILS  | y     |
+-------+--------+---------------------+------------------------------------------+--------+-----------------+-----------------------+-------+

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

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Dear Will Newton,

On Mon, 11 Nov 2013 10:25:27 +0000, Will Newton wrote:

> Yes, Thumb-2. Only those crazy microcontroller guys care about Thumb-1. ;-)
> 
> ARM ARM A8.8.203 is the relevant page, Thumb-2 cannot store pc/r15
> directly. It should be possible to use a temporary to achieve the same
> effect but it would need thorough testing.

So I guess we need to disable valgrind on Thumb-2, or make it build
with ARM instructions even on Thumb-2 builds. Or bump Valgrind and see
if the new version is fixed for Thumb-2.

Best regards,

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

[Buildroot] Analysis of build failures

[Ezequiel García]

Thomas,

On 9 November 2013 15:15, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:

>
>>      nios2 |                  libnspr-4.9.6 | NOK | http://autobuild.buildroot.net/results/8c01fdaac7afa00bd1117c79ae047344242d1463/
>>      nios2 |                  libnspr-4.9.6 | NOK | http://autobuild.buildroot.net/results/a418145d72e92f64956518bb2786e33dadd08a86/
>
> NIOS2 support missing in libnspr. Ezequiel, can you look into this?
> Normally, adding an architecture support in libnspr is really easy, so
> adding a patch to libnspr should be feasible.
>

Right. Would you accept a "builds-only" patch for it?
I'm not familiar with libnspr and it seems it's only loosely used
through libnss in BR.
-- 
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar

[Buildroot] Analysis of build failures

[Peter Korsgaard]

>>>>> "Ezequiel" == Ezequiel Garc?a <ezequiel@vanguardiasur.com.ar> writes:

Hi,

>> NIOS2 support missing in libnspr. Ezequiel, can you look into this?
>> Normally, adding an architecture support in libnspr is really easy, so
>> adding a patch to libnspr should be feasible.
>> 

> Right. Would you accept a "builds-only" patch for it?
> I'm not familiar with libnspr and it seems it's only loosely used
> through libnss in BR.

Yes. Even if you cannot do any runtime tests, it will most likely be OK
and is in any case a step forward compared to a build failure.

-- 
Bye, Peter Korsgaard

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Dear Ezequiel Garc?a,

On Mon, 11 Nov 2013 09:25:03 -0200, Ezequiel Garc?a wrote:

> On 9 November 2013 15:15, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> 
> >
> >>      nios2 |                  libnspr-4.9.6 | NOK | http://autobuild.buildroot.net/results/8c01fdaac7afa00bd1117c79ae047344242d1463/
> >>      nios2 |                  libnspr-4.9.6 | NOK | http://autobuild.buildroot.net/results/a418145d72e92f64956518bb2786e33dadd08a86/
> >
> > NIOS2 support missing in libnspr. Ezequiel, can you look into this?
> > Normally, adding an architecture support in libnspr is really easy, so
> > adding a patch to libnspr should be feasible.
> 
> Right. Would you accept a "builds-only" patch for it?
> I'm not familiar with libnspr and it seems it's only loosely used
> through libnss in BR.

I'm personally fine with that, especially since I don't believe the
patch is going to be really big or strange.

Maybe you can even submit the patch upstream? Upstream seems to be
active, latest release is from the end of september.

Thanks!

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

[Buildroot] Analysis of build failures

[Fatih Aşıcı]

On Monday 11 November 2013 12:09:06 Thomas Petazzoni wrote:
> Dear Fatih A??c?,
> 
> On Mon, 11 Nov 2013 11:14:51 +0200, Fatih A??c? wrote:
> > >   http://autobuild.buildroot.net/results/555278227680e90737e6dbe0a6dcc0
> > >   35507150aa/build-end.log (sqlite problem)
> > 
> > Needs posix_fallocate() which is not available in the test toolchain.
> 
> Except that posix_fallocate() is not available in uClibc. It is indeed
> available in the internal toolchain backend, due to a patch that we
> have added, but we cannot assume it will be available in external
> uClibc toolchains that may not have the same of patches applied.
> 
> Moreover, the sqlite3.c code in Qt seems to have some code to handle
> the absence of posix_fallocate():
> 
> #if defined(HAVE_POSIX_FALLOCATE) && HAVE_POSIX_FALLOCATE
>   { "fallocate",    (sqlite3_syscall_ptr)posix_fallocate,  0 },
> #else
>   { "fallocate",    (sqlite3_syscall_ptr)0,                0 },
> #endif
> 
> It would be nice to have a look at why HAVE_POSIX_FALLOCATE is defined
> even though posix_fallocate() is not available.

Probably the following change will fix it:

--- a/src/3rdparty/sqlite/sqlite3.c
+++ b/src/3rdparty/sqlite/sqlite3.c
@@ -22938,7 +22938,8 @@ SQLITE_PRIVATE const char *sqlite3OpcodeName(int i){
 /* Use posix_fallocate() if it is available
 */
 #if !defined(HAVE_POSIX_FALLOCATE) \
-      && (_XOPEN_SOURCE >= 600 || _POSIX_C_SOURCE >= 200112L)
+      && (_XOPEN_SOURCE >= 600 || _POSIX_C_SOURCE >= 200112L) \
+      && !defined(__UCLIBC__)
 # define HAVE_POSIX_FALLOCATE 1
 #endif
 


sqlite3's own build system (which is not available in qt) checks if 
posix_fallocate() is available. I wonder if there is a special reason for 
providing an option to use the built-in sqlite.

[Buildroot] [PATCH] tstools: fix build (link) error

[Tzu-Jung Lee]

Signed-off-by: Tzu-Jung Lee <tjlee@ambarella.com>
---
 ...x-a-build-error-linking-of-shared-library.patch | 23 ++++++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 package/tstools/tstools-003-build-fix-a-build-error-linking-of-shared-library.patch

diff --git a/package/tstools/tstools-003-build-fix-a-build-error-linking-of-shared-library.patch b/package/tstools/tstools-003-build-fix-a-build-error-linking-of-shared-library.patch
new file mode 100644
index 0000000..e87413f
--- /dev/null
+++ b/package/tstools/tstools-003-build-fix-a-build-error-linking-of-shared-library.patch
@@ -0,0 +1,23 @@
+From 1f83d1aa7f3abc75faeb31f169f1162e11168e16 Mon Sep 17 00:00:00 2001
+From: Tzu-Jung Lee <tjlee@ambarella.com>
+Date: Mon, 11 Nov 2013 14:16:11 -0800
+Subject: [PATCH] build: fix a build error (linking of shared library)
+
+Signed-off-by: Tzu-Jung Lee <tjlee@ambarella.com>
+
+diff --git a/Makefile b/Makefile
+index ad7f163..83ff416 100644
+--- a/Makefile
++++ b/Makefile
+@@ -203,7 +203,7 @@ $(STATIC_LIB): $(OBJS)
+ 	ar rc $(STATIC_LIB) $(OBJS)
+ 
+ $(SHARED_LIB): $(OBJS)
+-	$(LD) -shared -o $(SHARED_LIB) $(OBJS) -lc
++	$(CC) -shared -o $(SHARED_LIB) $(OBJS) -lc
+ endif
+ 
+ # Build all of the utilities with the static library, so that they can
+-- 
+1.8.4.3
+
-- 
1.8.4.3

[Buildroot] [PATCH] tstools: fix build (link) error

[Peter Korsgaard]

>>>>> "Tzu-Jung" == Tzu-Jung Lee <roylee17@gmail.com> writes:

> Signed-off-by: Tzu-Jung Lee <tjlee@ambarella.com>
> ---
>  ...x-a-build-error-linking-of-shared-library.patch | 23 ++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
>  create mode 100644 package/tstools/tstools-003-build-fix-a-build-error-linking-of-shared-library.patch

> diff --git a/package/tstools/tstools-003-build-fix-a-build-error-linking-of-shared-library.patch b/package/tstools/tstools-003-build-fix-a-build-error-linking-of-shared-library.patch
> new file mode 100644
> index 0000000..e87413f
> --- /dev/null
> +++ b/package/tstools/tstools-003-build-fix-a-build-error-linking-of-shared-library.patch
> @@ -0,0 +1,23 @@
> +From 1f83d1aa7f3abc75faeb31f169f1162e11168e16 Mon Sep 17 00:00:00 2001
> +From: Tzu-Jung Lee <tjlee@ambarella.com>
> +Date: Mon, 11 Nov 2013 14:16:11 -0800
> +Subject: [PATCH] build: fix a build error (linking of shared library)

It would be good to explain in more detail (and/or add a link to an
autobuild failure).

For this kind of issue we normally just pass LD="$(TARGET_CC)" to make
instead of patching the Makefile, so I've committed a fix doing that,
thanks.

-- 
Bye, Peter Korsgaard