* [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-11
@ 2017-05-12 6:29 Thomas Petazzoni
2017-05-14 17:45 ` Eric Le Bihan
0 siblings, 1 reply; 8+ messages in thread
From: Thomas Petazzoni @ 2017-05-12 6:29 UTC (permalink / raw)
To: buildroot
Hello,
Build statistics for 2017-05-11
================================
successes : 244
failures : 21
timeouts : 0
TOTAL : 265
Classification of failures by reason
====================================
opencv3-3.2.0 | 3
libcdio-0.94 | 2
mplayer-1.3.0 | 2
ntp-4.2.8p10 | 2
radvd-2.12 | 2
bluez_utils-4.101 | 1
ltp-testsuite-20170116 | 1
mimic-1.1.0 | 1
openblas-f04af36ad0e85b64f1... | 1
poppler-0.54.0 | 1
protobuf-3.2.0 | 1
skalibs-2.4.0.2 | 1
sudo-1.8.19p2 | 1
uclibc-ng-test-c9b9876cefc1... | 1
upmpdcli-1.2.12 | 1
Detail of failures
===================
arm | bluez_utils-4.101 | NOK | http://autobuild.buildroot.net/results/07e2f952ec974ab765acdf9209d2026504d495cc |
arc | libcdio-0.94 | NOK | http://autobuild.buildroot.net/results/6c305d720062c651dd856ed0bc5d30ab5fb31285 |
arc | libcdio-0.94 | NOK | http://autobuild.buildroot.net/results/ebc83038f86b49bce818bf43b4479ca5df86b2dd |
mips64el | ltp-testsuite-20170116 | NOK | http://autobuild.buildroot.net/results/b448569c1f899f08f704e556208b1db2be04f46e |
mipsel | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/a814dc78a9fc7bc80d0b82083817ddfe9cdb3c29 |
i686 | mplayer-1.3.0 | NOK | http://autobuild.buildroot.net/results/525048619d7d4438092ccb2f5d5da8c1e8929f1e |
i686 | mplayer-1.3.0 | NOK | http://autobuild.buildroot.net/results/b4dfa228118c20737e47323650194e9202567381 |
aarch64 | ntp-4.2.8p10 | NOK | http://autobuild.buildroot.net/results/1e5d70b1a48bdda4e2708ab584b61a966cbef62a | ORPH
mips | ntp-4.2.8p10 | NOK | http://autobuild.buildroot.net/results/c2a945855172970736a8ffea9c564f029a023344 | ORPH
sparc | openblas-f04af36ad0e85b64f1... | NOK | http://autobuild.buildroot.net/results/6699b89f96ed7095a14bfa18248444534eb81083 |
mips64el | opencv3-3.2.0 | NOK | http://autobuild.buildroot.net/results/421ba36bae19ead1bbe366cc7eac429b45a29990 |
arm | opencv3-3.2.0 | NOK | http://autobuild.buildroot.net/results/6b89c74c72694f61a5e86e5f8c26263d9e0afe47 |
x86_64 | opencv3-3.2.0 | NOK | http://autobuild.buildroot.net/results/32d6ac30ca5621b45f7090abb5fb76d9f577c066 |
arm | poppler-0.54.0 | NOK | http://autobuild.buildroot.net/results/1cc931a2d9658beebf2b82f10013c04cc3823bdc |
sparc | protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/1a328ea6e202898d5e39c904f713da3667b25806 | ORPH
xtensa | radvd-2.12 | NOK | http://autobuild.buildroot.net/results/7b9d92c859aa5ba11d6a1b10b482f887d8201eb1 | ORPH
microblazeel | radvd-2.12 | NOK | http://autobuild.buildroot.net/results/949a75d96299394e4ac957746fa23a4b52f31b43 | ORPH
sparc | skalibs-2.4.0.2 | NOK | http://autobuild.buildroot.net/results/85062b5f9dbe74d7d1c6edfeda085268ecaef4c2 |
arm | sudo-1.8.19p2 | NOK | http://autobuild.buildroot.net/results/ebbb4c3138b5023a0c8bd938db1932a25ba5b6fb | ORPH
nios2 | uclibc-ng-test-c9b9876cefc1... | NOK | http://autobuild.buildroot.net/results/8a0eaea2d3b2fb76bd68fab22623e118e00173cb |
arm | upmpdcli-1.2.12 | NOK | http://autobuild.buildroot.net/results/251c6ea384f638a8ab6831394b62373baef6f63a |
--
http://autobuild.buildroot.net
^ permalink raw reply [flat|nested] 8+ messages in thread* [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-11 2017-05-12 6:29 [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-11 Thomas Petazzoni @ 2017-05-14 17:45 ` Eric Le Bihan 2017-05-14 19:19 ` Thomas Petazzoni 0 siblings, 1 reply; 8+ messages in thread From: Eric Le Bihan @ 2017-05-14 17:45 UTC (permalink / raw) To: buildroot Hi! On 17-05-12 08:29:50, Thomas Petazzoni wrote: > sparc | skalibs-2.4.0.2 | NOK | http://autobuild.buildroot.net/results/85062b5f9dbe74d7d1c6edfeda085268ecaef4c2 | This one is puzzling. The configure steps ends with the following error: ``` Checking whether system has auto-close after fd-passing... ... test crashed, aborting. make: *** [/accts/mlweber1/instance-2/output/build/skalibs-2.4.0.2/.stamp_configured] Error 111 make: Leaving directory `/accts/mlweber1/instance-2/buildroot' ``` The configure script tries to cross-compile and execute a program (tryancilautoclose). The cross-compilation succeeds and of course the execution fails, as it means running a program compiled for the SPARC architecture on a x86 machine. Normally, the shell which executes the program should return the code 126, as mentioned in the list of Bash exit codes with special meaning [1]. Here the exit code is 111. When looking at tryancilautoclose.c, we can see that 111 may be returned. So this error means that either the shell managed to execute the cross-compiled program or the shell does not follow the convention [1]. Which are the architecture of the build machine and the shell used? [1] http://tldp.org/LDP/abs/html/exitcodes.html -- ELB ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-11 2017-05-14 17:45 ` Eric Le Bihan @ 2017-05-14 19:19 ` Thomas Petazzoni 2017-05-15 1:09 ` Matthew Weber 0 siblings, 1 reply; 8+ messages in thread From: Thomas Petazzoni @ 2017-05-14 19:19 UTC (permalink / raw) To: buildroot Hello, On Sun, 14 May 2017 19:45:06 +0200, Eric Le Bihan wrote: > On 17-05-12 08:29:50, Thomas Petazzoni wrote: > > > sparc | skalibs-2.4.0.2 | NOK | http://autobuild.buildroot.net/results/85062b5f9dbe74d7d1c6edfeda085268ecaef4c2 | > > This one is puzzling. The configure steps ends with the following error: > > ``` > Checking whether system has auto-close after fd-passing... > ... test crashed, aborting. > make: *** > [/accts/mlweber1/instance-2/output/build/skalibs-2.4.0.2/.stamp_configured] > Error 111 > make: Leaving directory `/accts/mlweber1/instance-2/buildroot' > ``` > > The configure script tries to cross-compile and execute a program > (tryancilautoclose). The cross-compilation succeeds and of course the > execution fails, as it means running a program compiled for the > SPARC architecture on a x86 machine. Normally, the shell which executes > the program should return the code 126, as mentioned in the list of Bash > exit codes with special meaning [1]. > > Here the exit code is 111. When looking at tryancilautoclose.c, we can > see that 111 may be returned. > > So this error means that either the shell managed to execute the > cross-compiled program or the shell does not follow the convention [1]. > > Which are the architecture of the build machine and the shell used? Thanks for investigating this issue. This build failure occurred on Matt Weber's autobuilder instance, so I've added him in Cc. His instance has already triggered some weird issues recently due to an unusual setup. Hopefully Matt will be able to shed some light on what's going on, possibly reproduce by hand the issue and investigate. Thanks! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-11 2017-05-14 19:19 ` Thomas Petazzoni @ 2017-05-15 1:09 ` Matthew Weber 2017-05-15 2:53 ` Matthew Weber 0 siblings, 1 reply; 8+ messages in thread From: Matthew Weber @ 2017-05-15 1:09 UTC (permalink / raw) To: buildroot Thomas/Eric, On Sun, May 14, 2017 at 2:19 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Hello, > > On Sun, 14 May 2017 19:45:06 +0200, Eric Le Bihan wrote: > >> On 17-05-12 08:29:50, Thomas Petazzoni wrote: >> >> > sparc | skalibs-2.4.0.2 | NOK | http://autobuild.buildroot.net/results/85062b5f9dbe74d7d1c6edfeda085268ecaef4c2 | >> >> This one is puzzling. The configure steps ends with the following error: >> >> ``` >> Checking whether system has auto-close after fd-passing... >> ... test crashed, aborting. >> make: *** >> [/accts/mlweber1/instance-2/output/build/skalibs-2.4.0.2/.stamp_configured] >> Error 111 >> make: Leaving directory `/accts/mlweber1/instance-2/buildroot' >> ``` >> >> The configure script tries to cross-compile and execute a program >> (tryancilautoclose). The cross-compilation succeeds and of course the >> execution fails, as it means running a program compiled for the >> SPARC architecture on a x86 machine. Normally, the shell which executes >> the program should return the code 126, as mentioned in the list of Bash >> exit codes with special meaning [1]. >> >> Here the exit code is 111. When looking at tryancilautoclose.c, we can >> see that 111 may be returned. >> >> So this error means that either the shell managed to execute the >> cross-compiled program or the shell does not follow the convention [1]. >> >> Which are the architecture of the build machine and the shell used? > > Thanks for investigating this issue. This build failure occurred on > Matt Weber's autobuilder instance, so I've added him in Cc. His > instance has already triggered some weird issues recently due to an > unusual setup. Hopefully Matt will be able to shed some light on what's > going on, possibly reproduce by hand the issue and investigate. > Here's the machine info # uname -a Linux largo 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux # ls -l /bin/sh lrwxrwxrwx 1 root root 4 Nov 18 2014 /bin/sh -> bash # bash --version GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu) I'll kick off a manual recreation now and see how it ends up. Matt ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-11 2017-05-15 1:09 ` Matthew Weber @ 2017-05-15 2:53 ` Matthew Weber 2017-05-15 3:03 ` Matthew Weber 0 siblings, 1 reply; 8+ messages in thread From: Matthew Weber @ 2017-05-15 2:53 UTC (permalink / raw) To: buildroot Eric, On Sun, May 14, 2017 at 8:09 PM, Matthew Weber <matthew.weber@rockwellcollins.com> wrote: > Thomas/Eric, > > On Sun, May 14, 2017 at 2:19 PM, Thomas Petazzoni > <thomas.petazzoni@free-electrons.com> wrote: >> Hello, >> >> On Sun, 14 May 2017 19:45:06 +0200, Eric Le Bihan wrote: >> >>> On 17-05-12 08:29:50, Thomas Petazzoni wrote: >>> >>> > sparc | skalibs-2.4.0.2 | NOK | http://autobuild.buildroot.net/results/85062b5f9dbe74d7d1c6edfeda085268ecaef4c2 | >>> >>> This one is puzzling. The configure steps ends with the following error: >>> >>> ``` >>> Checking whether system has auto-close after fd-passing... >>> ... test crashed, aborting. >>> make: *** >>> [/accts/mlweber1/instance-2/output/build/skalibs-2.4.0.2/.stamp_configured] >>> Error 111 >>> make: Leaving directory `/accts/mlweber1/instance-2/buildroot' >>> ``` >>> >>> The configure script tries to cross-compile and execute a program >>> (tryancilautoclose). The cross-compilation succeeds and of course the >>> execution fails, as it means running a program compiled for the >>> SPARC architecture on a x86 machine. Normally, the shell which executes >>> the program should return the code 126, as mentioned in the list of Bash >>> exit codes with special meaning [1]. >>> >>> Here the exit code is 111. When looking at tryancilautoclose.c, we can >>> see that 111 may be returned. >>> >>> So this error means that either the shell managed to execute the >>> cross-compiled program or the shell does not follow the convention [1]. >>> >>> Which are the architecture of the build machine and the shell used? >> >> Thanks for investigating this issue. This build failure occurred on >> Matt Weber's autobuilder instance, so I've added him in Cc. His >> instance has already triggered some weird issues recently due to an >> unusual setup. Hopefully Matt will be able to shed some light on what's >> going on, possibly reproduce by hand the issue and investigate. >> > > Here's the machine info > # uname -a > Linux largo 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC > 2014 x86_64 x86_64 x86_64 GNU/Linux > # ls -l /bin/sh > lrwxrwxrwx 1 root root 4 Nov 18 2014 /bin/sh -> bash > # bash --version > GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu) > > I'll kick off a manual recreation now and see how it ends up. > Well this is interesting and I'll have to dig around some more but here's what I've found after doing a build. It looks like I have SPARC ELF ABI compatibility on my x86_64 Ubuntu 14.04.1 machine. I can execute the test app since it's statically linked. # ./tryancilautoclose Unsupported ancillary data: 65535/1 # echo $? 111 # file tryancilautoclose tryancilautoclose: ELF 32-bit MSB executable, SPARC version 1 (SYSV), statically linked, with unknown capability 0x41000000 = 0xf676e75, with unknown capability 0x10000 = 0x70403, not stripped Matt ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-11 2017-05-15 2:53 ` Matthew Weber @ 2017-05-15 3:03 ` Matthew Weber 2017-05-15 7:23 ` Thomas Petazzoni 0 siblings, 1 reply; 8+ messages in thread From: Matthew Weber @ 2017-05-15 3:03 UTC (permalink / raw) To: buildroot All, On Sun, May 14, 2017 at 9:53 PM, Matthew Weber <matthew.weber@rockwellcollins.com> wrote: > Eric, > > On Sun, May 14, 2017 at 8:09 PM, Matthew Weber > <matthew.weber@rockwellcollins.com> wrote: >> Thomas/Eric, >> >> On Sun, May 14, 2017 at 2:19 PM, Thomas Petazzoni >> <thomas.petazzoni@free-electrons.com> wrote: >>> Hello, >>> >>> On Sun, 14 May 2017 19:45:06 +0200, Eric Le Bihan wrote: >>> >>>> On 17-05-12 08:29:50, Thomas Petazzoni wrote: >>>> >>>> > sparc | skalibs-2.4.0.2 | NOK | http://autobuild.buildroot.net/results/85062b5f9dbe74d7d1c6edfeda085268ecaef4c2 | >>>> >>>> This one is puzzling. The configure steps ends with the following error: >>>> >>>> ``` >>>> Checking whether system has auto-close after fd-passing... >>>> ... test crashed, aborting. >>>> make: *** >>>> [/accts/mlweber1/instance-2/output/build/skalibs-2.4.0.2/.stamp_configured] >>>> Error 111 >>>> make: Leaving directory `/accts/mlweber1/instance-2/buildroot' >>>> ``` >>>> >>>> The configure script tries to cross-compile and execute a program >>>> (tryancilautoclose). The cross-compilation succeeds and of course the >>>> execution fails, as it means running a program compiled for the >>>> SPARC architecture on a x86 machine. Normally, the shell which executes >>>> the program should return the code 126, as mentioned in the list of Bash >>>> exit codes with special meaning [1]. >>>> >>>> Here the exit code is 111. When looking at tryancilautoclose.c, we can >>>> see that 111 may be returned. >>>> >>>> So this error means that either the shell managed to execute the >>>> cross-compiled program or the shell does not follow the convention [1]. >>>> >>>> Which are the architecture of the build machine and the shell used? >>> >>> Thanks for investigating this issue. This build failure occurred on >>> Matt Weber's autobuilder instance, so I've added him in Cc. His >>> instance has already triggered some weird issues recently due to an >>> unusual setup. Hopefully Matt will be able to shed some light on what's >>> going on, possibly reproduce by hand the issue and investigate. >>> >> >> Here's the machine info >> # uname -a >> Linux largo 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC >> 2014 x86_64 x86_64 x86_64 GNU/Linux >> # ls -l /bin/sh >> lrwxrwxrwx 1 root root 4 Nov 18 2014 /bin/sh -> bash >> # bash --version >> GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu) >> >> I'll kick off a manual recreation now and see how it ends up. >> > > Well this is interesting and I'll have to dig around some more but > here's what I've found after doing a build. It looks like I have > SPARC ELF ABI compatibility on my x86_64 Ubuntu 14.04.1 machine. I > can execute the test app since it's statically linked. > > # ./tryancilautoclose > Unsupported ancillary data: 65535/1 > # echo $? > 111 > # file tryancilautoclose > tryancilautoclose: ELF 32-bit MSB executable, SPARC version 1 (SYSV), > statically linked, with unknown capability 0x41000000 = 0xf676e75, > with unknown capability 0x10000 = 0x70403, not stripped > Ok, didn't realize the qemu-user-static will automatically hook-up support for executing the arch it supports seamlessly. When I straced I noticed the call into qemu-sparc-static. Since removing that package, I now observe what would be expected. # ./tryancilautoclose bash: ./tryancilautoclose: cannot execute binary file: Exec format error # echo $? 11126 Sorry about that one Eric, it's fixed now on that machine and shouldn't reoccur. Thomas, should there be a check or warning added as part of buildroot's package/host checking which would catch a case where qemu-user-static is installed and may adversely affect the build? Matt ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-11 2017-05-15 3:03 ` Matthew Weber @ 2017-05-15 7:23 ` Thomas Petazzoni 2017-05-24 1:54 ` Matthew Weber 0 siblings, 1 reply; 8+ messages in thread From: Thomas Petazzoni @ 2017-05-15 7:23 UTC (permalink / raw) To: buildroot Hello, On Sun, 14 May 2017 22:03:27 -0500, Matthew Weber wrote: > > Well this is interesting and I'll have to dig around some more but > > here's what I've found after doing a build. It looks like I have > > SPARC ELF ABI compatibility on my x86_64 Ubuntu 14.04.1 machine. I > > can execute the test app since it's statically linked. > > > > # ./tryancilautoclose > > Unsupported ancillary data: 65535/1 > > # echo $? > > 111 > > # file tryancilautoclose > > tryancilautoclose: ELF 32-bit MSB executable, SPARC version 1 (SYSV), > > statically linked, with unknown capability 0x41000000 = 0xf676e75, > > with unknown capability 0x10000 = 0x70403, not stripped > > Ok, didn't realize the qemu-user-static will automatically hook-up > support for executing the arch it supports seamlessly. When I straced > I noticed the call into qemu-sparc-static. Since removing that > package, I now observe what would be expected. Wow, ok. Thanks a lot for investigating this issue. > # ./tryancilautoclose > bash: ./tryancilautoclose: cannot execute binary file: Exec format error > # echo $? > 11126 > > Sorry about that one Eric, it's fixed now on that machine and shouldn't reoccur. > > Thomas, should there be a check or warning added as part of > buildroot's package/host checking which would catch a case where > qemu-user-static is installed and may adversely affect the build? Yes, we should definitely do something about that. Ideally, Buildroot should do something to prevent binfmt_misc from kicking off the execution of foreign binaries. I have no idea if this is possible. If not, at the very least, we should warn/error out, but I really hate when a build system/tool asks me to change my system-wide configuration to operate correctly. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-11 2017-05-15 7:23 ` Thomas Petazzoni @ 2017-05-24 1:54 ` Matthew Weber 0 siblings, 0 replies; 8+ messages in thread From: Matthew Weber @ 2017-05-24 1:54 UTC (permalink / raw) To: buildroot Thomas, On Mon, May 15, 2017 at 2:23 AM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Hello, > > On Sun, 14 May 2017 22:03:27 -0500, Matthew Weber wrote: > >> > Well this is interesting and I'll have to dig around some more but >> > here's what I've found after doing a build. It looks like I have >> > SPARC ELF ABI compatibility on my x86_64 Ubuntu 14.04.1 machine. I >> > can execute the test app since it's statically linked. >> > >> > # ./tryancilautoclose >> > Unsupported ancillary data: 65535/1 >> > # echo $? >> > 111 >> > # file tryancilautoclose >> > tryancilautoclose: ELF 32-bit MSB executable, SPARC version 1 (SYSV), >> > statically linked, with unknown capability 0x41000000 = 0xf676e75, >> > with unknown capability 0x10000 = 0x70403, not stripped >> >> Ok, didn't realize the qemu-user-static will automatically hook-up >> support for executing the arch it supports seamlessly. When I straced >> I noticed the call into qemu-sparc-static. Since removing that >> package, I now observe what would be expected. > > Wow, ok. Thanks a lot for investigating this issue. > >> # ./tryancilautoclose >> bash: ./tryancilautoclose: cannot execute binary file: Exec format error >> # echo $? >> 11126 >> >> Sorry about that one Eric, it's fixed now on that machine and shouldn't reoccur. >> >> Thomas, should there be a check or warning added as part of >> buildroot's package/host checking which would catch a case where >> qemu-user-static is installed and may adversely affect the build? > > Yes, we should definitely do something about that. Ideally, Buildroot > should do something to prevent binfmt_misc from kicking off the > execution of foreign binaries. I have no idea if this is possible. If > not, at the very least, we should warn/error out, but I really hate > when a build system/tool asks me to change my system-wide configuration > to operate correctly. > I looked at this a bit more, I think we could check for /proc/sys/fs/binfmt_misc being mounted and then see if any qemu-* files exist. Beyond that I'm unsure of the action to take. I think for autobuilder machines they should error out from the autobuilder script as you'd want binfmts disabled (sudo update-binfmts --disable) before that runs. However for the normal shared use server/build machine it does seem like an issue to enforce having that disabled as a pre-req to doing a buildroot build. Maybe a check initially at the beginning of make to warn the user..... Matt ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-05-24 1:54 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-05-12 6:29 [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-11 Thomas Petazzoni 2017-05-14 17:45 ` Eric Le Bihan 2017-05-14 19:19 ` Thomas Petazzoni 2017-05-15 1:09 ` Matthew Weber 2017-05-15 2:53 ` Matthew Weber 2017-05-15 3:03 ` Matthew Weber 2017-05-15 7:23 ` Thomas Petazzoni 2017-05-24 1:54 ` Matthew Weber
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.