[Buildroot] [autobuild.buildroot.net] Build results for 2017-02-26

[Buildroot] [autobuild.buildroot.net] Build results for 2017-02-26

[Thomas Petazzoni]

Hello,

Build statistics for 2017-02-26
================================

      successes : 179
       failures : 29 
       timeouts : 0  
          TOTAL : 208

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

                 sngrep-v1.4.2 | 8 
              host-cmake-3.6.3 | 5 
               librsvg-2.40.16 | 3 
                classpath-0.98 | 2 
                 mplayer-1.3.0 | 2 
             rabbitmq-c-v0.8.0 | 2 
               libepoxy-v1.3.1 | 1 
             libsidplay2-2.1.1 | 1 
          linux-headers-4.9.13 | 1 
                    mpd-0.20.4 | 1 
                    mpv-0.23.0 | 1 
        qt5quickcontrols-5.8.0 | 1 
                     xterm-327 | 1 


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

       nios2 |                 classpath-0.98 | NOK | http://autobuild.buildroot.net/results/279dd731bd9ecf5f9d54bda3715caeaa7cbcdbb3
microblazeel |                 classpath-0.98 | NOK | http://autobuild.buildroot.net/results/55eb89f89e96b94a821778bc18ed844af08b7460
        bfin |               host-cmake-3.6.3 | NOK | http://autobuild.buildroot.net/results/10a06db5edb5243658bd16a41885a20f7b8c7e67
       nios2 |               host-cmake-3.6.3 | NOK | http://autobuild.buildroot.net/results/40b6694bafd45a9249e80240b7dc88069fc94014
        mips |               host-cmake-3.6.3 | NOK | http://autobuild.buildroot.net/results/01be357e6d56792371cfcc3f1bdc03b6e0d1c4be
       nios2 |               host-cmake-3.6.3 | NOK | http://autobuild.buildroot.net/results/7482902ec65e68a5c1e47147d17a084857abdee1
microblazeel |               host-cmake-3.6.3 | NOK | http://autobuild.buildroot.net/results/bc95760f71d99c7bdb5608cb213758ad827cfa40
         arm |                libepoxy-v1.3.1 | NOK | http://autobuild.buildroot.net/results/869e636a71c9574c0fad41cedf3d311f5f4ee8db
      x86_64 |                librsvg-2.40.16 | NOK | http://autobuild.buildroot.net/results/393145bc9bcb93d6df55ec8c63725c3d9a299957
      x86_64 |                librsvg-2.40.16 | NOK | http://autobuild.buildroot.net/results/60af583e52d9ff8efff1bc455e4f842721c5807c
      x86_64 |                librsvg-2.40.16 | NOK | http://autobuild.buildroot.net/results/492aaf78f4d47d80bb813810a54121799a5c8d46
 powerpc64le |              libsidplay2-2.1.1 | NOK | http://autobuild.buildroot.net/results/caba78cc2706accc187a428364c0e0d10a1dcd60
         arc |           linux-headers-4.9.13 | NOK | http://autobuild.buildroot.net/results/803453df521f258932baf5729d5afe2a084121fb
         arc |                     mpd-0.20.4 | NOK | http://autobuild.buildroot.net/results/7d70b62ad996830fbeca46dffcc7a1dc030e575d
        or1k |                  mplayer-1.3.0 | NOK | http://autobuild.buildroot.net/results/47207dfd10ff6e5ec4ccdcf8454aaf5f408ad1e3
        or1k |                  mplayer-1.3.0 | NOK | http://autobuild.buildroot.net/results/c165c47f45f1e5488e718770c06993d30f32f8e4
         arc |                     mpv-0.23.0 | NOK | http://autobuild.buildroot.net/results/fb677a917545adee321bdcd2c2519c81326448c4
         arm |         qt5quickcontrols-5.8.0 | NOK | http://autobuild.buildroot.net/results/1ff3e9ad4ba518d0a37f9fc12038bf9020f28094
        i686 |              rabbitmq-c-v0.8.0 | NOK | http://autobuild.buildroot.net/results/92f9a6b804072a521ad0b25086a0a5ed33eaf53e
         arc |              rabbitmq-c-v0.8.0 | NOK | http://autobuild.buildroot.net/results/a04ba24c6cd61bf6f2128a0e869f679cb3f2eac3
      xtensa |                  sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/dfd568ed7eb945cd5e3b53a9c1baa3021049fb82
         arm |                  sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/c87376d08656e1528fc45cfbef536ac2072d926c
         arm |                  sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/78053a5b1954433aeb52fd9cc55cd8ecbe84e7f1
microblazeel |                  sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/b58156dd7fbf0842311e60cfb18163772557e33e
      mipsel |                  sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/38bb7f09f5b37aac7f536feca45cf6d2a8d50eed
        i586 |                  sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/d26b76534c3ef3cd98459f27ac06048fd6f075eb
         arm |                  sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/fc853251d8b3aee5289994f996bb6e47d0e5fb76
      x86_64 |                  sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/36c28e7e49b31ed2398a67db2e9b08e3aad5a3ee
         arc |                      xterm-327 | NOK | http://autobuild.buildroot.net/results/28a92049a6ceef005787c5779f77ecf3fe8ad642

-- 
http://autobuild.buildroot.net

[Buildroot] Analysis of build results for 2017-02-26

[Thomas Petazzoni]

Hello,

Waldemar, Dagg, Sam, Vlad, Peter, Frank, Samuel, see below, there are
some build issues for you :-)

Thanks!

On Mon, 27 Feb 2017 08:28:48 +0100 (CET), Thomas Petazzoni wrote:

>        nios2 |                 classpath-0.98 | NOK | http://autobuild.buildroot.net/results/279dd731bd9ecf5f9d54bda3715caeaa7cbcdbb3
> microblazeel |                 classpath-0.98 | NOK | http://autobuild.buildroot.net/results/55eb89f89e96b94a821778bc18ed844af08b7460

Perhaps this needs a commit like
https://git.buildroot.org/buildroot/commit/?id=f12a146f817c8ef07a7d41a31a5336b5ef6a96e8
but for nios2 and microblaze ?

Waldemar ?

>         bfin |               host-cmake-3.6.3 | NOK | http://autobuild.buildroot.net/results/10a06db5edb5243658bd16a41885a20f7b8c7e67
>        nios2 |               host-cmake-3.6.3 | NOK | http://autobuild.buildroot.net/results/40b6694bafd45a9249e80240b7dc88069fc94014
>         mips |               host-cmake-3.6.3 | NOK | http://autobuild.buildroot.net/results/01be357e6d56792371cfcc3f1bdc03b6e0d1c4be
>        nios2 |               host-cmake-3.6.3 | NOK | http://autobuild.buildroot.net/results/7482902ec65e68a5c1e47147d17a084857abdee1
> microblazeel |               host-cmake-3.6.3 | NOK | http://autobuild.buildroot.net/results/bc95760f71d99c7bdb5608cb213758ad827cfa40

These are all download issues following the revert to CMake 3.6.3.
sources.buildroot.net has now picked up the tarball, so those issues
will no longer occur.

>          arm |                libepoxy-v1.3.1 | NOK | http://autobuild.buildroot.net/results/869e636a71c9574c0fad41cedf3d311f5f4ee8db

Still this problem with the odroid-mali OpenGL ES provider.

It's been there for ages. Dagg, could you have a look? If it doesn't
get resolved, we'll have to drop the odroid-mali package at some
point.

>       x86_64 |                librsvg-2.40.16 | NOK | http://autobuild.buildroot.net/results/393145bc9bcb93d6df55ec8c63725c3d9a299957
>       x86_64 |                librsvg-2.40.16 | NOK | http://autobuild.buildroot.net/results/60af583e52d9ff8efff1bc455e4f842721c5807c
>       x86_64 |                librsvg-2.40.16 | NOK | http://autobuild.buildroot.net/results/492aaf78f4d47d80bb813810a54121799a5c8d46

   Makefile:807: recipe for target 'gdk-pixbuf-loaders' failed

at installation time. It only happens with that specific x86-64
toolchain: http://autobuild.buildroot.net/?reason=librsvg-2.40.16.

Could you be something like the host is x86-64/glibc and the target is
x86-64/glibc, and it confuses something?

>  powerpc64le |              libsidplay2-2.1.1 | NOK | http://autobuild.buildroot.net/results/caba78cc2706accc187a428364c0e0d10a1dcd60

Missing -fPIC apparently. Sam?

>          arc |           linux-headers-4.9.13 | NOK | http://autobuild.buildroot.net/results/803453df521f258932baf5729d5afe2a084121fb

Download issue.

>          arc |                     mpd-0.20.4 | NOK | http://autobuild.buildroot.net/results/7d70b62ad996830fbeca46dffcc7a1dc030e575d

Lacks a -lpthread apparently:

/home/peko/autobuild/instance-1/output/host/opt/ext-toolchain/bin/../lib/gcc/arc-snps-linux-uclibc/6.2.1/../../../../arc-snps-linux-uclibc/bin/ld: libthread.a(Thread.o): undefined reference to symbol 'pthread_create'
/home/peko/autobuild/instance-1/output/host/usr/arc-buildroot-linux-uclibc/sysroot/lib/libpthread.so.0: error adding symbols: DSO missing from command line

but the configure script fails to detect thread support:

checking for the pthreads library -lpthread... no

Aah, they test if the compiler defines _REENTRANT:

conftest.c:15:26: error: #error "_REENTRANT must be defined"
 #                        error "_REENTRANT must be defined"

and I know some architectures forget to do so.

I already reported this bug to gcc upstream:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71749

Vlad, could you have a look into this? We have
package/gcc/6.3.0/895-bfin-define-REENTRANT.patch for Blackfin in the
tree, but we don't have the corresponding patch for ARC.

>         or1k |                  mplayer-1.3.0 | NOK | http://autobuild.buildroot.net/results/47207dfd10ff6e5ec4ccdcf8454aaf5f408ad1e3
>         or1k |                  mplayer-1.3.0 | NOK | http://autobuild.buildroot.net/results/c165c47f45f1e5488e718770c06993d30f32f8e4

Would be fixed by https://patchwork.ozlabs.org/patch/732625/.

>          arc |                     mpv-0.23.0 | NOK | http://autobuild.buildroot.net/results/fb677a917545adee321bdcd2c2519c81326448c4

../video/out/filter_kernels.c: In function 'jinc':
../video/out/filter_kernels.c:318:18: error: implicit declaration of function 'j1' [-Werror=implicit-function-declaration]
     return 2.0 * j1(x) / x;

Vlad, this is only occurring on ARC, could you have a look?

>          arm |         qt5quickcontrols-5.8.0 | NOK | http://autobuild.buildroot.net/results/1ff3e9ad4ba518d0a37f9fc12038bf9020f28094

Was supposed to be fixed by
https://git.buildroot.org/buildroot/commit/?id=e482ebf51d9e8e00c3e58eb65af0dfb70d05d8cc,
but it isn't. Peter (Seiderer), could you have a look ?

>         i686 |              rabbitmq-c-v0.8.0 | NOK | http://autobuild.buildroot.net/results/92f9a6b804072a521ad0b25086a0a5ed33eaf53e
>          arc |              rabbitmq-c-v0.8.0 | NOK | http://autobuild.buildroot.net/results/a04ba24c6cd61bf6f2128a0e869f679cb3f2eac3

Static linking issues, with a CMake based package. Frank, Samuel, could
you have a look?

>       xtensa |                  sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/dfd568ed7eb945cd5e3b53a9c1baa3021049fb82
>          arm |                  sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/c87376d08656e1528fc45cfbef536ac2072d926c
>          arm |                  sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/78053a5b1954433aeb52fd9cc55cd8ecbe84e7f1
> microblazeel |                  sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/b58156dd7fbf0842311e60cfb18163772557e33e
>       mipsel |                  sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/38bb7f09f5b37aac7f536feca45cf6d2a8d50eed
>         i586 |                  sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/d26b76534c3ef3cd98459f27ac06048fd6f075eb
>          arm |                  sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/fc853251d8b3aee5289994f996bb6e47d0e5fb76
>       x86_64 |                  sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/36c28e7e49b31ed2398a67db2e9b08e3aad5a3ee

Some of these are the ncurses problem, fixed by
https://git.buildroot.org/buildroot/commit/?id=0c5946acc24a36f9dff079edd054d948c69434f6.

Some of the others are related to openssl, are not fixed and remain to
be investigated.

>          arc |                      xterm-327 | NOK | http://autobuild.buildroot.net/results/28a92049a6ceef005787c5779f77ecf3fe8ad642

The ARC uClibc doesn't implement getpt(), according to Yann, so we need
to exclude this package with the ARC external toolchain.

Thanks,

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

[Buildroot] Analysis of build results for 2017-02-26

[Yann E. MORIN]

Thomas, All,

On 2017-02-27 14:28 +0100, Thomas Petazzoni spake thusly:
[--SNIP--]
> >          arc |                     mpv-0.23.0 | NOK | http://autobuild.buildroot.net/results/fb677a917545adee321bdcd2c2519c81326448c4
> 
> ../video/out/filter_kernels.c: In function 'jinc':
> ../video/out/filter_kernels.c:318:18: error: implicit declaration of function 'j1' [-Werror=implicit-function-declaration]
>      return 2.0 * j1(x) / x;
> 
> Vlad, this is only occurring on ARC, could you have a look?

That's again because of the Synopsys toolchain, whise uClibc has been
configured without the "Bessel functions of the first kind".

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Analysis of build results for 2017-02-26

[Thomas Petazzoni]

Hello,

On Mon, 27 Feb 2017 16:54:03 +0100, Yann E. MORIN wrote:
> Thomas, All,
> 
> On 2017-02-27 14:28 +0100, Thomas Petazzoni spake thusly:
> [--SNIP--]
> > >          arc |                     mpv-0.23.0 | NOK | http://autobuild.buildroot.net/results/fb677a917545adee321bdcd2c2519c81326448c4  
> > 
> > ../video/out/filter_kernels.c: In function 'jinc':
> > ../video/out/filter_kernels.c:318:18: error: implicit declaration of function 'j1' [-Werror=implicit-function-declaration]
> >      return 2.0 * j1(x) / x;
> > 
> > Vlad, this is only occurring on ARC, could you have a look?  
> 
> That's again because of the Synopsys toolchain, whise uClibc has been
> configured without the "Bessel functions of the first kind".

Let's add yet another "depends on !..." then.

Thanks for the investigation!

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

[Buildroot] Analysis of build results for 2017-02-26

[Frank Hunleth]

Hello,

On Mon, Feb 27, 2017 at 8:28 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
>>         i686 |              rabbitmq-c-v0.8.0 | NOK | http://autobuild.buildroot.net/results/92f9a6b804072a521ad0b25086a0a5ed33eaf53e
>>          arc |              rabbitmq-c-v0.8.0 | NOK | http://autobuild.buildroot.net/results/a04ba24c6cd61bf6f2128a0e869f679cb3f2eac3
>
> Static linking issues, with a CMake based package. Frank, Samuel, could
> you have a look?
>

I took a quick look. The issue is due to a transitive dependency on
zlib not being added to the linker invocation. The rabbitmq utilities
make calls to libcrypto.a which has calls to zlib. I don't use cmake
enough to know how this is normally fixed with that tool. If there's
another example somewhere that I can copy, I don't mind submitting a
fix.

Frank

p.s. Fwiw, rabbitmq-c is actually maintained by Joris Lijssens, so I'm
adding him to the cc list in case he has run into this. My rabbitmq
package is rabbitmq-server, but my project with rabbit also uses
rabbitmq-c.

[Buildroot] Analysis of build results for 2017-02-26

[Thomas Petazzoni]

Hello,

On Mon, 27 Feb 2017 11:54:19 -0500, Frank Hunleth wrote:

> >>         i686 |              rabbitmq-c-v0.8.0 | NOK | http://autobuild.buildroot.net/results/92f9a6b804072a521ad0b25086a0a5ed33eaf53e
> >>          arc |              rabbitmq-c-v0.8.0 | NOK | http://autobuild.buildroot.net/results/a04ba24c6cd61bf6f2128a0e869f679cb3f2eac3  
> >
> > Static linking issues, with a CMake based package. Frank, Samuel, could
> > you have a look?
> >  
> 
> I took a quick look. The issue is due to a transitive dependency on
> zlib not being added to the linker invocation. The rabbitmq utilities
> make calls to libcrypto.a which has calls to zlib. I don't use cmake
> enough to know how this is normally fixed with that tool. If there's
> another example somewhere that I can copy, I don't mind submitting a
> fix.

The proper solution for this is to use pkg-config to discover the
libraries. pkg-config has the relevant information about transitive
dependencies that are needed for static linking to work properly.

It is worth noting that the problem does not occur only with
openssl->zlib, but also with libintl.

> p.s. Fwiw, rabbitmq-c is actually maintained by Joris Lijssens, so I'm
> adding him to the cc list in case he has run into this. My rabbitmq
> package is rabbitmq-server, but my project with rabbit also uses
> rabbitmq-c.

Ah, yes, indeed, my bad. Thanks for adding Joris in the loop then. He
should anyway have received notifications of the build failures.

Thanks,

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

[Buildroot] Analysis of build results for 2017-02-26: libsidplay issue on PowerPC64

[Thomas Petazzoni]

Hello,

On Mon, 27 Feb 2017 14:28:54 +0100, Thomas Petazzoni wrote:

> >  powerpc64le |              libsidplay2-2.1.1 | NOK | http://autobuild.buildroot.net/results/caba78cc2706accc187a428364c0e0d10a1dcd60  
> 
> Missing -fPIC apparently. Sam?

I had a closer look at this one. What happens is:

 1. libsidplay is autoreconf'ed due to <pkg>_AUTORECONF = YES

 2. we apply the powerpc64le trick that patches the configure script,
    thanks to this, during the configure step, the fact that shared
    libraries are supported is properly detected.

 3. for some reason, when the build starts, it auto-autoreconfs itself,
    which rewrites the configure script, without the powerpc64le
    trick. ./configure is re-executed, and this time doesn't detected
    shared library support anymore.

So the issue is: why does the package decides to auto-autoreconf itself
at the beginning of the build step.

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

[Buildroot] Analysis of build results for 2017-02-26: classpath issue

[Thomas Petazzoni]

Hello,

On Mon, 27 Feb 2017 14:28:54 +0100, Thomas Petazzoni wrote:

> >        nios2 |                 classpath-0.98 | NOK | http://autobuild.buildroot.net/results/279dd731bd9ecf5f9d54bda3715caeaa7cbcdbb3
> > microblazeel |                 classpath-0.98 | NOK | http://autobuild.buildroot.net/results/55eb89f89e96b94a821778bc18ed844af08b7460  
> 
> Perhaps this needs a commit like
> https://git.buildroot.org/buildroot/commit/?id=f12a146f817c8ef07a7d41a31a5336b5ef6a96e8
> but for nios2 and microblaze ?

For this one, I submitted:

   http://patchwork.ozlabs.org/patch/733183/

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

[Buildroot] Analysis of build results for 2017-02-26: librsvg failure

[Thomas Petazzoni]

Hello,

Adding Gustavo on this one, there is some gdk-pixbuf stuff involved.

On Mon, 27 Feb 2017 14:28:54 +0100, Thomas Petazzoni wrote:

> >       x86_64 |                librsvg-2.40.16 | NOK | http://autobuild.buildroot.net/results/393145bc9bcb93d6df55ec8c63725c3d9a299957
> >       x86_64 |                librsvg-2.40.16 | NOK | http://autobuild.buildroot.net/results/60af583e52d9ff8efff1bc455e4f842721c5807c
> >       x86_64 |                librsvg-2.40.16 | NOK | http://autobuild.buildroot.net/results/492aaf78f4d47d80bb813810a54121799a5c8d46  
> 
>    Makefile:807: recipe for target 'gdk-pixbuf-loaders' failed
> 
> at installation time. It only happens with that specific x86-64
> toolchain: http://autobuild.buildroot.net/?reason=librsvg-2.40.16.
> 
> Could you be something like the host is x86-64/glibc and the target is
> x86-64/glibc, and it confuses something?

Adding Gustavo in Cc on this one. On my x86-64 machine, the following
defconfig reproduces the issue:

BR2_x86_64=y
BR2_x86_steamroller=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_LIBRSVG=y
# BR2_TARGET_ROOTFS_TAR is not set

The command that causes the installation failure is:

   /home/thomas/projets/buildroot/output/host/usr/bin/gdk-pixbuf-query-loaders ./libpixbufloader-svg.la && /home/thomas/projets/buildroot/output/host/usr/bin/gdk-pixbuf-query-loaders

Interestingly, when run outside of the build process, it is successful
(echo $? says 0). However, when run by the package Makefile, it fails
with Error 132. It turns out that it's an "Illegal instruction" error:

( strace -o /tmp/pouet.log /home/thomas/projets/buildroot/output/host/usr/bin/gdk-pixbuf-query-loaders ./libpixbufloader-svg.la && /home/thomas/projets/buildroot/output/host/usr/bin/gdk-pixbuf-query-loaders)
/bin/bash: line 1: 31690 Illegal instruction     strace -o /tmp/pouet.log /home/thomas/projets/buildroot/output/host/usr/bin/gdk-pixbuf-query-loaders ./libpixbufloader-svg.la
Makefile:807: recipe for target 'gdk-pixbuf-loaders' failed
make[4]: *** [gdk-pixbuf-loaders] Error 132

The strace (which was added by me), give:

read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0V\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=1088952, ...}) = 0
mmap(NULL, 3178744, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8df2576000
mprotect(0x7f8df267e000, 2093056, PROT_NONE) = 0
mmap(0x7f8df287d000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x107000) = 0x7f8df287d000
close(3)                                = 0
mprotect(0x7f8df287d000, 4096, PROT_READ) = 0
mprotect(0x7f8df361b000, 4096, PROT_READ) = 0
mprotect(0x7f8df556d000, 4096, PROT_READ) = 0
--- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x7f8df3d26f02} ---
+++ killed by SIGILL +++

So very very early in the program execution, it aborts with an illegal
instruction. I dumped the environment from the Makefile right before
running this command, and couldn't see anything obviously wrong.

Any idea?

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

[Buildroot] Analysis of build results for 2017-02-26: libsidplay issue on PowerPC64

[Sam Bobroff]

On Mon, Feb 27, 2017 at 11:38:18PM +0100, Thomas Petazzoni wrote:
> Hello,
> 
> On Mon, 27 Feb 2017 14:28:54 +0100, Thomas Petazzoni wrote:
> 
> > >  powerpc64le |              libsidplay2-2.1.1 | NOK | http://autobuild.buildroot.net/results/caba78cc2706accc187a428364c0e0d10a1dcd60  
> > 
> > Missing -fPIC apparently. Sam?
> 
> I had a closer look at this one. What happens is:
> 
>  1. libsidplay is autoreconf'ed due to <pkg>_AUTORECONF = YES
> 
>  2. we apply the powerpc64le trick that patches the configure script,
>     thanks to this, during the configure step, the fact that shared
>     libraries are supported is properly detected.
> 
>  3. for some reason, when the build starts, it auto-autoreconfs itself,
>     which rewrites the configure script, without the powerpc64le
>     trick. ./configure is re-executed, and this time doesn't detected
>     shared library support anymore.
> 
> So the issue is: why does the package decides to auto-autoreconf itself
> at the beginning of the build step.

Ah, thanks for the investigation, I'll take a look at it.

Sam.

[Buildroot] Analysis of build results for 2017-02-26: librsvg failure

[Peter Korsgaard]

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

Hi,

 > The strace (which was added by me), give:

 > read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0V\0\0\0\0\0\0"..., 832) = 832
 > fstat(3, {st_mode=S_IFREG|0644, st_size=1088952, ...}) = 0
 > mmap(NULL, 3178744, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8df2576000
 > mprotect(0x7f8df267e000, 2093056, PROT_NONE) = 0
 > mmap(0x7f8df287d000, 8192, PROT_READ|PROT_WRITE,
 > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x107000) = 0x7f8df287d000
 > close(3)                                = 0
 > mprotect(0x7f8df287d000, 4096, PROT_READ) = 0
 > mprotect(0x7f8df361b000, 4096, PROT_READ) = 0
 > mprotect(0x7f8df556d000, 4096, PROT_READ) = 0
 > --- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x7f8df3d26f02} ---
 > +++ killed by SIGILL +++

Is that the complete strace output? Where is fd 3 getting opened? I
would imagine the problem is caused by some kind of host/target
libraries mixup.

-- 
Bye, Peter Korsgaard

[Buildroot] Analysis of build results for 2017-02-26: librsvg failure

[Thomas Petazzoni]

Hello,

On Tue, 28 Feb 2017 10:00:14 +0100, Peter Korsgaard wrote:

> Is that the complete strace output? Where is fd 3 getting opened? I
> would imagine the problem is caused by some kind of host/target
> libraries mixup.

No, that's only the end of the strace output. I've posted the full
strace output at:

  http://code.bulix.org/elused-120071

File descriptor 3 is:

open("/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3

Which looks correct to me, when running a host binary on the host machine.

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

[Buildroot] Analysis of build results for 2017-02-26: librsvg failure

[Thomas Petazzoni]

Hello,

On Tue, 28 Feb 2017 10:05:42 +0100, Thomas Petazzoni wrote:

> No, that's only the end of the strace output. I've posted the full
> strace output at:
> 
>   http://code.bulix.org/elused-120071
> 
> File descriptor 3 is:
> 
> open("/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
> 
> Which looks correct to me, when running a host binary on the host machine.

Ok, so I went through the next stage: running the program under gdb, so
now I know exactly the instruction that faulted, in which function, etc.

Program received signal SIGILL, Illegal instruction.
0x00007ffff4869f02 in have_feature ()
   from target:/home/thomas/projets/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libpixman-1.so.0
(gdb) bt
#0  0x00007ffff4869f02 in have_feature ()
   from target:/home/thomas/projets/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libpixman-1.so.0

So we're crashing in libpixman, in the have_feature() function, whose
goal is precisely to determine the capabilities of the CPU we are
running on.

The faulty instruction is:

(gdb) disassemble
Dump of assembler code for function have_feature:
   0x00007ffff4869ee1 <+0>:	push   %r13
   0x00007ffff4869ee3 <+2>:	push   %r12
   0x00007ffff4869ee5 <+4>:	mov    %edi,%r12d
   0x00007ffff4869ee8 <+7>:	push   %rbp
   0x00007ffff4869ee9 <+8>:	push   %rbx
   0x00007ffff4869eea <+9>:	sub    $0x18,%rsp
   0x00007ffff4869eee <+13>:	cmpl   $0x0,0x25e85f(%rip)        # 0x7ffff4ac8754 <initialized.4467>
   0x00007ffff4869ef5 <+20>:	jne    0x7ffff4869fc6 <have_feature+229>
   0x00007ffff4869efb <+26>:	mov    $0x1,%eax
   0x00007ffff4869f00 <+31>:	cpuid  
=> 0x00007ffff4869f02 <+33>:	bextr  $0x10f,%edx,%ebp
   0x00007ffff4869f0b <+42>:	shl    $0x4,%ebp
   0x00007ffff4869f0e <+45>:	mov    %ebp,%eax
   0x00007ffff4869f10 <+47>:	or     $0x1,%eax

This bextr instruction is indeed a somewhat new instruction: it was
introduced in the Haswell micro-architecture, but my i7-4600U is a
Haswell one. I'm not a big expert in Intel architecture, but I believe
this instruction should therefore be valid on my CPU.

What is very weird is that if I run this program outside of the build
process, it runs fine. It's only when it's run within the overall build
process that it crashes on this instruction. To get the above gdb
stuff, I had to hack the package Makefile to run the program under
gdbserver, and connect to it.

Looking at the pixman code, I don't see any place where a bextr
instruction is explicitly used, so it seems like it's generated by gcc.

Another weird thing: this only happens if the target is x86-64, with a
specific toolchain. Now, the question is: why a host package crash can
be related to the target architecture/toolchain...

/me calling Mulder and Scully :)

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

[Buildroot] Analysis of build results for 2017-02-26: librsvg failure

[Peter Korsgaard]

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

 > Hello,
 > On Tue, 28 Feb 2017 10:00:14 +0100, Peter Korsgaard wrote:

 >> Is that the complete strace output? Where is fd 3 getting opened? I
 >> would imagine the problem is caused by some kind of host/target
 >> libraries mixup.

 > No, that's only the end of the strace output. I've posted the full
 > strace output at:

 >   http://code.bulix.org/elused-120071

 > File descriptor 3 is:

 > open("/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3

 > Which looks correct to me, when running a host binary on the host machine.

Yes, but the part where it loads a library from the target-librsvg
doesn't:

stat("/home/thomas/projets/buildroot/output/build/librsvg-2.40.16/gdk-pixbuf-loader", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/home/thomas/projets/buildroot/output/build/librsvg-2.40.16/gdk-pixbuf-loader/./libpixbufloader-svg.la", {st_mode=S_IFREG|0644, st_size=3987, ...}) = 0
open("/home/thomas/projets/buildroot/output/build/librsvg-2.40.16/gdk-pixbuf-loader/./libpixbufloader-svg.la", O_RDONLY) = 3
read(3, "# libpixbufloader-svg.la - a lib"..., 4000) = 3987
futex(0x7fb04bc20488, FUTEX_WAKE_PRIVATE, 2147483647) = 0
read(3, "", 4000)                       = 0
close(3)                                = 0
futex(0x7fb04b3480a8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open("/home/thomas/projets/buildroot/output/build/librsvg-2.40.16/gdk-pixbuf-loader/./.libs/libpixbufloader-svg.so", O_RDONLY|O_CLOEXEC) = 3

-- 
Bye, Peter Korsgaard

[Buildroot] Analysis of build results for 2017-02-26

[Vlad Zakharov]

Hi Thomas,

On Mon, 2017-02-27 at 14:28 +0100, Thomas Petazzoni wrote:
> >????????? arc |???????????????????? mpd-0.20.4 | NOK ?
> 
> Lacks a -lpthread apparently:
> 
> /home/peko/autobuild/instance-1/output/host/opt/ext-toolchain/bin/../lib/gcc/arc-snps-linux-
> uclibc/6.2.1/../../../../arc-snps-linux-uclibc/bin/ld: libthread.a(Thread.o): undefined reference to symbol
> 'pthread_create'
> /home/peko/autobuild/instance-1/output/host/usr/arc-buildroot-linux-uclibc/sysroot/lib/libpthread.so.0: error adding
> symbols: DSO missing from command line
> 
> but the configure script fails to detect thread support:
> 
> checking for the pthreads library -lpthread... no
> 
> Aah, they test if the compiler defines _REENTRANT:
> 
> conftest.c:15:26: error: #error "_REENTRANT must be defined"
> ?#??????????????????????? error "_REENTRANT must be defined"
> 
> and I know some architectures forget to do so.
> 
> I already reported this bug to gcc upstream:
> 
> ?https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71749?
> 
> Vlad, could you have a look into this? We have
> package/gcc/6.3.0/895-bfin-define-REENTRANT.patch for Blackfin in the
> tree, but we don't have the corresponding patch for ARC.

The patch you have provided in gcc bugzilla solves the issue, thanks.
I am going to send it to Buildroot soon.

If you want to upstream your patch to gcc please send it to GCC mailing list. And please don't forget to include Claudiu
Zissulescu <claziss@synopsys.com>?in CC as he is co-maintainer of GCC port for ARC.

Thanks!

-- 
Best regards,
Vlad Zakharov <vzakhar@synopsys.com>

[Buildroot] Analysis of build results for 2017-02-26: librsvg failure

[Thomas Petazzoni]

Hello,

On Tue, 28 Feb 2017 15:48:08 +0100, Peter Korsgaard wrote:

>  > Which looks correct to me, when running a host binary on the host machine.  
> 
> Yes, but the part where it loads a library from the target-librsvg
> doesn't:
> 
> stat("/home/thomas/projets/buildroot/output/build/librsvg-2.40.16/gdk-pixbuf-loader", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> stat("/home/thomas/projets/buildroot/output/build/librsvg-2.40.16/gdk-pixbuf-loader/./libpixbufloader-svg.la", {st_mode=S_IFREG|0644, st_size=3987, ...}) = 0
> open("/home/thomas/projets/buildroot/output/build/librsvg-2.40.16/gdk-pixbuf-loader/./libpixbufloader-svg.la", O_RDONLY) = 3
> read(3, "# libpixbufloader-svg.la - a lib"..., 4000) = 3987
> futex(0x7fb04bc20488, FUTEX_WAKE_PRIVATE, 2147483647) = 0
> read(3, "", 4000)                       = 0
> close(3)                                = 0
> futex(0x7fb04b3480a8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
> open("/home/thomas/projets/buildroot/output/build/librsvg-2.40.16/gdk-pixbuf-loader/./.libs/libpixbufloader-svg.so", O_RDONLY|O_CLOEXEC) = 3

Wow, indeed!

But how does this fit with my findings with gdb, which were pointing at
a faulty instruction in the host libpixman?

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

[Buildroot] Analysis of build results for 2017-02-26

[Thomas Petazzoni]

Hello,

On Tue, 28 Feb 2017 15:34:56 +0000, Vlad Zakharov wrote:

> > Vlad, could you have a look into this? We have
> > package/gcc/6.3.0/895-bfin-define-REENTRANT.patch for Blackfin in the
> > tree, but we don't have the corresponding patch for ARC.  
> 
> The patch you have provided in gcc bugzilla solves the issue, thanks.
> I am going to send it to Buildroot soon.

Great, thanks for checking!

> If you want to upstream your patch to gcc please send it to GCC mailing list. And please don't forget to include Claudiu
> Zissulescu <claziss@synopsys.com>?in CC as he is co-maintainer of GCC port for ARC.

I received some feedback from Claudio through the gcc bug tracker. I'll
try to get my gcc patch submitted upstream. Thanks!

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

[Buildroot] Analysis of build results for 2017-02-26: librsvg failure

[Peter Korsgaard]

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

Hi,

 > Wow, indeed!

 > But how does this fit with my findings with gdb, which were pointing at
 > a faulty instruction in the host libpixman?

Target libpixman, not host-pixman. From the log:

open("/home/thomas/projets/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libpixman-1.so.0", O_RDONLY|O_CLOEXEC) = 3

So I guess it is all caused by host/target mismatch and the specific
optimization options selected.

-- 
Bye, Peter Korsgaard