* [Buildroot] [autobuild.buildroot.net] Daily results for 2021-03-03
@ 2021-03-04 8:15 Thomas Petazzoni
2021-03-04 21:49 ` [Buildroot] Analysis of build " Thomas Petazzoni
0 siblings, 1 reply; 16+ messages in thread
From: Thomas Petazzoni @ 2021-03-04 8:15 UTC (permalink / raw)
To: buildroot
Hello,
Autobuild statistics for 2021-03-03
===================================
branch | OK | NOK | TIM | TOT |
2020.02.x | 11 | 1 | 0 | 12 |
2020.11.x | 9 | 2 | 0 | 11 |
master | 87 | 31 | 0 | 118 |
next | 17 | 24 | 0 | 41 |
Classification of failures by reason for master
-----------------------------------------------
host-sentry-cli-1.57.0 | 4
dc3dd-7.2.641 | 3
kismet-2020-12-R3 | 2
libopenssl-1.1.1j | 2
tio-1.32 | 2
toolchain-external-linaro-a... | 2
zeromq-4.3.4 | 2
asterisk-16.14.1 | 1
belle-sip-4.4.8 | 1
dhcpcd-9.4.0 | 1
fuse-overlayfs-1.4.0 | 1
gstreamer1-mm-1.10.0 | 1
kvm-unit-tests-kvm-unit-tes... | 1
libgeos-3.9.0 | 1
libopenh264-2.1.1 | 1
libostree-2020.8 | 1
netopeer2-1.1.53 | 1
openblas-0.3.9 | 1
rt-tests-1.10 | 1
strace-5.10 | 1
unknown | 1
Detail of failures for master
-----------------------------
arch | reason | OK? | url | orph?
-------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
nios2 | asterisk-16.14.1 | NOK | http://autobuild.buildroot.net/results/24c0a6ca3b272711a1e6ceaa033925182d0d49c4 |
nios2 | belle-sip-4.4.8 | NOK | http://autobuild.buildroot.net/results/71f26fd81db8e9b19b3f18f3f3cefd9c768f094f |
arc | dc3dd-7.2.641 | NOK | http://autobuild.buildroot.net/results/4829278085da2409bb2902161f9984708411166a | ORPH
arc | dc3dd-7.2.641 | NOK | http://autobuild.buildroot.net/results/3b145a99a1f7498ee7fcd445f3cc319f548e9a81 | ORPH
arc | dc3dd-7.2.641 | NOK | http://autobuild.buildroot.net/results/c1cb2dd0b9e7547f3858e62281da3bd45b9a5b17 | ORPH
sparc | dhcpcd-9.4.0 | NOK | http://autobuild.buildroot.net/results/fba538d2ae4a1c53440ed73ced4023be27d7e9c2 |
riscv64 | fuse-overlayfs-1.4.0 | NOK | http://autobuild.buildroot.net/results/cfef18f3adf51edaedbbd193efbff19aebdfe508 |
mips64el | gstreamer1-mm-1.10.0 | NOK | http://autobuild.buildroot.net/results/b1c5989a3a09b39e504c21201e3e07c0afc2a1ea | ORPH
aarch64 | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/739d625673f9b2ce2d915ecdc21910c62618d145 |
microblazeel | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/b1779a7d46f6ee9c06864c3ca252f1cdad47cf08 |
i586 | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/a5fe402e3f4e538eb4584f345b029ef12ad43348 |
arc | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/abd3f886335f146ff6f16370484106bd8a205bda |
arc | kismet-2020-12-R3 | NOK | http://autobuild.buildroot.net/results/1c2885d75219aabadbb66ab66fe0dc4b4346ff1e | ORPH
i586 | kismet-2020-12-R3 | NOK | http://autobuild.buildroot.net/results/3a76afdbd8b564579bfb08a4d75b438dbd73ac2e | ORPH
powerpc64 | kvm-unit-tests-kvm-unit-tes... | NOK | http://autobuild.buildroot.net/results/06cce5030766fcc789f0ba4a76d2cbaa091300d0 |
nios2 | libgeos-3.9.0 | NOK | http://autobuild.buildroot.net/results/a05fdf1958f93a206c5c66c7f636b6650683626d | ORPH
mipsel | libopenh264-2.1.1 | NOK | http://autobuild.buildroot.net/results/26837f7c80a84e5ad31d5b15161848ebecc59917 |
riscv32 | libopenssl-1.1.1j | NOK | http://autobuild.buildroot.net/results/e7bf5db7745c56c4533c225260ff6c3fcd2000f5 |
riscv32 | libopenssl-1.1.1j | NOK | http://autobuild.buildroot.net/results/5b4834023eca039be59b969e3037bb23feeed6ac |
riscv64 | libostree-2020.8 | NOK | http://autobuild.buildroot.net/results/d42bce7ef9cf0f807b9ba7021af4a11f84e307d2 |
powerpc64 | netopeer2-1.1.53 | NOK | http://autobuild.buildroot.net/results/49efc0e93ad8fe30e5f32fed8a1efc1d2afd830e |
x86_64 | openblas-0.3.9 | NOK | http://autobuild.buildroot.net/results/d530db0f37e1e0462e3af1e1787e15f94ff21884 | ORPH
aarch64 | rt-tests-1.10 | NOK | http://autobuild.buildroot.net/results/c6a3cdd4a07f8918b164e0e1e85c92d8b14ec228 |
xtensa | strace-5.10 | NOK | http://autobuild.buildroot.net/results/6c679877e1a3f50d5e0bc4db3237e0c699bd7243 |
sparc | tio-1.32 | NOK | http://autobuild.buildroot.net/results/7cbace3ce72bbcce8ef36f71cba8071bfda9fc26 |
sparc64 | tio-1.32 | NOK | http://autobuild.buildroot.net/results/b9a671c46fa41875c1fd6a16790b314c16ef989b |
arm | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/d9b9a4b7c3660bd730a19ab09e44f24bc29e3f40 | ORPH
arm | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/13f9a551f5ac911e7daa2a382b0683d81486cffa | ORPH
powerpc | unknown | NOK | http://autobuild.buildroot.net/results/159d2c07060c235080711d1d0da0b2eae995d4bf |
or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/ed105d321c0bde99c293ab7328d57c3764db6f27 |
or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/ce351e0e97c2cacc17d4718d39941548c7558559 |
Classification of failures by reason for 2020.02.x
--------------------------------------------------
host-go-1.13.15 | 1
Detail of failures for 2020.02.x
--------------------------------
arch | reason | OK? | url | orph?
-------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
mips64el | host-go-1.13.15 | NOK | http://autobuild.buildroot.net/results/e48396969f14799833eab7602950cb15d25b4072 |
Classification of failures by reason for 2020.11.x
--------------------------------------------------
host-sentry-cli-1.57.0 | 1
zeromq-4.3.3 | 1
Detail of failures for 2020.11.x
--------------------------------
arch | reason | OK? | url | orph?
-------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
microblazeel | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/749a4cdca12f7d365cbec16028ccf3a3de671e05 |
i686 | zeromq-4.3.3 | NOK | http://autobuild.buildroot.net/results/a5f1c874b3e4827cf46706e6a06106d05811aa51 |
Classification of failures by reason for next
---------------------------------------------
mc-4.8.26 | 4
netopeer2-1.1.53 | 2
openmpi-4.0.0 | 2
package/ruby/ruby.mk:88: ru... | 2
unknown | 2
bustle-0.8.0 | 1
capnproto-0.8.0 | 1
dhcpcd-9.4.0 | 1
janet-1.15.0 | 1
libopenssl-1.1.1i | 1
libshout-2.4.5 | 1
mesa3d-20.3.4 | 1
micropython-1.14 | 1
monkey-1.6.9 | 1
mpd-0.22.3 | 1
pixman-0.40.0 | 1
toolchain-external-linaro-a... | 1
Detail of failures for next
---------------------------
arch | reason | OK? | url | orph?
-------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
arm | bustle-0.8.0 | NOK | http://autobuild.buildroot.net/results/f33b0a0a18d1b88d5ee726ec67aeff534d51140f | ORPH
riscv64 | capnproto-0.8.0 | NOK | http://autobuild.buildroot.net/results/69907885dd5e8e7a292ba8d61cb7dbd6962cf32f |
sparc64 | dhcpcd-9.4.0 | NOK | http://autobuild.buildroot.net/results/2bc9fb26635e44ef4aea143983b50b54ae40f626 |
powerpc | janet-1.15.0 | NOK | http://autobuild.buildroot.net/results/355e0992338a8d132050517f83a3884606b00529 |
riscv32 | libopenssl-1.1.1i | NOK | http://autobuild.buildroot.net/results/376c65488490ef385435a3e9d5a568893acbaa3d |
m68k | libshout-2.4.5 | NOK | http://autobuild.buildroot.net/results/a9f89b24a7e4a5090b26a5dfdfca47a58ee6a353 | ORPH
x86_64 | mc-4.8.26 | NOK | http://autobuild.buildroot.net/results/16ee8417f8d9192c91340e023d8e0b7ae0c2623d |
powerpc | mc-4.8.26 | NOK | http://autobuild.buildroot.net/results/f512d0367f8522fc22a700de41c1ef2f90a08b2a |
i686 | mc-4.8.26 | NOK | http://autobuild.buildroot.net/results/f3acd30494869eb78d2b65a02e5ee8ac7602d3a5 |
m68k | mc-4.8.26 | NOK | http://autobuild.buildroot.net/results/92dec890cd1d91aa673afd557be3edaca10c1f71 |
mips64el | mesa3d-20.3.4 | NOK | http://autobuild.buildroot.net/results/870acf5f007255d6ce7a7941addcbed6c90c381d |
xtensa | micropython-1.14 | NOK | http://autobuild.buildroot.net/results/b0d14dbc599aa121754f5dab9035ec042e9ac545 |
aarch64 | monkey-1.6.9 | NOK | http://autobuild.buildroot.net/results/f6432a77b33cb4b38201211d5f2f2564c05d1457 | ORPH
x86_64 | mpd-0.22.3 | NOK | http://autobuild.buildroot.net/results/836445f4730704322cd7bcc3c083dacef7bf48f4 |
arc | netopeer2-1.1.53 | NOK | http://autobuild.buildroot.net/results/2f5b80cac4c12d8425ff38be6aaaa345574f7710 |
m68k | netopeer2-1.1.53 | NOK | http://autobuild.buildroot.net/results/704f39a651990e3d730ba4bba3e10bd96ea23489 |
mipsel | openmpi-4.0.0 | NOK | http://autobuild.buildroot.net/results/0e575756592cc28bac0da8d9418e75ff7e2d51f7 | ORPH
mipsel | openmpi-4.0.0 | NOK | http://autobuild.buildroot.net/results/80be3da007d250c4780d51bb8afa6085b8512bd4 | ORPH
nios2 | package/ruby/ruby.mk:88: ru... | NOK | http://autobuild.buildroot.net/results/faa9fcfa701ac851fa6997fa2af1b0bff613dc54 |
arm | package/ruby/ruby.mk:88: ru... | NOK | http://autobuild.buildroot.net/results/7cd907b97811c0cfb89d8d402e4d974b9550e60a |
sh4 | pixman-0.40.0 | NOK | http://autobuild.buildroot.net/results/71418ca732156baed0650c6aa9f5fd8e7251cc2a |
arm | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/6ba6d7a8786421678209a29010f4713938efdc7c | ORPH
arm | unknown | NOK | http://autobuild.buildroot.net/results/b125bf54937f86aa07568de0040b960620ea4802 |
x86_64 | unknown | NOK | http://autobuild.buildroot.net/results/29e72418a8cb5cf821d8f139479b245c66bcaf98 |
--
http://autobuild.buildroot.net
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2021-03-03
2021-03-04 8:15 [Buildroot] [autobuild.buildroot.net] Daily results for 2021-03-03 Thomas Petazzoni
@ 2021-03-04 21:49 ` Thomas Petazzoni
2021-03-04 22:26 ` Yann E. MORIN
` (3 more replies)
0 siblings, 4 replies; 16+ messages in thread
From: Thomas Petazzoni @ 2021-03-04 21:49 UTC (permalink / raw)
To: buildroot
Hello,
Giulio, Heiko, Thomas DS there are specific questions for you below!
On Thu, 04 Mar 2021 08:15:14 -0000
Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> nios2 | asterisk-16.14.1 | NOK | http://autobuild.buildroot.net/results/24c0a6ca3b272711a1e6ceaa033925182d0d49c4
Some wonderful compiler issue.
utf8.c: In function 'ast_utf8_copy_string':
utf8.c:157:1: internal compiler error: Segmentation fault
Giulio, does this look like a known NIOS2 issue ?
> nios2 | belle-sip-4.4.8 | NOK | http://autobuild.buildroot.net/results/71f26fd81db8e9b19b3f18f3f3cefd9c768f094f |
/tmp/ccDtjRfo.s: Assembler messages:
/tmp/ccDtjRfo.s:210798: Error: branch offset out of range
Another wonderful nios2 toolchain issue. Giulio, what do you think ?
> arc | dc3dd-7.2.641 | NOK | http://autobuild.buildroot.net/results/4829278085da2409bb2902161f9984708411166a | ORPH
> arc | dc3dd-7.2.641 | NOK | http://autobuild.buildroot.net/results/3b145a99a1f7498ee7fcd445f3cc319f548e9a81 | ORPH
> arc | dc3dd-7.2.641 | NOK | http://autobuild.buildroot.net/results/c1cb2dd0b9e7547f3858e62281da3bd45b9a5b17 | ORPH
verify.h:132:30: error: negative width in bit-field 'verify_error_if_negative_size__'
132 | (struct { unsigned int verify_error_if_negative_size__: (R) ? 1 : -1; }))
This happens on RISC-V 32-bit, and on ARC, but only with internal
toolchains. The assertion that breaks is:
116 | verify (LONG_MIN <= TYPE_MINIMUM (time_t) && TYPE_MAXIMUM (time_t) <= LONG_MAX);
So to me, it smells like another instance of "this is a 32-bit
architecture, but time_t is 64-bit, and this breaks some userspace code
that makes bogus assumptions on the size of time_t".
This feels similar to the libopenssl situation for which Yann has just
sent a patch. Should we have a BR2_ARCH_IS_32_BUT_TIME_T_IS_64 boolean ?
> sparc | dhcpcd-9.4.0 | NOK | http://autobuild.buildroot.net/results/fba538d2ae4a1c53440ed73ced4023be27d7e9c2 |
I assume this is fixed by https://git.buildroot.org/buildroot/commit/?id=e5594f7239547672c08058b77f8098d2c080bebc
> riscv64 | fuse-overlayfs-1.4.0 | NOK | http://autobuild.buildroot.net/results/cfef18f3adf51edaedbbd193efbff19aebdfe508 |
This is a bug in uClibc: it implements renameat() only if the
SYS_renameat system call exists. If only the SYS_renameat2 system call
exists, the renameat() function is not implemented. Musl does this
correctly:
int renameat(int oldfd, const char *old, int newfd, const char *new)
{
#ifdef SYS_renameat
return syscall(SYS_renameat, oldfd, old, newfd, new);
#else
return syscall(SYS_renameat2, oldfd, old, newfd, new, 0);
#endif
}
uclibc needs to be patched here.
> mips64el | gstreamer1-mm-1.10.0 | NOK | http://autobuild.buildroot.net/results/b1c5989a3a09b39e504c21201e3e07c0afc2a1ea | ORPH
/home/buildroot/autobuild/instance-2/output-1/host/bin/../mips64el-buildroot-linux-gnu/sysroot/usr/include/glib-2.0/glib/gatomic.h:97:5: sorry, unimplemented: unexpected AST of kind static_assert
This messages comes from deep down gcc, when compiling the gatomic.h
macros. It happens on all MIPS architecture variants.
> aarch64 | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/739d625673f9b2ce2d915ecdc21910c62618d145 |
> microblazeel | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/b1779a7d46f6ee9c06864c3ca252f1cdad47cf08 |
> i586 | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/a5fe402e3f4e538eb4584f345b029ef12ad43348 |
> arc | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/abd3f886335f146ff6f16370484106bd8a205bda |
What do we do with this? The only way to solve that is to have the
Cargo vendoring support, which we won't have for 2021.02. Should we
drop this package ?
> arc | kismet-2020-12-R3 | NOK | http://autobuild.buildroot.net/results/1c2885d75219aabadbb66ab66fe0dc4b4346ff1e | ORPH
> i586 | kismet-2020-12-R3 | NOK | http://autobuild.buildroot.net/results/3a76afdbd8b564579bfb08a4d75b438dbd73ac2e | ORPH
Would be fixed by https://patchwork.ozlabs.org/project/buildroot/patch/20210304200430.1749334-1-fontaine.fabrice at gmail.com/
> powerpc64 | kvm-unit-tests-kvm-unit-tes... | NOK | http://autobuild.buildroot.net/results/06cce5030766fcc789f0ba4a76d2cbaa091300d0 |
/home/giuliobenetti/autobuild/run/instance-1/output-1/host/bin/powerpc64-linux-ld: powerpc/spapr_hcall.elf: error: PHDR segment not covered by LOAD segment
kvm-unit-tests has always been a bit complicated as it builds some kind
of bare-metal code. I would simply suggest that we drop powerpc64 from
the list of supported CPU architectures for this package.
> nios2 | libgeos-3.9.0 | NOK | http://autobuild.buildroot.net/results/a05fdf1958f93a206c5c66c7f636b6650683626d | ORPH
Some more nios2 toolchain issue.
Should we get rid of nios2 support entirely ?
> mipsel | libopenh264-2.1.1 | NOK | http://autobuild.buildroot.net/results/26837f7c80a84e5ad31d5b15161848ebecc59917 |
This is happening since we have added the use of the Bootlin mips32
toolchain early February:
http://autobuild.buildroot.net/?reason=libopenh264-2.1.1
Needs investigation to see if this is a toolchain issue, or a package
issue that wasn't noticed until now.
> riscv32 | libopenssl-1.1.1j | NOK | http://autobuild.buildroot.net/results/e7bf5db7745c56c4533c225260ff6c3fcd2000f5 |
> riscv32 | libopenssl-1.1.1j | NOK | http://autobuild.buildroot.net/results/5b4834023eca039be59b969e3037bb23feeed6ac |
Being worked on by Yann.
> riscv64 | libostree-2020.8 | NOK | http://autobuild.buildroot.net/results/d42bce7ef9cf0f807b9ba7021af4a11f84e307d2 |
Ah another instance of renameat() missing from uClibc.
> powerpc64 | netopeer2-1.1.53 | NOK | http://autobuild.buildroot.net/results/49efc0e93ad8fe30e5f32fed8a1efc1d2afd830e |
-- Installing missing sysrepo modules...
[ERR]: Retrieving GID "8000" grp entry failed (No such GID).
sysrepoctl error: Failed to connect (Item not found)
[ERR]: Retrieving GID "8000" grp entry failed (No such GID).
sysrepoctl error: Failed to connect (Item not found)
CMake Error at cmake_install.cmake:77 (message):
scripts/setup.sh failed: 1
Ah this seems like netopeer2's build system is looking at the host too
much ?
Heiko ?
> x86_64 | openblas-0.3.9 | NOK | http://autobuild.buildroot.net/results/d530db0f37e1e0462e3af1e1787e15f94ff21884 | ORPH
/home/giuliobenetti/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-buildroot-linux-musl/9.3.0/../../../../x86_64-buildroot-linux-musl/bin/ld: ../libopenblas_nehalem-r0.3.9.a(sbdsvdx.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
Thomas DS, you are now our expert in openblas. Could you have a look ?
> aarch64 | rt-tests-1.10 | NOK | http://autobuild.buildroot.net/results/c6a3cdd4a07f8918b164e0e1e85c92d8b14ec228 |
make[1]: Entering directory `/home/buildroot/autobuild/run/instance-2/output-1/build/rt-tests-1.10'
Makefile:41: *** commands commence before first target. Stop.
During the installation step. This shouldn't be too difficult to
reproduce and track down?
> xtensa | strace-5.10 | NOK | http://autobuild.buildroot.net/results/6c679877e1a3f50d5e0bc4db3237e0c699bd7243 |
./linux/xtensa/arch_regs.c:10:32: error: invalid use of undefined type 'struct user_pt_regs'
Some more pt_regs fun on a funky architecture. Oh dear.
> sparc | tio-1.32 | NOK | http://autobuild.buildroot.net/results/7cbace3ce72bbcce8ef36f71cba8071bfda9fc26 |
> sparc64 | tio-1.32 | NOK | http://autobuild.buildroot.net/results/b9a671c46fa41875c1fd6a16790b314c16ef989b |
This would be worked around by disabling the package on sparc/sparc64,
which has been proposed a long time ago already:
https://patchwork.ozlabs.org/project/buildroot/patch/20201025163457.30460-1-sergio.prado at e-labworks.com/
> arm | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/d9b9a4b7c3660bd730a19ab09e44f24bc29e3f40 | ORPH
> arm | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/13f9a551f5ac911e7daa2a382b0683d81486cffa | ORPH
toolchain is gone ?
> powerpc | unknown | NOK | http://autobuild.buildroot.net/results/159d2c07060c235080711d1d0da0b2eae995d4bf |
This is a top-level parallel build issue... but since we don't have the
full log, we don't have the error.
Should we perhaps keep the full log, compressed, for builds done in
parallel ?
> or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/ed105d321c0bde99c293ab7328d57c3764db6f27 |
> or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/ce351e0e97c2cacc17d4718d39941548c7558559 |
/home/giuliobenetti/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.33.1 assertion fail elf32-or1k.c:2329
collect2: error: ld returned 1 exit status
Giulio, is this a known or1k issue ?
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2021-03-03
2021-03-04 21:49 ` [Buildroot] Analysis of build " Thomas Petazzoni
@ 2021-03-04 22:26 ` Yann E. MORIN
2021-03-05 8:01 ` Giulio Benetti
2021-03-05 8:36 ` Peter Korsgaard
2021-03-05 7:56 ` Giulio Benetti
` (2 subsequent siblings)
3 siblings, 2 replies; 16+ messages in thread
From: Yann E. MORIN @ 2021-03-04 22:26 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2021-03-04 22:49 +0100, Thomas Petazzoni spake thusly:
> > riscv64 | fuse-overlayfs-1.4.0 | NOK | http://autobuild.buildroot.net/results/cfef18f3adf51edaedbbd193efbff19aebdfe508 |
>
> This is a bug in uClibc: it implements renameat() only if the
> SYS_renameat system call exists. If only the SYS_renameat2 system call
> exists, the renameat() function is not implemented. Musl does this
> correctly:
>
> int renameat(int oldfd, const char *old, int newfd, const char *new)
> {
> #ifdef SYS_renameat
> return syscall(SYS_renameat, oldfd, old, newfd, new);
> #else
> return syscall(SYS_renameat2, oldfd, old, newfd, new, 0);
> #endif
> }
>
> uclibc needs to be patched here.
But what about external toolchains? We can't know whether they would
carry such a patch or not...
> > aarch64 | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/739d625673f9b2ce2d915ecdc21910c62618d145 |
> > microblazeel | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/b1779a7d46f6ee9c06864c3ca252f1cdad47cf08 |
> > i586 | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/a5fe402e3f4e538eb4584f345b029ef12ad43348 |
> > arc | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/abd3f886335f146ff6f16370484106bd8a205bda |
> What do we do with this? The only way to solve that is to have the
> Cargo vendoring support, which we won't have for 2021.02. Should we
> drop this package ?
I am all in favour of dropping sentry-cli. It is a host-only package
with no in-tree users. When it was submitted, no rationale was given to
justify for having it upstream (although I suspect it may be helpfull
with traces generated with sentry-native).
In any case, this package is not playing nice with our infra, and our
infra is not ready to accomodate such a package yet.
Let's drop it for now...
Since you have it in your vendoring branch, you can still keep uisng it
to validate your code.
> > nios2 | libgeos-3.9.0 | NOK | http://autobuild.buildroot.net/results/a05fdf1958f93a206c5c66c7f636b6650683626d | ORPH
> Some more nios2 toolchain issue.
> Should we get rid of nios2 support entirely ?
How prevalent is nios2? What's the support in the kernel? Some time ago,
quite a few old architectures were dropped; IIR, a few others were put
on trial to see if they were really still alive (but apart an LWN
article https://lwn.net/Articles/748074/ I can't find that list...)
> > arm | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/d9b9a4b7c3660bd730a19ab09e44f24bc29e3f40 | ORPH
> > arm | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/13f9a551f5ac911e7daa2a382b0683d81486cffa | ORPH
> toolchain is gone ?
I can get it from here;
wget 'https://releases.linaro.org/components/toolchain/binaries/7.3-2018.05/arm-linux-gnueabihf/gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf.tar.xz'
--2021-03-04 23:03:07-- https://releases.linaro.org/components/toolchain/binaries/7.3-2018.05/arm-linux-gnueabihf/gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf.tar.xz
Resolving releases.linaro.org (releases.linaro.org)...
52.215.200.125
Connecting to releases.linaro.org (releases.linaro.org)|52.215.200.125|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://publishing-ie-linaro-org.s3.amazonaws.com/releases/components/toolchain/binaries/7.3-2018.05/arm-linux-gnueabihf/gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf.tar.xz?Signature=qIOVqoIXcsiFVTalQoTG%2FdNwu9A%3D&Expires=1614895479&AWSAccessKeyId=AKIAIELXV2RYNAHFUP7A [following]
--2021-03-04 23:03:09-- https://publishing-ie-linaro-org.s3.amazonaws.com/releases/components/toolchain/binaries/7.3-2018.05/arm-linux-gnueabihf/gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf.tar.xz?Signature=qIOVqoIXcsiFVTalQoTG%2FdNwu9A%3D&Expires=1614895479&AWSAccessKeyId=AKIAIELXV2RYNAHFUP7A
Resolving publishing-ie-linaro-org.s3.amazonaws.com (publishing-ie-linaro-org.s3.amazonaws.com)... 52.218.41.226
Connecting to publishing-ie-linaro-org.s3.amazonaws.com (publishing-ie-linaro-org.s3.amazonaws.com)|52.218.41.226|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 107031352 (102M) [application/octet-stream]
Saving to: ?gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf.tar.xz?
gcc-linaro-7.3.1-2018.05-x 100%[=====================================>] 102.07M 17.0MB/s in 5.8s
2021-03-04 23:03:15 (17.5 MB/s) - ?gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf.tar.xz? saved [107031352/107031352]
Temporary glitch in the network? Goblins? ;-)
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2021-03-03
2021-03-04 21:49 ` [Buildroot] Analysis of build " Thomas Petazzoni
2021-03-04 22:26 ` Yann E. MORIN
@ 2021-03-05 7:56 ` Giulio Benetti
2021-03-05 8:55 ` Giulio Benetti
2021-03-05 9:22 ` Thomas Petazzoni
2021-03-05 9:48 ` Thomas De Schampheleire
2021-03-05 15:10 ` Heiko Thiery
3 siblings, 2 replies; 16+ messages in thread
From: Giulio Benetti @ 2021-03-05 7:56 UTC (permalink / raw)
To: buildroot
Hi Thomas, All,
On 3/4/21 10:49 PM, Thomas Petazzoni wrote:
> Hello,
>
> Giulio, Heiko, Thomas DS there are specific questions for you below!
>
> On Thu, 04 Mar 2021 08:15:14 -0000
> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
>
>> nios2 | asterisk-16.14.1 | NOK | http://autobuild.buildroot.net/results/24c0a6ca3b272711a1e6ceaa033925182d0d49c4
>
> Some wonderful compiler issue.
>
> utf8.c: In function 'ast_utf8_copy_string':
> utf8.c:157:1: internal compiler error: Segmentation fault
>
> Giulio, does this look like a known NIOS2 issue ?
Yes, I've filed it time ago here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93847
Then maintainer wanted me to provide all pre-preprocessed files and all
build flags. There the issue was showing using Codesourcery only, but
here we have a Buildroot toolchain, so better chance to dig.
Anyway I can add patches to add the _BUG_ and use the -O0 workaround.
What about that?
>
>> nios2 | belle-sip-4.4.8 | NOK | http://autobuild.buildroot.net/results/71f26fd81db8e9b19b3f18f3f3cefd9c768f094f |
>
> /tmp/ccDtjRfo.s: Assembler messages:
> /tmp/ccDtjRfo.s:210798: Error: branch offset out of range
>
> Another wonderful nios2 toolchain issue. Giulio, what do you think ?
This is new to me, I've checked on Gcc Bugzilla and it doesn't seem to
be there. So I can file it up and look for a workaround, maybe the usual
-O0.
>
>> arc | dc3dd-7.2.641 | NOK | http://autobuild.buildroot.net/results/4829278085da2409bb2902161f9984708411166a | ORPH
>> arc | dc3dd-7.2.641 | NOK | http://autobuild.buildroot.net/results/3b145a99a1f7498ee7fcd445f3cc319f548e9a81 | ORPH
>> arc | dc3dd-7.2.641 | NOK | http://autobuild.buildroot.net/results/c1cb2dd0b9e7547f3858e62281da3bd45b9a5b17 | ORPH
>
> verify.h:132:30: error: negative width in bit-field 'verify_error_if_negative_size__'
> 132 | (struct { unsigned int verify_error_if_negative_size__: (R) ? 1 : -1; }))
>
> This happens on RISC-V 32-bit, and on ARC, but only with internal
> toolchains. The assertion that breaks is:
>
> 116 | verify (LONG_MIN <= TYPE_MINIMUM (time_t) && TYPE_MAXIMUM (time_t) <= LONG_MAX);
>
> So to me, it smells like another instance of "this is a 32-bit
> architecture, but time_t is 64-bit, and this breaks some userspace code
> that makes bogus assumptions on the size of time_t".
>
> This feels similar to the libopenssl situation for which Yann has just
> sent a patch. Should we have a BR2_ARCH_IS_32_BUT_TIME_T_IS_64 boolean ?
>
>> sparc | dhcpcd-9.4.0 | NOK | http://autobuild.buildroot.net/results/fba538d2ae4a1c53440ed73ced4023be27d7e9c2 |
>
> I assume this is fixed by https://git.buildroot.org/buildroot/commit/?id=e5594f7239547672c08058b77f8098d2c080bebc
>
>> riscv64 | fuse-overlayfs-1.4.0 | NOK | http://autobuild.buildroot.net/results/cfef18f3adf51edaedbbd193efbff19aebdfe508 |
>
> This is a bug in uClibc: it implements renameat() only if the
> SYS_renameat system call exists. If only the SYS_renameat2 system call
> exists, the renameat() function is not implemented. Musl does this
> correctly:
>
> int renameat(int oldfd, const char *old, int newfd, const char *new)
> {
> #ifdef SYS_renameat
> return syscall(SYS_renameat, oldfd, old, newfd, new);
> #else
> return syscall(SYS_renameat2, oldfd, old, newfd, new, 0);
> #endif
> }
>
> uclibc needs to be patched here.
>
>> mips64el | gstreamer1-mm-1.10.0 | NOK | http://autobuild.buildroot.net/results/b1c5989a3a09b39e504c21201e3e07c0afc2a1ea | ORPH
>
> /home/buildroot/autobuild/instance-2/output-1/host/bin/../mips64el-buildroot-linux-gnu/sysroot/usr/include/glib-2.0/glib/gatomic.h:97:5: sorry, unimplemented: unexpected AST of kind static_assert
>
> This messages comes from deep down gcc, when compiling the gatomic.h
> macros. It happens on all MIPS architecture variants.
>
>> aarch64 | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/739d625673f9b2ce2d915ecdc21910c62618d145 |
>> microblazeel | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/b1779a7d46f6ee9c06864c3ca252f1cdad47cf08 |
>> i586 | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/a5fe402e3f4e538eb4584f345b029ef12ad43348 |
>> arc | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/abd3f886335f146ff6f16370484106bd8a205bda |
>
> What do we do with this? The only way to solve that is to have the
> Cargo vendoring support, which we won't have for 2021.02. Should we
> drop this package ?
>
>> arc | kismet-2020-12-R3 | NOK | http://autobuild.buildroot.net/results/1c2885d75219aabadbb66ab66fe0dc4b4346ff1e | ORPH
>> i586 | kismet-2020-12-R3 | NOK | http://autobuild.buildroot.net/results/3a76afdbd8b564579bfb08a4d75b438dbd73ac2e | ORPH
>
> Would be fixed by https://patchwork.ozlabs.org/project/buildroot/patch/20210304200430.1749334-1-fontaine.fabrice at gmail.com/
>
>> powerpc64 | kvm-unit-tests-kvm-unit-tes... | NOK | http://autobuild.buildroot.net/results/06cce5030766fcc789f0ba4a76d2cbaa091300d0 |
>
> /home/giuliobenetti/autobuild/run/instance-1/output-1/host/bin/powerpc64-linux-ld: powerpc/spapr_hcall.elf: error: PHDR segment not covered by LOAD segment
>
> kvm-unit-tests has always been a bit complicated as it builds some kind
> of bare-metal code. I would simply suggest that we drop powerpc64 from
> the list of supported CPU architectures for this package.
>
>> nios2 | libgeos-3.9.0 | NOK | http://autobuild.buildroot.net/results/a05fdf1958f93a206c5c66c7f636b6650683626d | ORPH
>
> Some more nios2 toolchain issue.
This is very similar to one of Microblaze gcc bugs. So I could be able
to workaround it with the same -O0.
> Should we get rid of nios2 support entirely ?
Here it seems we get to the same point of Microblaze, if there is no
hurry I can provide patches to save Nios the same way I've done for
Microblaze.
>> mipsel | libopenh264-2.1.1 | NOK | http://autobuild.buildroot.net/results/26837f7c80a84e5ad31d5b15161848ebecc59917 |
>
> This is happening since we have added the use of the Bootlin mips32
> toolchain early February:
> http://autobuild.buildroot.net/?reason=libopenh264-2.1.1
>
> Needs investigation to see if this is a toolchain issue, or a package
> issue that wasn't noticed until now.
>
>> riscv32 | libopenssl-1.1.1j | NOK | http://autobuild.buildroot.net/results/e7bf5db7745c56c4533c225260ff6c3fcd2000f5 |
>> riscv32 | libopenssl-1.1.1j | NOK | http://autobuild.buildroot.net/results/5b4834023eca039be59b969e3037bb23feeed6ac |
>
> Being worked on by Yann.
>
>> riscv64 | libostree-2020.8 | NOK | http://autobuild.buildroot.net/results/d42bce7ef9cf0f807b9ba7021af4a11f84e307d2 |
>
> Ah another instance of renameat() missing from uClibc.
>
>> powerpc64 | netopeer2-1.1.53 | NOK | http://autobuild.buildroot.net/results/49efc0e93ad8fe30e5f32fed8a1efc1d2afd830e |
>
> -- Installing missing sysrepo modules...
> [ERR]: Retrieving GID "8000" grp entry failed (No such GID).
> sysrepoctl error: Failed to connect (Item not found)
> [ERR]: Retrieving GID "8000" grp entry failed (No such GID).
> sysrepoctl error: Failed to connect (Item not found)
> CMake Error at cmake_install.cmake:77 (message):
> scripts/setup.sh failed: 1
>
> Ah this seems like netopeer2's build system is looking at the host too
> much ?
>
> Heiko ?
>
>> x86_64 | openblas-0.3.9 | NOK | http://autobuild.buildroot.net/results/d530db0f37e1e0462e3af1e1787e15f94ff21884 | ORPH
>
> /home/giuliobenetti/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-buildroot-linux-musl/9.3.0/../../../../x86_64-buildroot-linux-musl/bin/ld: ../libopenblas_nehalem-r0.3.9.a(sbdsvdx.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
>
> Thomas DS, you are now our expert in openblas. Could you have a look ?
>
>> aarch64 | rt-tests-1.10 | NOK | http://autobuild.buildroot.net/results/c6a3cdd4a07f8918b164e0e1e85c92d8b14ec228 |
>
> make[1]: Entering directory `/home/buildroot/autobuild/run/instance-2/output-1/build/rt-tests-1.10'
> Makefile:41: *** commands commence before first target. Stop.
>
> During the installation step. This shouldn't be too difficult to
> reproduce and track down?
>
>> xtensa | strace-5.10 | NOK | http://autobuild.buildroot.net/results/6c679877e1a3f50d5e0bc4db3237e0c699bd7243 |
>
> ./linux/xtensa/arch_regs.c:10:32: error: invalid use of undefined type 'struct user_pt_regs'
>
> Some more pt_regs fun on a funky architecture. Oh dear.
>
>> sparc | tio-1.32 | NOK | http://autobuild.buildroot.net/results/7cbace3ce72bbcce8ef36f71cba8071bfda9fc26 |
>> sparc64 | tio-1.32 | NOK | http://autobuild.buildroot.net/results/b9a671c46fa41875c1fd6a16790b314c16ef989b |
>
> This would be worked around by disabling the package on sparc/sparc64,
> which has been proposed a long time ago already:
> https://patchwork.ozlabs.org/project/buildroot/patch/20201025163457.30460-1-sergio.prado at e-labworks.com/
>
>> arm | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/d9b9a4b7c3660bd730a19ab09e44f24bc29e3f40 | ORPH
>> arm | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/13f9a551f5ac911e7daa2a382b0683d81486cffa | ORPH
>
> toolchain is gone ?
Here it's Micronova firewall that blocks it, I've just written to my IT.
>
>> powerpc | unknown | NOK | http://autobuild.buildroot.net/results/159d2c07060c235080711d1d0da0b2eae995d4bf |
>
> This is a top-level parallel build issue... but since we don't have the
> full log, we don't have the error.
>
> Should we perhaps keep the full log, compressed, for builds done in
> parallel ?
I see it's on my Autobuilder, what can I do to provide suck full log? Do
you mean the entire Buildroot log? If yes I can try to reproduce it and
save it on a file and post it in some way.
>> or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/ed105d321c0bde99c293ab7328d57c3764db6f27 |
>> or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/ce351e0e97c2cacc17d4718d39941548c7558559 |
>
> /home/giuliobenetti/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.33.1 assertion fail elf32-or1k.c:2329
> collect2: error: ld returned 1 exit status
>
> Giulio, is this a known or1k issue ?
Yes, for this I've sent a patchset time ago:
https://patchwork.ozlabs.org/project/buildroot/list/?series=161548
So basically zeromq should be disabled like protobuf. But need to check it.
You've also answered me here:
https://patchwork.ozlabs.org/project/buildroot/patch/20200228175814.128730-1-giulio.benetti at benettiengineering.com/
Here it seems the same situation as Nios and Microblaze.
For this I can provide patches too if not in hurry.
Best regards
--
Giulio Benetti
Benetti Engineering sas
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2021-03-03
2021-03-04 22:26 ` Yann E. MORIN
@ 2021-03-05 8:01 ` Giulio Benetti
2021-03-05 8:36 ` Peter Korsgaard
1 sibling, 0 replies; 16+ messages in thread
From: Giulio Benetti @ 2021-03-05 8:01 UTC (permalink / raw)
To: buildroot
Hi Yann, All,
On 3/4/21 11:26 PM, Yann E. MORIN wrote:
> Thomas, All,
>
> On 2021-03-04 22:49 +0100, Thomas Petazzoni spake thusly:
>>> riscv64 | fuse-overlayfs-1.4.0 | NOK | http://autobuild.buildroot.net/results/cfef18f3adf51edaedbbd193efbff19aebdfe508 |
>>
>> This is a bug in uClibc: it implements renameat() only if the
>> SYS_renameat system call exists. If only the SYS_renameat2 system call
>> exists, the renameat() function is not implemented. Musl does this
>> correctly:
>>
>> int renameat(int oldfd, const char *old, int newfd, const char *new)
>> {
>> #ifdef SYS_renameat
>> return syscall(SYS_renameat, oldfd, old, newfd, new);
>> #else
>> return syscall(SYS_renameat2, oldfd, old, newfd, new, 0);
>> #endif
>> }
>>
>> uclibc needs to be patched here.
>
> But what about external toolchains? We can't know whether they would
> carry such a patch or not...
>
>>> aarch64 | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/739d625673f9b2ce2d915ecdc21910c62618d145 |
>>> microblazeel | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/b1779a7d46f6ee9c06864c3ca252f1cdad47cf08 |
>>> i586 | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/a5fe402e3f4e538eb4584f345b029ef12ad43348 |
>>> arc | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/abd3f886335f146ff6f16370484106bd8a205bda |
>> What do we do with this? The only way to solve that is to have the
>> Cargo vendoring support, which we won't have for 2021.02. Should we
>> drop this package ?
>
> I am all in favour of dropping sentry-cli. It is a host-only package
> with no in-tree users. When it was submitted, no rationale was given to
> justify for having it upstream (although I suspect it may be helpfull
> with traces generated with sentry-native).
>
> In any case, this package is not playing nice with our infra, and our
> infra is not ready to accomodate such a package yet.
>
> Let's drop it for now...
>
> Since you have it in your vendoring branch, you can still keep uisng it
> to validate your code.
>
>>> nios2 | libgeos-3.9.0 | NOK | http://autobuild.buildroot.net/results/a05fdf1958f93a206c5c66c7f636b6650683626d | ORPH
>> Some more nios2 toolchain issue.
>> Should we get rid of nios2 support entirely ?
>
> How prevalent is nios2? What's the support in the kernel? Some time ago,
> quite a few old architectures were dropped; IIR, a few others were put
> on trial to see if they were really still alive (but apart an LWN
> article https://lwn.net/Articles/748074/ I can't find that list...)
I think that(time allowing) we can get rid of it the same way as
Microblaze. During the last year it seems that Microblaze build failure
disappeared, only libgeos came out. But it's trivial to provide a patch
to work it around with -O0. If Nios gcc bugs can be worked around that
way I would keep it, as well as OpenRisc.
What about that?
>>> arm | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/d9b9a4b7c3660bd730a19ab09e44f24bc29e3f40 | ORPH
>>> arm | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/13f9a551f5ac911e7daa2a382b0683d81486cffa | ORPH
>> toolchain is gone ?
>
> I can get it from here;
>
> wget 'https://releases.linaro.org/components/toolchain/binaries/7.3-2018.05/arm-linux-gnueabihf/gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf.tar.xz'
> --2021-03-04 23:03:07-- https://releases.linaro.org/components/toolchain/binaries/7.3-2018.05/arm-linux-gnueabihf/gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf.tar.xz
> Resolving releases.linaro.org (releases.linaro.org)...
> 52.215.200.125
> Connecting to releases.linaro.org (releases.linaro.org)|52.215.200.125|:443... connected.
> HTTP request sent, awaiting response... 302 Found
> Location: https://publishing-ie-linaro-org.s3.amazonaws.com/releases/components/toolchain/binaries/7.3-2018.05/arm-linux-gnueabihf/gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf.tar.xz?Signature=qIOVqoIXcsiFVTalQoTG%2FdNwu9A%3D&Expires=1614895479&AWSAccessKeyId=AKIAIELXV2RYNAHFUP7A [following]
> --2021-03-04 23:03:09-- https://publishing-ie-linaro-org.s3.amazonaws.com/releases/components/toolchain/binaries/7.3-2018.05/arm-linux-gnueabihf/gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf.tar.xz?Signature=qIOVqoIXcsiFVTalQoTG%2FdNwu9A%3D&Expires=1614895479&AWSAccessKeyId=AKIAIELXV2RYNAHFUP7A
> Resolving publishing-ie-linaro-org.s3.amazonaws.com (publishing-ie-linaro-org.s3.amazonaws.com)... 52.218.41.226
> Connecting to publishing-ie-linaro-org.s3.amazonaws.com (publishing-ie-linaro-org.s3.amazonaws.com)|52.218.41.226|:443... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 107031352 (102M) [application/octet-stream]
> Saving to: ?gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf.tar.xz?
>
> gcc-linaro-7.3.1-2018.05-x 100%[=====================================>] 102.07M 17.0MB/s in 5.8s
>
> 2021-03-04 23:03:15 (17.5 MB/s) - ?gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf.tar.xz? saved [107031352/107031352]
>
> Temporary glitch in the network? Goblins? ;-)
:-)
Micronova IT should get rid of that Firewall issue.
Best regards
--
Giulio Benetti
Benetti Engineering sas
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2021-03-03
2021-03-04 22:26 ` Yann E. MORIN
2021-03-05 8:01 ` Giulio Benetti
@ 2021-03-05 8:36 ` Peter Korsgaard
1 sibling, 0 replies; 16+ messages in thread
From: Peter Korsgaard @ 2021-03-05 8:36 UTC (permalink / raw)
To: buildroot
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
Hi,
>> This is a bug in uClibc: it implements renameat() only if the
>> SYS_renameat system call exists. If only the SYS_renameat2 system call
>> exists, the renameat() function is not implemented. Musl does this
>> correctly:
>>
>> int renameat(int oldfd, const char *old, int newfd, const char *new)
>> {
>> #ifdef SYS_renameat
>> return syscall(SYS_renameat, oldfd, old, newfd, new);
>> #else
>> return syscall(SYS_renameat2, oldfd, old, newfd, new, 0);
>> #endif
>> }
>>
>> uclibc needs to be patched here.
> But what about external toolchains? We can't know whether they would
> carry such a patch or not...
But that is the general issue with external uClibc-based toolchains, we
cannot really do anything about it.
Thomas, will you create a uclibc-ng patch?
>> > aarch64 | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/739d625673f9b2ce2d915ecdc21910c62618d145 |
>> > microblazeel | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/b1779a7d46f6ee9c06864c3ca252f1cdad47cf08 |
>> > i586 | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/a5fe402e3f4e538eb4584f345b029ef12ad43348 |
>> > arc | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/abd3f886335f146ff6f16370484106bd8a205bda |
>> What do we do with this? The only way to solve that is to have the
>> Cargo vendoring support, which we won't have for 2021.02. Should we
>> drop this package ?
> I am all in favour of dropping sentry-cli. It is a host-only package
> with no in-tree users. When it was submitted, no rationale was given to
> justify for having it upstream (although I suspect it may be helpfull
> with traces generated with sentry-native).
> In any case, this package is not playing nice with our infra, and our
> infra is not ready to accomodate such a package yet.
> Let's drop it for now...
Fine by me.
>> > nios2 | libgeos-3.9.0 | NOK |
>> > http://autobuild.buildroot.net/results/a05fdf1958f93a206c5c66c7f636b6650683626d
>> > | ORPH
>> Some more nios2 toolchain issue.
>> Should we get rid of nios2 support entirely ?
> How prevalent is nios2? What's the support in the kernel? Some time ago,
> quite a few old architectures were dropped; IIR, a few others were put
> on trial to see if they were really still alive (but apart an LWN
> article https://lwn.net/Articles/748074/ I can't find that list...)
There is also https://lwn.net/Articles/838807/, which doesn't even list
nios2. I believe it was added back in 2014:
https://lwn.net/Articles/619011/
I think running Linux on nios2 is fairly rare, but there are users. As a
data point, it looks like the clone syscall got broken almost a year
ago, and has recently been fixed by someone from Siemens:
commit 9abcfcb20320e8f693e89d86573b58e6289931cb
Author: Andreas Oetken <andreas.oetken@siemens.com>
Date: Fri Feb 19 14:41:03 2021 +0800
nios2: fixed broken sys_clone syscall
The tls pointer must be pushed on the stack prior to calling nios2_clone
as it is the 5th function argument. Prior handling of the tls pointer was
done inside former called function copy_thread_tls using the r8 register
from the current_pt_regs directly. This was a bad design and resulted in
the current bug introduced in 04bd52fb.
Fixes: 04bd52fb ("nios2: enable HAVE_COPY_THREAD_TLS, switch to kernel_clone_args")
Signed-off-by: Andreas Oetken <andreas.oetken@siemens.com>
Signed-off-by: Ley Foon Tan <ley.foon.tan@intel.com>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Looking at the history of arch/nios2, almost all recent changes looks to
be from non-nios2 developers doing kernel wide changes, so I would say
it is fairly dead, E.G. the last functional code change authored by
someone from Intel is from 2018:
commit cb9f753a3731f7fe16447bea45cb6f8e8bb432fb
Author: Huang Ying <ying.huang@intel.com>
Date: Thu Apr 5 16:24:39 2018 -0700
mm: fix races between swapoff and flush dcache
So I don't have an issue with us getting rid of nios2 post-2021.02. I'll
try to remember to add a note about it in the announcement mail, so if
there are active users they will hopefully speak up.
>> > arm | toolchain-external-linaro-a... | NOK |
>> > http://autobuild.buildroot.net/results/d9b9a4b7c3660bd730a19ab09e44f24bc29e3f40
>> > | ORPH
>> > arm | toolchain-external-linaro-a... | NOK |
>> > http://autobuild.buildroot.net/results/13f9a551f5ac911e7daa2a382b0683d81486cffa
>> > | ORPH
>> toolchain is gone ?
> I can get it from here;
Yes, I already pushed it to s.b.o yesterday afternoon when I noticed the
failure.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2021-03-03
2021-03-05 7:56 ` Giulio Benetti
@ 2021-03-05 8:55 ` Giulio Benetti
2021-03-05 9:13 ` Giulio Benetti
2021-03-05 9:22 ` Thomas Petazzoni
1 sibling, 1 reply; 16+ messages in thread
From: Giulio Benetti @ 2021-03-05 8:55 UTC (permalink / raw)
To: buildroot
On 3/5/21 8:56 AM, Giulio Benetti wrote:
> Hi Thomas, All,
>
> On 3/4/21 10:49 PM, Thomas Petazzoni wrote:
>> Hello,
>>
>> Giulio, Heiko, Thomas DS there are specific questions for you below!
>>
>> On Thu, 04 Mar 2021 08:15:14 -0000
>> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
>>
>>> nios2 | asterisk-16.14.1 | NOK | http://autobuild.buildroot.net/results/24c0a6ca3b272711a1e6ceaa033925182d0d49c4
>>
>> Some wonderful compiler issue.
>>
>> utf8.c: In function 'ast_utf8_copy_string':
>> utf8.c:157:1: internal compiler error: Segmentation fault
>>
>> Giulio, does this look like a known NIOS2 issue ?
>
> Yes, I've filed it time ago here:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93847
>
> Then maintainer wanted me to provide all pre-preprocessed files and all
> build flags. There the issue was showing using Codesourcery only, but
> here we have a Buildroot toolchain, so better chance to dig.
>
> Anyway I can add patches to add the _BUG_ and use the -O0 workaround.
> What about that?
I've already added that _BUG_ to toolchain/Config.in, need some time to
pass CFLAGS to Asterisk in some way, at the moment -O3 is always
appended after -O0.
--
Giulio Benetti
Benetti Engineering sas
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2021-03-03
2021-03-05 8:55 ` Giulio Benetti
@ 2021-03-05 9:13 ` Giulio Benetti
0 siblings, 0 replies; 16+ messages in thread
From: Giulio Benetti @ 2021-03-05 9:13 UTC (permalink / raw)
To: buildroot
On 3/5/21 9:55 AM, Giulio Benetti wrote:
>
>
> On 3/5/21 8:56 AM, Giulio Benetti wrote:
>> Hi Thomas, All,
>>
>> On 3/4/21 10:49 PM, Thomas Petazzoni wrote:
>>> Hello,
>>>
>>> Giulio, Heiko, Thomas DS there are specific questions for you below!
>>>
>>> On Thu, 04 Mar 2021 08:15:14 -0000
>>> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
>>>
>>>> nios2 | asterisk-16.14.1 | NOK | http://autobuild.buildroot.net/results/24c0a6ca3b272711a1e6ceaa033925182d0d49c4
>>>
>>> Some wonderful compiler issue.
>>>
>>> utf8.c: In function 'ast_utf8_copy_string':
>>> utf8.c:157:1: internal compiler error: Segmentation fault
>>>
>>> Giulio, does this look like a known NIOS2 issue ?
>>
>> Yes, I've filed it time ago here:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93847
>>
>> Then maintainer wanted me to provide all pre-preprocessed files and all
>> build flags. There the issue was showing using Codesourcery only, but
>> here we have a Buildroot toolchain, so better chance to dig.
>>
>> Anyway I can add patches to add the _BUG_ and use the -O0 workaround.
>> What about that?
>
> I've already added that _BUG_ to toolchain/Config.in, need some time to
> pass CFLAGS to Asterisk in some way, at the moment -O3 is always
> appended after -O0.
>
This ^^^ is fixed by this patchset:
https://patchwork.ozlabs.org/project/buildroot/list/?series=232302
--
Giulio Benetti
Benetti Engineering sas
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2021-03-03
2021-03-05 7:56 ` Giulio Benetti
2021-03-05 8:55 ` Giulio Benetti
@ 2021-03-05 9:22 ` Thomas Petazzoni
2021-03-05 16:01 ` Giulio Benetti
1 sibling, 1 reply; 16+ messages in thread
From: Thomas Petazzoni @ 2021-03-05 9:22 UTC (permalink / raw)
To: buildroot
Hello Giulio,
On Fri, 5 Mar 2021 08:56:32 +0100
Giulio Benetti <giulio.benetti@benettiengineering.com> wrote:
> Yes, I've filed it time ago here:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93847
>
> Then maintainer wanted me to provide all pre-preprocessed files and all
> build flags. There the issue was showing using Codesourcery only, but
> here we have a Buildroot toolchain, so better chance to dig.
Indeed!
> Anyway I can add patches to add the _BUG_ and use the -O0 workaround.
> What about that?
Sure, sounds good.
> >> nios2 | belle-sip-4.4.8 | NOK | http://autobuild.buildroot.net/results/71f26fd81db8e9b19b3f18f3f3cefd9c768f094f |
> >
> > /tmp/ccDtjRfo.s: Assembler messages:
> > /tmp/ccDtjRfo.s:210798: Error: branch offset out of range
> >
> > Another wonderful nios2 toolchain issue. Giulio, what do you think ?
>
> This is new to me, I've checked on Gcc Bugzilla and it doesn't seem to
> be there. So I can file it up and look for a workaround, maybe the usual
> -O0.
With these errors, I'm never sure if it's a gcc issue (that emits bogus
assembly) or a binutils issue. But most likely a gcc issue.
> >> nios2 | libgeos-3.9.0 | NOK | http://autobuild.buildroot.net/results/a05fdf1958f93a206c5c66c7f636b6650683626d | ORPH
> >
> > Some more nios2 toolchain issue.
>
> This is very similar to one of Microblaze gcc bugs. So I could be able
> to workaround it with the same -O0.
OK.
Maybe we should default to -O2 for those funky architectures? Indeed,
our default is -Os, but this is perhaps less widely used/tested than
-O2 ?
Or are the bugs in question also appearing at -O2 ?
> > Should we get rid of nios2 support entirely ?
>
> Here it seems we get to the same point of Microblaze, if there is no
> hurry I can provide patches to save Nios the same way I've done for
> Microblaze.
My concern is that those gcc issues for nios2/microblaze never seem to
be fixed. That there are gcc issues that we need to workaround, it's
fine I guess, but that they stay forever is more annoying.
> >> arm | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/d9b9a4b7c3660bd730a19ab09e44f24bc29e3f40 | ORPH
> >> arm | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/13f9a551f5ac911e7daa2a382b0683d81486cffa | ORPH
> >
> > toolchain is gone ?
>
> Here it's Micronova firewall that blocks it, I've just written to my IT.
OK, thanks!
> >> powerpc | unknown | NOK | http://autobuild.buildroot.net/results/159d2c07060c235080711d1d0da0b2eae995d4bf |
> >
> > This is a top-level parallel build issue... but since we don't have the
> > full log, we don't have the error.
> >
> > Should we perhaps keep the full log, compressed, for builds done in
> > parallel ?
>
> I see it's on my Autobuilder, what can I do to provide suck full log? Do
> you mean the entire Buildroot log? If yes I can try to reproduce it and
> save it on a file and post it in some way.
Now that the build is finished, the build log is gone. My proposal here
was to adjust the autobuild-run script to upload to
autobuild.buildroot.org the full build log (compressed) when the build
is a top-level parallel build.
> >> or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/ed105d321c0bde99c293ab7328d57c3764db6f27 |
> >> or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/ce351e0e97c2cacc17d4718d39941548c7558559 |
> >
> > /home/giuliobenetti/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.33.1 assertion fail elf32-or1k.c:2329
> > collect2: error: ld returned 1 exit status
> >
> > Giulio, is this a known or1k issue ?
>
> Yes, for this I've sent a patchset time ago:
> https://patchwork.ozlabs.org/project/buildroot/list/?series=161548
>
> So basically zeromq should be disabled like protobuf. But need to check it.
>
> You've also answered me here:
> https://patchwork.ozlabs.org/project/buildroot/patch/20200228175814.128730-1-giulio.benetti at benettiengineering.com/
>
> Here it seems the same situation as Nios and Microblaze.
>
> For this I can provide patches too if not in hurry.
Maybe we should be pragmatic here and just take your patches as-is.
Thanks for all the feedback!
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2021-03-03
2021-03-04 21:49 ` [Buildroot] Analysis of build " Thomas Petazzoni
2021-03-04 22:26 ` Yann E. MORIN
2021-03-05 7:56 ` Giulio Benetti
@ 2021-03-05 9:48 ` Thomas De Schampheleire
2021-03-05 15:10 ` Heiko Thiery
3 siblings, 0 replies; 16+ messages in thread
From: Thomas De Schampheleire @ 2021-03-05 9:48 UTC (permalink / raw)
To: buildroot
Hello,
El jue, 4 mar 2021 a las 22:49, Thomas Petazzoni
(<thomas.petazzoni@bootlin.com>) escribi?:
[..]
>
> > x86_64 | openblas-0.3.9 | NOK | http://autobuild.buildroot.net/results/d530db0f37e1e0462e3af1e1787e15f94ff21884 | ORPH
>
> /home/giuliobenetti/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-buildroot-linux-musl/9.3.0/../../../../x86_64-buildroot-linux-musl/bin/ld: ../libopenblas_nehalem-r0.3.9.a(sbdsvdx.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
>
> Thomas DS, you are now our expert in openblas. Could you have a look ?
>
Yes I will have a look. I can reproduce locally, will see if I can fix it.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2021-03-03
2021-03-04 21:49 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (2 preceding siblings ...)
2021-03-05 9:48 ` Thomas De Schampheleire
@ 2021-03-05 15:10 ` Heiko Thiery
2021-03-05 15:14 ` Thomas Petazzoni
3 siblings, 1 reply; 16+ messages in thread
From: Heiko Thiery @ 2021-03-05 15:10 UTC (permalink / raw)
To: buildroot
Hi Thomas and all,
[---]
> > powerpc64 | netopeer2-1.1.53 | NOK | http://autobuild.buildroot.net/results/49efc0e93ad8fe30e5f32fed8a1efc1d2afd830e |
>
> -- Installing missing sysrepo modules...
> [ERR]: Retrieving GID "8000" grp entry failed (No such GID).
> sysrepoctl error: Failed to connect (Item not found)
> [ERR]: Retrieving GID "8000" grp entry failed (No such GID).
> sysrepoctl error: Failed to connect (Item not found)
> CMake Error at cmake_install.cmake:77 (message):
> scripts/setup.sh failed: 1
>
> Ah this seems like netopeer2's build system is looking at the host too
> much ?
Indeed. The netopeer package is a bit annoying to install. But I hope
Jan Kundrat will make his offer come true [1] and provide a better
solution.
Since the problem currently only occurs on one autobuild host, I would
leave it alone until then. Is that ok for you? Or should I try to
patch the problem?
[1] http://lists.busybox.net/pipermail/buildroot/2021-February/303560.html
[...]
Thank you
--
Heiko
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2021-03-03
2021-03-05 15:10 ` Heiko Thiery
@ 2021-03-05 15:14 ` Thomas Petazzoni
2021-03-05 15:38 ` Heiko Thiery
0 siblings, 1 reply; 16+ messages in thread
From: Thomas Petazzoni @ 2021-03-05 15:14 UTC (permalink / raw)
To: buildroot
On Fri, 5 Mar 2021 16:10:27 +0100
Heiko Thiery <heiko.thiery@gmail.com> wrote:
> Indeed. The netopeer package is a bit annoying to install. But I hope
> Jan Kundrat will make his offer come true [1] and provide a better
> solution.
>
> Since the problem currently only occurs on one autobuild host, I would
> leave it alone until then. Is that ok for you? Or should I try to
> patch the problem?
We try when possible to fix or work around the issues, as having noise
in the autobuilders is always a bit annoying. I haven't looked in
details into the problem, so I don't have a particular suggestion to
make, though.
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2021-03-03
2021-03-05 15:14 ` Thomas Petazzoni
@ 2021-03-05 15:38 ` Heiko Thiery
0 siblings, 0 replies; 16+ messages in thread
From: Heiko Thiery @ 2021-03-05 15:38 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Am Fr., 5. M?rz 2021 um 16:14 Uhr schrieb Thomas Petazzoni
<thomas.petazzoni@bootlin.com>:
>
> On Fri, 5 Mar 2021 16:10:27 +0100
> Heiko Thiery <heiko.thiery@gmail.com> wrote:
>
> > Indeed. The netopeer package is a bit annoying to install. But I hope
> > Jan Kundrat will make his offer come true [1] and provide a better
> > solution.
> >
> > Since the problem currently only occurs on one autobuild host, I would
> > leave it alone until then. Is that ok for you? Or should I try to
> > patch the problem?
>
> We try when possible to fix or work around the issues, as having noise
> in the autobuilders is always a bit annoying. I haven't looked in
> details into the problem, so I don't have a particular suggestion to
> make, though.
I understand the problem with the noise, but at the moment I don't see
a solution here.
The problem comes from sysrepoctl which is used during the
installation. This needs a user and a group as names [1] [2]. But on
the autobuilder that fails there seems to be no name for the group in
the /etc/group.
Why all this fiddling is necessary is described in the explanation of
Jan Kundrats.
[1] https://github.com/sysrepo/sysrepo/blob/master/src/executables/sysrepoctl.c#L590
[2] https://github.com/CESNET/netopeer2/blob/master/CMakeLists.txt#L77
A possible solution would be to introduce a config option that
enables/disables the installation of the YANG modules and disable them
by default.
--
Heiko
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2021-03-03
2021-03-05 9:22 ` Thomas Petazzoni
@ 2021-03-05 16:01 ` Giulio Benetti
2021-03-05 16:13 ` Giulio Benetti
0 siblings, 1 reply; 16+ messages in thread
From: Giulio Benetti @ 2021-03-05 16:01 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On 3/5/21 10:22 AM, Thomas Petazzoni wrote:
> Hello Giulio,
>
> On Fri, 5 Mar 2021 08:56:32 +0100
> Giulio Benetti <giulio.benetti@benettiengineering.com> wrote:
>
>> Yes, I've filed it time ago here:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93847
>>
>> Then maintainer wanted me to provide all pre-preprocessed files and all
>> build flags. There the issue was showing using Codesourcery only, but
>> here we have a Buildroot toolchain, so better chance to dig.
>
> Indeed!
Need to provide more details on gcc bug then.
>> Anyway I can add patches to add the _BUG_ and use the -O0 workaround.
>> What about that?
>
> Sure, sounds good.
>
>>>> nios2 | belle-sip-4.4.8 | NOK | http://autobuild.buildroot.net/results/71f26fd81db8e9b19b3f18f3f3cefd9c768f094f |
>>>
>>> /tmp/ccDtjRfo.s: Assembler messages:
>>> /tmp/ccDtjRfo.s:210798: Error: branch offset out of range
>>>
>>> Another wonderful nios2 toolchain issue. Giulio, what do you think ?
>>
>> This is new to me, I've checked on Gcc Bugzilla and it doesn't seem to
>> be there. So I can file it up and look for a workaround, maybe the usual
>> -O0.
>
> With these errors, I'm never sure if it's a gcc issue (that emits bogus
> assembly) or a binutils issue. But most likely a gcc issue.
It's a gcc bug and worked around with this patchset:
https://patchwork.ozlabs.org/project/buildroot/list/?series=232394
>
>>>> nios2 | libgeos-3.9.0 | NOK | http://autobuild.buildroot.net/results/a05fdf1958f93a206c5c66c7f636b6650683626d | ORPH
>>>
>>> Some more nios2 toolchain issue.
>>
>> This is very similar to one of Microblaze gcc bugs. So I could be able
>> to workaround it with the same -O0.
For this I don't find any work-around. I've found this patch from Nios
gcc mantainer:
https://patchwork.ozlabs.org/project/gcc/patch/b652a8a6-dcad-bbe6-4ec8-bc0cb3d71d45 at codesourcery.com/
where she states that it could have fixed the bug due too many linker
warnings, but at the end she reverted. So no way.
Since I've tried building libgeos with gcc7/8/9/10 unsuccesfully,
for this package then I've sent this patch to disable it while building
for Nios:
https://patchwork.ozlabs.org/project/buildroot/patch/20210305160005.3826615-1-giulio.benetti at benettiengineering.com/
> OK.
>
> Maybe we should default to -O2 for those funky architectures? Indeed,
> our default is -Os, but this is perhaps less widely used/tested than
> -O2 ?
>
> Or are the bugs in question also appearing at -O2 ?
Unfortunately they show also with -O2, so we should entirely build with
-O0 but that would results in a very big rootfs. So for the moment IMHO
I would keep sending these workarounds.
>>> Should we get rid of nios2 support entirely ?
>>
>> Here it seems we get to the same point of Microblaze, if there is no
>> hurry I can provide patches to save Nios the same way I've done for
>> Microblaze.
>
> My concern is that those gcc issues for nios2/microblaze never seem to
> be fixed. That there are gcc issues that we need to workaround, it's
> fine I guess, but that they stay forever is more annoying.
Judging from the last 2 years, yes they won't be fixed at 90%...
>
>>>> arm | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/d9b9a4b7c3660bd730a19ab09e44f24bc29e3f40 | ORPH
>>>> arm | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/13f9a551f5ac911e7daa2a382b0683d81486cffa | ORPH
>>>
>>> toolchain is gone ?
>>
>> Here it's Micronova firewall that blocks it, I've just written to my IT.
>
> OK, thanks!
>
>>>> powerpc | unknown | NOK | http://autobuild.buildroot.net/results/159d2c07060c235080711d1d0da0b2eae995d4bf |
>>>
>>> This is a top-level parallel build issue... but since we don't have the
>>> full log, we don't have the error.
>>>
>>> Should we perhaps keep the full log, compressed, for builds done in
>>> parallel ?
>>
>> I see it's on my Autobuilder, what can I do to provide suck full log? Do
>> you mean the entire Buildroot log? If yes I can try to reproduce it and
>> save it on a file and post it in some way.
>
> Now that the build is finished, the build log is gone. My proposal here
> was to adjust the autobuild-run script to upload to
> autobuild.buildroot.org the full build log (compressed) when the build
> is a top-level parallel build.
Ah ok!
>>>> or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/ed105d321c0bde99c293ab7328d57c3764db6f27 |
>>>> or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/ce351e0e97c2cacc17d4718d39941548c7558559 |
>>>
>>> /home/giuliobenetti/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.33.1 assertion fail elf32-or1k.c:2329
>>> collect2: error: ld returned 1 exit status
>>>
>>> Giulio, is this a known or1k issue ?
>>
>> Yes, for this I've sent a patchset time ago:
>> https://patchwork.ozlabs.org/project/buildroot/list/?series=161548
>>
>> So basically zeromq should be disabled like protobuf. But need to check it.
>>
>> You've also answered me here:
>> https://patchwork.ozlabs.org/project/buildroot/patch/20200228175814.128730-1-giulio.benetti at benettiengineering.com/
>>
>> Here it seems the same situation as Nios and Microblaze.
>>
>> For this I can provide patches too if not in hurry.
>
> Maybe we should be pragmatic here and just take your patches as-is.
They still apply to master branch too.
I've also sent these patches since 2 Microblaze bugs have been fixed in
gcc 10.x:
https://patchwork.ozlabs.org/project/buildroot/patch/20210305153730.3671327-1-giulio.benetti at benettiengineering.com/
https://patchwork.ozlabs.org/project/buildroot/patch/20210305154139.3682817-1-giulio.benetti at benettiengineering.com/
Best regards
--
Giulio Benetti
Benetti Engineering sas
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2021-03-03
2021-03-05 16:01 ` Giulio Benetti
@ 2021-03-05 16:13 ` Giulio Benetti
2021-03-05 16:52 ` Giulio Benetti
0 siblings, 1 reply; 16+ messages in thread
From: Giulio Benetti @ 2021-03-05 16:13 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On 3/5/21 5:01 PM, Giulio Benetti wrote:
> Hi Thomas,
>
> On 3/5/21 10:22 AM, Thomas Petazzoni wrote:
>> Hello Giulio,
>>
>> On Fri, 5 Mar 2021 08:56:32 +0100
>> Giulio Benetti <giulio.benetti@benettiengineering.com> wrote:
>>
>>> Yes, I've filed it time ago here:
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93847
>>>
>>> Then maintainer wanted me to provide all pre-preprocessed files and all
>>> build flags. There the issue was showing using Codesourcery only, but
>>> here we have a Buildroot toolchain, so better chance to dig.
>>
>> Indeed!
>
> Need to provide more details on gcc bug then.
>
>>> Anyway I can add patches to add the _BUG_ and use the -O0 workaround.
>>> What about that?
>>
>> Sure, sounds good.
>>
>>>>> nios2 | belle-sip-4.4.8 | NOK | http://autobuild.buildroot.net/results/71f26fd81db8e9b19b3f18f3f3cefd9c768f094f |
>>>>
>>>> /tmp/ccDtjRfo.s: Assembler messages:
>>>> /tmp/ccDtjRfo.s:210798: Error: branch offset out of range
>>>>
>>>> Another wonderful nios2 toolchain issue. Giulio, what do you think ?
>>>
>>> This is new to me, I've checked on Gcc Bugzilla and it doesn't seem to
>>> be there. So I can file it up and look for a workaround, maybe the usual
>>> -O0.
>>
>> With these errors, I'm never sure if it's a gcc issue (that emits bogus
>> assembly) or a binutils issue. But most likely a gcc issue.
>
> It's a gcc bug and worked around with this patchset:
> https://patchwork.ozlabs.org/project/buildroot/list/?series=232394
>
>>
>>>>> nios2 | libgeos-3.9.0 | NOK | http://autobuild.buildroot.net/results/a05fdf1958f93a206c5c66c7f636b6650683626d | ORPH
>>>>
>>>> Some more nios2 toolchain issue.
>>>
>>> This is very similar to one of Microblaze gcc bugs. So I could be able
>>> to workaround it with the same -O0.
>
> For this I don't find any work-around. I've found this patch from Nios
> gcc mantainer:
> https://patchwork.ozlabs.org/project/gcc/patch/b652a8a6-dcad-bbe6-4ec8-bc0cb3d71d45 at codesourcery.com/
>
> where she states that it could have fixed the bug due too many linker
> warnings, but at the end she reverted. So no way.
> Since I've tried building libgeos with gcc7/8/9/10 unsuccesfully,
> for this package then I've sent this patch to disable it while building
> for Nios:
> https://patchwork.ozlabs.org/project/buildroot/patch/20210305160005.3826615-1-giulio.benetti at benettiengineering.com/
>
>> OK.
>>
>> Maybe we should default to -O2 for those funky architectures? Indeed,
>> our default is -Os, but this is perhaps less widely used/tested than
>> -O2 ?
>>
>> Or are the bugs in question also appearing at -O2 ?
>
> Unfortunately they show also with -O2, so we should entirely build with
> -O0 but that would results in a very big rootfs. So for the moment IMHO
> I would keep sending these workarounds.
>
>>>> Should we get rid of nios2 support entirely ?
>>>
>>> Here it seems we get to the same point of Microblaze, if there is no
>>> hurry I can provide patches to save Nios the same way I've done for
>>> Microblaze.
>>
>> My concern is that those gcc issues for nios2/microblaze never seem to
>> be fixed. That there are gcc issues that we need to workaround, it's
>> fine I guess, but that they stay forever is more annoying.
>
> Judging from the last 2 years, yes they won't be fixed at 90%...
>
>>
>>>>> arm | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/d9b9a4b7c3660bd730a19ab09e44f24bc29e3f40 | ORPH
>>>>> arm | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/13f9a551f5ac911e7daa2a382b0683d81486cffa | ORPH
>>>>
>>>> toolchain is gone ?
>>>
>>> Here it's Micronova firewall that blocks it, I've just written to my IT.
>>
>> OK, thanks!
>>
>>>>> powerpc | unknown | NOK | http://autobuild.buildroot.net/results/159d2c07060c235080711d1d0da0b2eae995d4bf |
>>>>
>>>> This is a top-level parallel build issue... but since we don't have the
>>>> full log, we don't have the error.
>>>>
>>>> Should we perhaps keep the full log, compressed, for builds done in
>>>> parallel ?
>>>
>>> I see it's on my Autobuilder, what can I do to provide suck full log? Do
>>> you mean the entire Buildroot log? If yes I can try to reproduce it and
>>> save it on a file and post it in some way.
>>
>> Now that the build is finished, the build log is gone. My proposal here
>> was to adjust the autobuild-run script to upload to
>> autobuild.buildroot.org the full build log (compressed) when the build
>> is a top-level parallel build.
>
> Ah ok!
>
>>>>> or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/ed105d321c0bde99c293ab7328d57c3764db6f27 |
>>>>> or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/ce351e0e97c2cacc17d4718d39941548c7558559 |
>>>>
>>>> /home/giuliobenetti/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.33.1 assertion fail elf32-or1k.c:2329
>>>> collect2: error: ld returned 1 exit status
>>>>
>>>> Giulio, is this a known or1k issue ?
>>>
>>> Yes, for this I've sent a patchset time ago:
>>> https://patchwork.ozlabs.org/project/buildroot/list/?series=161548
>>>
>>> So basically zeromq should be disabled like protobuf. But need to check it.
>>>
>>> You've also answered me here:
>>> https://patchwork.ozlabs.org/project/buildroot/patch/20200228175814.128730-1-giulio.benetti at benettiengineering.com/
>>>
>>> Here it seems the same situation as Nios and Microblaze.
>>>
>>> For this I can provide patches too if not in hurry.
>>
>> Maybe we should be pragmatic here and just take your patches as-is.
Forgotten that here is the v2 patchset including zeromq build failure
disabling:
https://patchwork.ozlabs.org/project/buildroot/list/?series=232409
> They still apply to master branch too.
>
> I've also sent these patches since 2 Microblaze bugs have been fixed in
> gcc 10.x:
> https://patchwork.ozlabs.org/project/buildroot/patch/20210305153730.3671327-1-giulio.benetti at benettiengineering.com/
> https://patchwork.ozlabs.org/project/buildroot/patch/20210305154139.3682817-1-giulio.benetti at benettiengineering.com/
>
> Best regards
>
Best regards
--
Giulio Benetti
Benetti Engineering sas
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2021-03-03
2021-03-05 16:13 ` Giulio Benetti
@ 2021-03-05 16:52 ` Giulio Benetti
0 siblings, 0 replies; 16+ messages in thread
From: Giulio Benetti @ 2021-03-05 16:52 UTC (permalink / raw)
To: buildroot
On 3/5/21 5:13 PM, Giulio Benetti wrote:
> Hi Thomas,
>
> On 3/5/21 5:01 PM, Giulio Benetti wrote:
>> Hi Thomas,
>>
>> On 3/5/21 10:22 AM, Thomas Petazzoni wrote:
>>> Hello Giulio,
>>>
>>> On Fri, 5 Mar 2021 08:56:32 +0100
>>> Giulio Benetti <giulio.benetti@benettiengineering.com> wrote:
>>>
>>>> Yes, I've filed it time ago here:
>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93847
>>>>
>>>> Then maintainer wanted me to provide all pre-preprocessed files and all
>>>> build flags. There the issue was showing using Codesourcery only, but
>>>> here we have a Buildroot toolchain, so better chance to dig.
>>>
>>> Indeed!
>>
>> Need to provide more details on gcc bug then.
I've updated the gcc bugzilla entry:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93847
Let's hope it's enough for them to reproduce and fix.
>>>> Anyway I can add patches to add the _BUG_ and use the -O0 workaround.
>>>> What about that?
>>>
>>> Sure, sounds good.
>>>
>>>>>> nios2 | belle-sip-4.4.8 | NOK | http://autobuild.buildroot.net/results/71f26fd81db8e9b19b3f18f3f3cefd9c768f094f |
>>>>>
>>>>> /tmp/ccDtjRfo.s: Assembler messages:
>>>>> /tmp/ccDtjRfo.s:210798: Error: branch offset out of range
>>>>>
>>>>> Another wonderful nios2 toolchain issue. Giulio, what do you think ?
>>>>
>>>> This is new to me, I've checked on Gcc Bugzilla and it doesn't seem to
>>>> be there. So I can file it up and look for a workaround, maybe the usual
>>>> -O0.
>>>
>>> With these errors, I'm never sure if it's a gcc issue (that emits bogus
>>> assembly) or a binutils issue. But most likely a gcc issue.
>>
>> It's a gcc bug and worked around with this patchset:
>> https://patchwork.ozlabs.org/project/buildroot/list/?series=232394
>>
>>>
>>>>>> nios2 | libgeos-3.9.0 | NOK | http://autobuild.buildroot.net/results/a05fdf1958f93a206c5c66c7f636b6650683626d | ORPH
>>>>>
>>>>> Some more nios2 toolchain issue.
>>>>
>>>> This is very similar to one of Microblaze gcc bugs. So I could be able
>>>> to workaround it with the same -O0.
>>
>> For this I don't find any work-around. I've found this patch from Nios
>> gcc mantainer:
>> https://patchwork.ozlabs.org/project/gcc/patch/b652a8a6-dcad-bbe6-4ec8-bc0cb3d71d45 at codesourcery.com/
>>
>> where she states that it could have fixed the bug due too many linker
>> warnings, but at the end she reverted. So no way.
>> Since I've tried building libgeos with gcc7/8/9/10 unsuccesfully,
>> for this package then I've sent this patch to disable it while building
>> for Nios:
>> https://patchwork.ozlabs.org/project/buildroot/patch/20210305160005.3826615-1-giulio.benetti at benettiengineering.com/
>>
>>> OK.
>>>
>>> Maybe we should default to -O2 for those funky architectures? Indeed,
>>> our default is -Os, but this is perhaps less widely used/tested than
>>> -O2 ?
>>>
>>> Or are the bugs in question also appearing at -O2 ?
>>
>> Unfortunately they show also with -O2, so we should entirely build with
>> -O0 but that would results in a very big rootfs. So for the moment IMHO
>> I would keep sending these workarounds.
>>
>>>>> Should we get rid of nios2 support entirely ?
>>>>
>>>> Here it seems we get to the same point of Microblaze, if there is no
>>>> hurry I can provide patches to save Nios the same way I've done for
>>>> Microblaze.
>>>
>>> My concern is that those gcc issues for nios2/microblaze never seem to
>>> be fixed. That there are gcc issues that we need to workaround, it's
>>> fine I guess, but that they stay forever is more annoying.
>>
>> Judging from the last 2 years, yes they won't be fixed at 90%...
>>
>>>
>>>>>> arm | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/d9b9a4b7c3660bd730a19ab09e44f24bc29e3f40 | ORPH
>>>>>> arm | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/13f9a551f5ac911e7daa2a382b0683d81486cffa | ORPH
>>>>>
>>>>> toolchain is gone ?
>>>>
>>>> Here it's Micronova firewall that blocks it, I've just written to my IT.
>>>
>>> OK, thanks!
>>>
>>>>>> powerpc | unknown | NOK | http://autobuild.buildroot.net/results/159d2c07060c235080711d1d0da0b2eae995d4bf |
>>>>>
>>>>> This is a top-level parallel build issue... but since we don't have the
>>>>> full log, we don't have the error.
>>>>>
>>>>> Should we perhaps keep the full log, compressed, for builds done in
>>>>> parallel ?
>>>>
>>>> I see it's on my Autobuilder, what can I do to provide suck full log? Do
>>>> you mean the entire Buildroot log? If yes I can try to reproduce it and
>>>> save it on a file and post it in some way.
>>>
>>> Now that the build is finished, the build log is gone. My proposal here
>>> was to adjust the autobuild-run script to upload to
>>> autobuild.buildroot.org the full build log (compressed) when the build
>>> is a top-level parallel build.
>>
>> Ah ok!
>>
>>>>>> or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/ed105d321c0bde99c293ab7328d57c3764db6f27 |
>>>>>> or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/ce351e0e97c2cacc17d4718d39941548c7558559 |
>>>>>
>>>>> /home/giuliobenetti/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.33.1 assertion fail elf32-or1k.c:2329
>>>>> collect2: error: ld returned 1 exit status
>>>>>
>>>>> Giulio, is this a known or1k issue ?
>>>>
>>>> Yes, for this I've sent a patchset time ago:
>>>> https://patchwork.ozlabs.org/project/buildroot/list/?series=161548
>>>>
>>>> So basically zeromq should be disabled like protobuf. But need to check it.
>>>>
>>>> You've also answered me here:
>>>> https://patchwork.ozlabs.org/project/buildroot/patch/20200228175814.128730-1-giulio.benetti at benettiengineering.com/
>>>>
>>>> Here it seems the same situation as Nios and Microblaze.
>>>>
>>>> For this I can provide patches too if not in hurry.
>>>
>>> Maybe we should be pragmatic here and just take your patches as-is.
>
> Forgotten that here is the v2 patchset including zeromq build failure
> disabling:
> https://patchwork.ozlabs.org/project/buildroot/list/?series=232409
>
>> They still apply to master branch too.
>>
>> I've also sent these patches since 2 Microblaze bugs have been fixed in
>> gcc 10.x:
>> https://patchwork.ozlabs.org/project/buildroot/patch/20210305153730.3671327-1-giulio.benetti at benettiengineering.com/
>> https://patchwork.ozlabs.org/project/buildroot/patch/20210305154139.3682817-1-giulio.benetti at benettiengineering.com/
>>
>> Best regards
>>
>
> Best regards
>
--
Giulio Benetti
Benetti Engineering sas
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2021-03-05 16:52 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-04 8:15 [Buildroot] [autobuild.buildroot.net] Daily results for 2021-03-03 Thomas Petazzoni
2021-03-04 21:49 ` [Buildroot] Analysis of build " Thomas Petazzoni
2021-03-04 22:26 ` Yann E. MORIN
2021-03-05 8:01 ` Giulio Benetti
2021-03-05 8:36 ` Peter Korsgaard
2021-03-05 7:56 ` Giulio Benetti
2021-03-05 8:55 ` Giulio Benetti
2021-03-05 9:13 ` Giulio Benetti
2021-03-05 9:22 ` Thomas Petazzoni
2021-03-05 16:01 ` Giulio Benetti
2021-03-05 16:13 ` Giulio Benetti
2021-03-05 16:52 ` Giulio Benetti
2021-03-05 9:48 ` Thomas De Schampheleire
2021-03-05 15:10 ` Heiko Thiery
2021-03-05 15:14 ` Thomas Petazzoni
2021-03-05 15:38 ` Heiko Thiery
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.