* [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-29
@ 2014-08-30 6:30 Thomas Petazzoni
2014-08-30 9:07 ` [Buildroot] Analysis of build results Thomas Petazzoni
2014-09-01 12:51 ` [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-29 Vicente Olivert Riera
0 siblings, 2 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2014-08-30 6:30 UTC (permalink / raw)
To: buildroot
Build statistics for 2014-08-29
===============================
success : 133
failures : 21
timeouts : 1
TOTAL : 155
Classification of failures by reason
====================================
gnupg2-2.0.25 | 2
python3-3.4.1 | 2
alsa-lib-1.0.28 | 1
gd-2.1.0 | 1
libplist-1.6 | 1
fxload-2008_10_13 | 1
opencv-2.4.8 | 1
czmq-v2.2.0 | 1
expedite-1.7.7 | 1
host-icu-51.2 | 1
lftp-4.5.2 | 1
libiscsi-1.6.0 | 1
make: *** wait: No child pr... | 1
taglib-1.9.1 | 1
zeromq-4.0.4 | 1
upmpdcli-0.7.1 | 1
btrfs-progs-3.14.2 | 1
xapp_xfs-1c8459eafc04997751... | 1
enlightenment-0.17.3 | 1
lttng-tools-2.4.1 | 1
Detail of failures
===================
sh4 | alsa-lib-1.0.28 | NOK | http://autobuild.buildroot.net/results/a810c2f27dee1978808461c05cbdcbf51a214e09/
arm | btrfs-progs-3.14.2 | NOK | http://autobuild.buildroot.net/results/ddcc70143ce2c2882894184e4ce195a11407e027/
arm | czmq-v2.2.0 | NOK | http://autobuild.buildroot.net/results/404c80e23bbeb21e7c44cd28a187f2bdfa1d82c5/
powerpc | enlightenment-0.17.3 | NOK | http://autobuild.buildroot.net/results/d0adacc2961e1aee919f366d1c2982c142c8631e/
x86_64 | expedite-1.7.7 | NOK | http://autobuild.buildroot.net/results/5d0ec95e9a65ce342757b2af53762bd9d3950d14/
microblazeel | fxload-2008_10_13 | NOK | http://autobuild.buildroot.net/results/b849c8cd01acc86ca0507237e9b72ab7cf2cb563/
i486 | gd-2.1.0 | NOK | http://autobuild.buildroot.net/results/bbc8f65035ab31f30d90e8979e3d6e855a2d3957/
arm | gnupg2-2.0.25 | NOK | http://autobuild.buildroot.net/results/8842ad68bc3ec820a6ffb849770983957f35009d/
arm | gnupg2-2.0.25 | NOK | http://autobuild.buildroot.net/results/a43fdda52628afb2127fa915f8dc0fe5f271d1df/
arm | host-icu-51.2 | NOK | http://autobuild.buildroot.net/results/9e1dfe72d6dcfeaa1c9f6415936e3957d55d06cd/
x86_64 | lftp-4.5.2 | NOK | http://autobuild.buildroot.net/results/b16d964f275d4d8703665236b969cc19f7ef20be/
bfin | libiscsi-1.6.0 | NOK | http://autobuild.buildroot.net/results/8b9dc2848cc001d1f88cbf0ad93c9276d12af8d3/
bfin | libplist-1.6 | NOK | http://autobuild.buildroot.net/results/9a364e3d91634a2da2bc481da1dee0ad0e870941/
arm | lttng-tools-2.4.1 | NOK | http://autobuild.buildroot.net/results/3009327a72705f97501a9c997d56683a57d3881f/
x86_64 | make: *** wait: No child pr... | TIM | http://autobuild.buildroot.net/results/89641bf6251eb605c807e0092f5280d0274911c9/
powerpc | opencv-2.4.8 | NOK | http://autobuild.buildroot.net/results/3dc3e10e412d87937adae4d20a67cc4557bb328b/
mips64el | python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/f6088f98372199bdf4fc02ea4e82818c68e30a54/
mips64el | python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/940015d84ee574e785ef8aa7d4502f157399524f/
bfin | taglib-1.9.1 | NOK | http://autobuild.buildroot.net/results/a9cfe66c57bffc5a4560b2e4dcb41994da59e294/
bfin | upmpdcli-0.7.1 | NOK | http://autobuild.buildroot.net/results/d453d4dba313970f7440701f747b7b50d51120d7/
microblazeel | xapp_xfs-1c8459eafc04997751... | NOK | http://autobuild.buildroot.net/results/540b42436f6248adf131d2940b9528ed2f0fd5d6/
bfin | zeromq-4.0.4 | NOK | http://autobuild.buildroot.net/results/6e7afb29f3af0b4782d2a71be326133a3d3c474d/
--
http://autobuild.buildroot.net
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2014-08-30 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-29 Thomas Petazzoni
@ 2014-08-30 9:07 ` Thomas Petazzoni
2014-09-01 12:51 ` [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-29 Vicente Olivert Riera
1 sibling, 0 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2014-08-30 9:07 UTC (permalink / raw)
To: buildroot
Hello,
On Sat, 30 Aug 2014 08:30:10 +0200 (CEST), Thomas Petazzoni wrote:
> sh4 | alsa-lib-1.0.28 | NOK | http://autobuild.buildroot.net/results/a810c2f27dee1978808461c05cbdcbf51a214e09/
The usual vfork() uClibc issue. I've now reported the problem to the
uClibc developers. They ask me to see if the problem still occurs on
uClibc master, so I'm currently building a toolchain with the latest
uClibc version.
> arm | btrfs-progs-3.14.2 | NOK | http://autobuild.buildroot.net/results/ddcc70143ce2c2882894184e4ce195a11407e027/
[LD] libbtrfs.so.0.1
Trying to build a shared library in a pure static context. I'll have a
look.
> arm | czmq-v2.2.0 | NOK | http://autobuild.buildroot.net/results/404c80e23bbeb21e7c44cd28a187f2bdfa1d82c5/
checking for zmq_init in -lzmq... no
configure: error: cannot link with -lzmq, install libzmq.
make: *** [/home/test/autobuild/instance-3/output/build/czmq-v2.2.0/.stamp_configured] Error 1
make: Leaving directory `/home/test/autobuild/instance-3/buildroot'
I guess it's the -ldl issue investigated by J?rg?
> powerpc | enlightenment-0.17.3 | NOK | http://autobuild.buildroot.net/results/d0adacc2961e1aee919f366d1c2982c142c8631e/
e_start_main.c:478:42: error: 'PT_GETSIGINFO' undeclared (first use in this function)
r = ptrace(PT_GETSIGINFO, child, NULL, &sig);
I think we had a similar issue for a different package, but I don't
remember the details. Gustavo, maybe?
> x86_64 | expedite-1.7.7 | NOK | http://autobuild.buildroot.net/results/5d0ec95e9a65ce342757b2af53762bd9d3950d14/
CXXLD expedite
/home/test/autobuild/instance-2/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/libgcrypt.so.20: undefined reference to `gpg_err_set_errno'
(It's with BR2_PREFER_STATIC_LIB disabled).
> microblazeel | fxload-2008_10_13 | NOK | http://autobuild.buildroot.net/results/b849c8cd01acc86ca0507237e9b72ab7cf2cb563/
This looks like either a gcc or binutils bug. I've reported the issue
upstream as a binutils bug, see
https://sourceware.org/bugzilla/show_bug.cgi?id=17329. It's the
combination of an optimization flag, and the -g flag that causes the
issue.
> i486 | gd-2.1.0 | NOK | http://autobuild.buildroot.net/results/bbc8f65035ab31f30d90e8979e3d6e855a2d3957/
Static lib issue, forgets to link with -lpthread.
> arm | gnupg2-2.0.25 | NOK | http://autobuild.buildroot.net/results/8842ad68bc3ec820a6ffb849770983957f35009d/
> arm | gnupg2-2.0.25 | NOK | http://autobuild.buildroot.net/results/a43fdda52628afb2127fa915f8dc0fe5f271d1df/
I really don't know what to do about this one...
> arm | host-icu-51.2 | NOK | http://autobuild.buildroot.net/results/9e1dfe72d6dcfeaa1c9f6415936e3957d55d06cd/
Memory allocation problem, ignore. I've modified the autobuild
infrastructure to automatically reject such build failures in the
future.
> x86_64 | lftp-4.5.2 | NOK | http://autobuild.buildroot.net/results/b16d964f275d4d8703665236b969cc19f7ef20be/
Fixed by http://git.buildroot.net/buildroot/commit/?id=c9ad5ddfb1544a61c271354a1070edfec730bda4.
> bfin | libiscsi-1.6.0 | NOK | http://autobuild.buildroot.net/results/8b9dc2848cc001d1f88cbf0ad93c9276d12af8d3/
dlfcn.h usage on Blackfin FLAT. I need to finish my patch that bumps
libiscsi.
> bfin | libplist-1.6 | NOK | http://autobuild.buildroot.net/results/9a364e3d91634a2da2bc481da1dee0ad0e870941/
CMake package trying to build a shared library even when it's told not
to do so. Samuel?
> arm | lttng-tools-2.4.1 | NOK | http://autobuild.buildroot.net/results/3009327a72705f97501a9c997d56683a57d3881f/
Compiler affected by a well-known issue causing a build failure of
lttng-tools. Exception added to the autobuilder script.
> x86_64 | make: *** wait: No child pr... | TIM | http://autobuild.buildroot.net/results/89641bf6251eb605c807e0092f5280d0274911c9/
Ignore.
> powerpc | opencv-2.4.8 | NOK | http://autobuild.buildroot.net/results/3dc3e10e412d87937adae4d20a67cc4557bb328b/
Samuel, this is for you.
> mips64el | python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/f6088f98372199bdf4fc02ea4e82818c68e30a54/
> mips64el | python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/940015d84ee574e785ef8aa7d4502f157399524f/
Caused by SYS_getdents64 being not provided by the C library, because
the glibc used by the toolchain is too old. Exception added to the
autobuilder script.
Yann, maybe it would be good to see how Crosstool-NG could take into
account the various build issues that we have found, and then provide
an updated version of the toolchains.
> bfin | taglib-1.9.1 | NOK | http://autobuild.buildroot.net/results/a9cfe66c57bffc5a4560b2e4dcb41994da59e294/
Another stupid CMake based package building a shared library when told
not to do so. Samuel? :-)
> bfin | upmpdcli-0.7.1 | NOK | http://autobuild.buildroot.net/results/d453d4dba313970f7440701f747b7b50d51120d7/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=f4905d7a3e1945d79084ca860ac88fbfedc01eaa.
> microblazeel | xapp_xfs-1c8459eafc04997751... | NOK | http://autobuild.buildroot.net/results/540b42436f6248adf131d2940b9528ed2f0fd5d6/
/home/buildroot/instance-1/output/host/usr/microblazeel-buildroot-linux-gnu/sysroot/usr/lib/libXfont.so: undefined reference to `dlopen'
/home/buildroot/instance-1/output/host/usr/microblazeel-buildroot-linux-gnu/sysroot/usr/lib/libXfont.so: undefined reference to `dlsym'
> bfin | zeromq-4.0.4 | NOK | http://autobuild.buildroot.net/results/6e7afb29f3af0b4782d2a71be326133a3d3c474d/
source.c:(.text+0x1a2): undefined reference to `___sync_fetch_and_add_2'
Maybe Blackfin doesn't provide the atomic compiler intrinsics?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-29
2014-08-30 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-29 Thomas Petazzoni
2014-08-30 9:07 ` [Buildroot] Analysis of build results Thomas Petazzoni
@ 2014-09-01 12:51 ` Vicente Olivert Riera
1 sibling, 0 replies; 38+ messages in thread
From: Vicente Olivert Riera @ 2014-09-01 12:51 UTC (permalink / raw)
To: buildroot
On 08/30/2014 07:30 AM, Thomas Petazzoni wrote:
> Build statistics for 2014-08-29
> ===============================
> mips64el | python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/f6088f98372199bdf4fc02ea4e82818c68e30a54/
> mips64el | python3-3.4.1 | NOK | http://autobuild.buildroot.net/results/940015d84ee574e785ef8aa7d4502f157399524f/
These failures are caused because the toolchain
mips64el-ctng_n64-linux-gnu.tar.xz uses eglibc-2.18 which lacks the
definition of SYS_getdents64 for MIPS64 n64.
Could be possible to upgrade that toolchain using a newer eglibc
version, please?
--
Vincent
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2020-02-29 21:15 ` Romain Naour
@ 2020-02-29 23:17 ` Peter Seiderer
0 siblings, 0 replies; 38+ messages in thread
From: Peter Seiderer @ 2020-02-29 23:17 UTC (permalink / raw)
To: buildroot
Hello Romain,
On Sat, 29 Feb 2020 22:15:10 +0100, Romain Naour <romain.naour@gmail.com> wrote:
> Hi Peter,
>
> Le 28/02/2020 ? 16:02, Peter Seiderer a ?crit?:
> > Hello Romain,
> >
> > On Fri, 28 Feb 2020 08:32:18 +0100, Romain Naour <romain.naour@gmail.com> wrote:
> >
> >>>
> >>>> arm | mesa3d-19.3.4 | NOK |
> >>> http://autobuild.buildroot.net/results/6387b0a99e1a0922811919623d9a10b0943988df
> >>> |
> >>>
> >>> {standard input}: Assembler messages:
> >>> {standard input}:334: Error: selected processor does not support `vldm
> >>> r4,{q0,q1,q2,q3}' in ARM mode
> >>> {standard input}:335: Error: selected processor does not support `vst1.8
> >>> d0,[r3],r2' in ARM mode
> >>> {standard input}:336: Error: selected processor does not support `vst1.8
> >>> d1,[r3],r2' in ARM mode
> >>> {standard input}:337: Error: selected processor does not support `vst1.8
> >>> d2,[r3],r2' in ARM mode
> >>>
> >>> Bad stuff happens when building the vc4 driver. It probably needs some
> >>> minimal ARM architecture variant.
> >>>
> >>
> >> I believe we should re-add the dependency on neon for vc4 driver. There is
> >> -mfpu=neon added by the build system.
> >
> > The BR2_ARM_CPU_HAS_NEON dependency was dropped with commit [1] because mesa3d
> > commit [2] added a compile time detected neon support, in the meantime this
> > was changed to a runtime detection [3] and finally enabled for the meson
> > cross compile build with commit [4] (assuming toolchain support for the
> > neon assembler instructions)...
>
> Thank you for the detailed explanation.
>
> I saw the commit [4] and conclude that upstream mesa3d now require neon support
> when vc4 driver is enabled.
>
> >
> > Maybe the compile error could be fixed by re-adding partly the compile time
> > check for the neon support (tested):
> >
> > --- mesa3d-19.3.4/src/broadcom/common/v3d_cpu_tiling.h_orig 2020-02-28 14:47:44.232634657 +0100
> > +++ mesa3d-19.3.4/src/broadcom/common/v3d_cpu_tiling.h 2020-02-28 14:49:21.518425222 +0100
> > @@ -31,7 +31,7 @@
> > v3d_load_utile(void *cpu, uint32_t cpu_stride,
> > void *gpu, uint32_t gpu_stride)
> > {
> > -#if defined(V3D_BUILD_NEON) && defined(PIPE_ARCH_ARM)
> > +#if defined(V3D_BUILD_NEON) && defined(__ARM_ARCH) && __ARM_ARCH >= 7
> > if (gpu_stride == 8) {
> > __asm__ volatile (
> > /* Load from the GPU in one shot, no interleave, to
> > @@ -141,7 +141,7 @@
> > v3d_store_utile(void *gpu, uint32_t gpu_stride,
> > void *cpu, uint32_t cpu_stride)
> > {
> > -#if defined(V3D_BUILD_NEON) && defined(PIPE_ARCH_ARM)
> > +#if defined(V3D_BUILD_NEON) && defined(__ARM_ARCH) && __ARM_ARCH >= 7
> > if (gpu_stride == 8) {
> > __asm__ volatile (
> > /* Load each 8-byte line from cpu-side source,
> >
>
> But -mfpu=neon is still present on the command line.
But without problems, as all the neon stuff in handcrafted via
inline assambler ;-)
>
> Do you think if the neon support can be handled/forced by a new meson option?
The following patch fixes the problem for the vc4 driver (but not for the
v3d one which needs neon unconditionally - or fixed by the previous patch):
diff --git a/meson.build b/meson.build
index 7e2295b..a3134b1 100644
--- a/meson.build
+++ b/meson.build
@@ -1112,8 +1112,10 @@ elif host_machine.cpu_family() == 'x86_64'
endif
elif host_machine.cpu_family() == 'arm'
if system_has_kms_drm
- with_asm_arch = 'arm'
- pre_args += ['-DUSE_ARM_ASM']
+ if not (host_machine.cpu().contains('4') or host_machine.cpu().contains('5') or host_machine.cpu().contains('6'))
+ with_asm_arch = 'arm'
+ pre_args += ['-DUSE_ARM_ASM']
+ endif
endif
elif host_machine.cpu_family() == 'aarch64'
if system_has_kms_drm
diff --git a/src/gallium/drivers/vc4/meson.build b/src/gallium/drivers/vc4/meson.build
index 5ce5af5..2bb5d06 100644
--- a/src/gallium/drivers/vc4/meson.build
+++ b/src/gallium/drivers/vc4/meson.build
@@ -84,7 +84,7 @@ files_libvc4 = files(
vc4_c_args = []
libvc4_neon = []
-if host_machine.cpu_family() == 'arm'
+if host_machine.cpu_family() == 'arm' and not (host_machine.cpu().contains('4') or host_machine.cpu().contains('5') or host_machine.cpu().contains('6'))
libvc4_neon = static_library(
'vc4_neon',
'vc4_tiling_lt_neon.c',
An alternative to the check on ARMvX >=7 a new meson option should be possible...
Regards,
Peter
>
> Best regards,
> Romain
>
> > Regards,
> > Peter
> >
> > [1] https://git.buildroot.net/buildroot/commit/package/mesa3d?id=350cb0d32ece533b9723a5f3ca6fbf7e6f071c90
> > [2] https://cgit.freedesktop.org/mesa/mesa/commit/?h=17.1&id=4d30024238efa829cabc72c1601beeee18c3dbf2
> > [3] https://cgit.freedesktop.org/mesa/mesa/commit/?h=staging/19.3&id=ece06defe77a77d2db40abeddee5a2e0e45654ce
> > [4] https://cgit.freedesktop.org/mesa/mesa/commit/?id=932ed9c00b99e6ec92146ec9e820f546cf3e6551
> >
> >>
> >> Romain
> >
>
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2020-02-28 15:02 ` Peter Seiderer
@ 2020-02-29 21:15 ` Romain Naour
2020-02-29 23:17 ` Peter Seiderer
0 siblings, 1 reply; 38+ messages in thread
From: Romain Naour @ 2020-02-29 21:15 UTC (permalink / raw)
To: buildroot
Hi Peter,
Le 28/02/2020 ? 16:02, Peter Seiderer a ?crit?:
> Hello Romain,
>
> On Fri, 28 Feb 2020 08:32:18 +0100, Romain Naour <romain.naour@gmail.com> wrote:
>
>>>
>>>> arm | mesa3d-19.3.4 | NOK |
>>> http://autobuild.buildroot.net/results/6387b0a99e1a0922811919623d9a10b0943988df
>>> |
>>>
>>> {standard input}: Assembler messages:
>>> {standard input}:334: Error: selected processor does not support `vldm
>>> r4,{q0,q1,q2,q3}' in ARM mode
>>> {standard input}:335: Error: selected processor does not support `vst1.8
>>> d0,[r3],r2' in ARM mode
>>> {standard input}:336: Error: selected processor does not support `vst1.8
>>> d1,[r3],r2' in ARM mode
>>> {standard input}:337: Error: selected processor does not support `vst1.8
>>> d2,[r3],r2' in ARM mode
>>>
>>> Bad stuff happens when building the vc4 driver. It probably needs some
>>> minimal ARM architecture variant.
>>>
>>
>> I believe we should re-add the dependency on neon for vc4 driver. There is
>> -mfpu=neon added by the build system.
>
> The BR2_ARM_CPU_HAS_NEON dependency was dropped with commit [1] because mesa3d
> commit [2] added a compile time detected neon support, in the meantime this
> was changed to a runtime detection [3] and finally enabled for the meson
> cross compile build with commit [4] (assuming toolchain support for the
> neon assembler instructions)...
Thank you for the detailed explanation.
I saw the commit [4] and conclude that upstream mesa3d now require neon support
when vc4 driver is enabled.
>
> Maybe the compile error could be fixed by re-adding partly the compile time
> check for the neon support (tested):
>
> --- mesa3d-19.3.4/src/broadcom/common/v3d_cpu_tiling.h_orig 2020-02-28 14:47:44.232634657 +0100
> +++ mesa3d-19.3.4/src/broadcom/common/v3d_cpu_tiling.h 2020-02-28 14:49:21.518425222 +0100
> @@ -31,7 +31,7 @@
> v3d_load_utile(void *cpu, uint32_t cpu_stride,
> void *gpu, uint32_t gpu_stride)
> {
> -#if defined(V3D_BUILD_NEON) && defined(PIPE_ARCH_ARM)
> +#if defined(V3D_BUILD_NEON) && defined(__ARM_ARCH) && __ARM_ARCH >= 7
> if (gpu_stride == 8) {
> __asm__ volatile (
> /* Load from the GPU in one shot, no interleave, to
> @@ -141,7 +141,7 @@
> v3d_store_utile(void *gpu, uint32_t gpu_stride,
> void *cpu, uint32_t cpu_stride)
> {
> -#if defined(V3D_BUILD_NEON) && defined(PIPE_ARCH_ARM)
> +#if defined(V3D_BUILD_NEON) && defined(__ARM_ARCH) && __ARM_ARCH >= 7
> if (gpu_stride == 8) {
> __asm__ volatile (
> /* Load each 8-byte line from cpu-side source,
>
But -mfpu=neon is still present on the command line.
Do you think if the neon support can be handled/forced by a new meson option?
Best regards,
Romain
> Regards,
> Peter
>
> [1] https://git.buildroot.net/buildroot/commit/package/mesa3d?id=350cb0d32ece533b9723a5f3ca6fbf7e6f071c90
> [2] https://cgit.freedesktop.org/mesa/mesa/commit/?h=17.1&id=4d30024238efa829cabc72c1601beeee18c3dbf2
> [3] https://cgit.freedesktop.org/mesa/mesa/commit/?h=staging/19.3&id=ece06defe77a77d2db40abeddee5a2e0e45654ce
> [4] https://cgit.freedesktop.org/mesa/mesa/commit/?id=932ed9c00b99e6ec92146ec9e820f546cf3e6551
>
>>
>> Romain
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2020-02-27 23:18 ` Giulio Benetti
2020-02-28 8:03 ` Thomas Petazzoni
@ 2020-02-28 18:06 ` Giulio Benetti
1 sibling, 0 replies; 38+ messages in thread
From: Giulio Benetti @ 2020-02-28 18:06 UTC (permalink / raw)
To: buildroot
Hello,
On 2/28/20 12:18 AM, Giulio Benetti wrote:
> Hello,
>
> Inviato da iPhone
>
>> Il giorno 27 feb 2020, alle ore 23:49, Thomas Petazzoni <thomas.petazzoni@bootlin.com> ha scritto:
>>
>> ?Hello,
>>
>> Here is an analysis of yesterday's build failures. Please have a look
>> and help!
>>
>>> On Thu, 27 Feb 2020 09:31:33 -0000
>>> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
>>>
>>> arch | reason | OK? | url | orph?
>>> -------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
>>> microblazeel | bash-5.0 | NOK | http://autobuild.buildroot.net/results/c4bc6cc208e94ffb84caaea03c4898a3001c7f9a | ORPH
>>
>> Would be fixed by http://patchwork.ozlabs.org/patch/1242647/, but I'm
>> personally not entirely sure about this patch.
>>
>>> arc | bitcoin-0.19.0.1 | NOK | http://autobuild.buildroot.net/results/f4821f44ceb2811e9ab160dd2cb886243215df52 |
>>> arc | bitcoin-0.19.0.1 | NOK | http://autobuild.buildroot.net/results/f3ac50c32c7e4fd3a5e9e3dd4170b0799a26270b |
>>
>> undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)'
>>
>> According to http://autobuild.buildroot.net/?reason=bitcoin%, this only
>> happens on the ARC architecture.
>>
>> ARC maintainers, any idea ?
>>
>>> mips64el | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/4569cbbe97ab9057e5e3909a03540544d588a479 |
>>> sparc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/71fdd490873809acd89d7b3e3ea27e88c5b62c24 |
>>> xtensa | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/caa1041217f8b2bc835dd6a06c13d59f70f72caa |
>>> arc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/a05dee0491871bdd7d0a8f53d96e7971f7c71d1a |
>>> arc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/a8edb5621ecc2d250f572240b0607762735b0ffb |
>>> sparc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/1c6d8e80974547c48f6a4c9d2ff43b9ba268a2aa |
>>> arm | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/7d8ccf9cc8559db9aed19bf32e6cb342141bd360 |
>>
>> Fixed by https://git.buildroot.org/buildroot/commit/?id=7bed3ee409661107b6ce2a05c48adcc7f79258fa.
>>
>>> xtensa | domoticz-0f411f781ae4fb4a82... | NOK | http://autobuild.buildroot.net/results/7885705f1b1c0f31cf21b464150f5509929c1906 |
>>
>> Toolchain issue:
>>
>> BFD (GNU Binutils) 2.31.1 internal error, aborting at elf32-xtensa.c:3283 in elf_xtensa_finish_dynamic_sections
>>
>> Max, any idea ?
>>
>>> m68k | dvdauthor-0.7.2 | NOK | http://autobuild.buildroot.net/results/9c7f4f22386d4ffd211ed62da323f9861f1b1716 |
>>
>> elf2flt issue, Romain has posted a series to avoid it.
>>
>>> arm | fail2ban-0.11.1 | NOK | http://autobuild.buildroot.net/results/4b16c925a0aa0aba073324e2c3a4297c456b55bd |
>>
>> I would assume fixed by
>> https://git.buildroot.org/buildroot/commit/?id=bdc9364ffae64623158830698a4f84fb2a179910.
>>
>>> riscv64 | gerbera-1.3.4 | NOK | http://autobuild.buildroot.net/results/b499442a920dd3969e2beb2099504d33641b4980 |
>>
>> /home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: cannot find /lib64/libc.so.6
>> /home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: cannot find /usr/lib/libc_nonshared.a
>> /home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: cannot find /lib/ld-linux-riscv64-lp64d.so.1
>>
>> This is a per-package directory build issue I believe.
>>
>>> xtensa | gst1-plugins-base-1.16.2 | NOK | http://autobuild.buildroot.net/results/42cbc33ded6cf04f5cb2edb105f2e561d06886ff |
>>
>> /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/xtensa-buildroot-linux-uclibc/8.3.0/../../../../xtensa-buildroot-linux-uclibc/bin/ld: gstplugin.c:(.text+0xb58): undefined reference to `g_module_open'
>> /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/xtensa-buildroot-linux-uclibc/8.3.0/../../../../xtensa-buildroot-linux-uclibc/bin/ld: gstplugin.c:(.text+0xb5c): undefined reference to `g_module_error'
>>
>> static linking issue. Any brave meson/gstreamer person in the house ?
>> Adam ? :-)
>>
>>> mips64el | host-go-1.13.8 | NOK | http://autobuild.buildroot.net/results/fa13a054995d6060d2dc15c36007e41a50ed7fc4 |
>>
>> Some funky toolchain issue:
>>
>> /data/buildroot/buildroot-test/instance-0/output/build/host-go-1.13.8/pkg/tool/linux_amd64/link: running /data/buildroot/buildroot-test/instance-0/output/host/bin/mips64el-linux-gcc failed: exit status 1
>> collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped
>> compilation terminated.
>> /data/buildroot/buildroot-test/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64el-buildroot-linux-uclibc/5.5.0/../../../../mips64el-buildroot-linux-uclibc/bin/ld: /tmp/go-link-130627779/go.o: relocation R_MIPS_26 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
>> /data/buildroot/buildroot-test/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64el-buildroot-linux-uclibc/5.5.0/../../../../mips64el-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elfxx-mips.c:6550
>>
>>> mips64el | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/4f853af32b5c09e63896e2125b5d018d279c0951 |
>>
>> Yann's machine still exhibiting this weird issue.
>>
>>> aarch64 | host-nodejs-12.16.0 | NOK | http://autobuild.buildroot.net/results/a83acd958d177a47ea2b1ca94b8a163da3e4a2c5 |
>>> arm | host-nodejs-12.16.0 | NOK | http://autobuild.buildroot.net/results/c7934318c29b9dce9062d93158906409c5229a6d |
>>
>> Would be fixed by http://patchwork.ozlabs.org/patch/1239736/, but I
>> don't like the fact that package A refers to package B build directory.
>>
>>> arc | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/46c5cf068cf9ea50e53491870d9dbf3f134c8c22 |
>>
>> /home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/9.2.1/../../../../arc-buildroot-linux-uclibc/bin/ld: ../src/.libs/libgdiplus.so: undefined reference to `GifQuantizeBuffer'
>>
>> This is *not* a static linking issue.
>>
>>> m68k | libopenssl-1.1.1d | NOK | http://autobuild.buildroot.net/results/686b92af36ec691dd06078c18df21f59209bea06 |
>>
>> elf2flt mess.
>>
>>> sparc64 | lxc-3.2.1 | NOK | http://autobuild.buildroot.net/results/94d021c513569cf4062619127ec2262d30b3201f |
>>
>> error: ^[[m^[[Kinvalid 'asm': invalid operand output code
>>
>> J?r?me, you are listed as the lxc package developer, could you have a
>> look ?
>>
>>
>>> arm | mesa3d-19.3.4 | NOK | http://autobuild.buildroot.net/results/6387b0a99e1a0922811919623d9a10b0943988df |
>>
>> {standard input}: Assembler messages:
>> {standard input}:334: Error: selected processor does not support `vldm r4,{q0,q1,q2,q3}' in ARM mode
>> {standard input}:335: Error: selected processor does not support `vst1.8 d0,[r3],r2' in ARM mode
>> {standard input}:336: Error: selected processor does not support `vst1.8 d1,[r3],r2' in ARM mode
>> {standard input}:337: Error: selected processor does not support `vst1.8 d2,[r3],r2' in ARM mode
>>
>> Bad stuff happens when building the vc4 driver. It probably needs some
>> minimal ARM architecture variant.
>>
>>> powerpc | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/ddb1c83ede34c125296563227f6b8f4b76729480 |
>>
>> /home/giuliobenetti/autobuild/run/instance-0/output-1/host/lib/gcc/powerpc-buildroot-linux-uclibc/8.3.0/crtbeginS.o: in function `__do_global_dtors_aux':
>> crtstuff.c:(.text+0x13c): relocation truncated to fit: R_PPC_PLTREL24 against symbol `__cxa_finalize' defined in .text section in /home/giuliobenetti/autobuild/run/instance-0/output-1/host/powerpc-buildroot-linux-uclibc/sysroot/lib/libc.so.1
>> collect2: error: ld returned 1 exit status
>>
>>> m68k | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/1a0caff18be6d55395c40f4d9f04076b03122757 |
>>
>> elf2flt mess.
>>
>>> arm | minicom-52b626b15a883b03006... | NOK | http://autobuild.buildroot.net/results/d3edbab1f2cd0f7b790e2559dc8d489497ae02f3 |
>>
>> Fixed by https://git.buildroot.org/buildroot/commit/?id=acbae76d6977b1f2d3847ea379c7dd8f1761f565.
>>
>>> x86_64 | mongodb-r4.0.12 | NOK | http://autobuild.buildroot.net/results/80a0d9dc59567c28b891c50c63280cea3aad613f |
>>
>> src/mongo/util/heap_profiler.cpp:484:33: error: 'abi' has not been declared
>>
>>> arm | mongodb-r4.0.12 | NOK | http://autobuild.buildroot.net/results/5765e33f444a22701b055015ed41436d3526e9eb |
>>
>> /home/test/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-linux-gnueabihf/7.3.1/../../../../arm-linux-gnueabihf/bin/ld.gold: error: /home/test/autobuild/run/instance-1/output-1/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libyaml-cpp.a(null.cpp.o): requires unsupported dynamic reloc R_ARM_MOVW_ABS_NC; recompile with -fPIC
>>
>>> aarch64_be | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/3938ecd3a0aae2e87d3876e7bf0d8244dcffb457 |
>>
>> /home/test/autobuild/run/instance-2/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:17:2: error: #error This file was generated by an older version of protoc which is
>> #error This file was generated by an older version of protoc which is
>>
>> Sigh.
>>
>>> microblazeel | pango-1.44.6 | NOK | http://autobuild.buildroot.net/results/e5cfb968bc867d14f4ef4dd8da63b51360bc6808 | ORPH
>>
>> Static linking issue.
>>
>>> or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/25a594a74795bbccf5a218a6cd3b6804beac6e4d |
>>> or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/f0086358fd7bca5f2e77855c926641329e2e6ac8 |
>>> or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/079fd66a15dba75ed1ba70aec8708f35fb7e93fe |
>>> or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/f800a5f24cb4b23231165ad60c03bf177bad4a9f |
>>
>> /home/giuliobenetti/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752
>> /home/giuliobenetti/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752
>>
>> Giulio, I think you like toolchain issues! :-)
>
> Everyone has its particular tastes... :-)
> I take care about this and...
This is fixed by these:
https://patchwork.ozlabs.org/project/buildroot/list/?series=161548
>>> microblazeel | unknown | NOK | http://autobuild.buildroot.net/results/b92c1c09de74886c9039b3b76f35275f4e7a7b6c |
>>
>> Another funky toolchain issue:
>>
>> /home/giuliobenetti/autobuild/run/instance-3/output-1/per-package/x264/host/bin/../lib/gcc/microblazeel-buildroot-linux-uclibc/8.3.0/../../../../microblazeel-buildroot-linux-uclibc/bin/ld: FDE encoding in /home/giuliobenetti/autobuild/run/instance-3/output-1/per-package/x264/host/bin/../lib/gcc/microblazeel-buildroot-linux-uclibc/8.3.0/libgcc.a(_divdi3.o)(.eh_frame) prevents .eh_frame_hdr table being created
I can't reproduce this, any suggestions to make it trigger?
Thank you
Best regards
--
Giulio Benetti
Benetti Engineering sas
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2020-02-28 7:32 ` Romain Naour
@ 2020-02-28 15:02 ` Peter Seiderer
2020-02-29 21:15 ` Romain Naour
0 siblings, 1 reply; 38+ messages in thread
From: Peter Seiderer @ 2020-02-28 15:02 UTC (permalink / raw)
To: buildroot
Hello Romain,
On Fri, 28 Feb 2020 08:32:18 +0100, Romain Naour <romain.naour@gmail.com> wrote:
> >
> > > arm | mesa3d-19.3.4 | NOK |
> > http://autobuild.buildroot.net/results/6387b0a99e1a0922811919623d9a10b0943988df
> > |
> >
> > {standard input}: Assembler messages:
> > {standard input}:334: Error: selected processor does not support `vldm
> > r4,{q0,q1,q2,q3}' in ARM mode
> > {standard input}:335: Error: selected processor does not support `vst1.8
> > d0,[r3],r2' in ARM mode
> > {standard input}:336: Error: selected processor does not support `vst1.8
> > d1,[r3],r2' in ARM mode
> > {standard input}:337: Error: selected processor does not support `vst1.8
> > d2,[r3],r2' in ARM mode
> >
> > Bad stuff happens when building the vc4 driver. It probably needs some
> > minimal ARM architecture variant.
> >
>
> I believe we should re-add the dependency on neon for vc4 driver. There is
> -mfpu=neon added by the build system.
The BR2_ARM_CPU_HAS_NEON dependency was dropped with commit [1] because mesa3d
commit [2] added a compile time detected neon support, in the meantime this
was changed to a runtime detection [3] and finally enabled for the meson
cross compile build with commit [4] (assuming toolchain support for the
neon assembler instructions)...
Maybe the compile error could be fixed by re-adding partly the compile time
check for the neon support (tested):
--- mesa3d-19.3.4/src/broadcom/common/v3d_cpu_tiling.h_orig 2020-02-28 14:47:44.232634657 +0100
+++ mesa3d-19.3.4/src/broadcom/common/v3d_cpu_tiling.h 2020-02-28 14:49:21.518425222 +0100
@@ -31,7 +31,7 @@
v3d_load_utile(void *cpu, uint32_t cpu_stride,
void *gpu, uint32_t gpu_stride)
{
-#if defined(V3D_BUILD_NEON) && defined(PIPE_ARCH_ARM)
+#if defined(V3D_BUILD_NEON) && defined(__ARM_ARCH) && __ARM_ARCH >= 7
if (gpu_stride == 8) {
__asm__ volatile (
/* Load from the GPU in one shot, no interleave, to
@@ -141,7 +141,7 @@
v3d_store_utile(void *gpu, uint32_t gpu_stride,
void *cpu, uint32_t cpu_stride)
{
-#if defined(V3D_BUILD_NEON) && defined(PIPE_ARCH_ARM)
+#if defined(V3D_BUILD_NEON) && defined(__ARM_ARCH) && __ARM_ARCH >= 7
if (gpu_stride == 8) {
__asm__ volatile (
/* Load each 8-byte line from cpu-side source,
Regards,
Peter
[1] https://git.buildroot.net/buildroot/commit/package/mesa3d?id=350cb0d32ece533b9723a5f3ca6fbf7e6f071c90
[2] https://cgit.freedesktop.org/mesa/mesa/commit/?h=17.1&id=4d30024238efa829cabc72c1601beeee18c3dbf2
[3] https://cgit.freedesktop.org/mesa/mesa/commit/?h=staging/19.3&id=ece06defe77a77d2db40abeddee5a2e0e45654ce
[4] https://cgit.freedesktop.org/mesa/mesa/commit/?id=932ed9c00b99e6ec92146ec9e820f546cf3e6551
>
> Romain
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2020-02-27 23:18 ` Giulio Benetti
@ 2020-02-28 8:03 ` Thomas Petazzoni
2020-02-28 18:06 ` Giulio Benetti
1 sibling, 0 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2020-02-28 8:03 UTC (permalink / raw)
To: buildroot
On Fri, 28 Feb 2020 00:18:29 +0100
Giulio Benetti <giulio.benetti@benettiengineering.com> wrote:
> ... this too in 1-2 days at most.
Thanks!
> And as I?ve pointed libnss is waiting to be applied. Upstream almost applied it to, but we had a deal for PowerPC sys/auxv.h build failure.
Yes, I've seen you posted a new version of the patch.
> Btw did you all noticed an increase of NOK after adding the 2
> Micronova Autobuilders? They build fast but I don?t know in the
> complex how much they contribute.
You can see statistics over time at http://autobuild.buildroot.net/stats.php.
Bringing new builders doesn't really increase the number of failed
builds, but rather the overall number of builds. In the mean time, we
have fixed a number of build failures, which statistically reduces the
number of build failures overall.
I have also restarted builders on the Bootlin build server, gcc159 and
gcc160, so overall, we are getting quite a bit more of build results
compared to a few days ago.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2020-02-28 6:21 ` Heiko Thiery
2020-02-28 7:56 ` Sergio Prado
@ 2020-02-28 8:01 ` Thomas Petazzoni
1 sibling, 0 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2020-02-28 8:01 UTC (permalink / raw)
To: buildroot
Hello Heiko,
Thanks for looking into this!
On Fri, 28 Feb 2020 07:21:55 +0100
Heiko Thiery <heiko.thiery@gmail.com> wrote:
> > > arc | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/46c5cf068cf9ea50e53491870d9dbf3f134c8c22 |
> >
> > /home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/9.2.1/../../../../arc-buildroot-linux-uclibc/bin/ld: ../src/.libs/libgdiplus.so: undefined reference to `GifQuantizeBuffer'
> >
> > This is *not* a static linking issue.
>
> This is an issue coming with a newer giflib version
> (https://github.com/mono/libgdiplus/pull/575).
> Gitlib has remove the code used by libgdiplus version in buildroot.
> But in version 6.x of libgdiplus the commit
> https://github.com/mono/libgdiplus/commit/1c028b7087b27e62fff6dcf8e3240ce2b1a4ce7a
> included the missing fucntion from giflib.
>
>
> There are 2 options:
> 1) update libgdiplus to 6.x in buildroot (I dont know if it is
> possible with little effort)
> 2) backport the fix commit (unfortunatly the commit does not apply to
> the version used by buildroot)
>
> What do you think?
For master, a small backport is much more reasonable, if said backport
can easily be achieved.
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2020-02-28 6:21 ` Heiko Thiery
@ 2020-02-28 7:56 ` Sergio Prado
2020-02-28 8:01 ` Thomas Petazzoni
1 sibling, 0 replies; 38+ messages in thread
From: Sergio Prado @ 2020-02-28 7:56 UTC (permalink / raw)
To: buildroot
Hi Heiko, Thomas, and all:
Em sex., 28 de fev. de 2020 ?s 03:22, Heiko Thiery <heiko.thiery@gmail.com>
escreveu:
>
> Hi Thomas ,Sergio and all,
>
> > > arc | libgdiplus-5.6 | NOK |
http://autobuild.buildroot.net/results/46c5cf068cf9ea50e53491870d9dbf3f134c8c22
|
> >
> >
/home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/9.2.1/../../../../arc-buildroot-linux-uclibc/bin/ld:
../src/.libs/libgdiplus.so: undefined reference to `GifQuantizeBuffer'
> >
> > This is *not* a static linking issue.
>
> This is an issue coming with a newer giflib version
> (https://github.com/mono/libgdiplus/pull/575).
> Gitlib has remove the code used by libgdiplus version in buildroot.
> But in version 6.x of libgdiplus the commit
>
https://github.com/mono/libgdiplus/commit/1c028b7087b27e62fff6dcf8e3240ce2b1a4ce7a
> included the missing fucntion from giflib.
>
>
> There are 2 options:
> 1) update libgdiplus to 6.x in buildroot (I dont know if it is
> possible with little effort)
> 2) backport the fix commit (unfortunatly the commit does not apply to
> the version used by buildroot)
>
> What do you think?
I will bump to version 6.0.4, test it and send a patch.
Best regards,
Sergio Prado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200228/e5860a63/attachment.html>
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2020-02-27 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni
` (2 preceding siblings ...)
2020-02-28 6:21 ` Heiko Thiery
@ 2020-02-28 7:32 ` Romain Naour
2020-02-28 15:02 ` Peter Seiderer
3 siblings, 1 reply; 38+ messages in thread
From: Romain Naour @ 2020-02-28 7:32 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Le jeu. 27 f?vr. 2020 ? 23:49, Thomas Petazzoni <
thomas.petazzoni@bootlin.com> a ?crit :
> Hello,
>
> Here is an analysis of yesterday's build failures. Please have a look
> and help!
>
> On Thu, 27 Feb 2020 09:31:33 -0000
> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
>
> > arch | reason | OK? |
> url | orph?
> >
> -------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
> > microblazeel | bash-5.0 | NOK |
> http://autobuild.buildroot.net/results/c4bc6cc208e94ffb84caaea03c4898a3001c7f9a
> | ORPH
>
> Would be fixed by http://patchwork.ozlabs.org/patch/1242647/, but I'm
> personally not entirely sure about this patch.
>
> > arc | bitcoin-0.19.0.1 | NOK |
> http://autobuild.buildroot.net/results/f4821f44ceb2811e9ab160dd2cb886243215df52
> |
> > arc | bitcoin-0.19.0.1 | NOK |
> http://autobuild.buildroot.net/results/f3ac50c32c7e4fd3a5e9e3dd4170b0799a26270b
> |
>
> undefined reference to
> `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)'
>
> According to http://autobuild.buildroot.net/?reason=bitcoin%, this only
> happens on the ARC architecture.
>
> ARC maintainers, any idea ?
>
> > mips64el | brltty-6.0 | NOK |
> http://autobuild.buildroot.net/results/4569cbbe97ab9057e5e3909a03540544d588a479
> |
> > sparc | brltty-6.0 | NOK |
> http://autobuild.buildroot.net/results/71fdd490873809acd89d7b3e3ea27e88c5b62c24
> |
> > xtensa | brltty-6.0 | NOK |
> http://autobuild.buildroot.net/results/caa1041217f8b2bc835dd6a06c13d59f70f72caa
> |
> > arc | brltty-6.0 | NOK |
> http://autobuild.buildroot.net/results/a05dee0491871bdd7d0a8f53d96e7971f7c71d1a
> |
> > arc | brltty-6.0 | NOK |
> http://autobuild.buildroot.net/results/a8edb5621ecc2d250f572240b0607762735b0ffb
> |
> > sparc | brltty-6.0 | NOK |
> http://autobuild.buildroot.net/results/1c6d8e80974547c48f6a4c9d2ff43b9ba268a2aa
> |
> > arm | brltty-6.0 | NOK |
> http://autobuild.buildroot.net/results/7d8ccf9cc8559db9aed19bf32e6cb342141bd360
> |
>
> Fixed by
> https://git.buildroot.org/buildroot/commit/?id=7bed3ee409661107b6ce2a05c48adcc7f79258fa
> .
>
> > xtensa | domoticz-0f411f781ae4fb4a82... | NOK |
> http://autobuild.buildroot.net/results/7885705f1b1c0f31cf21b464150f5509929c1906
> |
>
> Toolchain issue:
>
> BFD (GNU Binutils) 2.31.1 internal error, aborting at elf32-xtensa.c:3283
> in elf_xtensa_finish_dynamic_sections
>
> Max, any idea ?
>
> > m68k | dvdauthor-0.7.2 | NOK |
> http://autobuild.buildroot.net/results/9c7f4f22386d4ffd211ed62da323f9861f1b1716
> |
>
> elf2flt issue, Romain has posted a series to avoid it.
>
> > arm | fail2ban-0.11.1 | NOK |
> http://autobuild.buildroot.net/results/4b16c925a0aa0aba073324e2c3a4297c456b55bd
> |
>
> I would assume fixed by
>
> https://git.buildroot.org/buildroot/commit/?id=bdc9364ffae64623158830698a4f84fb2a179910
> .
>
> > riscv64 | gerbera-1.3.4 | NOK |
> http://autobuild.buildroot.net/results/b499442a920dd3969e2beb2099504d33641b4980
> |
>
> /home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld:
> cannot find /lib64/libc.so.6
> /home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld:
> cannot find /usr/lib/libc_nonshared.a
> /home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld:
> cannot find /lib/ld-linux-riscv64-lp64d.so.1
>
> This is a per-package directory build issue I believe.
>
> > xtensa | gst1-plugins-base-1.16.2 | NOK |
> http://autobuild.buildroot.net/results/42cbc33ded6cf04f5cb2edb105f2e561d06886ff
> |
>
> /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/xtensa-buildroot-linux-uclibc/8.3.0/../../../../xtensa-buildroot-linux-uclibc/bin/ld:
> gstplugin.c:(.text+0xb58): undefined reference to `g_module_open'
> /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/xtensa-buildroot-linux-uclibc/8.3.0/../../../../xtensa-buildroot-linux-uclibc/bin/ld:
> gstplugin.c:(.text+0xb5c): undefined reference to `g_module_error'
>
> static linking issue. Any brave meson/gstreamer person in the house ?
> Adam ? :-)
>
> > mips64el | host-go-1.13.8 | NOK |
> http://autobuild.buildroot.net/results/fa13a054995d6060d2dc15c36007e41a50ed7fc4
> |
>
> Some funky toolchain issue:
>
> /data/buildroot/buildroot-test/instance-0/output/build/host-go-1.13.8/pkg/tool/linux_amd64/link:
> running
> /data/buildroot/buildroot-test/instance-0/output/host/bin/mips64el-linux-gcc
> failed: exit status 1
> collect2: fatal error: ld terminated with signal 11 [Segmentation fault],
> core dumped
> compilation terminated.
> /data/buildroot/buildroot-test/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64el-buildroot-linux-uclibc/5.5.0/../../../../mips64el-buildroot-linux-uclibc/bin/ld:
> /tmp/go-link-130627779/go.o: relocation R_MIPS_26 against `a local symbol'
> can not be used when making a shared object; recompile with -fPIC
> /data/buildroot/buildroot-test/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64el-buildroot-linux-uclibc/5.5.0/../../../../mips64el-buildroot-linux-uclibc/bin/ld:
> BFD (GNU Binutils) 2.31.1 assertion fail elfxx-mips.c:6550
>
> > mips64el | host-grpc-1.25.0 | NOK |
> http://autobuild.buildroot.net/results/4f853af32b5c09e63896e2125b5d018d279c0951
> |
>
> Yann's machine still exhibiting this weird issue.
>
> > aarch64 | host-nodejs-12.16.0 | NOK |
> http://autobuild.buildroot.net/results/a83acd958d177a47ea2b1ca94b8a163da3e4a2c5
> |
> > arm | host-nodejs-12.16.0 | NOK |
> http://autobuild.buildroot.net/results/c7934318c29b9dce9062d93158906409c5229a6d
> |
>
> Would be fixed by http://patchwork.ozlabs.org/patch/1239736/, but I
> don't like the fact that package A refers to package B build directory.
>
> > arc | libgdiplus-5.6 | NOK |
> http://autobuild.buildroot.net/results/46c5cf068cf9ea50e53491870d9dbf3f134c8c22
> |
>
> /home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/9.2.1/../../../../arc-buildroot-linux-uclibc/bin/ld:
> ../src/.libs/libgdiplus.so: undefined reference to `GifQuantizeBuffer'
>
> This is *not* a static linking issue.
>
> > m68k | libopenssl-1.1.1d | NOK |
> http://autobuild.buildroot.net/results/686b92af36ec691dd06078c18df21f59209bea06
> |
>
> elf2flt mess.
>
> > sparc64 | lxc-3.2.1 | NOK |
> http://autobuild.buildroot.net/results/94d021c513569cf4062619127ec2262d30b3201f
> |
>
> error: [m [Kinvalid 'asm': invalid operand output code
>
> J?r?me, you are listed as the lxc package developer, could you have a
> look ?
>
>
> > arm | mesa3d-19.3.4 | NOK |
> http://autobuild.buildroot.net/results/6387b0a99e1a0922811919623d9a10b0943988df
> |
>
> {standard input}: Assembler messages:
> {standard input}:334: Error: selected processor does not support `vldm
> r4,{q0,q1,q2,q3}' in ARM mode
> {standard input}:335: Error: selected processor does not support `vst1.8
> d0,[r3],r2' in ARM mode
> {standard input}:336: Error: selected processor does not support `vst1.8
> d1,[r3],r2' in ARM mode
> {standard input}:337: Error: selected processor does not support `vst1.8
> d2,[r3],r2' in ARM mode
>
> Bad stuff happens when building the vc4 driver. It probably needs some
> minimal ARM architecture variant.
>
I believe we should re-add the dependency on neon for vc4 driver. There is
-mfpu=neon added by the build system.
Romain
> > powerpc | mimic-1.1.0 | NOK |
> http://autobuild.buildroot.net/results/ddb1c83ede34c125296563227f6b8f4b76729480
> |
>
> /home/giuliobenetti/autobuild/run/instance-0/output-1/host/lib/gcc/powerpc-buildroot-linux-uclibc/8.3.0/crtbeginS.o:
> in function `__do_global_dtors_aux':
> crtstuff.c:(.text+0x13c): relocation truncated to fit: R_PPC_PLTREL24
> against symbol `__cxa_finalize' defined in .text section in
> /home/giuliobenetti/autobuild/run/instance-0/output-1/host/powerpc-buildroot-linux-uclibc/sysroot/lib/libc.so.1
> collect2: error: ld returned 1 exit status
>
> > m68k | mimic-1.1.0 | NOK |
> http://autobuild.buildroot.net/results/1a0caff18be6d55395c40f4d9f04076b03122757
> |
>
> elf2flt mess.
>
> > arm | minicom-52b626b15a883b03006... | NOK |
> http://autobuild.buildroot.net/results/d3edbab1f2cd0f7b790e2559dc8d489497ae02f3
> |
>
> Fixed by
> https://git.buildroot.org/buildroot/commit/?id=acbae76d6977b1f2d3847ea379c7dd8f1761f565
> .
>
> > x86_64 | mongodb-r4.0.12 | NOK |
> http://autobuild.buildroot.net/results/80a0d9dc59567c28b891c50c63280cea3aad613f
> |
>
> src/mongo/util/heap_profiler.cpp:484:33: error: 'abi' has not been declared
>
> > arm | mongodb-r4.0.12 | NOK |
> http://autobuild.buildroot.net/results/5765e33f444a22701b055015ed41436d3526e9eb
> |
>
> /home/test/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-linux-gnueabihf/7.3.1/../../../../arm-linux-gnueabihf/bin/ld.gold:
> error:
> /home/test/autobuild/run/instance-1/output-1/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libyaml-cpp.a(null.cpp.o):
> requires unsupported dynamic reloc R_ARM_MOVW_ABS_NC; recompile with -fPIC
>
> > aarch64_be | opencv3-3.4.9 | NOK |
> http://autobuild.buildroot.net/results/3938ecd3a0aae2e87d3876e7bf0d8244dcffb457
> |
>
> /home/test/autobuild/run/instance-2/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:17:2:
> error: #error This file was generated by an older version of protoc which is
> #error This file was generated by an older version of protoc which is
>
> Sigh.
>
> > microblazeel | pango-1.44.6 | NOK |
> http://autobuild.buildroot.net/results/e5cfb968bc867d14f4ef4dd8da63b51360bc6808
> | ORPH
>
> Static linking issue.
>
> > or1k | protobuf-3.11.0 | NOK |
> http://autobuild.buildroot.net/results/25a594a74795bbccf5a218a6cd3b6804beac6e4d
> |
> > or1k | protobuf-3.11.0 | NOK |
> http://autobuild.buildroot.net/results/f0086358fd7bca5f2e77855c926641329e2e6ac8
> |
> > or1k | protobuf-3.11.0 | NOK |
> http://autobuild.buildroot.net/results/079fd66a15dba75ed1ba70aec8708f35fb7e93fe
> |
> > or1k | protobuf-3.11.0 | NOK |
> http://autobuild.buildroot.net/results/f800a5f24cb4b23231165ad60c03bf177bad4a9f
> |
>
> /home/giuliobenetti/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
> BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752
> /home/giuliobenetti/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
> BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752
>
> Giulio, I think you like toolchain issues! :-)
>
> > powerpc | qpdf-9.1.1 | NOK |
> http://autobuild.buildroot.net/results/c57fccab2e644b4b97971e9961682fac96f00a5c
> |
>
> libtool: error: 'libqpdf/build/QUtil.lo' is not a valid libtool object
>
> Not sure. Parallel build issue ?
>
> > m68k | qpdf-9.1.1 | NOK |
> http://autobuild.buildroot.net/results/1e2299df96a2ddea22907870b6571553c5e7f7ef
> |
>
> elf2flt mess.
>
> > arm | qt5svg-5.12.7 | NOK |
> http://autobuild.buildroot.net/results/1c957888ba8f6124f093f96653035c8db2fc37ca
> |
>
> per-package directory issue known, due to qt5
>
> > arm | rocksdb-6.6.4 | NOK |
> http://autobuild.buildroot.net/results/832e1c85ee5ff79c74e84536ce09a66befe14c39
> |
> > arm | rocksdb-6.6.4 | NOK |
> http://autobuild.buildroot.net/results/cdf9f3435e9526eee12bbf036d333c82323d24ba
> |
>
> Would be fixed by http://patchwork.ozlabs.org/patch/1243001/.
>
> > microblazeel | unknown | NOK |
> http://autobuild.buildroot.net/results/b92c1c09de74886c9039b3b76f35275f4e7a7b6c
> |
>
> Another funky toolchain issue:
>
> /home/giuliobenetti/autobuild/run/instance-3/output-1/per-package/x264/host/bin/../lib/gcc/microblazeel-buildroot-linux-uclibc/8.3.0/../../../../microblazeel-buildroot-linux-uclibc/bin/ld:
> FDE encoding in
> /home/giuliobenetti/autobuild/run/instance-3/output-1/per-package/x264/host/bin/../lib/gcc/microblazeel-buildroot-linux-uclibc/8.3.0/libgcc.a(_divdi3.o)(.eh_frame)
> prevents .eh_frame_hdr table being created
>
> > i686 | unknown | NOK |
> http://autobuild.buildroot.net/results/cdee1d3a823238be39f1d0bc6eb3498633b25865
> |
>
> Probably a top-level parallel build issue.
>
> > arm | unknown | NOK |
> http://autobuild.buildroot.net/results/4e60fa31b1cd08bc7fdf9c5dd3a3f4941e029ba3
> |
>
> Top-level parallel build issue that is fixed by my rework of the
> installed file list collection logic:
>
> mv: cannot stat
> '/home/giuliobenetti/autobuild/run/instance-0/output-1/build/.files-list-staging.new':
> No such file or directory
>
>
> > microblazeel | unknown | NOK |
> http://autobuild.buildroot.net/results/8466f1798cad365040ba6a5359fac30aafc82a60
> |
>
> Reproducible build issue in:
>
> - getconf
> - rpm
>
> > x86_64 | unknown | NOK |
> http://autobuild.buildroot.net/results/deb862bed384296c2a6f119f63d4174cacb823d9
> |
>
> Probably another top-level parallel build issue.
>
> > arm | unknown | NOK |
> http://autobuild.buildroot.net/results/4ce1704d3fc60fd3dec1d06b9031fb674b2236e3
> |
>
> Fixed by my rework of the installed file collection logic:
>
> comm: /home/naourr/work/instance-1/output-1/build/.files-list-staging.new:
> No such file or directory
>
>
> > riscv64 | vlc-3.0.8 | NOK |
> http://autobuild.buildroot.net/results/e8fd34f3b9b7166772e04d3e15c478990d07d894
> |
> > riscv32 | vlc-3.0.8 | NOK |
> http://autobuild.buildroot.net/results/a61819381ff8dc59b1cf20338df6b6a49f63e0c0
> |
> > i586 | vlc-3.0.8 | NOK |
> http://autobuild.buildroot.net/results/f11e2f24b998ac68891ab58a2bcf7b8677801767
> |
>
> video_filter/opencv_example.cpp:200:46: error: could not convert
> 'cv::Scalar_<double>((double)0, (double)0, (double)0, (double)0)' from
> 'cv::Scalar' {aka 'cv::Scalar_<double>'} to 'CvScalar'
> cvRectangle( p_img[0], pt1, pt2, CV_RGB(0,0,0), 3, 8, 0 );
>
> Bernd, you are in charge of vlc, could you have a look ?
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200228/9e0f3691/attachment.html>
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2020-02-27 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni
2020-02-27 23:06 ` Max Filippov
2020-02-27 23:18 ` Giulio Benetti
@ 2020-02-28 6:21 ` Heiko Thiery
2020-02-28 7:56 ` Sergio Prado
2020-02-28 8:01 ` Thomas Petazzoni
2020-02-28 7:32 ` Romain Naour
3 siblings, 2 replies; 38+ messages in thread
From: Heiko Thiery @ 2020-02-28 6:21 UTC (permalink / raw)
To: buildroot
Hi Thomas ,Sergio and all,
> > arc | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/46c5cf068cf9ea50e53491870d9dbf3f134c8c22 |
>
> /home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/9.2.1/../../../../arc-buildroot-linux-uclibc/bin/ld: ../src/.libs/libgdiplus.so: undefined reference to `GifQuantizeBuffer'
>
> This is *not* a static linking issue.
This is an issue coming with a newer giflib version
(https://github.com/mono/libgdiplus/pull/575).
Gitlib has remove the code used by libgdiplus version in buildroot.
But in version 6.x of libgdiplus the commit
https://github.com/mono/libgdiplus/commit/1c028b7087b27e62fff6dcf8e3240ce2b1a4ce7a
included the missing fucntion from giflib.
There are 2 options:
1) update libgdiplus to 6.x in buildroot (I dont know if it is
possible with little effort)
2) backport the fix commit (unfortunatly the commit does not apply to
the version used by buildroot)
What do you think?
--
Heiko
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2020-02-27 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni
2020-02-27 23:06 ` Max Filippov
@ 2020-02-27 23:18 ` Giulio Benetti
2020-02-28 8:03 ` Thomas Petazzoni
2020-02-28 18:06 ` Giulio Benetti
2020-02-28 6:21 ` Heiko Thiery
2020-02-28 7:32 ` Romain Naour
3 siblings, 2 replies; 38+ messages in thread
From: Giulio Benetti @ 2020-02-27 23:18 UTC (permalink / raw)
To: buildroot
Hello,
Inviato da iPhone
> Il giorno 27 feb 2020, alle ore 23:49, Thomas Petazzoni <thomas.petazzoni@bootlin.com> ha scritto:
>
> ?Hello,
>
> Here is an analysis of yesterday's build failures. Please have a look
> and help!
>
>> On Thu, 27 Feb 2020 09:31:33 -0000
>> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
>>
>> arch | reason | OK? | url | orph?
>> -------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
>> microblazeel | bash-5.0 | NOK | http://autobuild.buildroot.net/results/c4bc6cc208e94ffb84caaea03c4898a3001c7f9a | ORPH
>
> Would be fixed by http://patchwork.ozlabs.org/patch/1242647/, but I'm
> personally not entirely sure about this patch.
>
>> arc | bitcoin-0.19.0.1 | NOK | http://autobuild.buildroot.net/results/f4821f44ceb2811e9ab160dd2cb886243215df52 |
>> arc | bitcoin-0.19.0.1 | NOK | http://autobuild.buildroot.net/results/f3ac50c32c7e4fd3a5e9e3dd4170b0799a26270b |
>
> undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)'
>
> According to http://autobuild.buildroot.net/?reason=bitcoin%, this only
> happens on the ARC architecture.
>
> ARC maintainers, any idea ?
>
>> mips64el | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/4569cbbe97ab9057e5e3909a03540544d588a479 |
>> sparc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/71fdd490873809acd89d7b3e3ea27e88c5b62c24 |
>> xtensa | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/caa1041217f8b2bc835dd6a06c13d59f70f72caa |
>> arc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/a05dee0491871bdd7d0a8f53d96e7971f7c71d1a |
>> arc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/a8edb5621ecc2d250f572240b0607762735b0ffb |
>> sparc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/1c6d8e80974547c48f6a4c9d2ff43b9ba268a2aa |
>> arm | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/7d8ccf9cc8559db9aed19bf32e6cb342141bd360 |
>
> Fixed by https://git.buildroot.org/buildroot/commit/?id=7bed3ee409661107b6ce2a05c48adcc7f79258fa.
>
>> xtensa | domoticz-0f411f781ae4fb4a82... | NOK | http://autobuild.buildroot.net/results/7885705f1b1c0f31cf21b464150f5509929c1906 |
>
> Toolchain issue:
>
> BFD (GNU Binutils) 2.31.1 internal error, aborting at elf32-xtensa.c:3283 in elf_xtensa_finish_dynamic_sections
>
> Max, any idea ?
>
>> m68k | dvdauthor-0.7.2 | NOK | http://autobuild.buildroot.net/results/9c7f4f22386d4ffd211ed62da323f9861f1b1716 |
>
> elf2flt issue, Romain has posted a series to avoid it.
>
>> arm | fail2ban-0.11.1 | NOK | http://autobuild.buildroot.net/results/4b16c925a0aa0aba073324e2c3a4297c456b55bd |
>
> I would assume fixed by
> https://git.buildroot.org/buildroot/commit/?id=bdc9364ffae64623158830698a4f84fb2a179910.
>
>> riscv64 | gerbera-1.3.4 | NOK | http://autobuild.buildroot.net/results/b499442a920dd3969e2beb2099504d33641b4980 |
>
> /home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: cannot find /lib64/libc.so.6
> /home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: cannot find /usr/lib/libc_nonshared.a
> /home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: cannot find /lib/ld-linux-riscv64-lp64d.so.1
>
> This is a per-package directory build issue I believe.
>
>> xtensa | gst1-plugins-base-1.16.2 | NOK | http://autobuild.buildroot.net/results/42cbc33ded6cf04f5cb2edb105f2e561d06886ff |
>
> /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/xtensa-buildroot-linux-uclibc/8.3.0/../../../../xtensa-buildroot-linux-uclibc/bin/ld: gstplugin.c:(.text+0xb58): undefined reference to `g_module_open'
> /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/xtensa-buildroot-linux-uclibc/8.3.0/../../../../xtensa-buildroot-linux-uclibc/bin/ld: gstplugin.c:(.text+0xb5c): undefined reference to `g_module_error'
>
> static linking issue. Any brave meson/gstreamer person in the house ?
> Adam ? :-)
>
>> mips64el | host-go-1.13.8 | NOK | http://autobuild.buildroot.net/results/fa13a054995d6060d2dc15c36007e41a50ed7fc4 |
>
> Some funky toolchain issue:
>
> /data/buildroot/buildroot-test/instance-0/output/build/host-go-1.13.8/pkg/tool/linux_amd64/link: running /data/buildroot/buildroot-test/instance-0/output/host/bin/mips64el-linux-gcc failed: exit status 1
> collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped
> compilation terminated.
> /data/buildroot/buildroot-test/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64el-buildroot-linux-uclibc/5.5.0/../../../../mips64el-buildroot-linux-uclibc/bin/ld: /tmp/go-link-130627779/go.o: relocation R_MIPS_26 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
> /data/buildroot/buildroot-test/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64el-buildroot-linux-uclibc/5.5.0/../../../../mips64el-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elfxx-mips.c:6550
>
>> mips64el | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/4f853af32b5c09e63896e2125b5d018d279c0951 |
>
> Yann's machine still exhibiting this weird issue.
>
>> aarch64 | host-nodejs-12.16.0 | NOK | http://autobuild.buildroot.net/results/a83acd958d177a47ea2b1ca94b8a163da3e4a2c5 |
>> arm | host-nodejs-12.16.0 | NOK | http://autobuild.buildroot.net/results/c7934318c29b9dce9062d93158906409c5229a6d |
>
> Would be fixed by http://patchwork.ozlabs.org/patch/1239736/, but I
> don't like the fact that package A refers to package B build directory.
>
>> arc | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/46c5cf068cf9ea50e53491870d9dbf3f134c8c22 |
>
> /home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/9.2.1/../../../../arc-buildroot-linux-uclibc/bin/ld: ../src/.libs/libgdiplus.so: undefined reference to `GifQuantizeBuffer'
>
> This is *not* a static linking issue.
>
>> m68k | libopenssl-1.1.1d | NOK | http://autobuild.buildroot.net/results/686b92af36ec691dd06078c18df21f59209bea06 |
>
> elf2flt mess.
>
>> sparc64 | lxc-3.2.1 | NOK | http://autobuild.buildroot.net/results/94d021c513569cf4062619127ec2262d30b3201f |
>
> error: ^[[m^[[Kinvalid 'asm': invalid operand output code
>
> J?r?me, you are listed as the lxc package developer, could you have a
> look ?
>
>
>> arm | mesa3d-19.3.4 | NOK | http://autobuild.buildroot.net/results/6387b0a99e1a0922811919623d9a10b0943988df |
>
> {standard input}: Assembler messages:
> {standard input}:334: Error: selected processor does not support `vldm r4,{q0,q1,q2,q3}' in ARM mode
> {standard input}:335: Error: selected processor does not support `vst1.8 d0,[r3],r2' in ARM mode
> {standard input}:336: Error: selected processor does not support `vst1.8 d1,[r3],r2' in ARM mode
> {standard input}:337: Error: selected processor does not support `vst1.8 d2,[r3],r2' in ARM mode
>
> Bad stuff happens when building the vc4 driver. It probably needs some
> minimal ARM architecture variant.
>
>> powerpc | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/ddb1c83ede34c125296563227f6b8f4b76729480 |
>
> /home/giuliobenetti/autobuild/run/instance-0/output-1/host/lib/gcc/powerpc-buildroot-linux-uclibc/8.3.0/crtbeginS.o: in function `__do_global_dtors_aux':
> crtstuff.c:(.text+0x13c): relocation truncated to fit: R_PPC_PLTREL24 against symbol `__cxa_finalize' defined in .text section in /home/giuliobenetti/autobuild/run/instance-0/output-1/host/powerpc-buildroot-linux-uclibc/sysroot/lib/libc.so.1
> collect2: error: ld returned 1 exit status
>
>> m68k | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/1a0caff18be6d55395c40f4d9f04076b03122757 |
>
> elf2flt mess.
>
>> arm | minicom-52b626b15a883b03006... | NOK | http://autobuild.buildroot.net/results/d3edbab1f2cd0f7b790e2559dc8d489497ae02f3 |
>
> Fixed by https://git.buildroot.org/buildroot/commit/?id=acbae76d6977b1f2d3847ea379c7dd8f1761f565.
>
>> x86_64 | mongodb-r4.0.12 | NOK | http://autobuild.buildroot.net/results/80a0d9dc59567c28b891c50c63280cea3aad613f |
>
> src/mongo/util/heap_profiler.cpp:484:33: error: 'abi' has not been declared
>
>> arm | mongodb-r4.0.12 | NOK | http://autobuild.buildroot.net/results/5765e33f444a22701b055015ed41436d3526e9eb |
>
> /home/test/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-linux-gnueabihf/7.3.1/../../../../arm-linux-gnueabihf/bin/ld.gold: error: /home/test/autobuild/run/instance-1/output-1/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libyaml-cpp.a(null.cpp.o): requires unsupported dynamic reloc R_ARM_MOVW_ABS_NC; recompile with -fPIC
>
>> aarch64_be | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/3938ecd3a0aae2e87d3876e7bf0d8244dcffb457 |
>
> /home/test/autobuild/run/instance-2/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:17:2: error: #error This file was generated by an older version of protoc which is
> #error This file was generated by an older version of protoc which is
>
> Sigh.
>
>> microblazeel | pango-1.44.6 | NOK | http://autobuild.buildroot.net/results/e5cfb968bc867d14f4ef4dd8da63b51360bc6808 | ORPH
>
> Static linking issue.
>
>> or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/25a594a74795bbccf5a218a6cd3b6804beac6e4d |
>> or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/f0086358fd7bca5f2e77855c926641329e2e6ac8 |
>> or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/079fd66a15dba75ed1ba70aec8708f35fb7e93fe |
>> or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/f800a5f24cb4b23231165ad60c03bf177bad4a9f |
>
> /home/giuliobenetti/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752
> /home/giuliobenetti/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752
>
> Giulio, I think you like toolchain issues! :-)
Everyone has its particular tastes... :-)
I take care about this and...
>
>> powerpc | qpdf-9.1.1 | NOK | http://autobuild.buildroot.net/results/c57fccab2e644b4b97971e9961682fac96f00a5c |
>
> libtool: error: 'libqpdf/build/QUtil.lo' is not a valid libtool object
>
> Not sure. Parallel build issue ?
>
>> m68k | qpdf-9.1.1 | NOK | http://autobuild.buildroot.net/results/1e2299df96a2ddea22907870b6571553c5e7f7ef |
>
> elf2flt mess.
>
>> arm | qt5svg-5.12.7 | NOK | http://autobuild.buildroot.net/results/1c957888ba8f6124f093f96653035c8db2fc37ca |
>
> per-package directory issue known, due to qt5
>
>> arm | rocksdb-6.6.4 | NOK | http://autobuild.buildroot.net/results/832e1c85ee5ff79c74e84536ce09a66befe14c39 |
>> arm | rocksdb-6.6.4 | NOK | http://autobuild.buildroot.net/results/cdf9f3435e9526eee12bbf036d333c82323d24ba |
>
> Would be fixed by http://patchwork.ozlabs.org/patch/1243001/.
>
>> microblazeel | unknown | NOK | http://autobuild.buildroot.net/results/b92c1c09de74886c9039b3b76f35275f4e7a7b6c |
>
> Another funky toolchain issue:
>
> /home/giuliobenetti/autobuild/run/instance-3/output-1/per-package/x264/host/bin/../lib/gcc/microblazeel-buildroot-linux-uclibc/8.3.0/../../../../microblazeel-buildroot-linux-uclibc/bin/ld: FDE encoding in /home/giuliobenetti/autobuild/run/instance-3/output-1/per-package/x264/host/bin/../lib/gcc/microblazeel-buildroot-linux-uclibc/8.3.0/libgcc.a(_divdi3.o)(.eh_frame) prevents .eh_frame_hdr table being created
... this too in 1-2 days at most.
And as I?ve pointed libnss is waiting to be applied. Upstream almost applied it to, but we had a deal for PowerPC sys/auxv.h build failure.
Btw did you all noticed an increase of NOK after adding the 2 Micronova Autobuilders? They build fast but I don?t know in the complex how much they contribute.
Best regards!
Giulio Benetti
>
>> i686 | unknown | NOK | http://autobuild.buildroot.net/results/cdee1d3a823238be39f1d0bc6eb3498633b25865 |
>
> Probably a top-level parallel build issue.
>
>> arm | unknown | NOK | http://autobuild.buildroot.net/results/4e60fa31b1cd08bc7fdf9c5dd3a3f4941e029ba3 |
>
> Top-level parallel build issue that is fixed by my rework of the
> installed file list collection logic:
>
> mv: cannot stat '/home/giuliobenetti/autobuild/run/instance-0/output-1/build/.files-list-staging.new': No such file or directory
>
>
>> microblazeel | unknown | NOK | http://autobuild.buildroot.net/results/8466f1798cad365040ba6a5359fac30aafc82a60 |
>
> Reproducible build issue in:
>
> - getconf
> - rpm
>
>> x86_64 | unknown | NOK | http://autobuild.buildroot.net/results/deb862bed384296c2a6f119f63d4174cacb823d9 |
>
> Probably another top-level parallel build issue.
>
>> arm | unknown | NOK | http://autobuild.buildroot.net/results/4ce1704d3fc60fd3dec1d06b9031fb674b2236e3 |
>
> Fixed by my rework of the installed file collection logic:
>
> comm: /home/naourr/work/instance-1/output-1/build/.files-list-staging.new: No such file or directory
>
>
>> riscv64 | vlc-3.0.8 | NOK | http://autobuild.buildroot.net/results/e8fd34f3b9b7166772e04d3e15c478990d07d894 |
>> riscv32 | vlc-3.0.8 | NOK | http://autobuild.buildroot.net/results/a61819381ff8dc59b1cf20338df6b6a49f63e0c0 |
>> i586 | vlc-3.0.8 | NOK | http://autobuild.buildroot.net/results/f11e2f24b998ac68891ab58a2bcf7b8677801767 |
>
> video_filter/opencv_example.cpp:200:46: error: could not convert 'cv::Scalar_<double>((double)0, (double)0, (double)0, (double)0)' from 'cv::Scalar' {aka 'cv::Scalar_<double>'} to 'CvScalar'
> cvRectangle( p_img[0], pt1, pt2, CV_RGB(0,0,0), 3, 8, 0 );
>
> Bernd, you are in charge of vlc, could you have a look ?
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2020-02-27 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni
@ 2020-02-27 23:06 ` Max Filippov
2020-02-27 23:18 ` Giulio Benetti
` (2 subsequent siblings)
3 siblings, 0 replies; 38+ messages in thread
From: Max Filippov @ 2020-02-27 23:06 UTC (permalink / raw)
To: buildroot
On Thu, Feb 27, 2020 at 2:49 PM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> > xtensa | domoticz-0f411f781ae4fb4a82... | NOK | http://autobuild.buildroot.net/results/7885705f1b1c0f31cf21b464150f5509929c1906 |
>
> Toolchain issue:
>
> BFD (GNU Binutils) 2.31.1 internal error, aborting at elf32-xtensa.c:3283 in elf_xtensa_finish_dynamic_sections
>
> Max, any idea ?
Looking at it, thanks for the heads up!
--
Thanks.
-- Max
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2020-02-27 9:31 [Buildroot] [autobuild.buildroot.net] Daily results for 2020-02-26 Thomas Petazzoni
@ 2020-02-27 22:49 ` Thomas Petazzoni
2020-02-27 23:06 ` Max Filippov
` (3 more replies)
0 siblings, 4 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2020-02-27 22:49 UTC (permalink / raw)
To: buildroot
Hello,
Here is an analysis of yesterday's build failures. Please have a look
and help!
On Thu, 27 Feb 2020 09:31:33 -0000
Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> arch | reason | OK? | url | orph?
> -------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
> microblazeel | bash-5.0 | NOK | http://autobuild.buildroot.net/results/c4bc6cc208e94ffb84caaea03c4898a3001c7f9a | ORPH
Would be fixed by http://patchwork.ozlabs.org/patch/1242647/, but I'm
personally not entirely sure about this patch.
> arc | bitcoin-0.19.0.1 | NOK | http://autobuild.buildroot.net/results/f4821f44ceb2811e9ab160dd2cb886243215df52 |
> arc | bitcoin-0.19.0.1 | NOK | http://autobuild.buildroot.net/results/f3ac50c32c7e4fd3a5e9e3dd4170b0799a26270b |
undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)'
According to http://autobuild.buildroot.net/?reason=bitcoin%, this only
happens on the ARC architecture.
ARC maintainers, any idea ?
> mips64el | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/4569cbbe97ab9057e5e3909a03540544d588a479 |
> sparc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/71fdd490873809acd89d7b3e3ea27e88c5b62c24 |
> xtensa | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/caa1041217f8b2bc835dd6a06c13d59f70f72caa |
> arc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/a05dee0491871bdd7d0a8f53d96e7971f7c71d1a |
> arc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/a8edb5621ecc2d250f572240b0607762735b0ffb |
> sparc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/1c6d8e80974547c48f6a4c9d2ff43b9ba268a2aa |
> arm | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/7d8ccf9cc8559db9aed19bf32e6cb342141bd360 |
Fixed by https://git.buildroot.org/buildroot/commit/?id=7bed3ee409661107b6ce2a05c48adcc7f79258fa.
> xtensa | domoticz-0f411f781ae4fb4a82... | NOK | http://autobuild.buildroot.net/results/7885705f1b1c0f31cf21b464150f5509929c1906 |
Toolchain issue:
BFD (GNU Binutils) 2.31.1 internal error, aborting at elf32-xtensa.c:3283 in elf_xtensa_finish_dynamic_sections
Max, any idea ?
> m68k | dvdauthor-0.7.2 | NOK | http://autobuild.buildroot.net/results/9c7f4f22386d4ffd211ed62da323f9861f1b1716 |
elf2flt issue, Romain has posted a series to avoid it.
> arm | fail2ban-0.11.1 | NOK | http://autobuild.buildroot.net/results/4b16c925a0aa0aba073324e2c3a4297c456b55bd |
I would assume fixed by
https://git.buildroot.org/buildroot/commit/?id=bdc9364ffae64623158830698a4f84fb2a179910.
> riscv64 | gerbera-1.3.4 | NOK | http://autobuild.buildroot.net/results/b499442a920dd3969e2beb2099504d33641b4980 |
/home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: cannot find /lib64/libc.so.6
/home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: cannot find /usr/lib/libc_nonshared.a
/home/buildroot/autobuild/instance-3/output-1/per-package/gerbera/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-gnu/8.3.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: cannot find /lib/ld-linux-riscv64-lp64d.so.1
This is a per-package directory build issue I believe.
> xtensa | gst1-plugins-base-1.16.2 | NOK | http://autobuild.buildroot.net/results/42cbc33ded6cf04f5cb2edb105f2e561d06886ff |
/home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/xtensa-buildroot-linux-uclibc/8.3.0/../../../../xtensa-buildroot-linux-uclibc/bin/ld: gstplugin.c:(.text+0xb58): undefined reference to `g_module_open'
/home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/xtensa-buildroot-linux-uclibc/8.3.0/../../../../xtensa-buildroot-linux-uclibc/bin/ld: gstplugin.c:(.text+0xb5c): undefined reference to `g_module_error'
static linking issue. Any brave meson/gstreamer person in the house ?
Adam ? :-)
> mips64el | host-go-1.13.8 | NOK | http://autobuild.buildroot.net/results/fa13a054995d6060d2dc15c36007e41a50ed7fc4 |
Some funky toolchain issue:
/data/buildroot/buildroot-test/instance-0/output/build/host-go-1.13.8/pkg/tool/linux_amd64/link: running /data/buildroot/buildroot-test/instance-0/output/host/bin/mips64el-linux-gcc failed: exit status 1
collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped
compilation terminated.
/data/buildroot/buildroot-test/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64el-buildroot-linux-uclibc/5.5.0/../../../../mips64el-buildroot-linux-uclibc/bin/ld: /tmp/go-link-130627779/go.o: relocation R_MIPS_26 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/data/buildroot/buildroot-test/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64el-buildroot-linux-uclibc/5.5.0/../../../../mips64el-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elfxx-mips.c:6550
> mips64el | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/4f853af32b5c09e63896e2125b5d018d279c0951 |
Yann's machine still exhibiting this weird issue.
> aarch64 | host-nodejs-12.16.0 | NOK | http://autobuild.buildroot.net/results/a83acd958d177a47ea2b1ca94b8a163da3e4a2c5 |
> arm | host-nodejs-12.16.0 | NOK | http://autobuild.buildroot.net/results/c7934318c29b9dce9062d93158906409c5229a6d |
Would be fixed by http://patchwork.ozlabs.org/patch/1239736/, but I
don't like the fact that package A refers to package B build directory.
> arc | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/46c5cf068cf9ea50e53491870d9dbf3f134c8c22 |
/home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/9.2.1/../../../../arc-buildroot-linux-uclibc/bin/ld: ../src/.libs/libgdiplus.so: undefined reference to `GifQuantizeBuffer'
This is *not* a static linking issue.
> m68k | libopenssl-1.1.1d | NOK | http://autobuild.buildroot.net/results/686b92af36ec691dd06078c18df21f59209bea06 |
elf2flt mess.
> sparc64 | lxc-3.2.1 | NOK | http://autobuild.buildroot.net/results/94d021c513569cf4062619127ec2262d30b3201f |
error: ^[[m^[[Kinvalid 'asm': invalid operand output code
J?r?me, you are listed as the lxc package developer, could you have a
look ?
> arm | mesa3d-19.3.4 | NOK | http://autobuild.buildroot.net/results/6387b0a99e1a0922811919623d9a10b0943988df |
{standard input}: Assembler messages:
{standard input}:334: Error: selected processor does not support `vldm r4,{q0,q1,q2,q3}' in ARM mode
{standard input}:335: Error: selected processor does not support `vst1.8 d0,[r3],r2' in ARM mode
{standard input}:336: Error: selected processor does not support `vst1.8 d1,[r3],r2' in ARM mode
{standard input}:337: Error: selected processor does not support `vst1.8 d2,[r3],r2' in ARM mode
Bad stuff happens when building the vc4 driver. It probably needs some
minimal ARM architecture variant.
> powerpc | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/ddb1c83ede34c125296563227f6b8f4b76729480 |
/home/giuliobenetti/autobuild/run/instance-0/output-1/host/lib/gcc/powerpc-buildroot-linux-uclibc/8.3.0/crtbeginS.o: in function `__do_global_dtors_aux':
crtstuff.c:(.text+0x13c): relocation truncated to fit: R_PPC_PLTREL24 against symbol `__cxa_finalize' defined in .text section in /home/giuliobenetti/autobuild/run/instance-0/output-1/host/powerpc-buildroot-linux-uclibc/sysroot/lib/libc.so.1
collect2: error: ld returned 1 exit status
> m68k | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/1a0caff18be6d55395c40f4d9f04076b03122757 |
elf2flt mess.
> arm | minicom-52b626b15a883b03006... | NOK | http://autobuild.buildroot.net/results/d3edbab1f2cd0f7b790e2559dc8d489497ae02f3 |
Fixed by https://git.buildroot.org/buildroot/commit/?id=acbae76d6977b1f2d3847ea379c7dd8f1761f565.
> x86_64 | mongodb-r4.0.12 | NOK | http://autobuild.buildroot.net/results/80a0d9dc59567c28b891c50c63280cea3aad613f |
src/mongo/util/heap_profiler.cpp:484:33: error: 'abi' has not been declared
> arm | mongodb-r4.0.12 | NOK | http://autobuild.buildroot.net/results/5765e33f444a22701b055015ed41436d3526e9eb |
/home/test/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-linux-gnueabihf/7.3.1/../../../../arm-linux-gnueabihf/bin/ld.gold: error: /home/test/autobuild/run/instance-1/output-1/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libyaml-cpp.a(null.cpp.o): requires unsupported dynamic reloc R_ARM_MOVW_ABS_NC; recompile with -fPIC
> aarch64_be | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/3938ecd3a0aae2e87d3876e7bf0d8244dcffb457 |
/home/test/autobuild/run/instance-2/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:17:2: error: #error This file was generated by an older version of protoc which is
#error This file was generated by an older version of protoc which is
Sigh.
> microblazeel | pango-1.44.6 | NOK | http://autobuild.buildroot.net/results/e5cfb968bc867d14f4ef4dd8da63b51360bc6808 | ORPH
Static linking issue.
> or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/25a594a74795bbccf5a218a6cd3b6804beac6e4d |
> or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/f0086358fd7bca5f2e77855c926641329e2e6ac8 |
> or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/079fd66a15dba75ed1ba70aec8708f35fb7e93fe |
> or1k | protobuf-3.11.0 | NOK | http://autobuild.buildroot.net/results/f800a5f24cb4b23231165ad60c03bf177bad4a9f |
/home/giuliobenetti/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752
/home/giuliobenetti/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752
Giulio, I think you like toolchain issues! :-)
> powerpc | qpdf-9.1.1 | NOK | http://autobuild.buildroot.net/results/c57fccab2e644b4b97971e9961682fac96f00a5c |
libtool: error: 'libqpdf/build/QUtil.lo' is not a valid libtool object
Not sure. Parallel build issue ?
> m68k | qpdf-9.1.1 | NOK | http://autobuild.buildroot.net/results/1e2299df96a2ddea22907870b6571553c5e7f7ef |
elf2flt mess.
> arm | qt5svg-5.12.7 | NOK | http://autobuild.buildroot.net/results/1c957888ba8f6124f093f96653035c8db2fc37ca |
per-package directory issue known, due to qt5
> arm | rocksdb-6.6.4 | NOK | http://autobuild.buildroot.net/results/832e1c85ee5ff79c74e84536ce09a66befe14c39 |
> arm | rocksdb-6.6.4 | NOK | http://autobuild.buildroot.net/results/cdf9f3435e9526eee12bbf036d333c82323d24ba |
Would be fixed by http://patchwork.ozlabs.org/patch/1243001/.
> microblazeel | unknown | NOK | http://autobuild.buildroot.net/results/b92c1c09de74886c9039b3b76f35275f4e7a7b6c |
Another funky toolchain issue:
/home/giuliobenetti/autobuild/run/instance-3/output-1/per-package/x264/host/bin/../lib/gcc/microblazeel-buildroot-linux-uclibc/8.3.0/../../../../microblazeel-buildroot-linux-uclibc/bin/ld: FDE encoding in /home/giuliobenetti/autobuild/run/instance-3/output-1/per-package/x264/host/bin/../lib/gcc/microblazeel-buildroot-linux-uclibc/8.3.0/libgcc.a(_divdi3.o)(.eh_frame) prevents .eh_frame_hdr table being created
> i686 | unknown | NOK | http://autobuild.buildroot.net/results/cdee1d3a823238be39f1d0bc6eb3498633b25865 |
Probably a top-level parallel build issue.
> arm | unknown | NOK | http://autobuild.buildroot.net/results/4e60fa31b1cd08bc7fdf9c5dd3a3f4941e029ba3 |
Top-level parallel build issue that is fixed by my rework of the
installed file list collection logic:
mv: cannot stat '/home/giuliobenetti/autobuild/run/instance-0/output-1/build/.files-list-staging.new': No such file or directory
> microblazeel | unknown | NOK | http://autobuild.buildroot.net/results/8466f1798cad365040ba6a5359fac30aafc82a60 |
Reproducible build issue in:
- getconf
- rpm
> x86_64 | unknown | NOK | http://autobuild.buildroot.net/results/deb862bed384296c2a6f119f63d4174cacb823d9 |
Probably another top-level parallel build issue.
> arm | unknown | NOK | http://autobuild.buildroot.net/results/4ce1704d3fc60fd3dec1d06b9031fb674b2236e3 |
Fixed by my rework of the installed file collection logic:
comm: /home/naourr/work/instance-1/output-1/build/.files-list-staging.new: No such file or directory
> riscv64 | vlc-3.0.8 | NOK | http://autobuild.buildroot.net/results/e8fd34f3b9b7166772e04d3e15c478990d07d894 |
> riscv32 | vlc-3.0.8 | NOK | http://autobuild.buildroot.net/results/a61819381ff8dc59b1cf20338df6b6a49f63e0c0 |
> i586 | vlc-3.0.8 | NOK | http://autobuild.buildroot.net/results/f11e2f24b998ac68891ab58a2bcf7b8677801767 |
video_filter/opencv_example.cpp:200:46: error: could not convert 'cv::Scalar_<double>((double)0, (double)0, (double)0, (double)0)' from 'cv::Scalar' {aka 'cv::Scalar_<double>'} to 'CvScalar'
cvRectangle( p_img[0], pt1, pt2, CV_RGB(0,0,0), 3, 8, 0 );
Bernd, you are in charge of vlc, could you have a look ?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
[not found] ` <20200220034343.2370e4e4@windsurf>
` (2 preceding siblings ...)
[not found] ` <94c8edad-773d-2b36-5daf-b6ee60dd747f@micronovasrl.com>
@ 2020-02-22 23:48 ` Romain Naour
3 siblings, 0 replies; 38+ messages in thread
From: Romain Naour @ 2020-02-22 23:48 UTC (permalink / raw)
To: buildroot
Hello,
Le 20/02/2020 ? 03:43, Thomas Petazzoni a ?crit?:
> Hello,
>
> On Wed, 19 Feb 2020 07:48:39 -0000
> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
>
>> master | 92 | 67 | 0 | 159 |
>
> These results are not really good, so we need to put some effort into
> reducing the number of build failures in the autobuilders. See below
> for an analysis of the different build failures. Your help is
> appreciated to fix those issues.
>
>
>> arm | efl-1.22.3 | NOK | http://autobuild.buildroot.net/results/4d7861fd5908c59546de19f6af3c27d061fed60b |
>
> /data/buildroot/buildroot-test/instance-0/output/host/bin/../arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/poppler/cpp/poppler-page.h:39:22: error: expected ',' or '...' before '&&' token
>
> Some C++ mess it seems. Romain, any idea ?
This is an issue related to poppler dependency that is built with C++11 standard:
sysroot/usr/include/poppler/cpp/poppler-page.h:70:10:
"error: 'unique_ptr' in namespace 'std' does not name a template type"
But with this toolchain based on gcc-5, the default C++ standard is gnu++98 [2].
The efl libraries should be built with -std=c++11 in CFLAGS (see [1] for similar
issue).
Or maybe we should bump the poppler's package gcc dependency (gcc 5 to gcc 6)
[3]. Doing so, the C++ standard for poppler and efl are the same (C++14).
Otherwise, I don't see how the efl package can know the C++ standard to use.
[1]
https://git.buildroot.net/buildroot/commit/?id=995fb9a4ebca3acb5dc6eb22edee039b67bf5303
[2] https://gcc.gnu.org/gcc-6/changes.html
[3]
https://git.buildroot.net/buildroot/tree/package/poppler/Config.in?h=2020.02-rc1#n7
Best regards,
Romain
> Thomas
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2020-02-22 21:48 ` Giulio Benetti
@ 2020-02-22 22:00 ` Fabrice Fontaine
0 siblings, 0 replies; 38+ messages in thread
From: Fabrice Fontaine @ 2020-02-22 22:00 UTC (permalink / raw)
To: buildroot
Le sam. 22 f?vr. 2020 ? 22:48, Giulio Benetti
<giulio.benetti@benettiengineering.com> a ?crit :
>
> Hi Fabrice,
>
> On 2/22/20 10:11 PM, Fabrice Fontaine wrote:
> > Dear all,
> >
> > Le sam. 22 f?vr. 2020 ? 20:44, Giulio Benetti
> > <giulio.benetti@micronovasrl.com> a ?crit :
> >>
> >> Hi Romain,
> >>
> >> +Cc me @benettiengineering.com and...
> >>
> >> Il 22/02/2020 20:10, Romain Naour ha scritto:
> >>> Hi Giulio,
> >>>
> >>> CC: buildroot <buildroot@buildroot.org>
> >>>
> >>> Le 22/02/2020 ? 19:57, Giulio Benetti a ?crit :
> >>>> Hi Romain,
> >>>>
> >>>> Il 22/02/2020 19:18, Romain Naour ha scritto:
> >>>>> Hi Giulio,
> >>>>>
> >>>>> Le 21/02/2020 ? 00:09, Giulio Benetti a ?crit :
> >>>>>> Hi Thomas,
> >>>>>>
> >>>>>> Il 20/02/2020 19:23, Thomas Petazzoni ha scritto:
> >>>>>>> On Thu, 20 Feb 2020 19:16:37 +0100
> >>>>>>> Giulio Benetti <giulio.benetti@micronovasrl.com> wrote:
> >>>>>>>
> >>>>>>>> So something like:
> >>>>>>>> # while true; do make foo && make foo-dirclean; done
> >>>>>>>>
> >>>>>>>> but please do you have a 'standard' form where it escapes on error?
> >>>>>>>
> >>>>>>> while true; do make foo && make foo-dirclean || break ; done
> >>>>>>
> >>>>>> Unfortunately the problem doesn't show up, I've also accelerated the building
> >>>>>> launching a local script in build/libsvgtiny-xxx/ that call make -j17 && make
> >>>>>> clean with all the arguments Buildroot provides to accelerate, but nothing. I've
> >>>>>> tried on my Workstation, my laptop and 1 of my autobuilders.
> >>>>>>
> >>>>>> Romain, have you had the chance to try that patch? Can I do something to ease
> >>>>>> the thing? Also, which specific distro(Distro name, kernel version) do you have?
> >>>>>
> >>>>> This a a Fedora 31 disto regularly updated.
> >>>>>
> >>>>> This is weird since we already disabled parallel build [1]
> >>>>
> >>>> Ah good finding, with this I've also found that [1] is wrong, since this is a
> >>>> generic package, so need to build with $(MAKE1) instead of $(MAKE) without
> >>>> LIBSVGTINY_MAKE = $(MAKE1)
> >>>> but maybe the patch i've sent you could work.
> >>>>
> >>>> Can you give a try?
> >>>
> >>> I tried to reproduce the issue but libsvgtiny still build fine here...
> >>>
> >>>>
> >>>> If it still fails, since this package contains 4 source files, I could send a
> >>>> patch that really avoid parallel build. And it must sent anyway a patch to fix
> >>>> that error.
> >>>
> >>> Maybe we can just fix the patch [1] ?
> >>> Can you send the patch ?
> >>
> >> ...yes, I'm going to send it soon.
> >>
> >>> BTW, who is using libsvgtiny? There is no package using it, no DEVELOPERS entry,
> >>> a fragile build system and the version we use is out of date (2011-03-21).
> >>> Maybe we can drop it?
> >>
> >> Yes, it should at least be bumped, I could take care of it, but I don't
> >> know if someone uses this package. Anyway I've seen that tags are set
> >> per year, so my effort would be very few to bump it and keep it up to date.
> > It should be noted that to bump it, you'll also have to bump
> > netsurf-buildsystem as well as add libdom package which is used
> > instead of libxml2 since
> > https://source.netsurf-browser.org/libsvgtiny.git/commit/?id=d03a7471001c4701e1fea976aee162b0de375f52
> > libdom depends on libparserutils and libwapcaplet which also need to
> > be added to buildroot.
> > So that's probably a lot of work for a package that is not used
> > currently by any package.
>
> Fortunately you've described all the implications for bumping this
> package, thank you! After this I can tell I won't bump and maintain that
> package.
That's perfectly understandable and I won't do it either so I would
"vote" to drop this package as suggested by Romain.
>
> Well, I've just sent the patch to fix parallel build:
> https://patchwork.ozlabs.org/patch/1242561/
>
> Kind regards
> --
> Giulio Benetti
> Benetti Engineering sas
>
> >>
> >> Thomas, please let me know if it is a good idea or better drop it.
> >>
> >> --
> >> Giulio Benetti
> >>
> >>> Best regards,
> >>> Romain
> >>>
> >>>>
> >>>> Please let me know
> >>>> Thank you
> >>>>
> >>>> Best regards!
> >>>
> >>
> > Best Regards,
> >
> > Fabrice
> > _______________________________________________
> > buildroot mailing list
> > buildroot at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot
> >
>
Best Regards,
Fabrice
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2020-02-22 21:11 ` Fabrice Fontaine
@ 2020-02-22 21:48 ` Giulio Benetti
2020-02-22 22:00 ` Fabrice Fontaine
0 siblings, 1 reply; 38+ messages in thread
From: Giulio Benetti @ 2020-02-22 21:48 UTC (permalink / raw)
To: buildroot
Hi Fabrice,
On 2/22/20 10:11 PM, Fabrice Fontaine wrote:
> Dear all,
>
> Le sam. 22 f?vr. 2020 ? 20:44, Giulio Benetti
> <giulio.benetti@micronovasrl.com> a ?crit :
>>
>> Hi Romain,
>>
>> +Cc me @benettiengineering.com and...
>>
>> Il 22/02/2020 20:10, Romain Naour ha scritto:
>>> Hi Giulio,
>>>
>>> CC: buildroot <buildroot@buildroot.org>
>>>
>>> Le 22/02/2020 ? 19:57, Giulio Benetti a ?crit :
>>>> Hi Romain,
>>>>
>>>> Il 22/02/2020 19:18, Romain Naour ha scritto:
>>>>> Hi Giulio,
>>>>>
>>>>> Le 21/02/2020 ? 00:09, Giulio Benetti a ?crit :
>>>>>> Hi Thomas,
>>>>>>
>>>>>> Il 20/02/2020 19:23, Thomas Petazzoni ha scritto:
>>>>>>> On Thu, 20 Feb 2020 19:16:37 +0100
>>>>>>> Giulio Benetti <giulio.benetti@micronovasrl.com> wrote:
>>>>>>>
>>>>>>>> So something like:
>>>>>>>> # while true; do make foo && make foo-dirclean; done
>>>>>>>>
>>>>>>>> but please do you have a 'standard' form where it escapes on error?
>>>>>>>
>>>>>>> while true; do make foo && make foo-dirclean || break ; done
>>>>>>
>>>>>> Unfortunately the problem doesn't show up, I've also accelerated the building
>>>>>> launching a local script in build/libsvgtiny-xxx/ that call make -j17 && make
>>>>>> clean with all the arguments Buildroot provides to accelerate, but nothing. I've
>>>>>> tried on my Workstation, my laptop and 1 of my autobuilders.
>>>>>>
>>>>>> Romain, have you had the chance to try that patch? Can I do something to ease
>>>>>> the thing? Also, which specific distro(Distro name, kernel version) do you have?
>>>>>
>>>>> This a a Fedora 31 disto regularly updated.
>>>>>
>>>>> This is weird since we already disabled parallel build [1]
>>>>
>>>> Ah good finding, with this I've also found that [1] is wrong, since this is a
>>>> generic package, so need to build with $(MAKE1) instead of $(MAKE) without
>>>> LIBSVGTINY_MAKE = $(MAKE1)
>>>> but maybe the patch i've sent you could work.
>>>>
>>>> Can you give a try?
>>>
>>> I tried to reproduce the issue but libsvgtiny still build fine here...
>>>
>>>>
>>>> If it still fails, since this package contains 4 source files, I could send a
>>>> patch that really avoid parallel build. And it must sent anyway a patch to fix
>>>> that error.
>>>
>>> Maybe we can just fix the patch [1] ?
>>> Can you send the patch ?
>>
>> ...yes, I'm going to send it soon.
>>
>>> BTW, who is using libsvgtiny? There is no package using it, no DEVELOPERS entry,
>>> a fragile build system and the version we use is out of date (2011-03-21).
>>> Maybe we can drop it?
>>
>> Yes, it should at least be bumped, I could take care of it, but I don't
>> know if someone uses this package. Anyway I've seen that tags are set
>> per year, so my effort would be very few to bump it and keep it up to date.
> It should be noted that to bump it, you'll also have to bump
> netsurf-buildsystem as well as add libdom package which is used
> instead of libxml2 since
> https://source.netsurf-browser.org/libsvgtiny.git/commit/?id=d03a7471001c4701e1fea976aee162b0de375f52
> libdom depends on libparserutils and libwapcaplet which also need to
> be added to buildroot.
> So that's probably a lot of work for a package that is not used
> currently by any package.
Fortunately you've described all the implications for bumping this
package, thank you! After this I can tell I won't bump and maintain that
package.
Well, I've just sent the patch to fix parallel build:
https://patchwork.ozlabs.org/patch/1242561/
Kind regards
--
Giulio Benetti
Benetti Engineering sas
>>
>> Thomas, please let me know if it is a good idea or better drop it.
>>
>> --
>> Giulio Benetti
>>
>>> Best regards,
>>> Romain
>>>
>>>>
>>>> Please let me know
>>>> Thank you
>>>>
>>>> Best regards!
>>>
>>
> Best Regards,
>
> Fabrice
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2020-02-22 19:44 ` Giulio Benetti
@ 2020-02-22 21:11 ` Fabrice Fontaine
2020-02-22 21:48 ` Giulio Benetti
0 siblings, 1 reply; 38+ messages in thread
From: Fabrice Fontaine @ 2020-02-22 21:11 UTC (permalink / raw)
To: buildroot
Dear all,
Le sam. 22 f?vr. 2020 ? 20:44, Giulio Benetti
<giulio.benetti@micronovasrl.com> a ?crit :
>
> Hi Romain,
>
> +Cc me @benettiengineering.com and...
>
> Il 22/02/2020 20:10, Romain Naour ha scritto:
> > Hi Giulio,
> >
> > CC: buildroot <buildroot@buildroot.org>
> >
> > Le 22/02/2020 ? 19:57, Giulio Benetti a ?crit :
> >> Hi Romain,
> >>
> >> Il 22/02/2020 19:18, Romain Naour ha scritto:
> >>> Hi Giulio,
> >>>
> >>> Le 21/02/2020 ? 00:09, Giulio Benetti a ?crit :
> >>>> Hi Thomas,
> >>>>
> >>>> Il 20/02/2020 19:23, Thomas Petazzoni ha scritto:
> >>>>> On Thu, 20 Feb 2020 19:16:37 +0100
> >>>>> Giulio Benetti <giulio.benetti@micronovasrl.com> wrote:
> >>>>>
> >>>>>> So something like:
> >>>>>> # while true; do make foo && make foo-dirclean; done
> >>>>>>
> >>>>>> but please do you have a 'standard' form where it escapes on error?
> >>>>>
> >>>>> while true; do make foo && make foo-dirclean || break ; done
> >>>>
> >>>> Unfortunately the problem doesn't show up, I've also accelerated the building
> >>>> launching a local script in build/libsvgtiny-xxx/ that call make -j17 && make
> >>>> clean with all the arguments Buildroot provides to accelerate, but nothing. I've
> >>>> tried on my Workstation, my laptop and 1 of my autobuilders.
> >>>>
> >>>> Romain, have you had the chance to try that patch? Can I do something to ease
> >>>> the thing? Also, which specific distro(Distro name, kernel version) do you have?
> >>>
> >>> This a a Fedora 31 disto regularly updated.
> >>>
> >>> This is weird since we already disabled parallel build [1]
> >>
> >> Ah good finding, with this I've also found that [1] is wrong, since this is a
> >> generic package, so need to build with $(MAKE1) instead of $(MAKE) without
> >> LIBSVGTINY_MAKE = $(MAKE1)
> >> but maybe the patch i've sent you could work.
> >>
> >> Can you give a try?
> >
> > I tried to reproduce the issue but libsvgtiny still build fine here...
> >
> >>
> >> If it still fails, since this package contains 4 source files, I could send a
> >> patch that really avoid parallel build. And it must sent anyway a patch to fix
> >> that error.
> >
> > Maybe we can just fix the patch [1] ?
> > Can you send the patch ?
>
> ...yes, I'm going to send it soon.
>
> > BTW, who is using libsvgtiny? There is no package using it, no DEVELOPERS entry,
> > a fragile build system and the version we use is out of date (2011-03-21).
> > Maybe we can drop it?
>
> Yes, it should at least be bumped, I could take care of it, but I don't
> know if someone uses this package. Anyway I've seen that tags are set
> per year, so my effort would be very few to bump it and keep it up to date.
It should be noted that to bump it, you'll also have to bump
netsurf-buildsystem as well as add libdom package which is used
instead of libxml2 since
https://source.netsurf-browser.org/libsvgtiny.git/commit/?id=d03a7471001c4701e1fea976aee162b0de375f52
libdom depends on libparserutils and libwapcaplet which also need to
be added to buildroot.
So that's probably a lot of work for a package that is not used
currently by any package.
>
> Thomas, please let me know if it is a good idea or better drop it.
>
> --
> Giulio Benetti
>
> > Best regards,
> > Romain
> >
> >>
> >> Please let me know
> >> Thank you
> >>
> >> Best regards!
> >
>
Best Regards,
Fabrice
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2020-02-22 19:10 ` Romain Naour
@ 2020-02-22 19:44 ` Giulio Benetti
2020-02-22 21:11 ` Fabrice Fontaine
0 siblings, 1 reply; 38+ messages in thread
From: Giulio Benetti @ 2020-02-22 19:44 UTC (permalink / raw)
To: buildroot
Hi Romain,
+Cc me @benettiengineering.com and...
Il 22/02/2020 20:10, Romain Naour ha scritto:
> Hi Giulio,
>
> CC: buildroot <buildroot@buildroot.org>
>
> Le 22/02/2020 ? 19:57, Giulio Benetti a ?crit?:
>> Hi Romain,
>>
>> Il 22/02/2020 19:18, Romain Naour ha scritto:
>>> Hi Giulio,
>>>
>>> Le 21/02/2020 ? 00:09, Giulio Benetti a ?crit?:
>>>> Hi Thomas,
>>>>
>>>> Il 20/02/2020 19:23, Thomas Petazzoni ha scritto:
>>>>> On Thu, 20 Feb 2020 19:16:37 +0100
>>>>> Giulio Benetti <giulio.benetti@micronovasrl.com> wrote:
>>>>>
>>>>>> So something like:
>>>>>> # while true; do make foo && make foo-dirclean; done
>>>>>>
>>>>>> but please do you have a 'standard' form where it escapes on error?
>>>>>
>>>>> while true; do make foo && make foo-dirclean || break ; done
>>>>
>>>> Unfortunately the problem doesn't show up, I've also accelerated the building
>>>> launching a local script in build/libsvgtiny-xxx/ that call make -j17 && make
>>>> clean with all the arguments Buildroot provides to accelerate, but nothing. I've
>>>> tried on my Workstation, my laptop and 1 of my autobuilders.
>>>>
>>>> Romain, have you had the chance to try that patch? Can I do something to ease
>>>> the thing? Also, which specific distro(Distro name, kernel version) do you have?
>>>
>>> This a a Fedora 31 disto regularly updated.
>>>
>>> This is weird since we already disabled parallel build [1]
>>
>> Ah good finding, with this I've also found that [1] is wrong, since this is a
>> generic package, so need to build with $(MAKE1) instead of $(MAKE) without
>> LIBSVGTINY_MAKE = $(MAKE1)
>> but maybe the patch i've sent you could work.
>>
>> Can you give a try?
>
> I tried to reproduce the issue but libsvgtiny still build fine here...
>
>>
>> If it still fails, since this package contains 4 source files, I could send a
>> patch that really avoid parallel build. And it must sent anyway a patch to fix
>> that error.
>
> Maybe we can just fix the patch [1] ?
> Can you send the patch ?
...yes, I'm going to send it soon.
> BTW, who is using libsvgtiny? There is no package using it, no DEVELOPERS entry,
> a fragile build system and the version we use is out of date (2011-03-21).
> Maybe we can drop it?
Yes, it should at least be bumped, I could take care of it, but I don't
know if someone uses this package. Anyway I've seen that tags are set
per year, so my effort would be very few to bump it and keep it up to date.
Thomas, please let me know if it is a good idea or better drop it.
--
Giulio Benetti
> Best regards,
> Romain
>
>>
>> Please let me know
>> Thank you
>>
>> Best regards!
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
[not found] ` <28258465-4f79-3f47-189d-bb066b0aa9f7@micronovasrl.com>
@ 2020-02-22 19:10 ` Romain Naour
2020-02-22 19:44 ` Giulio Benetti
0 siblings, 1 reply; 38+ messages in thread
From: Romain Naour @ 2020-02-22 19:10 UTC (permalink / raw)
To: buildroot
Hi Giulio,
CC: buildroot <buildroot@buildroot.org>
Le 22/02/2020 ? 19:57, Giulio Benetti a ?crit?:
> Hi Romain,
>
> Il 22/02/2020 19:18, Romain Naour ha scritto:
>> Hi Giulio,
>>
>> Le 21/02/2020 ? 00:09, Giulio Benetti a ?crit?:
>>> Hi Thomas,
>>>
>>> Il 20/02/2020 19:23, Thomas Petazzoni ha scritto:
>>>> On Thu, 20 Feb 2020 19:16:37 +0100
>>>> Giulio Benetti <giulio.benetti@micronovasrl.com> wrote:
>>>>
>>>>> So something like:
>>>>> # while true; do make foo && make foo-dirclean; done
>>>>>
>>>>> but please do you have a 'standard' form where it escapes on error?
>>>>
>>>> while true; do make foo && make foo-dirclean || break ; done
>>>
>>> Unfortunately the problem doesn't show up, I've also accelerated the building
>>> launching a local script in build/libsvgtiny-xxx/ that call make -j17 && make
>>> clean with all the arguments Buildroot provides to accelerate, but nothing. I've
>>> tried on my Workstation, my laptop and 1 of my autobuilders.
>>>
>>> Romain, have you had the chance to try that patch? Can I do something to ease
>>> the thing? Also, which specific distro(Distro name, kernel version) do you have?
>>
>> This a a Fedora 31 disto regularly updated.
>>
>> This is weird since we already disabled parallel build [1]
>
> Ah good finding, with this I've also found that [1] is wrong, since this is a
> generic package, so need to build with $(MAKE1) instead of $(MAKE) without
> LIBSVGTINY_MAKE = $(MAKE1)
> but maybe the patch i've sent you could work.
>
> Can you give a try?
I tried to reproduce the issue but libsvgtiny still build fine here...
>
> If it still fails, since this package contains 4 source files, I could send a
> patch that really avoid parallel build. And it must sent anyway a patch to fix
> that error.
Maybe we can just fix the patch [1] ?
Can you send the patch ?
BTW, who is using libsvgtiny? There is no package using it, no DEVELOPERS entry,
a fragile build system and the version we use is out of date (2011-03-21).
Maybe we can drop it?
Best regards,
Romain
>
> Please let me know
> Thank you
>
> Best regards!
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
[not found] ` <20200220034343.2370e4e4@windsurf>
2020-02-20 13:36 ` [Buildroot] Analysis of build results Giulio Benetti
@ 2020-02-21 8:23 ` Romain Naour
[not found] ` <94c8edad-773d-2b36-5daf-b6ee60dd747f@micronovasrl.com>
2020-02-22 23:48 ` Romain Naour
3 siblings, 0 replies; 38+ messages in thread
From: Romain Naour @ 2020-02-21 8:23 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Le 20/02/2020 ? 03:43, Thomas Petazzoni a ?crit?:
> Hello,
>
> On Wed, 19 Feb 2020 07:48:39 -0000
> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
>
>> master | 92 | 67 | 0 | 159 |
>
> These results are not really good, so we need to put some effort into
> reducing the number of build failures in the autobuilders. See below
> for an analysis of the different build failures. Your help is
> appreciated to fix those issues.
This email is missing from the Buildroot Archives [1].
There is something unusual... It seems that "buildroot at buildroot.org" is not in
"Cc" but "Redirect Mail".
Due to this, only the reply from Giulio was archived.
I'm replying using "Cc" for the ml.
[1] http://lists.busybox.net/pipermail/buildroot/2020-February/thread.html
Best regards,
Romain
>
>> m68k | acpica-20191018 | NOK | http://autobuild.buildroot.net/results/81ee33eb606062a62765d95b66a26f130d280c53 |
>
> Segmentation fault in elf2flt:
>
> ld (ld-elf2flt): /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/m68k-buildroot-uclinux-uclibc/bin/elf2flt terminated with signal 11 [Segmentation fault]
>
> Romain, I am wondering if you already had a look into this. Could you
> comment?
>
>> powerpc64 | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/d10a06addfdd927fd2ac772b25aaf9a057d20158 |
>> mips64el | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/16d2a2efed3b13ca648c83b64150da4c2c53afd7 |
>> powerpc64le | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/603f1be80822977f3181c99b8b01b3f2d531ace7 |
>> sparc | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/7b4780dd10b471243451f7f89c6b7de0c7e7ec4e |
>
> Per-package directories issue, fixed by
> https://git.buildroot.org/buildroot/commit/?id=84b4c19e551288911a230c2b73e96bc6e2ed12f9
>
>> m68k | augeas-1.12.0 | NOK | http://autobuild.buildroot.net/results/4e1f7f335d2c853e2a5e6ad96c14157ba8f003c7 |
>
> Another elf2flt issue:
>
> ld (ld-elf2flt): /home/giuliobenetti/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/m68k-buildroot-uclinux-uclibc/bin/elf2flt terminated with signal 11 [Segmentation fault], core dumped
>
> Romain ? :-)
>
>> microblazeel | bash-5.0 | NOK | http://autobuild.buildroot.net/results/b9edb405f6cf3322ddbb640c8e89cca57e840fc2 | ORPH
>
> ../input.h:76:3: error: unknown type name 'FILE'
>
> Not clear what is happening here. Could anyone investigate ?
>
>> i686 | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/16129b6d867578fc1cbcd36ed3a6cad806c21b10 |
>> powerpc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/7442b75921b95f5772520b62ff4004bc98251ee4 |
>> arm | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/979be1e697bb75cc018141e8fa83905696e738cf |
>> arm | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/240de32ee2a20b56db535147c98220783c48295f |
>
> I have submitted http://patchwork.ozlabs.org/patch/1241072/ to fix this.
>
>> m68k | cairo-1.16.0 | NOK | http://autobuild.buildroot.net/results/9552e97cd64c447c8582efbe326ddafa42bf9a01 |
>> m68k | cairo-1.16.0 | NOK | http://autobuild.buildroot.net/results/976d99bc9b052f8d9429e666ac7fff7768ffff6b |
>
> Another elf2flt segfault. Why are we seeing these segfaults? I don't
> think we used to have so many. Is it due to the relatively recent
> rebuild of all Buildroot toolchains, which perhaps mean we're using a
> newer version of elf2flt ?
>
>> arm | efl-1.22.3 | NOK | http://autobuild.buildroot.net/results/4d7861fd5908c59546de19f6af3c27d061fed60b |
>
> /data/buildroot/buildroot-test/instance-0/output/host/bin/../arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/poppler/cpp/poppler-page.h:39:22: error: expected ',' or '...' before '&&' token
>
> Some C++ mess it seems. Romain, any idea ?
>
>> arm | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/3cd8e2c64e8051a95e0e097cdd0878b00afacf8e |
>> sparc64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/edde1b609fd6b0e6be9870f78c71a6ababa49884 |
>> aarch64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/b24891ac2f7b661db63c54f52024efc1e23f0339 |
>> arm | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/491215f51a2f1c725099c53685b34513e3ff55e7 |
>> x86_64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/d3552e742381c737e5cacc5ca421c154ef93cde1 |
>> x86_64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/385f0b988fc1ffbf918fb9adc4dd556b2fb367ab |
>> mipsel | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/26137934eb18531985f5b648f391501835445331 |
>> powerpc | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/32b5aacc2cae822d169b9a61ec4d7c1292caf877 |
>> aarch64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/cc1e3df1eec85a9eca98b992f646061fb888512b |
>
> Fixed by https://git.buildroot.org/buildroot/commit/?id=607040e91381aae35205659e8edd7b2eeb45d420
>
>> arm | fontconfig-2.13.1 | NOK | http://autobuild.buildroot.net/results/4a5a8cb6411d709acb7ea8c83b3c8e45fdc0a10b | ORPH
>
> Another elf2flt issue.
>
>> nios2 | git-2.24.1 | NOK | http://autobuild.buildroot.net/results/432a2766836107ed5536f861a8fbcab33e1f8cf6 |
>
> Wonderful, another compiler segfault:
>
> ref-filter.c: In function 'find_longest_prefixes_1':
> ref-filter.c:1914:1: internal compiler error: Segmentation fault
>
> Giulio or Romain, any idea ?
>
>> m68k | gptfdisk-1.0.4 | NOK | http://autobuild.buildroot.net/results/6db5f9d8663730a54b04c1e624438095598b2573 | ORPH
>
> Our friend elf2flt strikes again. We really need to fix this issue.
>
>> arm | gst1-plugins-base-1.16.2 | NOK | http://autobuild.buildroot.net/results/b97923f7db5e0d7d5609152078573360937e0318 |
>
> Static linking issue. It may be the same problem as the one affecting
> libglib2. See below.
>
>> powerpc64le | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/89a2785352caae69cdf6aa02d55475aa4ed506d1 |
>> riscv64 | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/6e8ef0be643e030434474b58b15b3eff43081e5a |
>
> Still this mysterious failure that happens only on Yann's machine. Yann? :-)
>
>> riscv64 | host-llvm-9.0.1 | NOK | http://autobuild.buildroot.net/results/b922547540022a6fbde238053e2e5373a96ad48b |
>
> CMake Error at cmake/config-ix.cmake:438 (message):
> Unknown architecture
>
> Something not careful enough is using host-llvm even though the target
> architecture is not supported. Romain ?
>
>> i586 | host-pango-1.44.6 | NOK | http://autobuild.buildroot.net/results/30699ba23805d2b267644dc321b8aaec72a6bc89 | ORPH
>
> cannot delete non-empty directory: share/gettext
> could not make way for new symlink: share/gettext
>
> This is a per-package directory issue.
>
>> x86_64 | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/bc06573718c7b05bb2ea081089cb3afa6b3cd2c2 |
>> mips | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/929fb828553ca99c9fe3480286627f149226b857 |
>> arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/3cba9e7e96aeb5ca6c68a82b972988a7bc1dc87a |
>> arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/0e67255cc1b184273749e8fdb721f815b144031d |
>> arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/6216d389edff9893f8f791ab2fbfe46d8e1276fc |
>> arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/34644e28467ac49eb4bc676ac0eb48c0978d4eb9 |
>> microblazeel | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/7ba2762786c08231a69a07558274e52750b7627c |
>
> Fixed by https://git.buildroot.org/buildroot/commit/?id=6bf74ce3dbfec8979e379bc1b919f29d09f0d87b
>
>> xtensa | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/17cb7ca0e7ca1359fc2b575a6b6c93d493dd54fb |
>> riscv64 | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/5b619163f23e356c790a04c027f9b9ba8b650c43 |
>> arm | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/d9dca72127a005952a7f97ec0297cec2fd3968f4 |
>
> /data/buildroot/buildroot-test/instance-0/output/host/lib/gcc/arm-buildroot-linux-musleabihf/8.3.0/../../../../arm-buildroot-linux-musleabihf/bin/ld: ../src/.libs/libgdiplus.so: undefined reference to `GifQuantizeBuffer'
>
> Sergio, could you have a look ?
>
>> arm | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/68b4aa933fd5a60f4ac2ea023079053f805c621b |
>> sparc | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/279f4f8f293a4aa73b6534e4cbc90e5583951daa |
>> sh4 | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/1610673bc92f3cab2b858af8c4b1d0b6c871e614 |
>> arc | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/e27bf4715cc68ef976b2124663cc1c2d08a06d04 |
>> arm | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/b43ef2ad840c5bf897d0453f86026b58654f9377 |
>
> This is a static linking issue caused by a change in the pkg-config
> handling in our meson logic. I have reported this to Arnout at
> http://lists.busybox.net/pipermail/buildroot/2020-February/274491.html.
> However now I see that Fabrice has proposed
> http://lists.busybox.net/pipermail/buildroot/2020-February/274178.html
> to resolve the problem, which seems like a good approach.
>
> Arnout?
>
>> powerpc | libnss-3.50 | NOK | http://autobuild.buildroot.net/results/673d2a580afb774c39faf69c859418579cefccde |
>> powerpc | libnss-3.50 | NOK | http://autobuild.buildroot.net/results/7afbb81c0ebc93a75ec58c067f9758369bcae5d6 |
>
> These would be fixed by http://patchwork.ozlabs.org/patch/1235413/.
>
>> m68k | libopenssl-1.1.1d | NOK | http://autobuild.buildroot.net/results/f9d3d8534d090a575d163f92920b6ad6cc1531a2 |
>> m68k | libopenssl-1.1.1d | NOK | http://autobuild.buildroot.net/results/acf87e81130e85e7fb05edf5f6dedf095f16e226 |
>
> elf2flt I love you.
>
>> arc | libsvgtiny-ea9d99fc8b231c22... | NOK | http://autobuild.buildroot.net/results/67d341c0cc272323d6e231a20796a6848c21d760 | ORPH
>
> src/svgtiny.c:21:10: fatal error: autogenerated_colors.c: No such file or directory
> 21 | #include "autogenerated_colors.c"
>
> Some generated file is not here. Parallel build issue? Something else?
>
> We don't have any maintainer of libsvgtiny. Any volunteer ?
>
>> x86_64 | mesa3d-19.3.4 | NOK | http://autobuild.buildroot.net/results/49c150649fa50e9dc67939e072cd5a1d3a7aa661 |
>> x86_64 | mesa3d-19.3.4 | NOK | http://autobuild.buildroot.net/results/86036e0e4e29eeffbe4aa10ca6e075155b675e72 |
>
> I would suspect these would be fixed by http://patchwork.ozlabs.org/patch/1240964/.
>
>> m68k | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/61f53630ed85ee0d0d6dbf71012db77f4d7986ad |
>
> elf2flt issue.
>
>> xtensa | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/8c49a36b1fe423561473395d8f055c90436d2a5f |
>
> /home/giuliobenetti/autobuild/run/instance-0/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:17:2: error: #error This file was generated by an older version of protoc which is
> #error This file was generated by an older version of protoc which is
> ^~~~~
> /home/giuliobenetti/autobuild/run/instance-0/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:18:2: error: #error incompatible with your Protocol Buffer headers. Please
> #error incompatible with your Protocol Buffer headers. Please
> ^~~~~
> /home/giuliobenetti/autobuild/run/instance-0/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:19:2: error: #error regenerate this file with a newer version of protoc.
> #error regenerate this file with a newer version of protoc.
> ^~~~~
>
> OK, needs to be investigated. opencv3 used to be maintained by Samuel
> Martin, but Samuel is no longer active in Buildroot. Any volunteer?
>
>> i586 | openvmtools-10.3.5-10430147 | NOK | http://autobuild.buildroot.net/results/e0e7ed448df8bdd6cb13a0989d7a6c7dbaa5bc4e |
>
> /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/i586-buildroot-linux-musl/8.3.0/../../../../i586-buildroot-linux-musl/bin/ld: vmtoolsd-cmdLine.o: undefined reference to symbol 'libintl_gettext'
>
> Needs to link against the proper libintl library. Anyone to look into this ?
>
>> powerpc64 | ripgrep-0.8.1 | NOK | http://autobuild.buildroot.net/results/1ee145c19ee2cd5e6c237bc2864bae75e9ee4115 |
>
> Fails while downloading stuff during the build. I guess this is what is
> being fixed by the work on Cargo integration in Buildroot.
>
>> i686 | sdl2-2.0.10 | NOK | http://autobuild.buildroot.net/results/0996643e6d235168ca77271f15b21f8c167e400f |
>
> /home/buildroot/autobuild/instance-1/output-1/host/i686-buildroot-linux-uclibc/sysroot/usr/include/EGL/eglplatform.h:134:10: fatal error: X11/Xlib.h: No such file or directory
> #include <X11/Xlib.h>
>
> Anybody to have a look ?
>
>> sparc | tio-1.32 | NOK | http://autobuild.buildroot.net/results/7612824c472bd34f352a83aea50a9707442b1b42 |
>
> /home/peko/autobuild/instance-0/output-1/host/sparc-buildroot-linux-uclibc/sysroot/usr/include/asm/termbits.h:16:8: error: redefinition of 'struct termio'
> struct termio {
>
>
>> arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/cba93a681d10692c4e4c5584e4c962bd18a608d4 | ORPH
>> arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/efd344724a244010e3411bb6599dec42adb8acaa | ORPH
>> arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/3f7c9d3738db5154cad27e548495643225dde0bc | ORPH
>> arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/7513ce8a3c501aa31aa1bd1a9908ad090b2b11b1 | ORPH
>
> These would be fixed by my series:
>
> http://patchwork.ozlabs.org/project/buildroot/list/?series=159621
>
>> riscv32 | unknown | NOK | http://autobuild.buildroot.net/results/f0c62cf7edda5c811c7f2eda6212d3889f2920df |
>
> Not clear why it failed. This is not a reproducible build issue, there
> are no errors in the logs. It was built with
> BR2_PER_PACKAGE_DIRECTORIES=y, so possibly with top-level parallel
> build, and therefore the error might be outside of the log.
>
>> arm | unknown | NOK | http://autobuild.buildroot.net/results/593c94c707508b549547e4b42727ce669229c820 |
>
> This one is a reproducible build issue due to elf2flt storing the build
> date in the BFLT header. I have already fixed this in upstream elf2flt
> https://github.com/uclinux-dev/elf2flt/commit/453398f917d167f8c308c8f997270c48ae8f8b12,
> we need to backport this in BR and rebuild our noMMU toolchains.
>
>> powerpc | unknown | NOK | http://autobuild.buildroot.net/results/47667ea26dc4ed87d4aeb4ac9ae86fcd42223c6b |
>
> Also no visible error here, also probably a top-level parallel build.
> We need to somehow fix the logic we use to extract the error when doing
> top-level parallel builds.
>
>> arm | vlc-3.0.8 | NOK | http://autobuild.buildroot.net/results/ad8058cd98378d8813ab72bc292c8c5b9e41d7a0 |
>
> video_filter/opencv_example.cpp:200:46: error: could not convert 'cv::Scalar_<double>((double)0, (double)0, (double)0, (double)0)' from 'cv::Scalar' {aka 'cv::Scalar_<double>'} to 'CvScalar'
> cvRectangle( p_img[0], pt1, pt2, CV_RGB(0,0,0), 3, 8, 0 );
>
> Meh. VLC/OpenCV issue.
>
> Thomas
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
[not found] ` <20200220034343.2370e4e4@windsurf>
@ 2020-02-20 13:36 ` Giulio Benetti
2020-02-21 8:23 ` Romain Naour
` (2 subsequent siblings)
3 siblings, 0 replies; 38+ messages in thread
From: Giulio Benetti @ 2020-02-20 13:36 UTC (permalink / raw)
To: buildroot
Hi All,
Il 20/02/2020 03:43, Thomas Petazzoni ha scritto:
> Hello,
>
> On Wed, 19 Feb 2020 07:48:39 -0000
> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
>
>> master | 92 | 67 | 0 | 159 |
>
> These results are not really good, so we need to put some effort into
> reducing the number of build failures in the autobuilders. See below
> for an analysis of the different build failures. Your help is
> appreciated to fix those issues.
>
>> m68k | acpica-20191018 | NOK | http://autobuild.buildroot.net/results/81ee33eb606062a62765d95b66a26f130d280c53 |
>
> Segmentation fault in elf2flt:
>
> ld (ld-elf2flt): /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/m68k-buildroot-uclinux-uclibc/bin/elf2flt terminated with signal 11 [Segmentation fault]
>
> Romain, I am wondering if you already had a look into this. Could you
> comment?
>
>> powerpc64 | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/d10a06addfdd927fd2ac772b25aaf9a057d20158 |
>> mips64el | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/16d2a2efed3b13ca648c83b64150da4c2c53afd7 |
>> powerpc64le | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/603f1be80822977f3181c99b8b01b3f2d531ace7 |
>> sparc | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/7b4780dd10b471243451f7f89c6b7de0c7e7ec4e |
>
> Per-package directories issue, fixed by
> https://git.buildroot.org/buildroot/commit/?id=84b4c19e551288911a230c2b73e96bc6e2ed12f9
>
>> m68k | augeas-1.12.0 | NOK | http://autobuild.buildroot.net/results/4e1f7f335d2c853e2a5e6ad96c14157ba8f003c7 |
>
> Another elf2flt issue:
>
> ld (ld-elf2flt): /home/giuliobenetti/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/m68k-buildroot-uclinux-uclibc/bin/elf2flt terminated with signal 11 [Segmentation fault], core dumped
>
> Romain ? :-)
>
>> microblazeel | bash-5.0 | NOK | http://autobuild.buildroot.net/results/b9edb405f6cf3322ddbb640c8e89cca57e840fc2 | ORPH
>
> ../input.h:76:3: error: unknown type name 'FILE'
>
> Not clear what is happening here. Could anyone investigate ?
>
>> i686 | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/16129b6d867578fc1cbcd36ed3a6cad806c21b10 |
>> powerpc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/7442b75921b95f5772520b62ff4004bc98251ee4 |
>> arm | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/979be1e697bb75cc018141e8fa83905696e738cf |
>> arm | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/240de32ee2a20b56db535147c98220783c48295f |
>
> I have submitted http://patchwork.ozlabs.org/patch/1241072/ to fix this.
>
>> m68k | cairo-1.16.0 | NOK | http://autobuild.buildroot.net/results/9552e97cd64c447c8582efbe326ddafa42bf9a01 |
>> m68k | cairo-1.16.0 | NOK | http://autobuild.buildroot.net/results/976d99bc9b052f8d9429e666ac7fff7768ffff6b |
>
> Another elf2flt segfault. Why are we seeing these segfaults? I don't
> think we used to have so many. Is it due to the relatively recent
> rebuild of all Buildroot toolchains, which perhaps mean we're using a
> newer version of elf2flt ?
>
>> arm | efl-1.22.3 | NOK | http://autobuild.buildroot.net/results/4d7861fd5908c59546de19f6af3c27d061fed60b |
>
> /data/buildroot/buildroot-test/instance-0/output/host/bin/../arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/poppler/cpp/poppler-page.h:39:22: error: expected ',' or '...' before '&&' token
>
> Some C++ mess it seems. Romain, any idea ?
>
>> arm | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/3cd8e2c64e8051a95e0e097cdd0878b00afacf8e |
>> sparc64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/edde1b609fd6b0e6be9870f78c71a6ababa49884 |
>> aarch64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/b24891ac2f7b661db63c54f52024efc1e23f0339 |
>> arm | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/491215f51a2f1c725099c53685b34513e3ff55e7 |
>> x86_64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/d3552e742381c737e5cacc5ca421c154ef93cde1 |
>> x86_64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/385f0b988fc1ffbf918fb9adc4dd556b2fb367ab |
>> mipsel | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/26137934eb18531985f5b648f391501835445331 |
>> powerpc | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/32b5aacc2cae822d169b9a61ec4d7c1292caf877 |
>> aarch64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/cc1e3df1eec85a9eca98b992f646061fb888512b |
>
> Fixed by https://git.buildroot.org/buildroot/commit/?id=607040e91381aae35205659e8edd7b2eeb45d420
>
>> arm | fontconfig-2.13.1 | NOK | http://autobuild.buildroot.net/results/4a5a8cb6411d709acb7ea8c83b3c8e45fdc0a10b | ORPH
>
> Another elf2flt issue.
>
>> nios2 | git-2.24.1 | NOK | http://autobuild.buildroot.net/results/432a2766836107ed5536f861a8fbcab33e1f8cf6 |
>
> Wonderful, another compiler segfault:
>
> ref-filter.c: In function 'find_longest_prefixes_1':
> ref-filter.c:1914:1: internal compiler error: Segmentation fault
>
> Giulio or Romain, any idea ?
Going to deal with this and let you know when gcc bug is reported and I
have a decent work around.
--
Giulio Benetti
>> m68k | gptfdisk-1.0.4 | NOK | http://autobuild.buildroot.net/results/6db5f9d8663730a54b04c1e624438095598b2573 | ORPH
>
> Our friend elf2flt strikes again. We really need to fix this issue.
>
>> arm | gst1-plugins-base-1.16.2 | NOK | http://autobuild.buildroot.net/results/b97923f7db5e0d7d5609152078573360937e0318 |
>
> Static linking issue. It may be the same problem as the one affecting
> libglib2. See below.
>
>> powerpc64le | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/89a2785352caae69cdf6aa02d55475aa4ed506d1 |
>> riscv64 | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/6e8ef0be643e030434474b58b15b3eff43081e5a |
>
> Still this mysterious failure that happens only on Yann's machine. Yann? :-)
>
>> riscv64 | host-llvm-9.0.1 | NOK | http://autobuild.buildroot.net/results/b922547540022a6fbde238053e2e5373a96ad48b |
>
> CMake Error at cmake/config-ix.cmake:438 (message):
> Unknown architecture
>
> Something not careful enough is using host-llvm even though the target
> architecture is not supported. Romain ?
>
>> i586 | host-pango-1.44.6 | NOK | http://autobuild.buildroot.net/results/30699ba23805d2b267644dc321b8aaec72a6bc89 | ORPH
>
> cannot delete non-empty directory: share/gettext
> could not make way for new symlink: share/gettext
>
> This is a per-package directory issue.
>
>> x86_64 | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/bc06573718c7b05bb2ea081089cb3afa6b3cd2c2 |
>> mips | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/929fb828553ca99c9fe3480286627f149226b857 |
>> arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/3cba9e7e96aeb5ca6c68a82b972988a7bc1dc87a |
>> arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/0e67255cc1b184273749e8fdb721f815b144031d |
>> arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/6216d389edff9893f8f791ab2fbfe46d8e1276fc |
>> arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/34644e28467ac49eb4bc676ac0eb48c0978d4eb9 |
>> microblazeel | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/7ba2762786c08231a69a07558274e52750b7627c |
>
> Fixed by https://git.buildroot.org/buildroot/commit/?id=6bf74ce3dbfec8979e379bc1b919f29d09f0d87b
>
>> xtensa | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/17cb7ca0e7ca1359fc2b575a6b6c93d493dd54fb |
>> riscv64 | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/5b619163f23e356c790a04c027f9b9ba8b650c43 |
>> arm | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/d9dca72127a005952a7f97ec0297cec2fd3968f4 |
>
> /data/buildroot/buildroot-test/instance-0/output/host/lib/gcc/arm-buildroot-linux-musleabihf/8.3.0/../../../../arm-buildroot-linux-musleabihf/bin/ld: ../src/.libs/libgdiplus.so: undefined reference to `GifQuantizeBuffer'
>
> Sergio, could you have a look ?
>
>> arm | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/68b4aa933fd5a60f4ac2ea023079053f805c621b |
>> sparc | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/279f4f8f293a4aa73b6534e4cbc90e5583951daa |
>> sh4 | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/1610673bc92f3cab2b858af8c4b1d0b6c871e614 |
>> arc | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/e27bf4715cc68ef976b2124663cc1c2d08a06d04 |
>> arm | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/b43ef2ad840c5bf897d0453f86026b58654f9377 |
>
> This is a static linking issue caused by a change in the pkg-config
> handling in our meson logic. I have reported this to Arnout at
> http://lists.busybox.net/pipermail/buildroot/2020-February/274491.html.
> However now I see that Fabrice has proposed
> http://lists.busybox.net/pipermail/buildroot/2020-February/274178.html
> to resolve the problem, which seems like a good approach.
>
> Arnout?
>
>> powerpc | libnss-3.50 | NOK | http://autobuild.buildroot.net/results/673d2a580afb774c39faf69c859418579cefccde |
>> powerpc | libnss-3.50 | NOK | http://autobuild.buildroot.net/results/7afbb81c0ebc93a75ec58c067f9758369bcae5d6 |
>
> These would be fixed by http://patchwork.ozlabs.org/patch/1235413/.
>
>> m68k | libopenssl-1.1.1d | NOK | http://autobuild.buildroot.net/results/f9d3d8534d090a575d163f92920b6ad6cc1531a2 |
>> m68k | libopenssl-1.1.1d | NOK | http://autobuild.buildroot.net/results/acf87e81130e85e7fb05edf5f6dedf095f16e226 |
>
> elf2flt I love you.
>
>> arc | libsvgtiny-ea9d99fc8b231c22... | NOK | http://autobuild.buildroot.net/results/67d341c0cc272323d6e231a20796a6848c21d760 | ORPH
>
> src/svgtiny.c:21:10: fatal error: autogenerated_colors.c: No such file or directory
> 21 | #include "autogenerated_colors.c"
>
> Some generated file is not here. Parallel build issue? Something else?
>
> We don't have any maintainer of libsvgtiny. Any volunteer ?
>
>> x86_64 | mesa3d-19.3.4 | NOK | http://autobuild.buildroot.net/results/49c150649fa50e9dc67939e072cd5a1d3a7aa661 |
>> x86_64 | mesa3d-19.3.4 | NOK | http://autobuild.buildroot.net/results/86036e0e4e29eeffbe4aa10ca6e075155b675e72 |
>
> I would suspect these would be fixed by http://patchwork.ozlabs.org/patch/1240964/.
>
>> m68k | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/61f53630ed85ee0d0d6dbf71012db77f4d7986ad |
>
> elf2flt issue.
>
>> xtensa | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/8c49a36b1fe423561473395d8f055c90436d2a5f |
>
> /home/giuliobenetti/autobuild/run/instance-0/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:17:2: error: #error This file was generated by an older version of protoc which is
> #error This file was generated by an older version of protoc which is
> ^~~~~
> /home/giuliobenetti/autobuild/run/instance-0/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:18:2: error: #error incompatible with your Protocol Buffer headers. Please
> #error incompatible with your Protocol Buffer headers. Please
> ^~~~~
> /home/giuliobenetti/autobuild/run/instance-0/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:19:2: error: #error regenerate this file with a newer version of protoc.
> #error regenerate this file with a newer version of protoc.
> ^~~~~
>
> OK, needs to be investigated. opencv3 used to be maintained by Samuel
> Martin, but Samuel is no longer active in Buildroot. Any volunteer?
>
>> i586 | openvmtools-10.3.5-10430147 | NOK | http://autobuild.buildroot.net/results/e0e7ed448df8bdd6cb13a0989d7a6c7dbaa5bc4e |
>
> /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/i586-buildroot-linux-musl/8.3.0/../../../../i586-buildroot-linux-musl/bin/ld: vmtoolsd-cmdLine.o: undefined reference to symbol 'libintl_gettext'
>
> Needs to link against the proper libintl library. Anyone to look into this ?
>
>> powerpc64 | ripgrep-0.8.1 | NOK | http://autobuild.buildroot.net/results/1ee145c19ee2cd5e6c237bc2864bae75e9ee4115 |
>
> Fails while downloading stuff during the build. I guess this is what is
> being fixed by the work on Cargo integration in Buildroot.
>
>> i686 | sdl2-2.0.10 | NOK | http://autobuild.buildroot.net/results/0996643e6d235168ca77271f15b21f8c167e400f |
>
> /home/buildroot/autobuild/instance-1/output-1/host/i686-buildroot-linux-uclibc/sysroot/usr/include/EGL/eglplatform.h:134:10: fatal error: X11/Xlib.h: No such file or directory
> #include <X11/Xlib.h>
>
> Anybody to have a look ?
>
>> sparc | tio-1.32 | NOK | http://autobuild.buildroot.net/results/7612824c472bd34f352a83aea50a9707442b1b42 |
>
> /home/peko/autobuild/instance-0/output-1/host/sparc-buildroot-linux-uclibc/sysroot/usr/include/asm/termbits.h:16:8: error: redefinition of 'struct termio'
> struct termio {
>
>
>> arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/cba93a681d10692c4e4c5584e4c962bd18a608d4 | ORPH
>> arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/efd344724a244010e3411bb6599dec42adb8acaa | ORPH
>> arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/3f7c9d3738db5154cad27e548495643225dde0bc | ORPH
>> arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/7513ce8a3c501aa31aa1bd1a9908ad090b2b11b1 | ORPH
>
> These would be fixed by my series:
>
> http://patchwork.ozlabs.org/project/buildroot/list/?series=159621
>
>> riscv32 | unknown | NOK | http://autobuild.buildroot.net/results/f0c62cf7edda5c811c7f2eda6212d3889f2920df |
>
> Not clear why it failed. This is not a reproducible build issue, there
> are no errors in the logs. It was built with
> BR2_PER_PACKAGE_DIRECTORIES=y, so possibly with top-level parallel
> build, and therefore the error might be outside of the log.
>
>> arm | unknown | NOK | http://autobuild.buildroot.net/results/593c94c707508b549547e4b42727ce669229c820 |
>
> This one is a reproducible build issue due to elf2flt storing the build
> date in the BFLT header. I have already fixed this in upstream elf2flt
> https://github.com/uclinux-dev/elf2flt/commit/453398f917d167f8c308c8f997270c48ae8f8b12,
> we need to backport this in BR and rebuild our noMMU toolchains.
>
>> powerpc | unknown | NOK | http://autobuild.buildroot.net/results/47667ea26dc4ed87d4aeb4ac9ae86fcd42223c6b |
>
> Also no visible error here, also probably a top-level parallel build.
> We need to somehow fix the logic we use to extract the error when doing
> top-level parallel builds.
>
>> arm | vlc-3.0.8 | NOK | http://autobuild.buildroot.net/results/ad8058cd98378d8813ab72bc292c8c5b9e41d7a0 |
>
> video_filter/opencv_example.cpp:200:46: error: could not convert 'cv::Scalar_<double>((double)0, (double)0, (double)0, (double)0)' from 'cv::Scalar' {aka 'cv::Scalar_<double>'} to 'CvScalar'
> cvRectangle( p_img[0], pt1, pt2, CV_RGB(0,0,0), 3, 8, 0 );
>
> Meh. VLC/OpenCV issue.
>
> Thomas
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2014-11-11 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni
` (3 preceding siblings ...)
2014-11-16 10:07 ` Yann E. MORIN
@ 2014-11-22 11:10 ` Bernd Kuhls
4 siblings, 0 replies; 38+ messages in thread
From: Bernd Kuhls @ 2014-11-22 11:10 UTC (permalink / raw)
To: buildroot
[posted and mailed]
Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote
in news:20141111234919.3178e9d3 at free-electrons.com:
>> x86_64 | fltk-1.3.2 | NOK |
>> http://autobuild.buildroot.net/results/58a36291201a848a0a11cbb2b20
>> 0c2b39434046c/ x86_64 | fltk-1.3.2 | NOK |
>> http://autobuild.buildroot.net/results/fe53d0e9ad7c152105cb37a18e4
>> d712bbde3398d/
>
> Linking fluid...
> /home/peko/autobuild/instance-1/output/host/usr/x86_64-buildroot-linux-gn
> u/sysroot/usr/lib64/libxcb-shm.so.0: undefined reference to
> `xcb_get_reply_fds'
> /home/peko/autobuild/instance-1/output/host/usr/x86_64-buildroot-linux-gn
> u/sysroot/usr/lib64/libxcb-shm.so.0: undefined reference to
> `xcb_send_fd' collect2: error: ld returned 1 exit status
>
> Bernd, you are our X.org expert. Can you have a look? It might be worth
> mentioning that fltk 1.3.3 has been released on November 3rd, so we
> could try to upgrade and see if it fixes the problem.
Hi,
using fltk-1.3.2 I can not reproduce the problem.
Are any xcb packages installed locally on the autobuilders?
Locally this is not the case:
fli4l at fli4lbuild64:~/br2$ dpkg -l | grep xcb
fli4l at fli4lbuild64:~/br2$
Regards, Bernd
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2014-11-11 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni
` (2 preceding siblings ...)
2014-11-12 14:09 ` Jörg Krause
@ 2014-11-16 10:07 ` Yann E. MORIN
2014-11-22 11:10 ` Bernd Kuhls
4 siblings, 0 replies; 38+ messages in thread
From: Yann E. MORIN @ 2014-11-16 10:07 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2014-11-11 23:49 +0100, Thomas Petazzoni spake thusly:
> > i486 | alsa-lib-1.0.28 | NOK | http://autobuild.buildroot.net/results/6ce1ecdf2bf1f14f1497e9960a1b6689568a3658/
> > powerpc | alsa-lib-1.0.28 | NOK | http://autobuild.buildroot.net/results/a990b0deb0269e91bcd7fb008eb40a2e00350114/
>
> This is the same problem twice: uClibc behaving badly when vfork() is
> used in static linking configurations. This is now fixed for the
> internal toolchain backend. The first build failure is with an external
> Crosstool-NG toolchain using uClibc. Yann, what would be your
> recommendation here? Is it something you intend to fix upstream in
> Crosstool-NG? Or should I add an exception for this toolchain to not be
> used in static linking configurations?
Is that fixed in Buildroot with that patch patch:
package/uclibc/0.9.33.2/0062-nptl-remove-duplicate-vfork-in-libpthread.patch
It is not in upstream uClibc yet, so I've pinged them about applying
that patch.
I'm a bit warry of carrying patches in crosstool-NG, that are not
upstream. But uClibc is, well, a special case, isn't it? ;-)
Maybe I could just vampirise the patches from Buildroot, and be done
with it.
> > i686 | qemu-2.1.2 | NOK | http://autobuild.buildroot.net/results/9efc2b14a28fd21ed2ce492f41de538673d13dce/
> > i686 | qemu-2.1.2 | NOK | http://autobuild.buildroot.net/results/0f640d6b701bb854ada2023861a234dfe489f038/
> > x86_64 | qemu-2.1.2 | NOK | http://autobuild.buildroot.net/results/c58f7e10a416e0eaf7e49f0bb5ce9e6f85bc1559/
> > x86_64 | qemu-2.1.2 | NOK | http://autobuild.buildroot.net/results/5979559734620358a92186a6e67aea46b6034b44/
>
> ERROR: fdt disabled but some requested targets require it.
> You can turn off fdt only if you also disable all the system emulation
> targets which need it (by specifying a cut down --target-list).
O...K... Well, fdt support comes later in my series, and it is a part
that is not yet applied.
I'll see to re-order the series to be able to just submit the FDT part,
before the release.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2014-11-11 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni
2014-11-11 23:41 ` Gustavo Zacarias
2014-11-12 2:30 ` Nathaniel Roach
@ 2014-11-12 14:09 ` Jörg Krause
2014-11-16 10:07 ` Yann E. MORIN
2014-11-22 11:10 ` Bernd Kuhls
4 siblings, 0 replies; 38+ messages in thread
From: Jörg Krause @ 2014-11-12 14:09 UTC (permalink / raw)
To: buildroot
On Di, 2014-11-11 at 23:49 +0100, Thomas Petazzoni wrote:
> Hello,
>
> Yann, Gustavo, Bernd, Nathaniel, Maxime, Samuel, Peter, please read on,
> there is some stuff for you below :-)
> > bfin | libshairplay-64d59e3087f829... | NOK | http://autobuild.buildroot.net/results/f08787c7965c5594d9560db0aa2adb7b07a65a45/
>
> libshairplay_la-http_parser.o
> dnssd.c:74:21: error: dns_sd.h: No such file or directory
> dnssd.c:78: error: expected declaration specifiers or '...' before '*' token
> dnssd.c:80: error: expected ')' before '*' token
> dnssd.c:93: error: expected ')' before 'sdRef'
> dnssd.c:96: error: expected ')' before '*' token
libshairplay needs a mDNS library. If dynamic linkage is present through
libdl, the library is linked at runtime. If libdl is not present, like
in this case of a Blackfin target with FLAT binary format, a mDNS
library has to be statically linked.
Since the only mDNS library in Buildroot - avahi - needs dynamic
linkage, libshairplay cannot be built with static linkage in Buildroot
for now.
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2014-11-11 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni
2014-11-11 23:41 ` Gustavo Zacarias
@ 2014-11-12 2:30 ` Nathaniel Roach
2014-11-12 14:09 ` Jörg Krause
` (2 subsequent siblings)
4 siblings, 0 replies; 38+ messages in thread
From: Nathaniel Roach @ 2014-11-12 2:30 UTC (permalink / raw)
To: buildroot
On 12/11/14 06:49, Thomas Petazzoni wrote:
> Hello,
>
> Yann, Gustavo, Bernd, Nathaniel, Maxime, Samuel, Peter, please read on,
> there is some stuff for you below :-)
>
> On Tue, 11 Nov 2014 08:30:14 +0100 (CET), Thomas Petazzoni wrote:
>> Build statistics for 2014-11-10
>> ===============================
>>
>> success : 197
>> failures : 49
>> timeouts : 4
>> TOTAL : 250
>
> So a 20% failure rate. Not too bad, but we definitely need to improve
> this.
>
---- snip ----
>
>
>> x86_64 | host-mysql-5.1.73 | NOK | http://autobuild.buildroot.net/results/a0ff4949d621caf4cada6ae3f66ed38f569d34b9/
>
> checking for tgetent in -ltinfo... no
> checking for termcap functions library... configure: error: No curses/termcap library found
>
> Missing host-ncurses dependency. Nathaniel, since this is happening on
> your build server, maybe you could have a look?
>
I've checked and the configure script is checking for (or at least works
when) libncurses5-dev is installed on the host.
When lncurses is installed, the package from that specific config builds
fine. So it looks like host-mysql doesn't depend on host-ncurses, or
something along those lines.
I have removed libncurses5 from the autobuilder per our discussion on it
a few months back.
---- snip ----
>
> Thomas
>
Thanks,
Nathaniel.
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2014-11-11 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni
@ 2014-11-11 23:41 ` Gustavo Zacarias
2014-11-12 2:30 ` Nathaniel Roach
` (3 subsequent siblings)
4 siblings, 0 replies; 38+ messages in thread
From: Gustavo Zacarias @ 2014-11-11 23:41 UTC (permalink / raw)
To: buildroot
On 11/11/2014 07:49 PM, Thomas Petazzoni wrote:
>> bfin | bmon-3.5 | NOK | http://autobuild.buildroot.net/results/4d0c3c8b68b37f532378f19041379cb5c5798950/
>
> in_netlink.c:40:29: error: netlink/netlink.h: No such file or directory
> in_netlink.c:41:27: error: netlink/cache.h: No such file or directory
> in_netlink.c:42:27: error: netlink/utils.h: No such file or directory
> in_netlink.c:43:32: error: netlink/route/link.h: No such file or directory
> in_netlink.c:44:30: error: netlink/route/tc.h: No such file or directory
>
> Gustavo, maybe?
I blame Maxime's bump :)
Patch ready though.
>> powerpc | libcap-2.24 | NOK | http://autobuild.buildroot.net/results/be3466bacf99f8796d4cb73440e40f29041d7848/
>> powerpc | libcap-2.24 | NOK | http://autobuild.buildroot.net/results/b2140fc00e3de3ac401a49d2920bcf695f6aa184/
>> powerpc | libcap-2.24 | NOK | http://autobuild.buildroot.net/results/b6ee496683e91d73fd55111beb0e40fc6fc90be7/
>> powerpc | libcap-2.24 | NOK | http://autobuild.buildroot.net/results/6eadc312e621953345e6c25c89625da6e6d54868/
>
> The kernel headers problem. We need to re-add a dependency on kernel
> headers >= 3.0 I believe. Gustavo, what do you think?
I'll say it once more and sorry for the bad language.
That toolchain is f***** up in headers-land.
We can exclude it via deps, blacklist it or get rid of it.
Since it's the headers that are busted i'd vote for option 3, it's just
a matter of time before it shows up in some other package.
>> bfin | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/afadd15313ceb5b2dbe3bcef48a9bc8a5108b061/
>> sh4 | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/cc599de01d56177a74c5563cc0b9932754a34d55/
>> bfin | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/bd6575362a3ce97e24b65180fddbc3eae4bc10fb/
>
> Gazillions of:
>
> /home/buildroot/instance-0/output/build/libmemcached-1.0.18/libhashkit/rijndael.cc:1210: undefined reference to `___mf_lc_shift'
> /home/buildroot/instance-0/output/build/libmemcached-1.0.18/libhashkit/rijndael.cc:1210: undefined reference to `___mf_lc_mask'
> /home/buildroot/instance-0/output/build/libmemcached-1.0.18/libhashkit/rijndael.cc:1210: undefined reference to `___mf_lc_mask'
> /home/buildroot/instance-0/output/build/libmemcached-1.0.18/libhashkit/rijndael.cc:1210: undefined reference to `___mf_lookup_cache'
>
> For no apparent reason: some configs above are static, but some are
> not. Gustavo, you are our libmemcached guy :-)
Incomplete external toolchain libmudflap handling, patch is easy enough
to ditch the support, but we're missing the libmudflapth copies basically.
It's been deprecated for gcc >= 4.9 though so it probably doesn't make
much sense to fix it for external toolchains (if many shipped libmudflap
we'd seen this failure a lot more).
Regards.
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2014-11-11 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-11-10 Thomas Petazzoni
@ 2014-11-11 22:49 ` Thomas Petazzoni
2014-11-11 23:41 ` Gustavo Zacarias
` (4 more replies)
0 siblings, 5 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2014-11-11 22:49 UTC (permalink / raw)
To: buildroot
Hello,
Yann, Gustavo, Bernd, Nathaniel, Maxime, Samuel, Peter, please read on,
there is some stuff for you below :-)
On Tue, 11 Nov 2014 08:30:14 +0100 (CET), Thomas Petazzoni wrote:
> Build statistics for 2014-11-10
> ===============================
>
> success : 197
> failures : 49
> timeouts : 4
> TOTAL : 250
So a 20% failure rate. Not too bad, but we definitely need to improve
this.
> i486 | alsa-lib-1.0.28 | NOK | http://autobuild.buildroot.net/results/6ce1ecdf2bf1f14f1497e9960a1b6689568a3658/
> powerpc | alsa-lib-1.0.28 | NOK | http://autobuild.buildroot.net/results/a990b0deb0269e91bcd7fb008eb40a2e00350114/
This is the same problem twice: uClibc behaving badly when vfork() is
used in static linking configurations. This is now fixed for the
internal toolchain backend. The first build failure is with an external
Crosstool-NG toolchain using uClibc. Yann, what would be your
recommendation here? Is it something you intend to fix upstream in
Crosstool-NG? Or should I add an exception for this toolchain to not be
used in static linking configurations?
The second toolchain is a Buildroot toolchain, so this problem will go
away once I rebuild all the external Buildroot toolchain with the
latest Buildroot version.
> mipsel | alsa-utils-1.0.28 | NOK | http://autobuild.buildroot.net/results/045782ef114689c2cb7171b15f63f2770139806a/
Fixed by
http://git.buildroot.net/buildroot/commit/?id=48fe144111652547cf72d2bf3e8e15f36ee40b6d.
> bfin | bmon-3.5 | NOK | http://autobuild.buildroot.net/results/4d0c3c8b68b37f532378f19041379cb5c5798950/
in_netlink.c:40:29: error: netlink/netlink.h: No such file or directory
in_netlink.c:41:27: error: netlink/cache.h: No such file or directory
in_netlink.c:42:27: error: netlink/utils.h: No such file or directory
in_netlink.c:43:32: error: netlink/route/link.h: No such file or directory
in_netlink.c:44:30: error: netlink/route/tc.h: No such file or directory
Gustavo, maybe?
> i686 | checking whether /home/peko... | TIM | http://autobuild.buildroot.net/results/a7763e614d960e044d757eaf971c8a2777485f23/
Ignore.
> microblazeel | clamav-0.98.4 | NOK | http://autobuild.buildroot.net/results/2bed33fe03c8e49e7766f14020beea0d8e205fc1/
CCLD clamscan
../libclamav/.libs/libclamav.so: undefined reference to `bzDecompress'
../libclamav/.libs/libclamav.so: undefined reference to `bzDecompressInit'
../libclamav/.libs/libclamav.so: undefined reference to `bzDecompressEnd'
collect2: error: ld returned 1 exit status
Linking issue against the bzip2 library.
Bernd?
> x86_64 | czmq-v3.0.0 | NOK | http://autobuild.buildroot.net/results/8a8ddc4c9abda5366a3e76ae98f99b821aa52b09/
checking for zmq_init in -lzmq... no
configure: error: cannot link with -lzmq, install libzmq.
make: *** [/home/test/autobuild/instance-1/output/build/czmq-v3.0.0/.stamp_configured] Error 1
make: Leaving directory `/home/test/autobuild/instance-1/buildroot'
Don't know. Anyone to investigate this one?
> x86_64 | fltk-1.3.2 | NOK | http://autobuild.buildroot.net/results/58a36291201a848a0a11cbb2b200c2b39434046c/
> x86_64 | fltk-1.3.2 | NOK | http://autobuild.buildroot.net/results/fe53d0e9ad7c152105cb37a18e4d712bbde3398d/
Linking fluid...
/home/peko/autobuild/instance-1/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/libxcb-shm.so.0: undefined reference to `xcb_get_reply_fds'
/home/peko/autobuild/instance-1/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/libxcb-shm.so.0: undefined reference to `xcb_send_fd'
collect2: error: ld returned 1 exit status
Bernd, you are our X.org expert. Can you have a look? It might be worth
mentioning that fltk 1.3.3 has been released on November 3rd, so we
could try to upgrade and see if it fixes the problem.
> x86_64 | host-mysql-5.1.73 | NOK | http://autobuild.buildroot.net/results/a0ff4949d621caf4cada6ae3f66ed38f569d34b9/
checking for tgetent in -ltinfo... no
checking for termcap functions library... configure: error: No curses/termcap library found
Missing host-ncurses dependency. Nathaniel, since this is happening on
your build server, maybe you could have a look?
> powerpc | libcap-2.24 | NOK | http://autobuild.buildroot.net/results/be3466bacf99f8796d4cb73440e40f29041d7848/
> powerpc | libcap-2.24 | NOK | http://autobuild.buildroot.net/results/b2140fc00e3de3ac401a49d2920bcf695f6aa184/
> powerpc | libcap-2.24 | NOK | http://autobuild.buildroot.net/results/b6ee496683e91d73fd55111beb0e40fc6fc90be7/
> powerpc | libcap-2.24 | NOK | http://autobuild.buildroot.net/results/6eadc312e621953345e6c25c89625da6e6d54868/
The kernel headers problem. We need to re-add a dependency on kernel
headers >= 3.0 I believe. Gustavo, what do you think?
> bfin | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/afadd15313ceb5b2dbe3bcef48a9bc8a5108b061/
> sh4 | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/cc599de01d56177a74c5563cc0b9932754a34d55/
> bfin | libmemcached-1.0.18 | NOK | http://autobuild.buildroot.net/results/bd6575362a3ce97e24b65180fddbc3eae4bc10fb/
Gazillions of:
/home/buildroot/instance-0/output/build/libmemcached-1.0.18/libhashkit/rijndael.cc:1210: undefined reference to `___mf_lc_shift'
/home/buildroot/instance-0/output/build/libmemcached-1.0.18/libhashkit/rijndael.cc:1210: undefined reference to `___mf_lc_mask'
/home/buildroot/instance-0/output/build/libmemcached-1.0.18/libhashkit/rijndael.cc:1210: undefined reference to `___mf_lc_mask'
/home/buildroot/instance-0/output/build/libmemcached-1.0.18/libhashkit/rijndael.cc:1210: undefined reference to `___mf_lookup_cache'
For no apparent reason: some configs above are static, but some are
not. Gustavo, you are our libmemcached guy :-)
> bfin | libshairplay-64d59e3087f829... | NOK | http://autobuild.buildroot.net/results/f08787c7965c5594d9560db0aa2adb7b07a65a45/
libshairplay_la-http_parser.o
dnssd.c:74:21: error: dns_sd.h: No such file or directory
dnssd.c:78: error: expected declaration specifiers or '...' before '*' token
dnssd.c:80: error: expected ')' before '*' token
dnssd.c:93: error: expected ')' before 'sdRef'
dnssd.c:96: error: expected ')' before '*' token
Maxime, can you have a look? You are the person who added libshairplay
in the first place.
> nios2 | libssh2-1.4.3 | NOK | http://autobuild.buildroot.net/results/80dd3131cacecd629a72c38c1487d7b4ccb47a60/
checking for libgcrypt... no
configure: error: cannot find OpenSSL or Libgcrypt,
try --with-libssl-prefix=PATH or --with-libgcrypt-prefix=PATH
Related to http://patchwork.ozlabs.org/patch/364983/ maybe?
Someone to look into this?
> nios2 | minidlna-1.1.4 | NOK | http://autobuild.buildroot.net/results/df7da91985a7bf2b05093bae7379ef22362a44fc/
checking for avformat_open_input in -lavformat... no
configure: error: Could not find libavformat - part of ffmpeg
make: *** [/home/buildroot/instance-0/output/build/minidlna-1.1.4/.stamp_configured] Error 1
make: Leaving directory `/home/buildroot/instance-0/buildroot'
Some ffmpeg related problem. Bernd, maybe?
> bfin | mpdecimal-2.4.0 | NOK | http://autobuild.buildroot.net/results/df9a68c43eaf26a60865bf07c5913d65f051288c/
Tries to build a shared library in a pure static lib context. Since I
added mpdecimal, I guess this one is on my plate.
> arm | nodejs-0.10.33 | NOK | http://autobuild.buildroot.net/results/e1fb34818ff1167aa008b4011befb9fd14c81293/
Fixed by http://git.buildroot.net/buildroot/commit/?id=e712638b4adc6e18b3ce99ab37b94530e9aa786f.
> i686 | pulseaudio-5.0 | TIM | http://autobuild.buildroot.net/results/74e233383535f4459216c05fc705ee6b67707ac0/
Ignore.
> powerpc | python-2.7.8 | NOK | http://autobuild.buildroot.net/results/69d23eefe2a23ee130f723c9dfa9a1a875698dc7/
uClibc bug. Vicente has pinged again the uClibc folks. Not sure what we
can do about this...
> i686 | qemu-2.1.2 | NOK | http://autobuild.buildroot.net/results/9efc2b14a28fd21ed2ce492f41de538673d13dce/
> i686 | qemu-2.1.2 | NOK | http://autobuild.buildroot.net/results/0f640d6b701bb854ada2023861a234dfe489f038/
> x86_64 | qemu-2.1.2 | NOK | http://autobuild.buildroot.net/results/c58f7e10a416e0eaf7e49f0bb5ce9e6f85bc1559/
> x86_64 | qemu-2.1.2 | NOK | http://autobuild.buildroot.net/results/5979559734620358a92186a6e67aea46b6034b44/
ERROR: fdt disabled but some requested targets require it.
You can turn off fdt only if you also disable all the system emulation
targets which need it (by specifying a cut down --target-list).
Yann ?
> i686 | qt5webkit-5.3.2 | NOK | http://autobuild.buildroot.net/results/af8f3d3cc018006cee58d57cd9e8c6d8b3de3247/
AttributeError: 'dict_keys' object has no attribute 'sort'
make[3]: *** [generated/udis86_itab.c] Error 1
make[3]: *** Waiting for unfinished jobs....
Smells like a python2 vs. python3 issue. Maybe qt5webkit needs a
dependency on host-python, and use python2 explicitly? Or maybe it can
be fixed to be python3 compatible. Samuel, maybe?
> powerpc | rpm-5.2.0 | TIM | http://autobuild.buildroot.net/results/839b9044e936d992f12dd802b1d7578030e95f2d/
Ignore.
> powerpc | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/caf9899e529495b349df1c4a926749b98b4941cc/
> powerpc | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/50d5c1f7d234c12b00792c0a3a88885c1e3f1525/
> i686 | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/4e6fea56a1ae075ce0a286e20ff891c75762f10d/
> mips64el | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/84d3ec783b6d66e30e6fae9bc5d2a14fe9f2997a/
> xtensa | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/6d6ea6ef929ad1d47d9773eb1a62d85a16e54fa5/
> bfin | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/737c523cf856205a6cfa06da1156a350e8998624/
> arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/a713bc6de2c2cdca01a9d8852395cda7c9368e50/
> arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/811a7bad83b825e621ee86de216024d67f04a46e/
> x86_64 | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/6988e8d23db8e575b409cbddad0a6e2fdf29ba36/
> bfin | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/9daaf33512d6b7573acb0c0f62c4a0b26396cf64/
> arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/59d80e3d7487dd68b9273af70517adabec65c593/
> arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/db8b78cf6f3e7b940510ee94b58b96ece396a6cf/
> arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/6ff11e1a03106025883e86739bf73f99e976f817/
> arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/9c2396573db3cf1f40f5445c214d4e611989c4ad/
> x86_64 | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/90312a2bacc94dd79d8f5540aca7546061b0eb03/
> arm | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/2dc638f751ad635690225404878d13fd1748b81a/
> x86_64 | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/b6e63b198b3b3a181a509d57a21282e77b2b196c/
> powerpc | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/1d57af90b482b7bf300483ffb3dbfb1d449aa014/
> sh4a | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/8d406922b5986ba297aed9cca90adf9a1b995f6d/
> powerpc | schifra-0.0.1 | NOK | http://autobuild.buildroot.net/results/75d45ae59b30ca394c1f409e53af931c27f8120b/
Peter, you really don't want to mark it as broken for now? We can
always revert once the issue gets resolved upstream, if it gets
resolved before the final 2014.11 is out. In the mean time, it's
unnecessarily polluting the build results.
> arm | tn5250-0.17.4 | TIM | http://autobuild.buildroot.net/results/0988b54f84baa927f4ea789148f8d5ead0547d9b/
Ignore.
> arm | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/6b1123ea69c79bdd73bb85d2c8c3aac153a6f99a/
checking for GLES2/gl2.h... yes
checking whether to use OpenGL ES 2 support... configure: error: Cannot enable OpenGL ES 2 support without EGL
make: *** [/home/peko/autobuild/instance-0/output/build/webkit-1.11.5/.stamp_configured] Error 1
make: Leaving directory `/home/peko/autobuild/instance-0/buildroot'
Bernd, an OpenGL issue for you :)
> bfin | zeromq-4.0.4 | NOK | http://autobuild.buildroot.net/results/e63e422c77d9bcec8b58405dbf6a236be0d2a31b/
The atomic intrinsics dependency issue.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2014-08-31 16:58 ` Frank Bergmann
@ 2014-08-31 21:13 ` Ezequiel Garcia
0 siblings, 0 replies; 38+ messages in thread
From: Ezequiel Garcia @ 2014-08-31 21:13 UTC (permalink / raw)
To: buildroot
On 31 Aug 06:58 PM, Frank Bergmann wrote:
> On 28.08.2014 Ezequiel Garcia wrote:
> >(Ccing Frank)
> >
> >On 25 Aug 06:16 PM, Thomas Petazzoni wrote:
> >>> nios2 | util-linux-2.24.2 | NOK | http://autobuild.buildroot.net/results/fd30974bf2f976c600717268ce340f73d48dda34/
> >>
> >>sys-utils/prlimit.o: In function `main':
> >>prlimit.c:(.text.startup+0x440): undefined reference to `prlimit64'
> >>prlimit.c:(.text.startup+0x5d0): undefined reference to `prlimit64'
> >>collect2: error: ld returned 1 exit status
> >>
> >>Ezequiel, an idea?
> >>
> >
> >This is probably the same missing fallocate64 deal. The function is simply not
> >available, yet detected (Frank: please correct me if I'm wrong).
> >
> >By doing something similar to what we do for e2fsprogs:
> >
> >+ifeq ($(BR2_nios2),y)
> >+UTIL_LINUX_CONF_ENV += ac_cv_func_prlimit=no
> >+endif
> >+
> >
> >I can avoid the SYS_prlimit64 usage. However, we then get conflicting types:
> >
> > CC sys-utils/prlimit.o
> > CC sys-utils/lscpu.o
> >sys-utils/prlimit.c:139:12: error: conflicting types for 'prlimit'
> >In file included from /home/zeta/buildroot/buildroot-nios2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/sys/resource.h:25:0,
> > from sys-utils/prlimit.c:28:
> >/home/zeta/buildroot/buildroot-nios2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/bits/resource.h:313:12: note: previous declaration of 'prlimit' was here
> >
> >I wonder if anyone has an idea to disable the prlimit build, and all the
> >commands that depend on it.
> >
> >Notice that we have a similar issue on other packages, but the proposed
> >solution's have been too hacky to be accepted:
> >
> >http://lists.busybox.net/pipermail/buildroot/2014-May/096203.html
>
> I see a new toolchain on the mentor site: 2014.05-47 from August. Maybe
Thanks a lot for the hint!
> this release fixes some of the issues we have with the current
> toolchain. I will make some tests in the next week(s).
>
Indeed, the new toolchain seem to be working much better now. Packages
that have issues with the 2013.05 toolchain build fine with the new one,
such as util-linux, e2fsprogs (reverting the fallocate64 modifications),
fio, and dhcpd.
As far as I can see, they have fixed the issues with fallocate64, prlimit64
and the broken linux headers.
As agreed with Peter on the IRC, I'll push a patch adding the new toolchain
and leave the old one around for a while. Any further test is welcome.
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2014-08-28 12:52 ` Ezequiel Garcia
@ 2014-08-31 16:58 ` Frank Bergmann
2014-08-31 21:13 ` Ezequiel Garcia
0 siblings, 1 reply; 38+ messages in thread
From: Frank Bergmann @ 2014-08-31 16:58 UTC (permalink / raw)
To: buildroot
On 28.08.2014 Ezequiel Garcia wrote:
> (Ccing Frank)
>
> On 25 Aug 06:16 PM, Thomas Petazzoni wrote:
>>> nios2 | util-linux-2.24.2 | NOK | http://autobuild.buildroot.net/results/fd30974bf2f976c600717268ce340f73d48dda34/
>>
>> sys-utils/prlimit.o: In function `main':
>> prlimit.c:(.text.startup+0x440): undefined reference to `prlimit64'
>> prlimit.c:(.text.startup+0x5d0): undefined reference to `prlimit64'
>> collect2: error: ld returned 1 exit status
>>
>> Ezequiel, an idea?
>>
>
> This is probably the same missing fallocate64 deal. The function is simply not
> available, yet detected (Frank: please correct me if I'm wrong).
>
> By doing something similar to what we do for e2fsprogs:
>
> +ifeq ($(BR2_nios2),y)
> +UTIL_LINUX_CONF_ENV += ac_cv_func_prlimit=no
> +endif
> +
>
> I can avoid the SYS_prlimit64 usage. However, we then get conflicting types:
>
> CC sys-utils/prlimit.o
> CC sys-utils/lscpu.o
> sys-utils/prlimit.c:139:12: error: conflicting types for 'prlimit'
> In file included from /home/zeta/buildroot/buildroot-nios2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/sys/resource.h:25:0,
> from sys-utils/prlimit.c:28:
> /home/zeta/buildroot/buildroot-nios2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/bits/resource.h:313:12: note: previous declaration of 'prlimit' was here
>
> I wonder if anyone has an idea to disable the prlimit build, and all the
> commands that depend on it.
>
> Notice that we have a similar issue on other packages, but the proposed
> solution's have been too hacky to be accepted:
>
> http://lists.busybox.net/pipermail/buildroot/2014-May/096203.html
I see a new toolchain on the mentor site: 2014.05-47 from August. Maybe
this release fixes some of the issues we have with the current
toolchain. I will make some tests in the next week(s).
Regards,
Frank Bergmann.
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2014-08-25 16:16 ` [Buildroot] Analysis of build results Thomas Petazzoni
` (3 preceding siblings ...)
2014-08-26 6:17 ` Alexander Lukichev
@ 2014-08-28 12:52 ` Ezequiel Garcia
2014-08-31 16:58 ` Frank Bergmann
4 siblings, 1 reply; 38+ messages in thread
From: Ezequiel Garcia @ 2014-08-28 12:52 UTC (permalink / raw)
To: buildroot
(Ccing Frank)
On 25 Aug 06:16 PM, Thomas Petazzoni wrote:
> > nios2 | util-linux-2.24.2 | NOK | http://autobuild.buildroot.net/results/fd30974bf2f976c600717268ce340f73d48dda34/
>
> sys-utils/prlimit.o: In function `main':
> prlimit.c:(.text.startup+0x440): undefined reference to `prlimit64'
> prlimit.c:(.text.startup+0x5d0): undefined reference to `prlimit64'
> collect2: error: ld returned 1 exit status
>
> Ezequiel, an idea?
>
This is probably the same missing fallocate64 deal. The function is simply not
available, yet detected (Frank: please correct me if I'm wrong).
By doing something similar to what we do for e2fsprogs:
+ifeq ($(BR2_nios2),y)
+UTIL_LINUX_CONF_ENV += ac_cv_func_prlimit=no
+endif
+
I can avoid the SYS_prlimit64 usage. However, we then get conflicting types:
CC sys-utils/prlimit.o
CC sys-utils/lscpu.o
sys-utils/prlimit.c:139:12: error: conflicting types for 'prlimit'
In file included from /home/zeta/buildroot/buildroot-nios2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/sys/resource.h:25:0,
from sys-utils/prlimit.c:28:
/home/zeta/buildroot/buildroot-nios2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/bits/resource.h:313:12: note: previous declaration of 'prlimit' was here
I wonder if anyone has an idea to disable the prlimit build, and all the
commands that depend on it.
Notice that we have a similar issue on other packages, but the proposed
solution's have been too hacky to be accepted:
http://lists.busybox.net/pipermail/buildroot/2014-May/096203.html
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2014-08-25 16:16 ` [Buildroot] Analysis of build results Thomas Petazzoni
` (2 preceding siblings ...)
2014-08-25 21:13 ` Jörg Krause
@ 2014-08-26 6:17 ` Alexander Lukichev
2014-08-28 12:52 ` Ezequiel Garcia
4 siblings, 0 replies; 38+ messages in thread
From: Alexander Lukichev @ 2014-08-26 6:17 UTC (permalink / raw)
To: buildroot
Hi Thomas, all,
2014-08-25 19:16 GMT+03:00 Thomas Petazzoni <
thomas.petazzoni@free-electrons.com>:
> > bfin | zmqpp-36413487f05b165dfc82a... | NOK |
> http://autobuild.buildroot.net/results/97bcfe2d3765945cd7a7ba30cda21b08bf53ca86/
>
> Did I say I love C++ ?
>
> The same issue appears on other architectures apparently:
>
> http://autobuild.buildroot.org/?reason=zmqpp-36413487f05b165dfc82ad307a5a1c36a795e607
> .
>
> Simon, you're the original submitter of the zmqpp package. Could you
> take a look? Or maybe Alexander since he has also contributed a bump of
> the zmqpp package?
>
>
I'll try to solve some of those, at least I'll look into it. There seems to
be several issues there, though.
--
Best regards,
Alexander Lukichev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140826/ddf46931/attachment.html>
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2014-08-25 16:16 ` [Buildroot] Analysis of build results Thomas Petazzoni
2014-08-25 16:26 ` Phil Eichinger
2014-08-25 21:07 ` Peter Korsgaard
@ 2014-08-25 21:13 ` Jörg Krause
2014-08-26 6:17 ` Alexander Lukichev
2014-08-28 12:52 ` Ezequiel Garcia
4 siblings, 0 replies; 38+ messages in thread
From: Jörg Krause @ 2014-08-25 21:13 UTC (permalink / raw)
To: buildroot
On 08/25/2014 06:16 PM, Thomas Petazzoni wrote:
>
>> bfin | upmpdcli-0.7.1 | NOK | http://autobuild.buildroot.net/results/8e0db6a753c7d2af2cdb11f025879c9cdb57a25d/
> libupnpp/log.cxx:31: error: no matching function for call to 'std::basic_ofstream<char, std::char_traits<char> >::open(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::_Ios_Openmode)'
>
> I love C++.
>
> Joerg, since you are the original submitter of the upmpdcli package,
> can you look into this issue?
I love C++, too :-) Especially C++11, which is not supported by GNU
Toolchains for Blackfin.
Patch is send to the mailing list.
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2014-08-25 16:16 ` [Buildroot] Analysis of build results Thomas Petazzoni
2014-08-25 16:26 ` Phil Eichinger
@ 2014-08-25 21:07 ` Peter Korsgaard
2014-08-25 21:13 ` Jörg Krause
` (2 subsequent siblings)
4 siblings, 0 replies; 38+ messages in thread
From: Peter Korsgaard @ 2014-08-25 21:07 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> arm | make: *** [core-dependencie... | NOK | http://autobuild.buildroot.net/results/13019e563771ab2a6929427798e191546cde1fd9/
> Peter's machine trying to build XBMC. Peter, when will you start using
> autobuild-run so that we can solve such issues in a common fashion?
I'm just back from holidays now, but it's on my shortlist to move to
autobuild-run asap (E.G. still within August).
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2014-08-25 16:26 ` Phil Eichinger
@ 2014-08-25 17:47 ` Thomas Petazzoni
0 siblings, 0 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2014-08-25 17:47 UTC (permalink / raw)
To: buildroot
Dear Phil Eichinger,
On Mon, 25 Aug 2014 18:26:04 +0200, Phil Eichinger wrote:
> > mipsel | sispmctl-3.1 | NOK |
> > http://autobuild.buildroot.net/results/6473088e751d3ab3a5227e9d7876966934e66378/
> >
> > Static linking issue.
> >
> > Phil, since you are the original submitter of the sispmctl package, can
> > you look into this issue?
> >
>
> Yep, no problem, going to need it on mipsel soon anyway.
Ok, thanks. However, notice that the issue is not mipsel related, but
related to static linking. I'm pretty sure the same issue can be
reproduced on other architectures.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2014-08-25 16:16 ` [Buildroot] Analysis of build results Thomas Petazzoni
@ 2014-08-25 16:26 ` Phil Eichinger
2014-08-25 17:47 ` Thomas Petazzoni
2014-08-25 21:07 ` Peter Korsgaard
` (3 subsequent siblings)
4 siblings, 1 reply; 38+ messages in thread
From: Phil Eichinger @ 2014-08-25 16:26 UTC (permalink / raw)
To: buildroot
On 25 August 2014 18:16, Thomas Petazzoni <
thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
*snip*
> mipsel | sispmctl-3.1 | NOK |
> http://autobuild.buildroot.net/results/6473088e751d3ab3a5227e9d7876966934e66378/
>
> Static linking issue.
>
> Phil, since you are the original submitter of the sispmctl package, can
> you look into this issue?
>
Yep, no problem, going to need it on mipsel soon anyway.
Cheers, Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140825/40f11b40/attachment.html>
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Buildroot] Analysis of build results
2014-08-25 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-24 Thomas Petazzoni
@ 2014-08-25 16:16 ` Thomas Petazzoni
2014-08-25 16:26 ` Phil Eichinger
` (4 more replies)
0 siblings, 5 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2014-08-25 16:16 UTC (permalink / raw)
To: buildroot
Hello,
Joerg, Phil, Ezequiel, Simon, Alexander, see below.
On Mon, 25 Aug 2014 08:30:11 +0200 (CEST), Thomas Petazzoni wrote:
> arm | elfutils-0.155 | NOK | http://autobuild.buildroot.net/results/e2449b2a4f2239e832adc2f51f0c7266808b7068/
-shared and -static in the same command line :)
> bfin | libgeotiff-1.3.0 | NOK | http://autobuild.buildroot.net/results/24ab80be6cc20bbdb2f1860a373f1d15e36ac0c6/
checking for TIFFOpen in -ltiff... no
configure: error: You will need to substantially rewrite libxtiff to
build libgeotiff without libtiff
Don't know, need to reproduce.
> bfin | libmatroska-1.3.0 | NOK | http://autobuild.buildroot.net/results/f9689e9606844f24d13fa08c3cb9f6b9bb3adf70/
Seems like it's trying to build a shared library in a pure static
library context.
> arm | make: *** [core-dependencie... | NOK | http://autobuild.buildroot.net/results/13019e563771ab2a6929427798e191546cde1fd9/
Peter's machine trying to build XBMC. Peter, when will you start using
autobuild-run so that we can solve such issues in a common fashion?
> arm | perl-gd-2.53 | NOK | http://autobuild.buildroot.net/results/38aeac634b332866ae50b6b59361d7385500ce37/
Issue caused by the host Perl being too old. I continue to suggest to
mark perl-gd as broken for the 2014.08 release.
> arm | procps-ng-3.3.9 | NOK | http://autobuild.buildroot.net/results/f1de9bdf857ca0347ecd23c0d39179dadfd9ec97/
So after the compiler has been used to build gazillions of packages,
procps-ng decides that the C compiler does not work:
checking whether the C compiler works... no
configure: error: in `/home/test/autobuild/instance-3/output/build/procps-ng-3.3.9':
configure: error: C compiler cannot create executables
See `config.log' for more details
make: *** [/home/test/autobuild/instance-3/output/build/procps-ng-3.3.9/.stamp_configured] Error 77
Need to reproduce.
And someone should work on improving autobuild-run to store the
config.log file when available.
> mipsel | sispmctl-3.1 | NOK | http://autobuild.buildroot.net/results/6473088e751d3ab3a5227e9d7876966934e66378/
Static linking issue.
Phil, since you are the original submitter of the sispmctl package, can
you look into this issue?
> bfin | uboot-tools-2014.07 | NOK | http://autobuild.buildroot.net/results/1530f8247d1652da5779994f298141b1572ce74f/
Someone tries to strip FLAT binaries.
> bfin | upmpdcli-0.7.1 | NOK | http://autobuild.buildroot.net/results/8e0db6a753c7d2af2cdb11f025879c9cdb57a25d/
libupnpp/log.cxx:31: error: no matching function for call to 'std::basic_ofstream<char, std::char_traits<char> >::open(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::_Ios_Openmode)'
I love C++.
Joerg, since you are the original submitter of the upmpdcli package,
can you look into this issue?
> nios2 | util-linux-2.24.2 | NOK | http://autobuild.buildroot.net/results/fd30974bf2f976c600717268ce340f73d48dda34/
sys-utils/prlimit.o: In function `main':
prlimit.c:(.text.startup+0x440): undefined reference to `prlimit64'
prlimit.c:(.text.startup+0x5d0): undefined reference to `prlimit64'
collect2: error: ld returned 1 exit status
Ezequiel, an idea?
> sh4 | webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/55205239b74015b7b9e8dce898d89e5246e81846/
Some tuning is needed to get webkit to build on SH4. However, I would
propose to mark Webkit as not available on SuperH, until we bump to a
newer Webkit version.
./DerivedSources/JavaScriptCore/LLIntAssembly.h: In static member function 'static JSC::JSValue JSC::LLInt::CLoop::execute(JSC::CallFrame*, JSC::OpcodeID, bool)':
./DerivedSources/JavaScriptCore/LLIntAssembly.h:2548:33: error: 'Double2Ints' was not declared in this scope
CXX Source/JavaScriptCore/parser/libjavascriptcoregtk_1_0_la-Lexer.lo
> bfin | xapp_luit-1.1.1 | NOK | http://autobuild.buildroot.net/results/13a97461e3b6098e59cfcd829e6bcafa51e50bb4/
luit.o: In function `_main':
luit.c:(.text+0xbce): undefined reference to `_fork'
depends on BR2_USE_MMU
> bfin | xapp_xfs-1c8459eafc04997751... | NOK | http://autobuild.buildroot.net/results/7a89f79499e167cc98449a045604d25d4fc88484/
osglue.o: In function `_CloneMyself':
os/osglue.c:(.text+0x58): undefined reference to `_fork'
depends on BR2_USE_MMU
> powerpc | xscreensaver-5.22 | NOK | http://autobuild.buildroot.net/results/2c10e5bda7c5426feb95f8e9d7052945274aefa2/
Another compiler that doesn't work:
checking for C compiler default output file name...
configure: error: in `/home/test/autobuild/instance-2/output/build/xscreensaver-5.22':
configure: error: C compiler cannot create executables
See `config.log' for more details.
> microblazeel | xserver_xorg-server-1.16.0 | NOK | http://autobuild.buildroot.net/results/4d37c5594c0916c27c897b0d2545d1c5cc492598/
In file included from fbbits.c:27:0:
fb.h:94:2: error: #error "GLYPHPADBYTES must be 4"
#error "GLYPHPADBYTES must be 4"
Weird, that's typically when the X.org server is built for an
unsupported architecture. We never built the X.org server on Microblaze
so far?
> bfin | zmqpp-36413487f05b165dfc82a... | NOK | http://autobuild.buildroot.net/results/97bcfe2d3765945cd7a7ba30cda21b08bf53ca86/
Did I say I love C++ ?
The same issue appears on other architectures apparently:
http://autobuild.buildroot.org/?reason=zmqpp-36413487f05b165dfc82ad307a5a1c36a795e607.
Simon, you're the original submitter of the zmqpp package. Could you
take a look? Or maybe Alexander since he has also contributed a bump of
the zmqpp package?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2020-02-29 23:17 UTC | newest]
Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-30 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-29 Thomas Petazzoni
2014-08-30 9:07 ` [Buildroot] Analysis of build results Thomas Petazzoni
2014-09-01 12:51 ` [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-29 Vicente Olivert Riera
-- strict thread matches above, loose matches on Subject: below --
2020-02-27 9:31 [Buildroot] [autobuild.buildroot.net] Daily results for 2020-02-26 Thomas Petazzoni
2020-02-27 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni
2020-02-27 23:06 ` Max Filippov
2020-02-27 23:18 ` Giulio Benetti
2020-02-28 8:03 ` Thomas Petazzoni
2020-02-28 18:06 ` Giulio Benetti
2020-02-28 6:21 ` Heiko Thiery
2020-02-28 7:56 ` Sergio Prado
2020-02-28 8:01 ` Thomas Petazzoni
2020-02-28 7:32 ` Romain Naour
2020-02-28 15:02 ` Peter Seiderer
2020-02-29 21:15 ` Romain Naour
2020-02-29 23:17 ` Peter Seiderer
2020-02-19 7:48 [Buildroot] [autobuild.buildroot.net] Daily results for 2020-02-18 Thomas Petazzoni
[not found] ` <20200220034343.2370e4e4@windsurf>
2020-02-20 13:36 ` [Buildroot] Analysis of build results Giulio Benetti
2020-02-21 8:23 ` Romain Naour
[not found] ` <94c8edad-773d-2b36-5daf-b6ee60dd747f@micronovasrl.com>
[not found] ` <3e7b016b-eca6-b768-3fca-8fd7e44d0299@micronovasrl.com>
[not found] ` <20200220190807.505b4fb2@windsurf>
[not found] ` <00751b5d-ca05-fe42-0e9b-6a1005a09e6d@micronovasrl.com>
[not found] ` <20200220192344.03785f04@windsurf>
[not found] ` <bcc10a0e-c54e-5b75-9b77-8922b85a925a@micronovasrl.com>
[not found] ` <fe7d07df-71a0-e317-6b91-ade479545ec4@smile.fr>
[not found] ` <28258465-4f79-3f47-189d-bb066b0aa9f7@micronovasrl.com>
2020-02-22 19:10 ` Romain Naour
2020-02-22 19:44 ` Giulio Benetti
2020-02-22 21:11 ` Fabrice Fontaine
2020-02-22 21:48 ` Giulio Benetti
2020-02-22 22:00 ` Fabrice Fontaine
2020-02-22 23:48 ` Romain Naour
2014-11-11 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-11-10 Thomas Petazzoni
2014-11-11 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni
2014-11-11 23:41 ` Gustavo Zacarias
2014-11-12 2:30 ` Nathaniel Roach
2014-11-12 14:09 ` Jörg Krause
2014-11-16 10:07 ` Yann E. MORIN
2014-11-22 11:10 ` Bernd Kuhls
2014-08-25 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-24 Thomas Petazzoni
2014-08-25 16:16 ` [Buildroot] Analysis of build results Thomas Petazzoni
2014-08-25 16:26 ` Phil Eichinger
2014-08-25 17:47 ` Thomas Petazzoni
2014-08-25 21:07 ` Peter Korsgaard
2014-08-25 21:13 ` Jörg Krause
2014-08-26 6:17 ` Alexander Lukichev
2014-08-28 12:52 ` Ezequiel Garcia
2014-08-31 16:58 ` Frank Bergmann
2014-08-31 21:13 ` Ezequiel Garcia
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.