[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-11

[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-11

[Thomas Petazzoni]

Build statistics for 2014-05-11
===============================

        success : 87 
       failures : 32 
       timeouts : 0  
          TOTAL : 119

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

                protobuf-2.5.0 | 6 
           host-protobuf-2.5.0 | 4 
                 cairo-1.12.10 | 4 
             lttng-tools-2.4.1 | 2 
                    sdl-1.2.15 | 2 
                 host-gdb-6.6a | 1 
                  libeio-1.7.7 | 1 
             armadillo-4.000.4 | 1 
                 webkit-1.11.5 | 1 
            btrfs-progs-3.14.1 | 1 
                     lsof-4.85 | 1 
             alsa-utils-1.0.26 | 1 
                  cppcms-1.0.4 | 1 
                    crda-1.1.3 | 1 
               alsa-lib-1.0.26 | 1 
                elfutils-0.155 | 1 
          glibc-2.18-svnr23787 | 1 
jack2-ab409a65df95bc261ff72... | 1 
                aiccu-20070115 | 1 

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

     nios2 |                 aiccu-20070115 | NOK | http://autobuild.buildroot.net/results/7864cd5789a9f9b9f0603d738f4e63822d8469dd/
   powerpc |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/6a89535c0806939dcb6d4160899bd242a0648fb8/
    mipsel |              alsa-utils-1.0.26 | NOK | http://autobuild.buildroot.net/results/8ca7fb8e4b1da8c1a7e4d646469779e4032877ab/
      bfin |              armadillo-4.000.4 | NOK | http://autobuild.buildroot.net/results/a28df0ba10803e6e54c2f8160bbd8190cba4d690/
     avr32 |             btrfs-progs-3.14.1 | NOK | http://autobuild.buildroot.net/results/06501fd32c30549810c12f0ad50f510c4b74ee63/
microblazeel |                  cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/f94aa7382de01decbf0cd24f00a4ad4c0da1d5af/
      i686 |                  cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/036601736a9d593f7731cefff24a6364e95b5550/
   powerpc |                  cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/f1ca1a8f7ca8456003c6f17e146151a99835c4c0/
       arm |                  cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/9b7870354d70e27e42d3d9c1f131ab54706bf20e/
     avr32 |                   cppcms-1.0.4 | NOK | http://autobuild.buildroot.net/results/a26574419aacbea4140dfca1d503bcab599edd71/
     nios2 |                     crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/272f18410e4855ab6b3bfd8a44243c1ebecf6abe/
      bfin |                 elfutils-0.155 | NOK | http://autobuild.buildroot.net/results/993247d885172e64eea4f630558633a6ee488986/
   aarch64 |           glibc-2.18-svnr23787 | NOK | http://autobuild.buildroot.net/results/01a23f0f014cfa6d28d65756437ac044adfae206/
      bfin |                  host-gdb-6.6a | NOK | http://autobuild.buildroot.net/results/67708ae5907a5330bc1d06d38281357b0856922f/
      i686 |            host-protobuf-2.5.0 | NOK | http://autobuild.buildroot.net/results/c2955bd85f98106692a849858ea4947bf7bcc1fb/
      i686 |            host-protobuf-2.5.0 | NOK | http://autobuild.buildroot.net/results/7d628f590a5a99f6fff97c02db6197789c7e01d1/
      i686 |            host-protobuf-2.5.0 | NOK | http://autobuild.buildroot.net/results/76173e148207d1238cb970c69d2c35151f1fd468/
      i686 |            host-protobuf-2.5.0 | NOK | http://autobuild.buildroot.net/results/a2ebc5745a3f16d5b7090a7414ffd0c1d535b022/
    x86_64 | jack2-ab409a65df95bc261ff72... | NOK | http://autobuild.buildroot.net/results/ca81fb8e31a976513772970358f8d399bebc8fa8/
       arm |                   libeio-1.7.7 | NOK | http://autobuild.buildroot.net/results/27854bf8425d64dbb475653161bbf1f386173366/
       arm |                      lsof-4.85 | NOK | http://autobuild.buildroot.net/results/a1f0572dbf968c21f70b35cefff7ef7a1d9a348a/
       arm |              lttng-tools-2.4.1 | NOK | http://autobuild.buildroot.net/results/908ba3ab5a830696dea649f1623f74579083f4c8/
       arm |              lttng-tools-2.4.1 | NOK | http://autobuild.buildroot.net/results/71978ab25e521e4b06337a98d9a4aeb73c710b53/
      sh4a |                 protobuf-2.5.0 | NOK | http://autobuild.buildroot.net/results/f935c159dcafe7fd31caaddfeb93f75ddf6fa903/
   powerpc |                 protobuf-2.5.0 | NOK | http://autobuild.buildroot.net/results/d0014fc462016361e0f33707932f5fce7d8fd832/
   powerpc |                 protobuf-2.5.0 | NOK | http://autobuild.buildroot.net/results/d63de54ae546f434a4872da0ccc1f9cc685fd8b6/
       sh4 |                 protobuf-2.5.0 | NOK | http://autobuild.buildroot.net/results/400895373468b137138a0522bc00800b80ac3526/
   powerpc |                 protobuf-2.5.0 | NOK | http://autobuild.buildroot.net/results/071ad52698e199eb762387d22ae83d8e6635e20c/
   powerpc |                 protobuf-2.5.0 | NOK | http://autobuild.buildroot.net/results/1d65724a1206ec15842f7704b63c7ebd4c99d077/
   powerpc |                     sdl-1.2.15 | NOK | http://autobuild.buildroot.net/results/05d6d0bd1b001fb7027589768cbb25cd0d18f52b/
   powerpc |                     sdl-1.2.15 | NOK | http://autobuild.buildroot.net/results/e3765ce8f7f02045e7fe8bd578735bdd5499288e/
    mipsel |                  webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/070a19eb24f0b3d1516679ed3e2d1a54dae2d7cf/


-- 
http://autobuild.buildroot.net

[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-11

[Thomas Petazzoni]

Hello,

On Mon, 12 May 2014 08:30:08 +0200 (CEST), Thomas Petazzoni wrote:

>      nios2 |                 aiccu-20070115 | NOK | http://autobuild.buildroot.net/results/7864cd5789a9f9b9f0603d738f4e63822d8469dd/

Will be fixed once http://patchwork.ozlabs.org/patch/348125/ is
committed.

>    powerpc |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/6a89535c0806939dcb6d4160899bd242a0648fb8/

uClibc static linking issue.

>     mipsel |              alsa-utils-1.0.26 | NOK | http://autobuild.buildroot.net/results/8ca7fb8e4b1da8c1a7e4d646469779e4032877ab/

/home/test/test/2/output/host/usr/mipsel-buildroot-linux-uclibc/sysroot/usr/lib/libasound.a(control_shm.o): In function `_snd_ctl_shm_open':
control_shm.c:(.text+0x1550): warning: gethostbyname is obsolescent, use getnameinfo() instead.
/home/test/test/2/output/host/usr/mipsel-buildroot-linux-uclibc/sysroot/usr/lib/libasound.a(rawmidi_symbols.o):(.data.rel+0x4): undefined reference to `_snd_module_rawmidi_virt'
collect2: error: ld returned 1 exit status

>       bfin |              armadillo-4.000.4 | NOK | http://autobuild.buildroot.net/results/a28df0ba10803e6e54c2f8160bbd8190cba4d690/

Weird stuff going on. Samuel?

>      avr32 |             btrfs-progs-3.14.1 | NOK | http://autobuild.buildroot.net/results/06501fd32c30549810c12f0ad50f510c4b74ee63/

Gustavo? Probably simply exclude btrfs-progs from avr32 ?

> microblazeel |                  cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/f94aa7382de01decbf0cd24f00a4ad4c0da1d5af/

Some Microblaze person? Waldemar maybe?

>       i686 |                  cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/036601736a9d593f7731cefff24a6364e95b5550/

Should be fixed by:

  http://git.buildroot.net/buildroot/commit/?id=b11289752e5f862afeced9f34bfab2e6a521b776
  http://git.buildroot.net/buildroot/commit/?id=c95a30471da61bd8b1396d85fd4401c0cf7901c8

>    powerpc |                  cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/f1ca1a8f7ca8456003c6f17e146151a99835c4c0/

/home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/powerpc-buildroot-linux-uclibc/4.7.3/../../../../powerpc-buildroot-linux-uclibc/bin/ld: attempted static link of dynamic object `/home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/powerpc-buildroot-linux-uclibc/4.7.3/../../../../powerpc-buildroot-linux-uclibc/lib/libstdc++.so'

Gustavo, what is the status on this issue?

>        arm |                  cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/9b7870354d70e27e42d3d9c1f131ab54706bf20e/

Caused by the selection of multiple different providers: rpi for
OpenVG, gpu-viv-bin-mx6q for EGL and mesa3d for GLES. In discussion
with Yann.

>      avr32 |                   cppcms-1.0.4 | NOK | http://autobuild.buildroot.net/results/a26574419aacbea4140dfca1d503bcab599edd71/

Fixed by http://git.buildroot.net/buildroot/commit/?id=f015ad1c7b7453b38b19356882d434254f23b9cf.

>      nios2 |                     crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/272f18410e4855ab6b3bfd8a44243c1ebecf6abe/

Fixed by http://git.buildroot.net/buildroot/commit/?id=f287f0aab695b2a36bd1abc776e2ccfddee6c3fb.

>       bfin |                 elfutils-0.155 | NOK | http://autobuild.buildroot.net/results/993247d885172e64eea4f630558633a6ee488986/

{standard input}: Assembler messages:
{standard input}:4: Error: syntax error. Input text was _compat.elfutils_0.122.dwarf_bytesize.
{standard input}:4: Error: 
make[4]: *** [dwarf_bytesize.os] Error 1

>    aarch64 |           glibc-2.18-svnr23787 | NOK | http://autobuild.buildroot.net/results/01a23f0f014cfa6d28d65756437ac044adfae206/

I tried to investigate this again yesterday, but I'm still unable to
reproduce :/

>       bfin |                  host-gdb-6.6a | NOK | http://autobuild.buildroot.net/results/67708ae5907a5330bc1d06d38281357b0856922f/

configure: error: "*** Gdb does not support target bfin-buildroot-uclinux-uclibc"

Hum, that's weird, we have gdb 6.6 specifically for Blackfin. Maybe
more recent gdb versions have Blackfin support and we could drop 6.6 ?

>       i686 |            host-protobuf-2.5.0 | NOK | http://autobuild.buildroot.net/results/c2955bd85f98106692a849858ea4947bf7bcc1fb/
>       i686 |            host-protobuf-2.5.0 | NOK | http://autobuild.buildroot.net/results/7d628f590a5a99f6fff97c02db6197789c7e01d1/
>       i686 |            host-protobuf-2.5.0 | NOK | http://autobuild.buildroot.net/results/76173e148207d1238cb970c69d2c35151f1fd468/
>       i686 |            host-protobuf-2.5.0 | NOK | http://autobuild.buildroot.net/results/a2ebc5745a3f16d5b7090a7414ffd0c1d535b022/

Fixed by http://git.buildroot.net/buildroot/commit/?id=0f6fca606134b81c13a9cd03169158a24e3346f5.

>     x86_64 | jack2-ab409a65df95bc261ff72... | NOK | http://autobuild.buildroot.net/results/ca81fb8e31a976513772970358f8d399bebc8fa8/

Rather weird:

The project was not configured: run "waf configure" first!
make: *** [/home/test/test/1/output/build/jack2-ab409a65df95bc261ff72b52d6b3f4a65cf3266a/.stamp_built] Error 1

>        arm |                   libeio-1.7.7 | NOK | http://autobuild.buildroot.net/results/27854bf8425d64dbb475653161bbf1f386173366/

Fixed by http://git.buildroot.net/buildroot/commit/?id=7ed76d5427639987bfdf22ecf2cd10cdea1e8f95.

>        arm |                      lsof-4.85 | NOK | http://autobuild.buildroot.net/results/a1f0572dbf968c21f70b35cefff7ef7a1d9a348a/

Missing TCP_* definitions. Weird because the toolchain has recent
kernel headers (3.12) and uses glibc. Investigation needed.

>        arm |              lttng-tools-2.4.1 | NOK | http://autobuild.buildroot.net/results/908ba3ab5a830696dea649f1623f74579083f4c8/

Fixed by http://git.buildroot.net/buildroot/commit/?id=85082cab93b282021006ddee63793403b90ffe1f.

>        arm |              lttng-tools-2.4.1 | NOK | http://autobuild.buildroot.net/results/71978ab25e521e4b06337a98d9a4aeb73c710b53/

Same bug, but different toolchain. I'll have to add an exception in the
autobuilders, it seems. And Crosstool-NG should carry a fix for PR58595.

>       sh4a |                 protobuf-2.5.0 | NOK | http://autobuild.buildroot.net/results/f935c159dcafe7fd31caaddfeb93f75ddf6fa903/
>    powerpc |                 protobuf-2.5.0 | NOK | http://autobuild.buildroot.net/results/d0014fc462016361e0f33707932f5fce7d8fd832/
>    powerpc |                 protobuf-2.5.0 | NOK | http://autobuild.buildroot.net/results/d63de54ae546f434a4872da0ccc1f9cc685fd8b6/
>        sh4 |                 protobuf-2.5.0 | NOK | http://autobuild.buildroot.net/results/400895373468b137138a0522bc00800b80ac3526/
>    powerpc |                 protobuf-2.5.0 | NOK | http://autobuild.buildroot.net/results/071ad52698e199eb762387d22ae83d8e6635e20c/
>    powerpc |                 protobuf-2.5.0 | NOK | http://autobuild.buildroot.net/results/1d65724a1206ec15842f7704b63c7ebd4c99d077/

Fixed by
http://git.buildroot.net/buildroot/commit/?id=8677473035cc3e02281c8998c25d6dfa071f3b54.

>    powerpc |                     sdl-1.2.15 | NOK | http://autobuild.buildroot.net/results/05d6d0bd1b001fb7027589768cbb25cd0d18f52b/
>    powerpc |                     sdl-1.2.15 | NOK | http://autobuild.buildroot.net/results/e3765ce8f7f02045e7fe8bd578735bdd5499288e/

Another gcc issue.

>     mipsel |                  webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/070a19eb24f0b3d1516679ed3e2d1a54dae2d7cf/

OpenGL issue:

 /home/test/test/3/output/host/opt/ext-toolchain/bin/../lib/gcc/mipsel-buildroot-linux-uclibc/4.7.3/../../../../mipsel-buildroot-linux-uclibc/bin/ld: cannot find -lGL

Bernd maybe?

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

[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-11

[Baruch Siach]

Hi Thomas,

On Tue, May 13, 2014 at 09:44:26AM +0200, Thomas Petazzoni wrote:
> >        arm |                      lsof-4.85 | NOK | http://autobuild.buildroot.net/results/a1f0572dbf968c21f70b35cefff7ef7a1d9a348a/
> 
> Missing TCP_* definitions. Weird because the toolchain has recent
> kernel headers (3.12) and uses glibc. Investigation needed.

http://patchwork.ozlabs.org/patch/345018/ seems applicable (but I didn't test).

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] [autobuild.buildroot.net] Build results for 2014-05-11

[Thomas Petazzoni]

Dear Baruch Siach,

On Tue, 13 May 2014 10:52:47 +0300, Baruch Siach wrote:

> On Tue, May 13, 2014 at 09:44:26AM +0200, Thomas Petazzoni wrote:
> > >        arm |                      lsof-4.85 | NOK | http://autobuild.buildroot.net/results/a1f0572dbf968c21f70b35cefff7ef7a1d9a348a/
> > 
> > Missing TCP_* definitions. Weird because the toolchain has recent
> > kernel headers (3.12) and uses glibc. Investigation needed.
> 
> http://patchwork.ozlabs.org/patch/345018/ seems applicable (but I didn't test).

Indeed, but I'm not really convinced by the fix, seems strange that
--sysroot needs to be passed. More investigation is needed to validate
the proposed fix, I believe.

Thanks,

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

[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-11

[Baruch Siach]

On Tue, May 13, 2014 at 10:01:02AM +0200, Thomas Petazzoni wrote:
> On Tue, 13 May 2014 10:52:47 +0300, Baruch Siach wrote:
> 
> > On Tue, May 13, 2014 at 09:44:26AM +0200, Thomas Petazzoni wrote:
> > > >        arm |                      lsof-4.85 | NOK | http://autobuild.buildroot.net/results/a1f0572dbf968c21f70b35cefff7ef7a1d9a348a/
> > > 
> > > Missing TCP_* definitions. Weird because the toolchain has recent
> > > kernel headers (3.12) and uses glibc. Investigation needed.
> > 
> > http://patchwork.ozlabs.org/patch/345018/ seems applicable (but I didn't test).
> 
> Indeed, but I'm not really convinced by the fix, seems strange that
> --sysroot needs to be passed. More investigation is needed to validate
> the proposed fix, I believe.

Right. It just papers over the real problem which is building a target config 
test using the host toolchain, and then running it. The patch at 
http://patchwork.ozlabs.org/patch/348765/ is better, I believe.

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] [autobuild.buildroot.net] Build results for 2014-05-11

[Benoît Thébaudeau]

Hi,

On Wed, May 14, 2014 at 10:56 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> On Tue, May 13, 2014 at 10:01:02AM +0200, Thomas Petazzoni wrote:
>> On Tue, 13 May 2014 10:52:47 +0300, Baruch Siach wrote:
>>
>> > On Tue, May 13, 2014 at 09:44:26AM +0200, Thomas Petazzoni wrote:
>> > > >        arm |                      lsof-4.85 | NOK | http://autobuild.buildroot.net/results/a1f0572dbf968c21f70b35cefff7ef7a1d9a348a/
>> > >
>> > > Missing TCP_* definitions. Weird because the toolchain has recent
>> > > kernel headers (3.12) and uses glibc. Investigation needed.
>> >
>> > http://patchwork.ozlabs.org/patch/345018/ seems applicable (but I didn't test).
>>
>> Indeed, but I'm not really convinced by the fix, seems strange that
>> --sysroot needs to be passed. More investigation is needed to validate
>> the proposed fix, I believe.
>
> Right. It just papers over the real problem which is building a target config
> test using the host toolchain, and then running it. The patch at
> http://patchwork.ozlabs.org/patch/348765/ is better, I believe.

The issue in my case was that the native toolchain used for the
configure test implicitly #included a header file, which triggered a
conflict of direct inclusion between the native and cross toolchains
header files. Passing --sysroot forces the native toolchain to only
use the header files from the cross toolchain, fixing this conflict.
This directly addresses the issue without any assumption regarding the
cross libc.

http://patchwork.ozlabs.org/patch/348765/ works too, but it removes a
configure test and it relies on the "all libc variants we support have
the netinet/tcp.h header" assumption, which might become wrong in the
future, which is why I didn't choose this solution.

Best regards,
Beno?t

[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-11

[Thomas Petazzoni]

Dear Beno?t Th?baudeau,

On Wed, 14 May 2014 23:25:53 +0200, Beno?t Th?baudeau wrote:

> > Right. It just papers over the real problem which is building a target config
> > test using the host toolchain, and then running it. The patch at
> > http://patchwork.ozlabs.org/patch/348765/ is better, I believe.
> 
> The issue in my case was that the native toolchain used for the
> configure test implicitly #included a header file, which triggered a
> conflict of direct inclusion between the native and cross toolchains
> header files. Passing --sysroot forces the native toolchain to only
> use the header files from the cross toolchain, fixing this conflict.
> This directly addresses the issue without any assumption regarding the
> cross libc.

Right, but using target headers with the native toolchain is wrong, and
potentially also very fragile.

> http://patchwork.ozlabs.org/patch/348765/ works too, but it removes a
> configure test and it relies on the "all libc variants we support have
> the netinet/tcp.h header" assumption, which might become wrong in the
> future, which is why I didn't choose this solution.

How likely is that to happen? If it does, we will have very clear
build failures, so we will notice, no?

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

[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-11

[Benoît Thébaudeau]

Dear Thomas Petazzoni,

On Thursday, May 15, 2014 9:50:42 AM, Thomas Petazzoni wrote:
> On Wed, 14 May 2014 23:25:53 +0200, Beno?t Th?baudeau wrote:
> 
> > > Right. It just papers over the real problem which is building a target
> > > config
> > > test using the host toolchain, and then running it. The patch at
> > > http://patchwork.ozlabs.org/patch/348765/ is better, I believe.
> > 
> > The issue in my case was that the native toolchain used for the
> > configure test implicitly #included a header file, which triggered a
> > conflict of direct inclusion between the native and cross toolchains
> > header files. Passing --sysroot forces the native toolchain to only
> > use the header files from the cross toolchain, fixing this conflict.
> > This directly addresses the issue without any assumption regarding the
> > cross libc.
> 
> Right, but using target headers with the native toolchain is wrong, and
> potentially also very fragile.

True.

> > http://patchwork.ozlabs.org/patch/348765/ works too, but it removes a
> > configure test and it relies on the "all libc variants we support have
> > the netinet/tcp.h header" assumption, which might become wrong in the
> > future, which is why I didn't choose this solution.
> 
> How likely is that to happen? If it does, we will have very clear
> build failures, so we will notice, no?

For this specific test, yes, probably, because of the missing definitions in
Linux, as Baruch pointed out. But for some of the other configure tests, the
script sometimes silently chooses wrong options because of the header files
mix-up, so --sysroot helps here, but it's dirty, and forcing the GLIBC version
in the input options would not fix the other tests.

The root issue is that this configure script is totally broken when
cross-building, so most of its tests would have to be more or less rewritten.

Best regards,
Beno?t

[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-11

[Baruch Siach]

Hi Beno?t,

Please keep the list on Cc.

On Wed, May 14, 2014 at 11:22:34PM +0200, Beno?t Th?baudeau wrote:
> On Wed, May 14, 2014 at 10:56 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> > On Tue, May 13, 2014 at 10:01:02AM +0200, Thomas Petazzoni wrote:
> >> On Tue, 13 May 2014 10:52:47 +0300, Baruch Siach wrote:
> >>
> >> > On Tue, May 13, 2014 at 09:44:26AM +0200, Thomas Petazzoni wrote:
> >> > > >        arm |                      lsof-4.85 | NOK | http://autobuild.buildroot.net/results/a1f0572dbf968c21f70b35cefff7ef7a1d9a348a/
> >> > >
> >> > > Missing TCP_* definitions. Weird because the toolchain has recent
> >> > > kernel headers (3.12) and uses glibc. Investigation needed.
> >> >
> >> > http://patchwork.ozlabs.org/patch/345018/ seems applicable (but I didn't test).
> >>
> >> Indeed, but I'm not really convinced by the fix, seems strange that
> >> --sysroot needs to be passed. More investigation is needed to validate
> >> the proposed fix, I believe.
> >
> > Right. It just papers over the real problem which is building a target config
> > test using the host toolchain, and then running it. The patch at
> > http://patchwork.ozlabs.org/patch/348765/ is better, I believe.
> 
> The issue in my case was that the native toolchain used for the
> configure test implicitly #included a header file, which triggered a
> conflict of direct inclusion between the native and cross toolchains
> header files. Passing --sysroot forces the native toolchain to only
> use the header files from the cross toolchain, fixing this conflict.
> This directly addresses the issue without any assumption regarding the
> cross libc.

This make the test succeed sometimes, but mixing host toolchain with target 
headers doesn't look like a good idea.

> http://patchwork.ozlabs.org/patch/348765/ works too, but it removes a
> configure test and it relies on the "all libc variants we support have
> the netinet/tcp.h header" assumption, which might become wrong in the
> future, which is why I didn't choose this solution.

The alternative header, linux/tcp.h, is broken anyway, because this header 
does not export the TCP_* symbols, as you can see from the build failure error 
message. So getting this test "right" won't help us much.

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] [autobuild.buildroot.net] Build results for 2014-05-11

[Benoît Thébaudeau]

On Wed, May 14, 2014 at 11:41 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Beno?t,
>
> Please keep the list on Cc.

Yes, sorry. I had noticed that I had pressed "reply" instead of "reply
all" only after sending, then I re-sent my e-mail with the Cc's added,
so you must have received my e-mail twice.

> On Wed, May 14, 2014 at 11:22:34PM +0200, Beno?t Th?baudeau wrote:
>> On Wed, May 14, 2014 at 10:56 PM, Baruch Siach <baruch@tkos.co.il> wrote:
>> > On Tue, May 13, 2014 at 10:01:02AM +0200, Thomas Petazzoni wrote:
>> >> On Tue, 13 May 2014 10:52:47 +0300, Baruch Siach wrote:
>> >>
>> >> > On Tue, May 13, 2014 at 09:44:26AM +0200, Thomas Petazzoni wrote:
>> >> > > >        arm |                      lsof-4.85 | NOK | http://autobuild.buildroot.net/results/a1f0572dbf968c21f70b35cefff7ef7a1d9a348a/
>> >> > >
>> >> > > Missing TCP_* definitions. Weird because the toolchain has recent
>> >> > > kernel headers (3.12) and uses glibc. Investigation needed.
>> >> >
>> >> > http://patchwork.ozlabs.org/patch/345018/ seems applicable (but I didn't test).
>> >>
>> >> Indeed, but I'm not really convinced by the fix, seems strange that
>> >> --sysroot needs to be passed. More investigation is needed to validate
>> >> the proposed fix, I believe.
>> >
>> > Right. It just papers over the real problem which is building a target config
>> > test using the host toolchain, and then running it. The patch at
>> > http://patchwork.ozlabs.org/patch/348765/ is better, I believe.
>>
>> The issue in my case was that the native toolchain used for the
>> configure test implicitly #included a header file, which triggered a
>> conflict of direct inclusion between the native and cross toolchains
>> header files. Passing --sysroot forces the native toolchain to only
>> use the header files from the cross toolchain, fixing this conflict.
>> This directly addresses the issue without any assumption regarding the
>> cross libc.
>
> This make the test succeed sometimes,

By "sometimes", do you mean that the test also fails sometimes with this patch?

> but mixing host toolchain with target
> headers doesn't look like a good idea.

With this patch, it is less mixed than before, and some of the other
tests performed by the configuration script still try to
cross-configure using the native toolchain. The test fixed here only
looks at the definitions from the header files, so mixing the native
toolchain with the cross header files should not be an issue if the
native and cross header files are no longer mixed thanks to --sysroot.

Also, 'LSOF_INCLUDE="$(STAGING_DIR)/usr/include"' is explicitly asking
the configuration script to mix native and cross stuff for tests.

>> http://patchwork.ozlabs.org/patch/348765/ works too, but it removes a
>> configure test and it relies on the "all libc variants we support have
>> the netinet/tcp.h header" assumption, which might become wrong in the
>> future, which is why I didn't choose this solution.
>
> The alternative header, linux/tcp.h, is broken anyway, because this header
> does not export the TCP_* symbols, as you can see from the build failure error
> message. So getting this test "right" won't help us much.

Correct.

Beno?t

[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-11

[Baruch Siach]

Hi Beno?t,

On Thu, May 15, 2014 at 12:10:06AM +0200, Beno?t Th?baudeau wrote:
> On Wed, May 14, 2014 at 11:41 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> > On Wed, May 14, 2014 at 11:22:34PM +0200, Beno?t Th?baudeau wrote:
> >> On Wed, May 14, 2014 at 10:56 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> >> > On Tue, May 13, 2014 at 10:01:02AM +0200, Thomas Petazzoni wrote:
> >> >> On Tue, 13 May 2014 10:52:47 +0300, Baruch Siach wrote:
> >> >>
> >> >> > On Tue, May 13, 2014 at 09:44:26AM +0200, Thomas Petazzoni wrote:
> >> >> > > >        arm |                      lsof-4.85 | NOK | http://autobuild.buildroot.net/results/a1f0572dbf968c21f70b35cefff7ef7a1d9a348a/
> >> >> > >
> >> >> > > Missing TCP_* definitions. Weird because the toolchain has recent
> >> >> > > kernel headers (3.12) and uses glibc. Investigation needed.
> >> >> >
> >> >> > http://patchwork.ozlabs.org/patch/345018/ seems applicable (but I didn't test).
> >> >>
> >> >> Indeed, but I'm not really convinced by the fix, seems strange that
> >> >> --sysroot needs to be passed. More investigation is needed to validate
> >> >> the proposed fix, I believe.
> >> >
> >> > Right. It just papers over the real problem which is building a target config
> >> > test using the host toolchain, and then running it. The patch at
> >> > http://patchwork.ozlabs.org/patch/348765/ is better, I believe.
> >>
> >> The issue in my case was that the native toolchain used for the
> >> configure test implicitly #included a header file, which triggered a
> >> conflict of direct inclusion between the native and cross toolchains
> >> header files. Passing --sysroot forces the native toolchain to only
> >> use the header files from the cross toolchain, fixing this conflict.
> >> This directly addresses the issue without any assumption regarding the
> >> cross libc.
> >
> > This make the test succeed sometimes,
> 
> By "sometimes", do you mean that the test also fails sometimes with this patch?

I haven't observed such a failure. But target headers include some 
architecture specific definitions. Mixing these with host predefined macros 
(output of 'gcc -dM -E - < /dev/null') feels like a bad idea. Things like 
endianess and types sizeof mismatches might break tests in unexpected ways.

> > but mixing host toolchain with target
> > headers doesn't look like a good idea.
> 
> With this patch, it is less mixed than before, and some of the other
> tests performed by the configuration script still try to
> cross-configure using the native toolchain. The test fixed here only
> looks at the definitions from the header files, so mixing the native
> toolchain with the cross header files should not be an issue if the
> native and cross header files are no longer mixed thanks to --sysroot.
> 
> Also, 'LSOF_INCLUDE="$(STAGING_DIR)/usr/include"' is explicitly asking
> the configuration script to mix native and cross stuff for tests.

This should be fixed then. I'll look into it.

> >> http://patchwork.ozlabs.org/patch/348765/ works too, but it removes a
> >> configure test and it relies on the "all libc variants we support have
> >> the netinet/tcp.h header" assumption, which might become wrong in the
> >> future, which is why I didn't choose this solution.
> >
> > The alternative header, linux/tcp.h, is broken anyway, because this header
> > does not export the TCP_* symbols, as you can see from the build failure error
> > message. So getting this test "right" won't help us much.
> 
> Correct.

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] [autobuild.buildroot.net] Build results for 2014-05-11

[Benoît Thébaudeau]

Hi Baruch,

On Thursday, May 15, 2014 5:44:47 AM, Baruch Siach wrote:
> On Thu, May 15, 2014 at 12:10:06AM +0200, Beno?t Th?baudeau wrote:
> > On Wed, May 14, 2014 at 11:41 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> > > On Wed, May 14, 2014 at 11:22:34PM +0200, Beno?t Th?baudeau wrote:
> > >> On Wed, May 14, 2014 at 10:56 PM, Baruch Siach <baruch@tkos.co.il>
> > >> wrote:
> > >> > On Tue, May 13, 2014 at 10:01:02AM +0200, Thomas Petazzoni wrote:
> > >> >> On Tue, 13 May 2014 10:52:47 +0300, Baruch Siach wrote:
> > >> >>
> > >> >> > On Tue, May 13, 2014 at 09:44:26AM +0200, Thomas Petazzoni wrote:
> > >> >> > > >        arm |                      lsof-4.85 | NOK |
> > >> >> > > >        http://autobuild.buildroot.net/results/a1f0572dbf968c21f70b35cefff7ef7a1d9a348a/
> > >> >> > >
> > >> >> > > Missing TCP_* definitions. Weird because the toolchain has recent
> > >> >> > > kernel headers (3.12) and uses glibc. Investigation needed.
> > >> >> >
> > >> >> > http://patchwork.ozlabs.org/patch/345018/ seems applicable (but I
> > >> >> > didn't test).
> > >> >>
> > >> >> Indeed, but I'm not really convinced by the fix, seems strange that
> > >> >> --sysroot needs to be passed. More investigation is needed to
> > >> >> validate
> > >> >> the proposed fix, I believe.
> > >> >
> > >> > Right. It just papers over the real problem which is building a target
> > >> > config
> > >> > test using the host toolchain, and then running it. The patch at
> > >> > http://patchwork.ozlabs.org/patch/348765/ is better, I believe.
> > >>
> > >> The issue in my case was that the native toolchain used for the
> > >> configure test implicitly #included a header file, which triggered a
> > >> conflict of direct inclusion between the native and cross toolchains
> > >> header files. Passing --sysroot forces the native toolchain to only
> > >> use the header files from the cross toolchain, fixing this conflict.
> > >> This directly addresses the issue without any assumption regarding the
> > >> cross libc.
> > >
> > > This make the test succeed sometimes,
> > 
> > By "sometimes", do you mean that the test also fails sometimes with this
> > patch?
> 
> I haven't observed such a failure. But target headers include some
> architecture specific definitions. Mixing these with host predefined macros
> (output of 'gcc -dM -E - < /dev/null') feels like a bad idea. Things like
> endianess and types sizeof mismatches might break tests in unexpected ways.

Right.

> > > but mixing host toolchain with target
> > > headers doesn't look like a good idea.
> > 
> > With this patch, it is less mixed than before, and some of the other
> > tests performed by the configuration script still try to
> > cross-configure using the native toolchain. The test fixed here only
> > looks at the definitions from the header files, so mixing the native
> > toolchain with the cross header files should not be an issue if the
> > native and cross header files are no longer mixed thanks to --sysroot.
> > 
> > Also, 'LSOF_INCLUDE="$(STAGING_DIR)/usr/include"' is explicitly asking
> > the configuration script to mix native and cross stuff for tests.
> 
> This should be fixed then. I'll look into it.

Cool. OTOH, the worst test is probably the one for strftime() support, which
just tests native toolchain features by running code on the build machine (not
just testing #define-s). Most of the other tests do things like for GLIBC, hence
a lot of mix-up in the header files.

> > >> http://patchwork.ozlabs.org/patch/348765/ works too, but it removes a
> > >> configure test and it relies on the "all libc variants we support have
> > >> the netinet/tcp.h header" assumption, which might become wrong in the
> > >> future, which is why I didn't choose this solution.
> > >
> > > The alternative header, linux/tcp.h, is broken anyway, because this
> > > header
> > > does not export the TCP_* symbols, as you can see from the build failure
> > > error
> > > message. So getting this test "right" won't help us much.
> > 
> > Correct.

Beno?t

[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-11

[Baruch Siach]

Hi Beno?t,

On Thu, May 15, 2014 at 02:44:11PM +0200, Beno?t Th?baudeau wrote:
> On Thursday, May 15, 2014 5:44:47 AM, Baruch Siach wrote:
> > On Thu, May 15, 2014 at 12:10:06AM +0200, Beno?t Th?baudeau wrote:
> > > Also, 'LSOF_INCLUDE="$(STAGING_DIR)/usr/include"' is explicitly asking
> > > the configuration script to mix native and cross stuff for tests.
> > 
> > This should be fixed then. I'll look into it.
> 
> Cool.

I went through the Configure script, and it seems that almost all uses of 
$LSOF_INCLUDE are for direct headers existence or grep tests, not build/run 
tests. I guess leaving the $LSOF_INCLUDE setting as is should be safe for now.

> OTOH, the worst test is probably the one for strftime() support, which
> just tests native toolchain features by running code on the build machine (not
> just testing #define-s).

This test doesn't use $LSOF_INCLUDE at all, and is a purely host test and thus 
useless. OTOH, there is no easy way to disable this test short of patching the 
Configure script. IMO this test is harmless. In case we encounter a target 
without strftime()/localtime(), we'll see a clear build failure. So I believe 
we should just leave this test as is for now as well.

> Most of the other tests do things like for GLIBC, hence
> a lot of mix-up in the header files.

Other that the glibc test which is now disabled I have not found any other 
example of host toolchain with target headers mix in the Configure script. 
Have you seen any?

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] [autobuild.buildroot.net] Build results for 2014-05-11

[Benoît Thébaudeau]

Hi Baruch,

On Friday, May 16, 2014 7:20:01 AM, Baruch Siach wrote:
> On Thu, May 15, 2014 at 02:44:11PM +0200, Beno?t Th?baudeau wrote:
> > On Thursday, May 15, 2014 5:44:47 AM, Baruch Siach wrote:
> > > On Thu, May 15, 2014 at 12:10:06AM +0200, Beno?t Th?baudeau wrote:
> > > > Also, 'LSOF_INCLUDE="$(STAGING_DIR)/usr/include"' is explicitly asking
> > > > the configuration script to mix native and cross stuff for tests.
> > > 
> > > This should be fixed then. I'll look into it.
> > 
> > Cool.
> 
> I went through the Configure script, and it seems that almost all uses of
> $LSOF_INCLUDE are for direct headers existence or grep tests, not build/run
> tests. I guess leaving the $LSOF_INCLUDE setting as is should be safe for
> now.

OK. Thanks for having checked.

> > OTOH, the worst test is probably the one for strftime() support, which
> > just tests native toolchain features by running code on the build machine
> > (not
> > just testing #define-s).
> 
> This test doesn't use $LSOF_INCLUDE at all,

Yes, I was just listing some configure issues that I remembered of, not
necessarily related to $LSOF_INCLUDE.

> and is a purely host test and
> thus
> useless.

It's used by the code that is then cross-built, through HAS_STRFTIME, but this
test does not make sense when cross-building.

> OTOH, there is no easy way to disable this test short of patching
> the
> Configure script.

Right, but the consequences of the test result could be overridden by adding
-DHAS_STRFTIME to $LSOF_CFGF (if strftime() is actually correct in the cross-
toolchain).

> IMO this test is harmless. In case we encounter a target
> without strftime()/localtime(), we'll see a clear build failure. So I believe
> we should just leave this test as is for now as well.

If the test result is wrong in that way, yes, but the test could also conclude
that strftime() is not supported while it actually is, thus removing features or
causing some other limitations (to be checked).

> > Most of the other tests do things like for GLIBC, hence
> > a lot of mix-up in the header files.
> 
> Other that the glibc test which is now disabled I have not found any other
> example of host toolchain with target headers mix in the Configure script.
> Have you seen any?

I've just rechecked the "LSOF_CC.*LSOF_INCLUDE" occurrences, and they seem to be
limited to non-Linux platforms, but I don't know if BuildRoot is supposed or not
to support some of these platforms as build machines.

Apart from the header files, LSOF_CC is also used for some tests, but for Linux
I only see the test for $LSOF_CCV, which does not seem to be able to be harmful.

Beno?t

[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-11

[Peter Korsgaard]

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

 > Hello,
 > On Mon, 12 May 2014 08:30:08 +0200 (CEST), Thomas Petazzoni wrote:

 >> nios2 |                 aiccu-20070115 | NOK | http://autobuild.buildroot.net/results/7864cd5789a9f9b9f0603d738f4e63822d8469dd/

 > Will be fixed once http://patchwork.ozlabs.org/patch/348125/ is
 > committed.

I committed that yesterday.


-- 
Bye, Peter Korsgaard

[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-11

[Samuel Martin]

Thomas, all,

On Tue, May 13, 2014 at 9:44 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Mon, 12 May 2014 08:30:08 +0200 (CEST), Thomas Petazzoni wrote:
>
>>      nios2 |                 aiccu-20070115 | NOK | http://autobuild.buildroot.net/results/7864cd5789a9f9b9f0603d738f4e63822d8469dd/
>
> Will be fixed once http://patchwork.ozlabs.org/patch/348125/ is
> committed.
>
>>    powerpc |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/6a89535c0806939dcb6d4160899bd242a0648fb8/
>
> uClibc static linking issue.
>
>>     mipsel |              alsa-utils-1.0.26 | NOK | http://autobuild.buildroot.net/results/8ca7fb8e4b1da8c1a7e4d646469779e4032877ab/
>
> /home/test/test/2/output/host/usr/mipsel-buildroot-linux-uclibc/sysroot/usr/lib/libasound.a(control_shm.o): In function `_snd_ctl_shm_open':
> control_shm.c:(.text+0x1550): warning: gethostbyname is obsolescent, use getnameinfo() instead.
> /home/test/test/2/output/host/usr/mipsel-buildroot-linux-uclibc/sysroot/usr/lib/libasound.a(rawmidi_symbols.o):(.data.rel+0x4): undefined reference to `_snd_module_rawmidi_virt'
> collect2: error: ld returned 1 exit status
>
>>       bfin |              armadillo-4.000.4 | NOK | http://autobuild.buildroot.net/results/a28df0ba10803e6e54c2f8160bbd8190cba4d690/
>
> Weird stuff going on. Samuel?

This is related to the bfin "_" symbol prefix in clapack.
I'm cooking a patch disabling clapack and its reverse deps. on bfin.

Regards

-- 
Samuel

[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-11

[Gustavo Zacarias]

On 05/13/2014 04:44 AM, Thomas Petazzoni wrote:

>>      avr32 |             btrfs-progs-3.14.1 | NOK | http://autobuild.buildroot.net/results/06501fd32c30549810c12f0ad50f510c4b74ee63/
> 
> Gustavo? Probably simply exclude btrfs-progs from avr32 ?

Hi.
Yes, toolchain issues at work, since btrfs is one of those "big storage"
filesystems and AVR32s don't have any big storage ports (or enough
resources in the cpu/memory department in general) it's better to
disable it.

>>    powerpc |                  cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/f1ca1a8f7ca8456003c6f17e146151a99835c4c0/
> 
> /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/powerpc-buildroot-linux-uclibc/4.7.3/../../../../powerpc-buildroot-linux-uclibc/bin/ld: attempted static link of dynamic object `/home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/powerpc-buildroot-linux-uclibc/4.7.3/../../../../powerpc-buildroot-linux-uclibc/lib/libstdc++.so'
> 
> Gustavo, what is the status on this issue?

I'm trying a less agressive workaround that the one i've previously
cooked-up since it's no good this late in the release cycle.
Hopefully it'll work, fingers crossed.
Regards.