Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-22  7:30 [Buildroot] [autobuild.buildroot.net] Build " Thomas Petazzoni
@ 2016-02-22 14:05 ` Thomas Petazzoni
  2016-02-23 10:12   ` John Keeping
                     ` (6 more replies)
  0 siblings, 7 replies; 23+ messages in thread
From: Thomas Petazzoni @ 2016-02-22 14:05 UTC (permalink / raw)
  To: buildroot

Hello,

The usual analysis of build failures. Karoly, Eric, Yann, Olivier,
Alexey, Lada, Bernd, Vicente, Alan, Waldemar, Samuel, Gustavo, could
you have a look below, there are some questions/issues for all of
you :-)

Thanks a lot!

On Mon, 22 Feb 2016 08:30:22 +0100 (CET), Thomas Petazzoni wrote:

>         mips |              bluez5_utils-5.37 | NOK | http://autobuild.buildroot.net/results/2bf4e5ea9b67b80ba38bfeaf71b747a92be09011/

tools/avinfo.c:193:24: error: unknown type name 'a2dp_ldac_t'
 static void print_ldac(a2dp_ldac_t *ldac)

It's not MIPS specific, since the same build issue occurred on other
architectures.

Could someone have a look ?

>          arm | canfestival-7740ac6fdedc23e... | NOK | http://autobuild.buildroot.net/results/92802995144a76202040421255b003aded527958/
>          arm | canfestival-7740ac6fdedc23e... | NOK | http://autobuild.buildroot.net/results/db5733d2a62f84f90056d5e48e3f08fe94b87a6d/

Musl build issue. A patch was submitted a long time ago, but got
rejected: https://patchwork.ozlabs.org/patch/509731/. Since nobody
really cared, I propose to mark canfestival as not available on musl.

>          arm |           chocolate-doom-2.2.1 | NOK | http://autobuild.buildroot.net/results/e09ea3a64d396bbc855acf7c07fcbea28fb2395d/

Static linking issue. Rodrigo is on it.

>          arm |                     cups-2.1.2 | NOK | http://autobuild.buildroot.net/results/07ccca8f80c56ab0ff48bfee876885b1c8c3916e/

/home/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.9.3/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld:
cannot find Scrt1.o: No such file or directory collect2: error: ld
returned 1 exit status Makefile:232: recipe for target 'ippserver'
failed

Olivier, you re-enabled and updated the CUPS package, can you have a
look ?


>          arc |                     cups-2.1.2 | NOK | http://autobuild.buildroot.net/results/b169b939e38cb761319a92d2871f4f59ddb5c4ac/

/home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/4.8.4/../../../../arc-buildroot-linux-uclibc/bin/ld:
BFD (GNU Binutils) 2.23.2 assertion fail
elf32-arc.c:3062 /home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/4.8.4/../../../../arc-buildroot-linux-uclibc/bin/ld:
BFD (GNU Binutils) 2.23.2 assertion fail elf32-arc.c:3062

Alexey, Lada, this is an ARC toolchain issue. Any hints?

>      aarch64 |                    erlang-17.5 | NOK | http://autobuild.buildroot.net/results/8b47dea53fc8608ab62cadfaeecdf828fd3d940f/

Atomic operations problem, this is being discussed around a patch that
was submitted by Frank.

>         sh4a |                    fio-fio-2.6 | NOK | http://autobuild.buildroot.net/results/68f98acca8b02aeaa98c78d2e95a6a29df629fef/

mutex.o: In function `fio_mutex_up':
/home/test/autobuild/instance-1/output/build/fio-fio-2.6/mutex.c:182: undefined reference to `arch_flags'

Not sure what's going on. Someone to investigate?

>          arm |                      gdb-7.9.1 | NOK | http://autobuild.buildroot.net/results/edfb6854306ccaed9592139ad803850c2e0011d2/

linux-nat.c: In function 'lin_thread_get_thread_signals':
linux-nat.c:4878:15: error: '__SIGRTMIN' undeclared (first use in this function)
     restart = __SIGRTMIN;

Smells like a musl build issue. Bernd had a patch "[PATCH 1/1]
package/gdb: Fix musl build", which I marked as "Changes Requested"
yesterday. It looks like this particular patch was pretty good, though
submitting the patch upstream would be good (the patch says it was
submitted and points to an almost 5 years old bug report).

>     mips64el |               gst1-libav-1.6.3 | NOK | http://autobuild.buildroot.net/results/b848969d518008dadb40fbebc40bab4124231c2b/
>     mips64el |               gst1-libav-1.6.3 | NOK | http://autobuild.buildroot.net/results/ace98b9c51379e19f70bbe0bda94ff80ab9dd7fc/

Vicente, this one is for you:

libavformat/aadec.c:1:0: error: '-mips64r2' conflicts with the other architecture options, which specify a mips64r6 processor

>         i686 | hidapi-d17db57b9d4354752e0a... | NOK | http://autobuild.buildroot.net/results/6f0c9a682bc98f962874a38c9e2a334fea21b0cb/
>       xtensa | hidapi-d17db57b9d4354752e0a... | NOK | http://autobuild.buildroot.net/results/a9216cd5f9568ef134b64341b629efea40d54fe1/

make[3]: Entering directory `/home/peko/autobuild/instance-2/output/build/hidapi-d17db57b9d4354752e0af42f5f33007a42ef2906/hidtest'
make[3]: *** No rule to make target `hidtest.o', needed by `hidtest-libusb'.  Stop.

Might be a parallel build issue. Alan, hidapi is your thing, can you
have a look?

>       x86_64 |                host-efl-1.15.3 | NOK | http://autobuild.buildroot.net/results/c427d13cf1c50305047a3f0b0051520e672f91d8/

Fixed by https://git.busybox.net/buildroot/commit/?id=fd7a2eacb37274e9bfc7d59eb4b3c4840a4c8a2d.

>          arm |        host-erlang-rebar-2.5.1 | TIM | http://autobuild.buildroot.net/results/685e2ec91d889c6a789025864e6b4890ef6b532d/

Ignore.

>          arm |                    hostapd-2.5 | NOK | http://autobuild.buildroot.net/results/39ff650ca14bdfa35b35bbf13e01cfceeb43035e/

Musl build problem.

>          arm |                  igmpproxy-0.1 | NOK | http://autobuild.buildroot.net/results/f44629feae5eb8b8b61e88eac5b24cbfce8a1c4d/

Musl build problem.

>          arm |                ipmitool-1.8.15 | NOK | http://autobuild.buildroot.net/results/ad8fbadedc152ec93c175aeb24f062e8290a352e/

Musl build problem.

>       x86_64 |              ipsec-tools-0.8.2 | NOK | http://autobuild.buildroot.net/results/d618837a536dfd3d076ae1cecd1f598b4bf7efcd/
>       x86_64 |              ipsec-tools-0.8.2 | NOK | http://autobuild.buildroot.net/results/fa6b8a8175420e9d76f23eb7b61075ac5ce315de/

Musl build problem.

>          arm |             kodi-15.2-Isengard | NOK | http://autobuild.buildroot.net/results/43939f65e4516adddc4385c6e0a2193abcab0446/

Usage of 64-bits on ARM with uClibc, doesn't work because gcc uses the
__write() internal glibc symbol. We need to isolate the Kodi features
that uses this 64 bits atomic operation (if possible) and make it
depend on BR2_TOOLCHAIN_ARM_HAS_SYNC_8. See also
https://git.busybox.net/buildroot/tree/toolchain/toolchain-common.in#n339
for a discussion of this problem.

Bernd ?

>          arm | kodi-pvr-argustv-32f03271cc... | NOK | http://autobuild.buildroot.net/results/dacc3bd00ab2346d7655c0a1fb99f6c50b9da08b/

Bernd ?

>        nios2 |                libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/67f19f1fdf642c3c72deb931cb674b114bacc4da/
>        nios2 |                libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/ed2503778126253fad08d9828f442a0b9d042fc2/

nios2 toolchain bug, will be fixed by
http://patchwork.ozlabs.org/patch/582313/.

>        sparc |                  libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/a17047ada385e5be5f60c07254597fcb7c4183d0/
>        sparc |                  libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/6d79591bce2d3fa5b93e268fe50d5b89ecd24521/

Could be fixed by http://patchwork.ozlabs.org/patch/569818/, but this
patch is wrong I believe now that we have proper Config.in options to
describe atomic operation dependencies.

Waldemar, could you have a look?

>       x86_64 |                  libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/52cdd46091740aab423987bdd6e2423b157a8799/

Musl build issue.

>          arc |                  libraw-0.17.1 | NOK | http://autobuild.buildroot.net/results/b1d80c4b62bd71e722f53b0e2caadd7951f23dd7/

/tmp/ccmCzrHn.s: Assembler messages:
/tmp/ccmCzrHn.s:765: Error: invalid register number `63'
/tmp/ccmCzrHn.s:3686: Error: invalid register number `63'
/tmp/ccmCzrHn.s:3688: Error: invalid register number `63'

Alexey, Lada, toolchain issue.

>        sparc |                libsodium-1.0.6 | TIM | http://autobuild.buildroot.net/results/80988d3cc1cebd32b5c9718b936f9dfe9c10e34a/

Ignore.

>      sparc64 |         ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/ce2c1fb10dfef1039545443ff9ef969889d2bf40/

Waldemar, this is a sparc64 issue, can you have a look?

> microblazeel | make[3]: *** [code/CMakeFil... | TIM | http://autobuild.buildroot.net/results/a692bc6df992cd05470fcc5b6e59ffb449da2069/

Ignore.

>          arc |                  mesa3d-11.1.1 | NOK | http://autobuild.buildroot.net/results/0eb25c0756eeb6b7ad4d3b1a86a47dfff3d766ef/

collect2: error: ld terminated with signal 11 [Segmentation fault]
Makefile:918: recipe for target 'gallium_dri.la' failed

Alexey, Lada, toolchain issue.

> microblazeel |                  mesa3d-11.1.1 | NOK | http://autobuild.buildroot.net/results/521aad4fd2e24fd78fa26a1d0c6284d56100a467/

./.libs/libglsl.a(glsl_parser_extras.o): In function `_mesa_glsl_compile_shader':
(.text+0x3850): undefined reference to `__sync_val_compare_and_swap_1'

Need to add some atomic operation dependency here.

>      aarch64 |                    mplayer-1.2 | NOK | http://autobuild.buildroot.net/results/e82b37607e3ef9efb0933e9300c48074d249a414/

mplayer on aarch64 has been failing to build for a while. I asked Joao
to fix the issue (since he enabled Mplayer on aarch64), but never
submitted a fix. I had a quick look, it didn't seem to be trivial, so I
propose to disable mplayer on aarch64.

>      powerpc |                nfs-utils-1.3.3 | NOK | http://autobuild.buildroot.net/results/630771e41d71443e7c6a1ab3367199ebcc451153/
>      powerpc |                nfs-utils-1.3.3 | NOK | http://autobuild.buildroot.net/results/ddb1f5ccb1fb41fdfb7c035c0a8282a4afaa9c61/

Patch pending from Maxime, http://patchwork.ozlabs.org/patch/577178/.

>      powerpc |                 numactl-2.0.11 | NOK | http://autobuild.buildroot.net/results/11e90fc79cb96631fd3e44af7e15650047858b7d/
>      powerpc |                 numactl-2.0.11 | NOK | http://autobuild.buildroot.net/results/1997e8c52e093395bc0b15d6de1ccf328e077fce/
>      powerpc |                 numactl-2.0.11 | NOK | http://autobuild.buildroot.net/results/39892be2a1857b727f4213079faaade52d4da0d2/
>     mips64el |                 numactl-2.0.11 | NOK | http://autobuild.buildroot.net/results/131b044097725c00c58c05bf0d4e2afa05cf145a/
>      powerpc |                 numactl-2.0.11 | NOK | http://autobuild.buildroot.net/results/4db511e9d09b67ea333814d3698866c82c7afb54/
>      powerpc |                 numactl-2.0.11 | NOK | http://autobuild.buildroot.net/results/6a1470c60b08c95765f3549177dfa6059b76493b/

Discussion on-going at http://patchwork.ozlabs.org/patch/582442/.

>      sparc64 |                  opencv-2.4.10 | NOK | http://autobuild.buildroot.net/results/63086c31c57fd68aa2759c51d7dfd49ae9e7239b/
>      sparc64 |                  opencv-2.4.10 | NOK | http://autobuild.buildroot.net/results/d05d7a24283cb0b5f305a7cd4cf8a60a4be7959d/
>      sparc64 |                  opencv-2.4.10 | NOK | http://autobuild.buildroot.net/results/92ebbd138dea50183880db49f920439b60e6f89b/

Not sure. Waldemar (sparc64 person) and Samuel (OpenCV person), any
idea ? Seems atomic related.

>          arm |        openpgm-release-5-2-122 | NOK | http://autobuild.buildroot.net/results/bc6209c2531c791a095935ffc6ff461de04f5b04/

Musl build issue.

>         i686 |      openvmtools-stable-9.10.2 | NOK | http://autobuild.buildroot.net/results/a6b5ef77df470c99c83ccc02a731f944e9747c65/

checking for getstat in -lproc-3.2.8... no
checking for getstat in -lproc-3.2.7... no
configure: error: libproc not found. Please configure without procps (using --without-procps) or install procps - http://procps.sourceforge.net

Karoly, can you have a look, since you originally added openvmtools?

>      powerpc |                pax-utils-1.1.4 | NOK | http://autobuild.buildroot.net/results/8a3156e287282fb63c009e04248faf09f9b29476/
>      powerpc |                pax-utils-1.1.4 | NOK | http://autobuild.buildroot.net/results/d2686e71dcc1cf017503f7c68efdfe5c521abbc3/

security.c:245:8: error: 'PR_SET_NO_NEW_PRIVS' undeclared (first use in this function)
security.c:245:8: note: each undeclared identifier is reported only once for each function it appears in

Too old kernel headers?

>         bfin |                pax-utils-1.1.4 | NOK | http://autobuild.buildroot.net/results/ee3701c11ba8094e74c7356105ee2a18c2c73100/

pspax.o: In function `_main':
pspax.c:(.text+0x4c8): undefined reference to `_cap_init'
pspax.c:(.text+0x964): undefined reference to `_capgetp'
pspax.c:(.text+0x970): undefined reference to `_cap_to_text'
pspax.c:(.text+0xe42): undefined reference to `_cap_free'

Static linking broken ?

>         i686 |                pax-utils-1.1.4 | NOK | http://autobuild.buildroot.net/results/a854da559be1d617d31acbb08c39e6ac5464cee7/

security.c: In function 'security_init':
security.c:245:8: error: 'PR_SET_NO_NEW_PRIVS' undeclared (first use in this function)
  prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);

Same as the PowerPC issue.

Gustavo, since you added pax-utils, can you have a look?

>          arm |                    perl-5.22.1 | NOK | http://autobuild.buildroot.net/results/985dc18ec04901bea7d4fdd6e0145f7625e80869/

/home/buildroot/build/instance-1/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libgdbm.a(gdbmerrno.o): In function `gdbm_strerror':
gdbmerrno.c:(.text+0x18): undefined reference to `libintl_dgettext'
/home/buildroot/build/instance-1/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libgdbm.a(gdbmfetch.o): In function `gdbm_fetch':

Static linking issue. Fran?ois, you are the maintainer of our Perl
package, can you have a look?

>          arm | pifmrds-0bf57f9ce0d954365a3... | NOK | http://autobuild.buildroot.net/results/f61ae46ba4d4fc3af3784d1f612a8c1cc7de3314/
>          arm | pifmrds-0bf57f9ce0d954365a3... | NOK | http://autobuild.buildroot.net/results/a124d4c8a2ef36165b29fbcc99c4c8ff89d296fb/

Static linking issue, forgets to link with libm.

Eric, you added pifmrds a while ago, can you have a look?

>         sh4a |                   prboom-2.5.0 | NOK | http://autobuild.buildroot.net/results/918d72bd9684a39dc688b143b682f8b5f49f1b26/

r_fps.c:296:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://support.codesourcery.com/GNUToolchain/> for instructions.

Gaah. A bit of investigation needed, maybe we should simply disable
prboom with this toolchain.

>         bfin |                    qhull-7.2.0 | NOK | http://autobuild.buildroot.net/results/884bd0fef2f88154da949fa3f4cc04368575183a/
>         bfin |                    qhull-7.2.0 | NOK | http://autobuild.buildroot.net/results/34f8754e2ddb243aaa73af196622449f655c5213/

Weird:

/home/peko/autobuild/instance-1/output/build/qhull-7.2.0/src/libqhullcpp/QhullSet.h:330: error: expected `;' before 'i'
/home/peko/autobuild/instance-1/output/build/qhull-7.2.0/src/libqhullcpp/QhullSet.h:331: error: expected `;' before 'e'
/home/peko/autobuild/instance-1/output/build/qhull-7.2.0/src/libqhullcpp/QhullSet.h:333: error: 'i' was not declared in this scope
/home/peko/autobuild/instance-1/output/build/qhull-7.2.0/src/libqhullcpp/QhullSet.h:333: error: 'e' was not declared in this scope

>        nios2 |                       qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/3f3d2938ba6a590ff2c4b20a7a15a46cbb079bc8/
>        nios2 |                       qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/f67b512b761cb53a9d66ecfda9894e1f8d86c26f/

Romain has submitted patches.

>        sparc |                       qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/872cb03d5869bd616fe8b22099a9ec4d556645ea/
>        sparc |                       qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/d462bf881ab01102ae26e20794b90c0ac3bbe27e/

obj/release/JSObjectRef.o: In function `JSClassRetain':
JSObjectRef.cpp:(.text+0xc0): undefined reference to `__sync_add_and_fetch_4'

Need to add some atomic operation dependency here. Waldemar?

>        nios2 |                       qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/90a74e1c6c759e7029802caed2b3117fd63b1f17/

Romain has submitted patches.

>       mipsel |                qt5webkit-5.5.1 | NOK | http://autobuild.buildroot.net/results/9379603f465a5ce3a579bf27338a5a4be0f11728/

{standard input}: Assembler messages:
{standard input}:708: Error: opcode not supported on this processor: mips32r6 (mips32r6) `movz $v0,$t8,$t7'
{standard input}:759: Error: opcode not supported on this processor: mips32r6 (mips32r6) `movz $v1,$t8,$t7'
{standard input}:765: Error: opcode not supported on this processor: mips32r6 (mips32r6) `movz $t2,$t8,$t7'

MIPS stuff. Vicente ?

>      powerpc |                     ruby-2.3.0 | NOK | http://autobuild.buildroot.net/results/87c882bc1a0dec9d76917c1e2db51fea61150294/

eval.c: In function 'rb_protect':
eval.c:881:1: internal compiler error: in move_insn, at haifa-sched.c:3439
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://support.codesourcery.com/GNUToolchain/> for instructions.

Compiler boom. Disable ruby with this toolchain? Gustavo?

>          arm | sconeserver-c4b8e14f6e9e06c... | NOK | http://autobuild.buildroot.net/results/d22c1da4439806ded7cf8abf54ef92d0bf97dc9f/

checking for no... no
configure: error: library 'libxml2' is required for the rss module
package/pkg-generic.mk:185: recipe for target '/home/autobuild/instance-0/output/build/sconeserver-

Smells like a static linking issue. Yann, you already fixed another
static linking issue with sconeserver, surely fixing another one will
make your evening more enjoyable ? :-)

>      sparc64 |                  setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/fde279194387e131a4027d5a1e2183da8e477bbb/

fpie/fPIE problem. I did had a patch for that, forgot to submit it.
Will try to submit it soonish.

>       mipsel |                     sox-14.4.2 | NOK | http://autobuild.buildroot.net/results/95721f7b88c46a20202fb02e408817097df965c3/

/home/test/autobuild/instance-2/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp_nonshared
/home/test/autobuild/instance-2/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp

Vicente, still no news from your toolchain guys?

>          arm |                 sqlite-3100200 | NOK | http://autobuild.buildroot.net/results/52202f98b9ebd273bdb3dd87f27cb1789f8362f9/
>          arm |                 sqlite-3100200 | NOK | http://autobuild.buildroot.net/results/d97674be3ebc90ab99e93b1b294cfae8c7c1dad8/

File truncated weird thing. Quick investigation reveals that:

 - It seems to appear only in static linking scenarios.

 - It appeared many times with sqlite-3100200, appeared only once with
   3100100, never appeared with neither 3100000 or 3090200.

Any ideas?

>     mips64el |                   stunnel-5.29 | NOK | http://autobuild.buildroot.net/results/64cd09dc957cbeaab9c5c6d331d38e6e22da29ae/

prototypes.h:625:5: error: conflicting types for 'getnameinfo'
 int getnameinfo(const struct sockaddr *, socklen_t,

Interestingly, this problem seems to occur only on MIPS. Vicente,
Gustavo, any idea?

>      aarch64 |                    tor-0.2.7.6 | NOK | http://autobuild.buildroot.net/results/fd0be644bf5c1c448eb1d2f94adbb433095f22f8/

src/common/libor-crypto-testing.a(src_common_libor_crypto_testing_a-crypto_format.o): In function `crypto_write_tagged_contents_to_file':
crypto_format.c:(.text+0x1c): relocation truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against symbol `smartlist_new' defined in .text section in src/common/libor.a(container.o)

Hmmmm, some ARM64 toolchain person in the room?

>          arm |                   trinity-v1.6 | NOK | http://autobuild.buildroot.net/results/6703eb14e69120f82878e4d3fb0dc5a4362cd8ef/

Musl build issue.

>          arc |                trousers-0.3.13 | NOK | http://autobuild.buildroot.net/results/28638752ebe923b6597ebc6838c1f97477dc23dc/

Will be fixed by http://patchwork.ozlabs.org/patch/569556/.

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
@ 2016-02-22 19:05 Olivier Schonken
  2016-02-22 21:55 ` Romain Naour
  2016-02-22 22:21 ` Thomas Petazzoni
  0 siblings, 2 replies; 23+ messages in thread
From: Olivier Schonken @ 2016-02-22 19:05 UTC (permalink / raw)
  To: buildroot

Hi Thomas, All


arm |                     cups-2.1.2 | NOK |
http://autobuild.buildroot.net/results/07ccca8f80c56ab0ff48bfee876885b1c8c3916e/
arc |                     cups-2.1.2 | NOK |
http://autobuild.buildroot.net/results/b169b939e38cb761319a92d2871f4f59ddb5c4ac/

Both error cases looks like it has to do with uclibc not behaving as
expected at link time for the ippserver build (Both builds link statically
with position independent execution also set).  For the arm platform it
can't find the Scrt1.o file, and for the ARC compiler, __init_array_end is
undefined.

I haven't considered all the options yet, but two that come to mind are
disabling cups support for uclibc type compilers, or else to disable the
cups test-framework.

The missing Scrt1.o has to do with the compiler.  In the Configure step,
autotools checks whether the compiler is capable of generating position
independent executables.

"checking whether compiler supports -fPIE... yes"

In the linking stage it then looks for Scrt1.o, which it can't find.  This
breaks the build.

From http://dev.gentoo.org/~vapier/crt.txt
crt1.o
  Newer style of the initial runtime code.  Contains the _start symbol which
  sets up the env with argc/argv/libc _init/libc _fini before jumping to the
  libc main.  glibc calls this file 'start.S'.
Scrt1.o
  Used in place of crt1.o when generating PIEs.

Regards

Olivier Schonken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160222/1f113fe6/attachment.html>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-22 19:05 [Buildroot] Analysis of build results for 2016-02-21 Olivier Schonken
@ 2016-02-22 21:55 ` Romain Naour
  2016-02-22 22:21 ` Thomas Petazzoni
  1 sibling, 0 replies; 23+ messages in thread
From: Romain Naour @ 2016-02-22 21:55 UTC (permalink / raw)
  To: buildroot

Hi Olivier, All,

Le 22/02/2016 20:05, Olivier Schonken a ?crit :
> Hi Thomas, All
> 
> 
> arm |                     cups-2.1.2 | NOK
> | http://autobuild.buildroot.net/results/07ccca8f80c56ab0ff48bfee876885b1c8c3916e/
> arc |                     cups-2.1.2 | NOK
> | http://autobuild.buildroot.net/results/b169b939e38cb761319a92d2871f4f59ddb5c4ac/
> 
> Both error cases looks like it has to do with uclibc not behaving as expected at
> link time for the ippserver build (Both builds link statically with position
> independent execution also set).  For the arm platform it can't find the Scrt1.o
> file, and for the ARC compiler, __init_array_end is undefined.

Thanks for the investigation!

I don't think it's related to uClibc library but static build only
(BR2_STATIC_LIBS=y).

> 
> I haven't considered all the options yet, but two that come to mind are
> disabling cups support for uclibc type compilers, or else to disable the cups
> test-framework.
> 
> The missing Scrt1.o has to do with the compiler.  In the Configure step,
> autotools checks whether the compiler is capable of generating position
> independent executables.
> 
> "checking whether compiler supports -fPIE... yes"

Can you try with LSB_BUILD=y in CUPS_CONF_OPTS ?
This allow to remove -fPIE -pie from CFLAGS.

Maybe something like:

# Remove -fPIE -pie from CFLAGS
ifeq ($(BR2_STATIC_LIBS),y)
CUPS_CONF_OPTS += LSB_BUILD=y
endif

Best regards,
Romain

> 
> In the linking stage it then looks for Scrt1.o, which it can't find.  This
> breaks the build.
> 
> From http://dev.gentoo.org/~vapier/crt.txt
> crt1.o
>   Newer style of the initial runtime code.  Contains the _start symbol which
>   sets up the env with argc/argv/libc _init/libc _fini before jumping to the
>   libc main.  glibc calls this file 'start.S'.
> Scrt1.o
>   Used in place of crt1.o when generating PIEs.
> 
> Regards
> 
> Olivier Schonken
> 
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-22 19:05 [Buildroot] Analysis of build results for 2016-02-21 Olivier Schonken
  2016-02-22 21:55 ` Romain Naour
@ 2016-02-22 22:21 ` Thomas Petazzoni
  2016-02-23  7:34   ` Olivier Schonken
  1 sibling, 1 reply; 23+ messages in thread
From: Thomas Petazzoni @ 2016-02-22 22:21 UTC (permalink / raw)
  To: buildroot

Hello Olivier,

On Mon, 22 Feb 2016 21:05:00 +0200, Olivier Schonken wrote:

> arm |                     cups-2.1.2 | NOK |
> http://autobuild.buildroot.net/results/07ccca8f80c56ab0ff48bfee876885b1c8c3916e/
> arc |                     cups-2.1.2 | NOK |
> http://autobuild.buildroot.net/results/b169b939e38cb761319a92d2871f4f59ddb5c4ac/
> 
> Both error cases looks like it has to do with uclibc not behaving as
> expected at link time for the ippserver build (Both builds link statically
> with position independent execution also set).  For the arm platform it
> can't find the Scrt1.o file, and for the ARC compiler, __init_array_end is
> undefined.
> 
> I haven't considered all the options yet, but two that come to mind are
> disabling cups support for uclibc type compilers, or else to disable the
> cups test-framework.

Disabling for uClibc is completely overkill: this problem only occurs
on ARM with static linking and on ARC. CUPS builds perfectly fine on
ARM/uClibc when dynamic linking is used.

The problem is that CUPS forcefully uses PIE support, and:

 1/ Our static-only toolchain for ARM that uses uClibc-ng does not
    contain Scrt1.o, while a dynamic-linking enabled uClibc-ng ARM
    toolchain does have it. Due to this, trying to link a minimal C
    program with -fPIE -pie fails. I'm Cc'ing Waldemar, the uClibc-ng
    maintainer, to get his input on this.

 2/ PIE is not supported by the ARC architecture, and should not be
    used. Unfortunately, the configure script of CUPS only does an
    AC_TRY_COMPILE() test to verify the support of PIE in the compiler,
    but on ARC, it only fails at link time, so the test should be an
    AC_TRY_LINK(). Olivier, could you try to fix the cups stuff so that
    we can autoreconf it properly, and therefore fix such issues in the
    cups configure.ac ? I'm also Cc'ing Alexey from Synopsys, who can
    give more details about the PIE issue on ARC.

Thanks for your investigation!

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-22 22:21 ` Thomas Petazzoni
@ 2016-02-23  7:34   ` Olivier Schonken
  2016-02-23  8:11     ` Thomas Petazzoni
  0 siblings, 1 reply; 23+ messages in thread
From: Olivier Schonken @ 2016-02-23  7:34 UTC (permalink / raw)
  To: buildroot

Hi Thomas, All

The suggestion from Romain to disable -fPIE as below works for both
architectures.  Can I submit a patch for this? Or do you want to wait for a
response from Alexey and Waldemar?

# Remove -fPIE -pie from CFLAGS
ifeq ($(BR2_STATIC_LIBS),y)
CUPS_CONF_OPTS += LSB_BUILD=y
endif

Regards

Olivier Schonken



On 23 February 2016 at 00:21, Thomas Petazzoni <
thomas.petazzoni@free-electrons.com> wrote:

> Hello Olivier,
>
> On Mon, 22 Feb 2016 21:05:00 +0200, Olivier Schonken wrote:
>
> > arm |                     cups-2.1.2 | NOK |
> >
> http://autobuild.buildroot.net/results/07ccca8f80c56ab0ff48bfee876885b1c8c3916e/
> > arc |                     cups-2.1.2 | NOK |
> >
> http://autobuild.buildroot.net/results/b169b939e38cb761319a92d2871f4f59ddb5c4ac/
> >
> > Both error cases looks like it has to do with uclibc not behaving as
> > expected at link time for the ippserver build (Both builds link
> statically
> > with position independent execution also set).  For the arm platform it
> > can't find the Scrt1.o file, and for the ARC compiler, __init_array_end
> is
> > undefined.
> >
> > I haven't considered all the options yet, but two that come to mind are
> > disabling cups support for uclibc type compilers, or else to disable the
> > cups test-framework.
>
> Disabling for uClibc is completely overkill: this problem only occurs
> on ARM with static linking and on ARC. CUPS builds perfectly fine on
> ARM/uClibc when dynamic linking is used.
>
> The problem is that CUPS forcefully uses PIE support, and:
>
>  1/ Our static-only toolchain for ARM that uses uClibc-ng does not
>     contain Scrt1.o, while a dynamic-linking enabled uClibc-ng ARM
>     toolchain does have it. Due to this, trying to link a minimal C
>     program with -fPIE -pie fails. I'm Cc'ing Waldemar, the uClibc-ng
>     maintainer, to get his input on this.
>
>  2/ PIE is not supported by the ARC architecture, and should not be
>     used. Unfortunately, the configure script of CUPS only does an
>     AC_TRY_COMPILE() test to verify the support of PIE in the compiler,
>     but on ARC, it only fails at link time, so the test should be an
>     AC_TRY_LINK(). Olivier, could you try to fix the cups stuff so that
>     we can autoreconf it properly, and therefore fix such issues in the
>     cups configure.ac ? I'm also Cc'ing Alexey from Synopsys, who can
>     give more details about the PIE issue on ARC.
>
> Thanks for your investigation!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160223/7ef394a3/attachment.html>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-23  7:34   ` Olivier Schonken
@ 2016-02-23  8:11     ` Thomas Petazzoni
  2016-02-23 11:13       ` Olivier Schonken
  2016-02-24 21:30       ` Waldemar Brodkorb
  0 siblings, 2 replies; 23+ messages in thread
From: Thomas Petazzoni @ 2016-02-23  8:11 UTC (permalink / raw)
  To: buildroot

Hello,

On Tue, 23 Feb 2016 09:34:31 +0200, Olivier Schonken wrote:

> The suggestion from Romain to disable -fPIE as below works for both
> architectures.  Can I submit a patch for this? Or do you want to wait for a
> response from Alexey and Waldemar?
> 
> # Remove -fPIE -pie from CFLAGS
> ifeq ($(BR2_STATIC_LIBS),y)
> CUPS_CONF_OPTS += LSB_BUILD=y
> endif

Unfortunately, I don't like this, for several reasons:

 1/ LSB_BUILD=y will also disable stack protection support.

 2/ Only uClibc in static library build is affected by the problem, not
    musl for example.

 3/ It is not fixing the real problem.

The real fixes are:

 1/ Use AC_CACHE_VAL() in the configure.ac script to be able to force
    disable PIE, and then use that to disable it on ARC. Or
    alternatively, change the configure.ac to use:

++AX_CHECK_COMPILE_FLAG([-fPIE -DPIE], [PIE_CFLAGS="-fPIE -DPIE"])
++AX_CHECK_LINK_FLAG([-pie], [PIE_LDFLAGS="$PIE_LDFLAGS -pie"])

    Which also provide cache variables to override their results. See
    http://patchwork.ozlabs.org/patch/569556/.

 2/ Fix the uClibc static case by fixing the toolchain build process or
    uClibc itself (depending on which one is broken).

Of course, this requires effort than the quick hack of LSB_BUILD=y, but
those are IMO the real fixes, while LSB_BUILD=y is papering over the
real problem.

Note that there are other classes of cups-2.1.2 build failures visible
at http://autobuild.buildroot.org/?reason=cups-2.1.2.

Best regards,

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-22 14:05 ` [Buildroot] Analysis of build " Thomas Petazzoni
@ 2016-02-23 10:12   ` John Keeping
  2016-02-23 10:40     ` Jeroen Roovers
  2016-02-24 11:08   ` Eric Limpens
                     ` (5 subsequent siblings)
  6 siblings, 1 reply; 23+ messages in thread
From: John Keeping @ 2016-02-23 10:12 UTC (permalink / raw)
  To: buildroot

On Mon, Feb 22, 2016 at 03:05:39PM +0100, Thomas Petazzoni wrote:
> On Mon, 22 Feb 2016 08:30:22 +0100 (CET), Thomas Petazzoni wrote:
> 
> >         mips |              bluez5_utils-5.37 | NOK | http://autobuild.buildroot.net/results/2bf4e5ea9b67b80ba38bfeaf71b747a92be09011/
> 
> tools/avinfo.c:193:24: error: unknown type name 'a2dp_ldac_t'
>  static void print_ldac(a2dp_ldac_t *ldac)
> 
> It's not MIPS specific, since the same build issue occurred on other
> architectures.
> 
> Could someone have a look ?

I think the problem affects all big endian systems and the necessary
patch to bluez5 is below, but I don't have a suitable toolchain or
system to test it.

If someone is able to test the patch I will submit it upstream and roll
a proper patch for Buildroot.

-- >8 --
diff --git a/profiles/audio/a2dp-codecs.h b/profiles/audio/a2dp-codecs.h
index e9da0bf..4fb5c0c 100644
--- a/profiles/audio/a2dp-codecs.h
+++ b/profiles/audio/a2dp-codecs.h
@@ -234,6 +234,11 @@ typedef struct {
 	uint8_t channel_mode:4;
 } __attribute__ ((packed)) a2dp_aptx_t;
 
+typedef struct {
+	a2dp_vendor_codec_t info;
+	uint8_t unknown[2];
+} __attribute__ ((packed)) a2dp_ldac_t;
+
 #else
 #error "Unknown byte order"
 #endif

^ permalink raw reply related	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-23 10:12   ` John Keeping
@ 2016-02-23 10:40     ` Jeroen Roovers
  2016-02-23 11:03       ` John Keeping
  2016-02-23 12:30       ` Thomas Petazzoni
  0 siblings, 2 replies; 23+ messages in thread
From: Jeroen Roovers @ 2016-02-23 10:40 UTC (permalink / raw)
  To: buildroot

https://gitweb.gentoo.org/repo/gentoo.git/tree/net-wireless/bluez/files/bluez-5.37-endian.patch

On 23 February 2016 at 11:12, John Keeping <john@keeping.me.uk> wrote:
> On Mon, Feb 22, 2016 at 03:05:39PM +0100, Thomas Petazzoni wrote:
>> On Mon, 22 Feb 2016 08:30:22 +0100 (CET), Thomas Petazzoni wrote:
>>
>> >         mips |              bluez5_utils-5.37 | NOK | http://autobuild.buildroot.net/results/2bf4e5ea9b67b80ba38bfeaf71b747a92be09011/
>>
>> tools/avinfo.c:193:24: error: unknown type name 'a2dp_ldac_t'
>>  static void print_ldac(a2dp_ldac_t *ldac)
>>
>> It's not MIPS specific, since the same build issue occurred on other
>> architectures.
>>
>> Could someone have a look ?
>
> I think the problem affects all big endian systems and the necessary
> patch to bluez5 is below, but I don't have a suitable toolchain or
> system to test it.
>
> If someone is able to test the patch I will submit it upstream and roll
> a proper patch for Buildroot.
>
> -- >8 --
> diff --git a/profiles/audio/a2dp-codecs.h b/profiles/audio/a2dp-codecs.h
> index e9da0bf..4fb5c0c 100644
> --- a/profiles/audio/a2dp-codecs.h
> +++ b/profiles/audio/a2dp-codecs.h
> @@ -234,6 +234,11 @@ typedef struct {
>         uint8_t channel_mode:4;
>  } __attribute__ ((packed)) a2dp_aptx_t;
>
> +typedef struct {
> +       a2dp_vendor_codec_t info;
> +       uint8_t unknown[2];
> +} __attribute__ ((packed)) a2dp_ldac_t;
> +
>  #else
>  #error "Unknown byte order"
>  #endif
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-23 10:40     ` Jeroen Roovers
@ 2016-02-23 11:03       ` John Keeping
  2016-02-23 12:30       ` Thomas Petazzoni
  1 sibling, 0 replies; 23+ messages in thread
From: John Keeping @ 2016-02-23 11:03 UTC (permalink / raw)
  To: buildroot

On Tue, Feb 23, 2016 at 11:40:52AM +0100, Jeroen Roovers wrote:
> https://gitweb.gentoo.org/repo/gentoo.git/tree/net-wireless/bluez/files/bluez-5.37-endian.patch

That patch looks wrong: you can't just pull a2dp_aptx_t out of the
little/big endian ifdefs since the order of the bit fields matters
(a2dp_ldac_t could be pulled out but I think it's more consistent to
duplicate the definition as the unknown fields may need to be different
on big/little endian systems).

> On 23 February 2016 at 11:12, John Keeping <john@keeping.me.uk> wrote:
> > On Mon, Feb 22, 2016 at 03:05:39PM +0100, Thomas Petazzoni wrote:
> >> On Mon, 22 Feb 2016 08:30:22 +0100 (CET), Thomas Petazzoni wrote:
> >>
> >> >         mips |              bluez5_utils-5.37 | NOK | http://autobuild.buildroot.net/results/2bf4e5ea9b67b80ba38bfeaf71b747a92be09011/
> >>
> >> tools/avinfo.c:193:24: error: unknown type name 'a2dp_ldac_t'
> >>  static void print_ldac(a2dp_ldac_t *ldac)
> >>
> >> It's not MIPS specific, since the same build issue occurred on other
> >> architectures.
> >>
> >> Could someone have a look ?
> >
> > I think the problem affects all big endian systems and the necessary
> > patch to bluez5 is below, but I don't have a suitable toolchain or
> > system to test it.
> >
> > If someone is able to test the patch I will submit it upstream and roll
> > a proper patch for Buildroot.
> >
> > -- >8 --
> > diff --git a/profiles/audio/a2dp-codecs.h b/profiles/audio/a2dp-codecs.h
> > index e9da0bf..4fb5c0c 100644
> > --- a/profiles/audio/a2dp-codecs.h
> > +++ b/profiles/audio/a2dp-codecs.h
> > @@ -234,6 +234,11 @@ typedef struct {
> >         uint8_t channel_mode:4;
> >  } __attribute__ ((packed)) a2dp_aptx_t;
> >
> > +typedef struct {
> > +       a2dp_vendor_codec_t info;
> > +       uint8_t unknown[2];
> > +} __attribute__ ((packed)) a2dp_ldac_t;
> > +
> >  #else
> >  #error "Unknown byte order"
> >  #endif
> > _______________________________________________
> > buildroot mailing list
> > buildroot at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-23  8:11     ` Thomas Petazzoni
@ 2016-02-23 11:13       ` Olivier Schonken
  2016-02-24 21:30       ` Waldemar Brodkorb
  1 sibling, 0 replies; 23+ messages in thread
From: Olivier Schonken @ 2016-02-23 11:13 UTC (permalink / raw)
  To: buildroot

Hi Thomas, all

I looked through the other classes of cups-2.1.2 build failures visible
at http://autobuild.buildroot.org/?reason=cups-2.1.2.

Basically 3 errors.  The 2 errors we have already discussed, and a 3rd
caused by linking with gnutls when building static libraries.
Fails at link stage with undefined references.

Regards

Olivier

On 23 February 2016 at 10:11, Thomas Petazzoni <
thomas.petazzoni@free-electrons.com> wrote:

> Hello,
>
> On Tue, 23 Feb 2016 09:34:31 +0200, Olivier Schonken wrote:
>
> > The suggestion from Romain to disable -fPIE as below works for both
> > architectures.  Can I submit a patch for this? Or do you want to wait
> for a
> > response from Alexey and Waldemar?
> >
> > # Remove -fPIE -pie from CFLAGS
> > ifeq ($(BR2_STATIC_LIBS),y)
> > CUPS_CONF_OPTS += LSB_BUILD=y
> > endif
>
> Unfortunately, I don't like this, for several reasons:
>
>  1/ LSB_BUILD=y will also disable stack protection support.
>
>  2/ Only uClibc in static library build is affected by the problem, not
>     musl for example.
>
>  3/ It is not fixing the real problem.
>
> The real fixes are:
>
>  1/ Use AC_CACHE_VAL() in the configure.ac script to be able to force
>     disable PIE, and then use that to disable it on ARC. Or
>     alternatively, change the configure.ac to use:
>
> ++AX_CHECK_COMPILE_FLAG([-fPIE -DPIE], [PIE_CFLAGS="-fPIE -DPIE"])
> ++AX_CHECK_LINK_FLAG([-pie], [PIE_LDFLAGS="$PIE_LDFLAGS -pie"])
>
>     Which also provide cache variables to override their results. See
>     http://patchwork.ozlabs.org/patch/569556/.
>
>  2/ Fix the uClibc static case by fixing the toolchain build process or
>     uClibc itself (depending on which one is broken).
>
> Of course, this requires effort than the quick hack of LSB_BUILD=y, but
> those are IMO the real fixes, while LSB_BUILD=y is papering over the
> real problem.
>
> Note that there are other classes of cups-2.1.2 build failures visible
> at http://autobuild.buildroot.org/?reason=cups-2.1.2.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160223/5dcf35cb/attachment.html>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-23 10:40     ` Jeroen Roovers
  2016-02-23 11:03       ` John Keeping
@ 2016-02-23 12:30       ` Thomas Petazzoni
  1 sibling, 0 replies; 23+ messages in thread
From: Thomas Petazzoni @ 2016-02-23 12:30 UTC (permalink / raw)
  To: buildroot

Jeroen, John,

On Tue, 23 Feb 2016 11:40:52 +0100, Jeroen Roovers wrote:
> https://gitweb.gentoo.org/repo/gentoo.git/tree/net-wireless/bluez/files/bluez-5.37-endian.patch

Sounds good! Care to submit a patch for Buildroot that adds this patch,
with a proper description and SoB ?

Could you also look if the patch has been merged upstream? If it has
been merged, using the upstream patch is better. If it hasn't been
merged upstream, then submitting it would be good.

Thanks a lot!

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-22 14:05 ` [Buildroot] Analysis of build " Thomas Petazzoni
  2016-02-23 10:12   ` John Keeping
@ 2016-02-24 11:08   ` Eric Limpens
  2016-02-24 20:45     ` Arnout Vandecappelle
  2016-02-24 21:42   ` Waldemar Brodkorb
                     ` (4 subsequent siblings)
  6 siblings, 1 reply; 23+ messages in thread
From: Eric Limpens @ 2016-02-24 11:08 UTC (permalink / raw)
  To: buildroot

I've just submitted a patch to fix the issue for pifmrds. I don't fully
understand why, but changing the order of 2 libraries fixed the problem.

Tested the patch with a non-static build and no issues occurred during
building.

Eric

On Mon, Feb 22, 2016 at 3:05 PM, Thomas Petazzoni <
thomas.petazzoni@free-electrons.com> wrote:

> Hello,
>
> The usual analysis of build failures. Karoly, Eric, Yann, Olivier,
> Alexey, Lada, Bernd, Vicente, Alan, Waldemar, Samuel, Gustavo, could
> you have a look below, there are some questions/issues for all of
> you :-)
>
> Thanks a lot!
>
> On Mon, 22 Feb 2016 08:30:22 +0100 (CET), Thomas Petazzoni wrote:
>
> >         mips |              bluez5_utils-5.37 | NOK |
> http://autobuild.buildroot.net/results/2bf4e5ea9b67b80ba38bfeaf71b747a92be09011/
>
> tools/avinfo.c:193:24: error: unknown type name 'a2dp_ldac_t'
>  static void print_ldac(a2dp_ldac_t *ldac)
>
> It's not MIPS specific, since the same build issue occurred on other
> architectures.
>
> Could someone have a look ?
>
> >          arm | canfestival-7740ac6fdedc23e... | NOK |
> http://autobuild.buildroot.net/results/92802995144a76202040421255b003aded527958/
> >          arm | canfestival-7740ac6fdedc23e... | NOK |
> http://autobuild.buildroot.net/results/db5733d2a62f84f90056d5e48e3f08fe94b87a6d/
>
> Musl build issue. A patch was submitted a long time ago, but got
> rejected: https://patchwork.ozlabs.org/patch/509731/. Since nobody
> really cared, I propose to mark canfestival as not available on musl.
>
> >          arm |           chocolate-doom-2.2.1 | NOK |
> http://autobuild.buildroot.net/results/e09ea3a64d396bbc855acf7c07fcbea28fb2395d/
>
> Static linking issue. Rodrigo is on it.
>
> >          arm |                     cups-2.1.2 | NOK |
> http://autobuild.buildroot.net/results/07ccca8f80c56ab0ff48bfee876885b1c8c3916e/
>
>
> /home/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.9.3/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld:
> cannot find Scrt1.o: No such file or directory collect2: error: ld
> returned 1 exit status Makefile:232: recipe for target 'ippserver'
> failed
>
> Olivier, you re-enabled and updated the CUPS package, can you have a
> look ?
>
>
> >          arc |                     cups-2.1.2 | NOK |
> http://autobuild.buildroot.net/results/b169b939e38cb761319a92d2871f4f59ddb5c4ac/
>
>
> /home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/4.8.4/../../../../arc-buildroot-linux-uclibc/bin/ld:
> BFD (GNU Binutils) 2.23.2 assertion fail
> elf32-arc.c:3062
> /home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/4.8.4/../../../../arc-buildroot-linux-uclibc/bin/ld:
> BFD (GNU Binutils) 2.23.2 assertion fail elf32-arc.c:3062
>
> Alexey, Lada, this is an ARC toolchain issue. Any hints?
>
> >      aarch64 |                    erlang-17.5 | NOK |
> http://autobuild.buildroot.net/results/8b47dea53fc8608ab62cadfaeecdf828fd3d940f/
>
> Atomic operations problem, this is being discussed around a patch that
> was submitted by Frank.
>
> >         sh4a |                    fio-fio-2.6 | NOK |
> http://autobuild.buildroot.net/results/68f98acca8b02aeaa98c78d2e95a6a29df629fef/
>
> mutex.o: In function `fio_mutex_up':
> /home/test/autobuild/instance-1/output/build/fio-fio-2.6/mutex.c:182:
> undefined reference to `arch_flags'
>
> Not sure what's going on. Someone to investigate?
>
> >          arm |                      gdb-7.9.1 | NOK |
> http://autobuild.buildroot.net/results/edfb6854306ccaed9592139ad803850c2e0011d2/
>
> linux-nat.c: In function 'lin_thread_get_thread_signals':
> linux-nat.c:4878:15: error: '__SIGRTMIN' undeclared (first use in this
> function)
>      restart = __SIGRTMIN;
>
> Smells like a musl build issue. Bernd had a patch "[PATCH 1/1]
> package/gdb: Fix musl build", which I marked as "Changes Requested"
> yesterday. It looks like this particular patch was pretty good, though
> submitting the patch upstream would be good (the patch says it was
> submitted and points to an almost 5 years old bug report).
>
> >     mips64el |               gst1-libav-1.6.3 | NOK |
> http://autobuild.buildroot.net/results/b848969d518008dadb40fbebc40bab4124231c2b/
> >     mips64el |               gst1-libav-1.6.3 | NOK |
> http://autobuild.buildroot.net/results/ace98b9c51379e19f70bbe0bda94ff80ab9dd7fc/
>
> Vicente, this one is for you:
>
> libavformat/aadec.c:1:0: error: '-mips64r2' conflicts with the other
> architecture options, which specify a mips64r6 processor
>
> >         i686 | hidapi-d17db57b9d4354752e0a... | NOK |
> http://autobuild.buildroot.net/results/6f0c9a682bc98f962874a38c9e2a334fea21b0cb/
> >       xtensa | hidapi-d17db57b9d4354752e0a... | NOK |
> http://autobuild.buildroot.net/results/a9216cd5f9568ef134b64341b629efea40d54fe1/
>
> make[3]: Entering directory
> `/home/peko/autobuild/instance-2/output/build/hidapi-d17db57b9d4354752e0af42f5f33007a42ef2906/hidtest'
> make[3]: *** No rule to make target `hidtest.o', needed by
> `hidtest-libusb'.  Stop.
>
> Might be a parallel build issue. Alan, hidapi is your thing, can you
> have a look?
>
> >       x86_64 |                host-efl-1.15.3 | NOK |
> http://autobuild.buildroot.net/results/c427d13cf1c50305047a3f0b0051520e672f91d8/
>
> Fixed by
> https://git.busybox.net/buildroot/commit/?id=fd7a2eacb37274e9bfc7d59eb4b3c4840a4c8a2d
> .
>
> >          arm |        host-erlang-rebar-2.5.1 | TIM |
> http://autobuild.buildroot.net/results/685e2ec91d889c6a789025864e6b4890ef6b532d/
>
> Ignore.
>
> >          arm |                    hostapd-2.5 | NOK |
> http://autobuild.buildroot.net/results/39ff650ca14bdfa35b35bbf13e01cfceeb43035e/
>
> Musl build problem.
>
> >          arm |                  igmpproxy-0.1 | NOK |
> http://autobuild.buildroot.net/results/f44629feae5eb8b8b61e88eac5b24cbfce8a1c4d/
>
> Musl build problem.
>
> >          arm |                ipmitool-1.8.15 | NOK |
> http://autobuild.buildroot.net/results/ad8fbadedc152ec93c175aeb24f062e8290a352e/
>
> Musl build problem.
>
> >       x86_64 |              ipsec-tools-0.8.2 | NOK |
> http://autobuild.buildroot.net/results/d618837a536dfd3d076ae1cecd1f598b4bf7efcd/
> >       x86_64 |              ipsec-tools-0.8.2 | NOK |
> http://autobuild.buildroot.net/results/fa6b8a8175420e9d76f23eb7b61075ac5ce315de/
>
> Musl build problem.
>
> >          arm |             kodi-15.2-Isengard | NOK |
> http://autobuild.buildroot.net/results/43939f65e4516adddc4385c6e0a2193abcab0446/
>
> Usage of 64-bits on ARM with uClibc, doesn't work because gcc uses the
> __write() internal glibc symbol. We need to isolate the Kodi features
> that uses this 64 bits atomic operation (if possible) and make it
> depend on BR2_TOOLCHAIN_ARM_HAS_SYNC_8. See also
> https://git.busybox.net/buildroot/tree/toolchain/toolchain-common.in#n339
> for a discussion of this problem.
>
> Bernd ?
>
> >          arm | kodi-pvr-argustv-32f03271cc... | NOK |
> http://autobuild.buildroot.net/results/dacc3bd00ab2346d7655c0a1fb99f6c50b9da08b/
>
> Bernd ?
>
> >        nios2 |                libcap-ng-0.7.4 | NOK |
> http://autobuild.buildroot.net/results/67f19f1fdf642c3c72deb931cb674b114bacc4da/
> >        nios2 |                libcap-ng-0.7.4 | NOK |
> http://autobuild.buildroot.net/results/ed2503778126253fad08d9828f442a0b9d042fc2/
>
> nios2 toolchain bug, will be fixed by
> http://patchwork.ozlabs.org/patch/582313/.
>
> >        sparc |                  libdrm-2.4.66 | NOK |
> http://autobuild.buildroot.net/results/a17047ada385e5be5f60c07254597fcb7c4183d0/
> >        sparc |                  libdrm-2.4.66 | NOK |
> http://autobuild.buildroot.net/results/6d79591bce2d3fa5b93e268fe50d5b89ecd24521/
>
> Could be fixed by http://patchwork.ozlabs.org/patch/569818/, but this
> patch is wrong I believe now that we have proper Config.in options to
> describe atomic operation dependencies.
>
> Waldemar, could you have a look?
>
> >       x86_64 |                  libdrm-2.4.66 | NOK |
> http://autobuild.buildroot.net/results/52cdd46091740aab423987bdd6e2423b157a8799/
>
> Musl build issue.
>
> >          arc |                  libraw-0.17.1 | NOK |
> http://autobuild.buildroot.net/results/b1d80c4b62bd71e722f53b0e2caadd7951f23dd7/
>
> /tmp/ccmCzrHn.s: Assembler messages:
> /tmp/ccmCzrHn.s:765: Error: invalid register number `63'
> /tmp/ccmCzrHn.s:3686: Error: invalid register number `63'
> /tmp/ccmCzrHn.s:3688: Error: invalid register number `63'
>
> Alexey, Lada, toolchain issue.
>
> >        sparc |                libsodium-1.0.6 | TIM |
> http://autobuild.buildroot.net/results/80988d3cc1cebd32b5c9718b936f9dfe9c10e34a/
>
> Ignore.
>
> >      sparc64 |         ltp-testsuite-20150903 | NOK |
> http://autobuild.buildroot.net/results/ce2c1fb10dfef1039545443ff9ef969889d2bf40/
>
> Waldemar, this is a sparc64 issue, can you have a look?
>
> > microblazeel | make[3]: *** [code/CMakeFil... | TIM |
> http://autobuild.buildroot.net/results/a692bc6df992cd05470fcc5b6e59ffb449da2069/
>
> Ignore.
>
> >          arc |                  mesa3d-11.1.1 | NOK |
> http://autobuild.buildroot.net/results/0eb25c0756eeb6b7ad4d3b1a86a47dfff3d766ef/
>
> collect2: error: ld terminated with signal 11 [Segmentation fault]
> Makefile:918: recipe for target 'gallium_dri.la' failed
>
> Alexey, Lada, toolchain issue.
>
> > microblazeel |                  mesa3d-11.1.1 | NOK |
> http://autobuild.buildroot.net/results/521aad4fd2e24fd78fa26a1d0c6284d56100a467/
>
> ./.libs/libglsl.a(glsl_parser_extras.o): In function
> `_mesa_glsl_compile_shader':
> (.text+0x3850): undefined reference to `__sync_val_compare_and_swap_1'
>
> Need to add some atomic operation dependency here.
>
> >      aarch64 |                    mplayer-1.2 | NOK |
> http://autobuild.buildroot.net/results/e82b37607e3ef9efb0933e9300c48074d249a414/
>
> mplayer on aarch64 has been failing to build for a while. I asked Joao
> to fix the issue (since he enabled Mplayer on aarch64), but never
> submitted a fix. I had a quick look, it didn't seem to be trivial, so I
> propose to disable mplayer on aarch64.
>
> >      powerpc |                nfs-utils-1.3.3 | NOK |
> http://autobuild.buildroot.net/results/630771e41d71443e7c6a1ab3367199ebcc451153/
> >      powerpc |                nfs-utils-1.3.3 | NOK |
> http://autobuild.buildroot.net/results/ddb1f5ccb1fb41fdfb7c035c0a8282a4afaa9c61/
>
> Patch pending from Maxime, http://patchwork.ozlabs.org/patch/577178/.
>
> >      powerpc |                 numactl-2.0.11 | NOK |
> http://autobuild.buildroot.net/results/11e90fc79cb96631fd3e44af7e15650047858b7d/
> >      powerpc |                 numactl-2.0.11 | NOK |
> http://autobuild.buildroot.net/results/1997e8c52e093395bc0b15d6de1ccf328e077fce/
> >      powerpc |                 numactl-2.0.11 | NOK |
> http://autobuild.buildroot.net/results/39892be2a1857b727f4213079faaade52d4da0d2/
> >     mips64el |                 numactl-2.0.11 | NOK |
> http://autobuild.buildroot.net/results/131b044097725c00c58c05bf0d4e2afa05cf145a/
> >      powerpc |                 numactl-2.0.11 | NOK |
> http://autobuild.buildroot.net/results/4db511e9d09b67ea333814d3698866c82c7afb54/
> >      powerpc |                 numactl-2.0.11 | NOK |
> http://autobuild.buildroot.net/results/6a1470c60b08c95765f3549177dfa6059b76493b/
>
> Discussion on-going at http://patchwork.ozlabs.org/patch/582442/.
>
> >      sparc64 |                  opencv-2.4.10 | NOK |
> http://autobuild.buildroot.net/results/63086c31c57fd68aa2759c51d7dfd49ae9e7239b/
> >      sparc64 |                  opencv-2.4.10 | NOK |
> http://autobuild.buildroot.net/results/d05d7a24283cb0b5f305a7cd4cf8a60a4be7959d/
> >      sparc64 |                  opencv-2.4.10 | NOK |
> http://autobuild.buildroot.net/results/92ebbd138dea50183880db49f920439b60e6f89b/
>
> Not sure. Waldemar (sparc64 person) and Samuel (OpenCV person), any
> idea ? Seems atomic related.
>
> >          arm |        openpgm-release-5-2-122 | NOK |
> http://autobuild.buildroot.net/results/bc6209c2531c791a095935ffc6ff461de04f5b04/
>
> Musl build issue.
>
> >         i686 |      openvmtools-stable-9.10.2 | NOK |
> http://autobuild.buildroot.net/results/a6b5ef77df470c99c83ccc02a731f944e9747c65/
>
> checking for getstat in -lproc-3.2.8... no
> checking for getstat in -lproc-3.2.7... no
> configure: error: libproc not found. Please configure without procps
> (using --without-procps) or install procps - http://procps.sourceforge.net
>
> Karoly, can you have a look, since you originally added openvmtools?
>
> >      powerpc |                pax-utils-1.1.4 | NOK |
> http://autobuild.buildroot.net/results/8a3156e287282fb63c009e04248faf09f9b29476/
> >      powerpc |                pax-utils-1.1.4 | NOK |
> http://autobuild.buildroot.net/results/d2686e71dcc1cf017503f7c68efdfe5c521abbc3/
>
> security.c:245:8: error: 'PR_SET_NO_NEW_PRIVS' undeclared (first use in
> this function)
> security.c:245:8: note: each undeclared identifier is reported only once
> for each function it appears in
>
> Too old kernel headers?
>
> >         bfin |                pax-utils-1.1.4 | NOK |
> http://autobuild.buildroot.net/results/ee3701c11ba8094e74c7356105ee2a18c2c73100/
>
> pspax.o: In function `_main':
> pspax.c:(.text+0x4c8): undefined reference to `_cap_init'
> pspax.c:(.text+0x964): undefined reference to `_capgetp'
> pspax.c:(.text+0x970): undefined reference to `_cap_to_text'
> pspax.c:(.text+0xe42): undefined reference to `_cap_free'
>
> Static linking broken ?
>
> >         i686 |                pax-utils-1.1.4 | NOK |
> http://autobuild.buildroot.net/results/a854da559be1d617d31acbb08c39e6ac5464cee7/
>
> security.c: In function 'security_init':
> security.c:245:8: error: 'PR_SET_NO_NEW_PRIVS' undeclared (first use in
> this function)
>   prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
>
> Same as the PowerPC issue.
>
> Gustavo, since you added pax-utils, can you have a look?
>
> >          arm |                    perl-5.22.1 | NOK |
> http://autobuild.buildroot.net/results/985dc18ec04901bea7d4fdd6e0145f7625e80869/
>
> /home/buildroot/build/instance-1/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libgdbm.a(gdbmerrno.o):
> In function `gdbm_strerror':
> gdbmerrno.c:(.text+0x18): undefined reference to `libintl_dgettext'
> /home/buildroot/build/instance-1/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libgdbm.a(gdbmfetch.o):
> In function `gdbm_fetch':
>
> Static linking issue. Fran?ois, you are the maintainer of our Perl
> package, can you have a look?
>
> >          arm | pifmrds-0bf57f9ce0d954365a3... | NOK |
> http://autobuild.buildroot.net/results/f61ae46ba4d4fc3af3784d1f612a8c1cc7de3314/
> >          arm | pifmrds-0bf57f9ce0d954365a3... | NOK |
> http://autobuild.buildroot.net/results/a124d4c8a2ef36165b29fbcc99c4c8ff89d296fb/
>
> Static linking issue, forgets to link with libm.
>
> Eric, you added pifmrds a while ago, can you have a look?
>
> >         sh4a |                   prboom-2.5.0 | NOK |
> http://autobuild.buildroot.net/results/918d72bd9684a39dc688b143b682f8b5f49f1b26/
>
> r_fps.c:296:1: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <https://support.codesourcery.com/GNUToolchain/> for instructions.
>
> Gaah. A bit of investigation needed, maybe we should simply disable
> prboom with this toolchain.
>
> >         bfin |                    qhull-7.2.0 | NOK |
> http://autobuild.buildroot.net/results/884bd0fef2f88154da949fa3f4cc04368575183a/
> >         bfin |                    qhull-7.2.0 | NOK |
> http://autobuild.buildroot.net/results/34f8754e2ddb243aaa73af196622449f655c5213/
>
> Weird:
>
> /home/peko/autobuild/instance-1/output/build/qhull-7.2.0/src/libqhullcpp/QhullSet.h:330:
> error: expected `;' before 'i'
> /home/peko/autobuild/instance-1/output/build/qhull-7.2.0/src/libqhullcpp/QhullSet.h:331:
> error: expected `;' before 'e'
> /home/peko/autobuild/instance-1/output/build/qhull-7.2.0/src/libqhullcpp/QhullSet.h:333:
> error: 'i' was not declared in this scope
> /home/peko/autobuild/instance-1/output/build/qhull-7.2.0/src/libqhullcpp/QhullSet.h:333:
> error: 'e' was not declared in this scope
>
> >        nios2 |                       qt-4.8.7 | NOK |
> http://autobuild.buildroot.net/results/3f3d2938ba6a590ff2c4b20a7a15a46cbb079bc8/
> >        nios2 |                       qt-4.8.7 | NOK |
> http://autobuild.buildroot.net/results/f67b512b761cb53a9d66ecfda9894e1f8d86c26f/
>
> Romain has submitted patches.
>
> >        sparc |                       qt-4.8.7 | NOK |
> http://autobuild.buildroot.net/results/872cb03d5869bd616fe8b22099a9ec4d556645ea/
> >        sparc |                       qt-4.8.7 | NOK |
> http://autobuild.buildroot.net/results/d462bf881ab01102ae26e20794b90c0ac3bbe27e/
>
> obj/release/JSObjectRef.o: In function `JSClassRetain':
> JSObjectRef.cpp:(.text+0xc0): undefined reference to
> `__sync_add_and_fetch_4'
>
> Need to add some atomic operation dependency here. Waldemar?
>
> >        nios2 |                       qt-4.8.7 | NOK |
> http://autobuild.buildroot.net/results/90a74e1c6c759e7029802caed2b3117fd63b1f17/
>
> Romain has submitted patches.
>
> >       mipsel |                qt5webkit-5.5.1 | NOK |
> http://autobuild.buildroot.net/results/9379603f465a5ce3a579bf27338a5a4be0f11728/
>
> {standard input}: Assembler messages:
> {standard input}:708: Error: opcode not supported on this processor:
> mips32r6 (mips32r6) `movz $v0,$t8,$t7'
> {standard input}:759: Error: opcode not supported on this processor:
> mips32r6 (mips32r6) `movz $v1,$t8,$t7'
> {standard input}:765: Error: opcode not supported on this processor:
> mips32r6 (mips32r6) `movz $t2,$t8,$t7'
>
> MIPS stuff. Vicente ?
>
> >      powerpc |                     ruby-2.3.0 | NOK |
> http://autobuild.buildroot.net/results/87c882bc1a0dec9d76917c1e2db51fea61150294/
>
> eval.c: In function 'rb_protect':
> eval.c:881:1: internal compiler error: in move_insn, at haifa-sched.c:3439
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <https://support.codesourcery.com/GNUToolchain/> for instructions.
>
> Compiler boom. Disable ruby with this toolchain? Gustavo?
>
> >          arm | sconeserver-c4b8e14f6e9e06c... | NOK |
> http://autobuild.buildroot.net/results/d22c1da4439806ded7cf8abf54ef92d0bf97dc9f/
>
> checking for no... no
> configure: error: library 'libxml2' is required for the rss module
> package/pkg-generic.mk:185: recipe for target
> '/home/autobuild/instance-0/output/build/sconeserver-
>
> Smells like a static linking issue. Yann, you already fixed another
> static linking issue with sconeserver, surely fixing another one will
> make your evening more enjoyable ? :-)
>
> >      sparc64 |                  setools-3.3.8 | NOK |
> http://autobuild.buildroot.net/results/fde279194387e131a4027d5a1e2183da8e477bbb/
>
> fpie/fPIE problem. I did had a patch for that, forgot to submit it.
> Will try to submit it soonish.
>
> >       mipsel |                     sox-14.4.2 | NOK |
> http://autobuild.buildroot.net/results/95721f7b88c46a20202fb02e408817097df965c3/
>
> /home/test/autobuild/instance-2/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld:
> cannot find -lssp_nonshared
> /home/test/autobuild/instance-2/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld:
> cannot find -lssp
>
> Vicente, still no news from your toolchain guys?
>
> >          arm |                 sqlite-3100200 | NOK |
> http://autobuild.buildroot.net/results/52202f98b9ebd273bdb3dd87f27cb1789f8362f9/
> >          arm |                 sqlite-3100200 | NOK |
> http://autobuild.buildroot.net/results/d97674be3ebc90ab99e93b1b294cfae8c7c1dad8/
>
> File truncated weird thing. Quick investigation reveals that:
>
>  - It seems to appear only in static linking scenarios.
>
>  - It appeared many times with sqlite-3100200, appeared only once with
>    3100100, never appeared with neither 3100000 or 3090200.
>
> Any ideas?
>
> >     mips64el |                   stunnel-5.29 | NOK |
> http://autobuild.buildroot.net/results/64cd09dc957cbeaab9c5c6d331d38e6e22da29ae/
>
> prototypes.h:625:5: error: conflicting types for 'getnameinfo'
>  int getnameinfo(const struct sockaddr *, socklen_t,
>
> Interestingly, this problem seems to occur only on MIPS. Vicente,
> Gustavo, any idea?
>
> >      aarch64 |                    tor-0.2.7.6 | NOK |
> http://autobuild.buildroot.net/results/fd0be644bf5c1c448eb1d2f94adbb433095f22f8/
>
> src/common/libor-crypto-testing.a(src_common_libor_crypto_testing_a-crypto_format.o):
> In function `crypto_write_tagged_contents_to_file':
> crypto_format.c:(.text+0x1c): relocation truncated to fit:
> R_AARCH64_LDST64_ABS_LO12_NC against symbol `smartlist_new' defined in
> .text section in src/common/libor.a(container.o)
>
> Hmmmm, some ARM64 toolchain person in the room?
>
> >          arm |                   trinity-v1.6 | NOK |
> http://autobuild.buildroot.net/results/6703eb14e69120f82878e4d3fb0dc5a4362cd8ef/
>
> Musl build issue.
>
> >          arc |                trousers-0.3.13 | NOK |
> http://autobuild.buildroot.net/results/28638752ebe923b6597ebc6838c1f97477dc23dc/
>
> Will be fixed by http://patchwork.ozlabs.org/patch/569556/.
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160224/0fdc08cc/attachment.html>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-24 11:08   ` Eric Limpens
@ 2016-02-24 20:45     ` Arnout Vandecappelle
  2016-02-24 20:59       ` Eric Limpens
  0 siblings, 1 reply; 23+ messages in thread
From: Arnout Vandecappelle @ 2016-02-24 20:45 UTC (permalink / raw)
  To: buildroot

On 02/24/16 12:08, Eric Limpens wrote:
> I've just submitted a patch to fix the issue for pifmrds. I don't fully
> understand why, but changing the order of 2 libraries fixed the problem.
> 
> Tested the patch with a non-static build and no issues occurred during building.
> 

 That patch doesn't appear on the list or patchwork. Can you check if it got
sent correctly?

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-24 20:45     ` Arnout Vandecappelle
@ 2016-02-24 20:59       ` Eric Limpens
  0 siblings, 0 replies; 23+ messages in thread
From: Eric Limpens @ 2016-02-24 20:59 UTC (permalink / raw)
  To: buildroot

Thanks Arnout,

My email configuration for git was messed up. I've resent the patch to the
list.

Sincerely, Eric.



On Wed, Feb 24, 2016 at 9:45 PM, Arnout Vandecappelle <arnout@mind.be>
wrote:

> On 02/24/16 12:08, Eric Limpens wrote:
> > I've just submitted a patch to fix the issue for pifmrds. I don't fully
> > understand why, but changing the order of 2 libraries fixed the problem.
> >
> > Tested the patch with a non-static build and no issues occurred during
> building.
> >
>
>  That patch doesn't appear on the list or patchwork. Can you check if it
> got
> sent correctly?
>
>  Regards,
>  Arnout
>
> --
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160224/c1f22415/attachment.html>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-23  8:11     ` Thomas Petazzoni
  2016-02-23 11:13       ` Olivier Schonken
@ 2016-02-24 21:30       ` Waldemar Brodkorb
  1 sibling, 0 replies; 23+ messages in thread
From: Waldemar Brodkorb @ 2016-02-24 21:30 UTC (permalink / raw)
  To: buildroot

Hi,
Thomas Petazzoni wrote,

> Hello,
> 
> On Tue, 23 Feb 2016 09:34:31 +0200, Olivier Schonken wrote:
> 
> > The suggestion from Romain to disable -fPIE as below works for both
> > architectures.  Can I submit a patch for this? Or do you want to wait for a
> > response from Alexey and Waldemar?
> > 
> > # Remove -fPIE -pie from CFLAGS
> > ifeq ($(BR2_STATIC_LIBS),y)
> > CUPS_CONF_OPTS += LSB_BUILD=y
> > endif
> 
> Unfortunately, I don't like this, for several reasons:
> 
>  1/ LSB_BUILD=y will also disable stack protection support.
> 
>  2/ Only uClibc in static library build is affected by the problem, not
>     musl for example.

Oh, that is interesting. I always thought static PIE binaries on
Linux are not supported via the toolchain. So this is a C library
issue? 
We disabled for example package/openssh exactly because of the same reason.

best regards
 Waldemar 

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-22 14:05 ` [Buildroot] Analysis of build " Thomas Petazzoni
  2016-02-23 10:12   ` John Keeping
  2016-02-24 11:08   ` Eric Limpens
@ 2016-02-24 21:42   ` Waldemar Brodkorb
  2016-02-24 22:09     ` Arnout Vandecappelle
  2016-02-27 15:19   ` Romain Naour
                     ` (3 subsequent siblings)
  6 siblings, 1 reply; 23+ messages in thread
From: Waldemar Brodkorb @ 2016-02-24 21:42 UTC (permalink / raw)
  To: buildroot

Hi Thomas,
Thomas Petazzoni wrote,

> Hello,
> 
> >        sparc |                  libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/a17047ada385e5be5f60c07254597fcb7c4183d0/
> >        sparc |                  libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/6d79591bce2d3fa5b93e268fe50d5b89ecd24521/
> 
> Could be fixed by http://patchwork.ozlabs.org/patch/569818/, but this
> patch is wrong I believe now that we have proper Config.in options to
> describe atomic operation dependencies.
> 
> Waldemar, could you have a look?

What about adding a nice chapter to the buildroot manual explaining
how to handle typical build problems. Subchapters like:
- PIE and static builds 
- Atomic build failures

come into my mind. 

Then anybody trying to fix autobuilder problems could step in.

My personal agenda for buildroot is more like this:
- fix ARM noMMU internal toolchain 
- push any required elf2flt changes to new (old) upstream and update
  br url to fetch it from there
- add internal bfin toolchain support as soon as gcc 6 is out and
  integrated
- resend my coldfire/m68k patch set in a more granular way
- fix any interesting uClibc-ng compile problems
..
- analyze any interesting sparc/sparc64 autobuilder problems
  if no other is fixing it :)

best regards
 Waldemar

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-24 21:42   ` Waldemar Brodkorb
@ 2016-02-24 22:09     ` Arnout Vandecappelle
  0 siblings, 0 replies; 23+ messages in thread
From: Arnout Vandecappelle @ 2016-02-24 22:09 UTC (permalink / raw)
  To: buildroot

On 02/24/16 22:42, Waldemar Brodkorb wrote:
> Hi Thomas,
> Thomas Petazzoni wrote,
> 
>> Hello,
>>
>>>        sparc |                  libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/a17047ada385e5be5f60c07254597fcb7c4183d0/
>>>        sparc |                  libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/6d79591bce2d3fa5b93e268fe50d5b89ecd24521/
>>
>> Could be fixed by http://patchwork.ozlabs.org/patch/569818/, but this
>> patch is wrong I believe now that we have proper Config.in options to
>> describe atomic operation dependencies.
>>
>> Waldemar, could you have a look?
> 
> What about adding a nice chapter to the buildroot manual explaining
> how to handle typical build problems. Subchapters like:
> - PIE and static builds 
> - Atomic build failures

 Great plan! Patches welcome :-)


 Regards,
 Arnout

> 
> come into my mind. 
> 
> Then anybody trying to fix autobuilder problems could step in.
> 
> My personal agenda for buildroot is more like this:
> - fix ARM noMMU internal toolchain 
> - push any required elf2flt changes to new (old) upstream and update
>   br url to fetch it from there
> - add internal bfin toolchain support as soon as gcc 6 is out and
>   integrated
> - resend my coldfire/m68k patch set in a more granular way
> - fix any interesting uClibc-ng compile problems
> ..
> - analyze any interesting sparc/sparc64 autobuilder problems
>   if no other is fixing it :)
> 
> best regards
>  Waldemar
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-22 14:05 ` [Buildroot] Analysis of build " Thomas Petazzoni
                     ` (2 preceding siblings ...)
  2016-02-24 21:42   ` Waldemar Brodkorb
@ 2016-02-27 15:19   ` Romain Naour
  2016-02-27 22:05   ` Bernd Kuhls
                     ` (2 subsequent siblings)
  6 siblings, 0 replies; 23+ messages in thread
From: Romain Naour @ 2016-02-27 15:19 UTC (permalink / raw)
  To: buildroot

Hi Thomas, All,

Le 22/02/2016 15:05, Thomas Petazzoni a ?crit :
> Hello,
> 

[snip]

>>         sh4a |                   prboom-2.5.0 | NOK | http://autobuild.buildroot.net/results/918d72bd9684a39dc688b143b682f8b5f49f1b26/
> 
> r_fps.c:296:1: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <https://support.codesourcery.com/GNUToolchain/> for instructions.
> 
> Gaah. A bit of investigation needed, maybe we should simply disable
> prboom with this toolchain.

Prboom add unconditionally -O2 in CFLAGS and triggers a segfault with this
toolchain.

See -0s and -O2 in this command line:
/home/autobuild/instance-0/output/host/usr/bin/sh-linux-gnu-gcc -DHAVE_CONFIG_H
-I. -I..   -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -Os  -Wall
-Wno-unused -Wno-switch -Wextra -Wno-missing-field-initializers -Winline
-Wwrite-strings -Wundef -Wbad-function-cast -Wcast-align -Wcast-qual
-Wdeclaration-after-statement -ffast-math -O2 -fomit-frame-pointer -I../src
-I/home/autobuild/instance-0/output/host/usr/sh4a-buildroot-linux-gnu/sysroot/usr/include/SDL
-D_GNU_SOURCE=1 -D_REENTRANT -c r_filter.c

-O2 is added from CFLAGS_OPT in configure.ac, so we need to remove it and
autoreconf prboom to avoid this issue.
But if we use BR2_OPTIMIZE_2 we still have the compiler bug... So it's more a
toolchain issue...

I'm ok to disable prboom with this toolchain.

> 
>>         bfin |                    qhull-7.2.0 | NOK | http://autobuild.buildroot.net/results/884bd0fef2f88154da949fa3f4cc04368575183a/
>>         bfin |                    qhull-7.2.0 | NOK | http://autobuild.buildroot.net/results/34f8754e2ddb243aaa73af196622449f655c5213/
> 
> Weird:
> 
> /home/peko/autobuild/instance-1/output/build/qhull-7.2.0/src/libqhullcpp/QhullSet.h:330: error: expected `;' before 'i'
> /home/peko/autobuild/instance-1/output/build/qhull-7.2.0/src/libqhullcpp/QhullSet.h:331: error: expected `;' before 'e'
> /home/peko/autobuild/instance-1/output/build/qhull-7.2.0/src/libqhullcpp/QhullSet.h:333: error: 'i' was not declared in this scope
> /home/peko/autobuild/instance-1/output/build/qhull-7.2.0/src/libqhullcpp/QhullSet.h:333: error: 'e' was not declared in this scope
> 

qhull needs gcc >= 4.4:

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

Best regards,
Romain

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-22 14:05 ` [Buildroot] Analysis of build " Thomas Petazzoni
                     ` (3 preceding siblings ...)
  2016-02-27 15:19   ` Romain Naour
@ 2016-02-27 22:05   ` Bernd Kuhls
  2016-03-01  9:38     ` Thomas Petazzoni
  2016-02-28  0:17   ` Bernd Kuhls
  2016-03-03 13:56   ` Gustavo Zacarias
  6 siblings, 1 reply; 23+ messages in thread
From: Bernd Kuhls @ 2016-02-27 22:05 UTC (permalink / raw)
  To: buildroot

Am Mon, 22 Feb 2016 15:05:39 +0100 schrieb Thomas Petazzoni:

>>          arm |             kodi-15.2-Isengard | NOK |
>>          http://autobuild.buildroot.net/
results/43939f65e4516adddc4385c6e0a2193abcab0446/
> 
> Usage of 64-bits on ARM with uClibc, doesn't work because gcc uses the
> __write() internal glibc symbol. We need to isolate the Kodi features
> that uses this 64 bits atomic operation (if possible) and make it depend
> on BR2_TOOLCHAIN_ARM_HAS_SYNC_8. See also
> https://git.busybox.net/buildroot/tree/toolchain/toolchain-
common.in#n339
> for a discussion of this problem.
> 
> Bernd ?

Hi Thomas,

tbh I do not think that I fully understood the atomics stuff[1], but I 
could reproduce the build error ;) Kodi checks unconditionally for
	__sync_add_and_fetch
	__sync_sub_and_fetch
	__sync_val_compare_and_swap
in configure.ac, the only file using the resulting defines is xbmc/
threads/Atomics.cpp which is used in several parts of Kodi, I do not 
think all of these features are optional.
The build error also occurs with Kodi 16.0-Jarvis, btw, and should be 
fixes by this patch: http://patchwork.ozlabs.org/patch/589456/

Regards, Bernd

[1] https://git.busybox.net/buildroot/commit/toolchain/toolchain-
common.in?id=6856e417da4f3aa77e2a814db2a89429af072f7d

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-22 14:05 ` [Buildroot] Analysis of build " Thomas Petazzoni
                     ` (4 preceding siblings ...)
  2016-02-27 22:05   ` Bernd Kuhls
@ 2016-02-28  0:17   ` Bernd Kuhls
  2016-03-01  9:39     ` Thomas Petazzoni
  2016-03-03 13:56   ` Gustavo Zacarias
  6 siblings, 1 reply; 23+ messages in thread
From: Bernd Kuhls @ 2016-02-28  0:17 UTC (permalink / raw)
  To: buildroot

Am Mon, 22 Feb 2016 15:05:39 +0100 schrieb Thomas Petazzoni:

>>          arm | kodi-pvr-argustv-32f03271cc... | NOK |
>>          http://autobuild.buildroot.net/results/
dacc3bd00ab2346d7655c0a1fb99f6c50b9da08b/
> 
> Bernd ?

Hi Thomas,

fixed by backport of upstream fix:
http://patchwork.ozlabs.org/patch/589468/

Similar bugs in other pvr addons are fixed by
http://patchwork.ozlabs.org/patch/589467/
http://patchwork.ozlabs.org/patch/589469/

Regards, Bernd

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-27 22:05   ` Bernd Kuhls
@ 2016-03-01  9:38     ` Thomas Petazzoni
  0 siblings, 0 replies; 23+ messages in thread
From: Thomas Petazzoni @ 2016-03-01  9:38 UTC (permalink / raw)
  To: buildroot

Bernd,

Please try to Cc: me whenever you are replying to an e-mail that
specifically needs my attention. I have 3000+ unread e-mails in my
Buildroot folder, so I can easily miss some replies to previous threads.

On Sat, 27 Feb 2016 23:05:24 +0100, Bernd Kuhls wrote:

> Hi Thomas,
> 
> tbh I do not think that I fully understood the atomics stuff[1],

To be honest, I am not sure if I still fully groked the entire problem
space either.

> but I 
> could reproduce the build error ;) Kodi checks unconditionally for
> 	__sync_add_and_fetch
> 	__sync_sub_and_fetch
> 	__sync_val_compare_and_swap
> in configure.ac, the only file using the resulting defines is xbmc/
> threads/Atomics.cpp which is used in several parts of Kodi, I do not 
> think all of these features are optional.
> The build error also occurs with Kodi 16.0-Jarvis, btw, and should be 
> fixes by this patch: http://patchwork.ozlabs.org/patch/589456/

There are multiple issues here, which are independent from each other.

The first issue is the one that you can see at
http://autobuild.buildroot.net/results/439/43939f65e4516adddc4385c6e0a2193abcab0446/,
i.e:

/home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.7.4/libgcc.a(linux-atomic-64bit.o): In function `__check_for_sync8_kernelhelper':
/opt/toolchain-build/build/host-gcc-final-4.7.4/build/arm-buildroot-linux-uclibcgnueabi/libgcc/../../../libgcc/config/arm/linux-atomic-64bit.c:59: undefined reference to `__write'

This issue is due to the fact that a __sync_*() intrinsic is used on a
8 byte type, but this is unfortunately broken on ARM < v7 with
libraries other than glibc.

The configure script is indeed doing some checks for __sync_*()
intrinsics, but it does so on a "long" type, which on ARM is 4 bytes.
So in fact, it seems like Kodi is testing for the availability of 4
bytes intrinsics, but also uses 8 bytes intrinsics.

To solve this problem, your addition of the BR2_TOOLCHAIN_HAS_SYNC_8
dependency is correct.

The second issue is the one your report in the commit log itself, and
is an *unrelated* issue:

xbmc/filesystem/filesystem.a(FileCache.o): In function `std::__atomic_base<long long>::store(long long, std::memory_order)':
/home/bernd/buildroot/br6_kodi_next/output/host/usr/i486-buildroot-linux-uclibc/include/c++/4.9.3/bits/atomic_base.h:478: undefined reference to `__atomic_store_8'

Here, we are not talking about the __sync_*() intrinsics, but the
__atomic_*() ones, which are different. To solve this specific problem,
you need to:

 1/ Depend on BR2_TOOLCHAIN_HAS_ATOMIC.
 2/ Link against -latomic if BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 is defined.

By chance, adding the BR2_TOOLCHAIN_HAS_SYNC_8 dependency solves both
the first and the second issue, because the __sync_*() 8-bytes
built-ins are not available on i486, so Kodi is no longer selectable on
i486, and therefore you no longer see the second problem. However, I
believe you should still be seeing the second problem on i586 and later
i386 chips, since all the __atomic_*() intrinsics are all implemented
in libatomic on i386.

Note that my fix (2) is currently the recommended fix, but it is not
completely correct yet since I have discovered that libatomic is
apparently not build for toolchains that have thread support disabled.
I still need to think about it and figure out the proper way of
handling this situation. In the mean time, doing (1) and (2) is good
enough and should fix most problems.

Best regards,

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-28  0:17   ` Bernd Kuhls
@ 2016-03-01  9:39     ` Thomas Petazzoni
  0 siblings, 0 replies; 23+ messages in thread
From: Thomas Petazzoni @ 2016-03-01  9:39 UTC (permalink / raw)
  To: buildroot

Bernd,

On Sun, 28 Feb 2016 01:17:21 +0100, Bernd Kuhls wrote:

> fixed by backport of upstream fix:
> http://patchwork.ozlabs.org/patch/589468/
> 
> Similar bugs in other pvr addons are fixed by
> http://patchwork.ozlabs.org/patch/589467/
> http://patchwork.ozlabs.org/patch/589469/

Thanks. As you've seen, I've applied all those three patches.

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [Buildroot] Analysis of build results for 2016-02-21
  2016-02-22 14:05 ` [Buildroot] Analysis of build " Thomas Petazzoni
                     ` (5 preceding siblings ...)
  2016-02-28  0:17   ` Bernd Kuhls
@ 2016-03-03 13:56   ` Gustavo Zacarias
  6 siblings, 0 replies; 23+ messages in thread
From: Gustavo Zacarias @ 2016-03-03 13:56 UTC (permalink / raw)
  To: buildroot

On 22/02/16 11:05, Thomas Petazzoni wrote:

>>      mips64el |                   stunnel-5.29 | NOK | http://autobuild.buildroot.net/results/64cd09dc957cbeaab9c5c6d331d38e6e22da29ae/
>
> prototypes.h:625:5: error: conflicting types for 'getnameinfo'
>   int getnameinfo(const struct sockaddr *, socklen_t,
>
> Interestingly, this problem seems to occur only on MIPS. Vicente,
> Gustavo, any idea?

Hi.
I defer to Vicente on this one, seems to be a toolchain issue since all 
of the failures are mips(32/64)r6 little-endian with external toolchain 
(codescape), switching to r2 yields good builds.
Regards.

^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2016-03-03 13:56 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-02-22 19:05 [Buildroot] Analysis of build results for 2016-02-21 Olivier Schonken
2016-02-22 21:55 ` Romain Naour
2016-02-22 22:21 ` Thomas Petazzoni
2016-02-23  7:34   ` Olivier Schonken
2016-02-23  8:11     ` Thomas Petazzoni
2016-02-23 11:13       ` Olivier Schonken
2016-02-24 21:30       ` Waldemar Brodkorb
  -- strict thread matches above, loose matches on Subject: below --
2016-02-22  7:30 [Buildroot] [autobuild.buildroot.net] Build " Thomas Petazzoni
2016-02-22 14:05 ` [Buildroot] Analysis of build " Thomas Petazzoni
2016-02-23 10:12   ` John Keeping
2016-02-23 10:40     ` Jeroen Roovers
2016-02-23 11:03       ` John Keeping
2016-02-23 12:30       ` Thomas Petazzoni
2016-02-24 11:08   ` Eric Limpens
2016-02-24 20:45     ` Arnout Vandecappelle
2016-02-24 20:59       ` Eric Limpens
2016-02-24 21:42   ` Waldemar Brodkorb
2016-02-24 22:09     ` Arnout Vandecappelle
2016-02-27 15:19   ` Romain Naour
2016-02-27 22:05   ` Bernd Kuhls
2016-03-01  9:38     ` Thomas Petazzoni
2016-02-28  0:17   ` Bernd Kuhls
2016-03-01  9:39     ` Thomas Petazzoni
2016-03-03 13:56   ` Gustavo Zacarias

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox