* [Buildroot] [autobuild.buildroot.net] Daily results for 2020-08-14
@ 2020-08-15 8:01 Thomas Petazzoni
2020-08-15 22:09 ` [Buildroot] [autobuild.buildroot.net] Analysis of build results Thomas Petazzoni
0 siblings, 1 reply; 20+ messages in thread
From: Thomas Petazzoni @ 2020-08-15 8:01 UTC (permalink / raw
To: buildroot
Hello,
Autobuild statistics for 2020-08-14
===================================
branch | OK | NOK | TIM | TOT |
2020.02.x | 9 | 7 | 0 | 16 |
2020.05.x | 13 | 11 | 0 | 24 |
master | 121 | 67 | 0 | 188 |
next | 30 | 23 | 0 | 53 |
Classification of failures by reason for master
-----------------------------------------------
keepalived-2.1.4 | 8
libglib2-2.64.4 | 8
dvb-apps-3d43b280298c39a67d... | 7
boost-1.73.0 | 3
host-grpc-1.30.2 | 3
kismet-2016-07-R1 | 3
opencv-2.4.13.7 | 3
rocksdb-6.10.1 | 3
unknown | 3
ibm-sw-tpm2-1563 | 2
opencv3-3.4.9 | 2
qt5base-5.15.0 | 2
am33x-cm3-11107db2f1e9e58ee... | 1
assimp-5.0.1 | 1
avahi-0.8 | 1
cvs-1.12.13 | 1
dnsmasq-2.81 | 1
eigen-3.3.7 | 1
gr-osmosdr-0.2.0 | 1
gvfs-1.44.1 | 1
host-elixir-1.9.4 | 1
host-mender-artifact-3.4.0 | 1
kmsxx-cb0786049f960f2bd3836... | 1
libcamera-96fab38e02792a109... | 1
log4cplus-2.0.5 | 1
mpv-0.29.1 | 1
pistache-f2f5a50fbfb5b8ef6c... | 1
qt5wayland-5.15.0 | 1
supertux-0.6.0 | 1
tio-1.32 | 1
wampcc-1.6 | 1
zeromq-4.3.2 | 1
Detail of failures for master
-----------------------------
arch | reason | OK? | url | orph?
-------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
arm | am33x-cm3-11107db2f1e9e58ee... | NOK | http://autobuild.buildroot.net/results/2899bcd58dcce8a1b820c1f310e1af7ebec1e1f0 | ORPH
mips64el | assimp-5.0.1 | NOK | http://autobuild.buildroot.net/results/a9cdf1454920a264447665a241d0904a83a2fd06 |
aarch64 | avahi-0.8 | NOK | http://autobuild.buildroot.net/results/b31aae410feaef5ff70a8b644b1be337e4e27338 | ORPH
x86_64 | boost-1.73.0 | NOK | http://autobuild.buildroot.net/results/84eb9bb82255878d6a58772cb96d253a5c02f625 |
x86_64 | boost-1.73.0 | NOK | http://autobuild.buildroot.net/results/2ddfabda83a42d06b6b9689bc83882c59d1b8db6 |
x86_64 | boost-1.73.0 | NOK | http://autobuild.buildroot.net/results/ce3f75b5a259924924c934e784b58feed2705be8 |
arm | cvs-1.12.13 | NOK | http://autobuild.buildroot.net/results/81e50a5b565fba0b5703730671d9e9dd86db3b93 | ORPH
arm | dnsmasq-2.81 | NOK | http://autobuild.buildroot.net/results/119aeffa1c3d1eaad929cc40af073c71b46cd17b |
riscv32 | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/b2e4b144b4270cee0e1efb29ca86da322e403213 |
xtensa | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/2ac9a7f329289532c8a3a75257f349e5662efb70 |
mips64el | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/e2ea73ab636d3493ef0c1db07d2fb4fba1bbbbab |
riscv32 | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/44863a6c6bcf0021298fcd9dba7b2b10ef1dbc93 |
m68k | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/5cdeb12ba89285a96c4eeefce47bf72a86e2d1f7 |
arm | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/e71f315ebd29230c746f687e457e898b75fbc464 |
microblazeel | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/d6001c4f5e294524739ff422e192786f76fe8a92 |
arm | eigen-3.3.7 | NOK | http://autobuild.buildroot.net/results/0b972b4e63cac9ae95dcac78e031d7b19e2e4e0d |
mips | gr-osmosdr-0.2.0 | NOK | http://autobuild.buildroot.net/results/3bb8d678aaa782b70c14a8f9cd3e1df2e55bc613 |
arm | gvfs-1.44.1 | NOK | http://autobuild.buildroot.net/results/5cedf537d2e947a2a7f492611ec4a8323c6e2b97 | ORPH
i686 | host-elixir-1.9.4 | NOK | http://autobuild.buildroot.net/results/a3a37eb724ca5689f8e83c9b2af04d07afa80315 |
powerpc64 | host-grpc-1.30.2 | NOK | http://autobuild.buildroot.net/results/37847b16d8ece2f4f6ed34ef15c0a185e13a9055 |
arm | host-grpc-1.30.2 | NOK | http://autobuild.buildroot.net/results/b920d98e17e99f32c535cf046dd0e83d80271dd7 |
aarch64 | host-grpc-1.30.2 | NOK | http://autobuild.buildroot.net/results/d76edbda32622ff7cae2e8ac7a39e3fb46590796 |
aarch64_be | host-mender-artifact-3.4.0 | NOK | http://autobuild.buildroot.net/results/6c2fe35b309ae06eb4ada9a9292e03b7aa77a1b5 |
riscv64 | ibm-sw-tpm2-1563 | NOK | http://autobuild.buildroot.net/results/d01139419fdb0976754ee69dd35f8b8e78716820 |
arm | ibm-sw-tpm2-1563 | NOK | http://autobuild.buildroot.net/results/139eec08e9a138f59dcd8b91503716e73dad547f |
mipsel | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/453d38d0ef5b2a3825bc5f923a6b59055c651b11 |
arm | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/34cfaf0e7dd459f62792fc414df604c8ff04fc86 |
arc | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/79bde26aca95860a2e77cc9d70de97387c6a1be0 |
riscv64 | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/9b2ef7932c9fd74d72214b831ac203d3c74dd4ce |
aarch64 | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/5dd83b33ef54a4a6ecf0be47adb3a4672a5bb067 |
powerpc64 | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/4567e3b0a0510e8a615781178ff5bbbd835a92c3 |
aarch64_be | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/bbd1597534df46895a6736629ffc44bcc0150618 |
arm | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/c8e994a3d78910a2239211386b4ca6688ad8bb05 |
arc | kismet-2016-07-R1 | NOK | http://autobuild.buildroot.net/results/07dca0689044777cd6533dfe244f22abc7c3084d | ORPH
powerpc | kismet-2016-07-R1 | NOK | http://autobuild.buildroot.net/results/50e314b341fb46acfc81c84b6aff3381cb89cf75 | ORPH
xtensa | kismet-2016-07-R1 | NOK | http://autobuild.buildroot.net/results/718dd77dd44cd4bc43761900c1e0746074de038c | ORPH
arm | kmsxx-cb0786049f960f2bd3836... | NOK | http://autobuild.buildroot.net/results/7777cd9496e8f8cdb093c3f82c550eebedda0b5d |
x86_64 | libcamera-96fab38e02792a109... | NOK | http://autobuild.buildroot.net/results/c28500d4cc55fbd2bac87f2c11759ddc9163bc91 |
riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/2f05d672560a9e9dfb4412146b73f36667fe7e29 |
riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/4ba63b6df6229462cee9be880bec89216307acb3 |
riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/0839ee8b268dd010bef243d4b91a2a86f6e22655 |
riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/be8ce63d6053ecff4e51e210dfaf58a4a8f772bb |
riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/79d035ef9ae878d593c330f4b2e690d05651673d |
riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/0d1525c2e73a03650a1999c118108cb19fe7673d |
riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/5ee78c831db40d3e7fbe11d3538f9f311a886969 |
riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/e1c56bce298ea0276edb46b48b8d0681d2b539e1 |
arc | log4cplus-2.0.5 | NOK | http://autobuild.buildroot.net/results/a7732fdb2ba526a114d9fb759814236c5332f8d7 |
riscv64 | mpv-0.29.1 | NOK | http://autobuild.buildroot.net/results/d50171c7a90b38daf6b1c7af97dd61c816fcfac3 |
arc | opencv-2.4.13.7 | NOK | http://autobuild.buildroot.net/results/949630bb8bd63eed740abee4600deb238a6cbb0b |
arc | opencv-2.4.13.7 | NOK | http://autobuild.buildroot.net/results/db622456c121cef9ed54931abb5c59603b25e1a8 |
powerpc64 | opencv-2.4.13.7 | NOK | http://autobuild.buildroot.net/results/52d99beb5c7512429264e265545ddc0f05d53781 |
arc | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/e21dae6b7680d720b00558212a42206f6aaaa107 |
powerpc64le | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/87a49185211d0238aeb028f0c3607f3fa05e8c61 |
nios2 | pistache-f2f5a50fbfb5b8ef6c... | NOK | http://autobuild.buildroot.net/results/a1bb21a275e78de450f73e30821cbadb3a796d95 | ORPH
i686 | qt5base-5.15.0 | NOK | http://autobuild.buildroot.net/results/48165633b841ce6468b7c34d7e47a6fb2a4555ef |
arm | qt5base-5.15.0 | NOK | http://autobuild.buildroot.net/results/bcf68bf4cbb7cb6d1bf902ac6c288806d6c50588 |
aarch64 | qt5wayland-5.15.0 | NOK | http://autobuild.buildroot.net/results/f673d4bd730b029bda29357f0b1442cc22475895 |
arm | rocksdb-6.10.1 | NOK | http://autobuild.buildroot.net/results/7014f905b9a678cec0699f4bb1d9b6d61535704e |
arm | rocksdb-6.10.1 | NOK | http://autobuild.buildroot.net/results/3776d2302f389691db972de35e077dcf2a07afab |
arm | rocksdb-6.10.1 | NOK | http://autobuild.buildroot.net/results/72f6f1aca4f1c9e19850ceccef7fed756af0e403 |
aarch64_be | supertux-0.6.0 | NOK | http://autobuild.buildroot.net/results/0f02877a665b2281266df4b23c72a7c113906c31 |
sparc64 | tio-1.32 | NOK | http://autobuild.buildroot.net/results/028efb98838163b0c697bba30cedbc4f0704748d |
arm | unknown | NOK | http://autobuild.buildroot.net/results/0333faabe50ac103324085cc219fbfe06a1718bb |
powerpc64le | unknown | NOK | http://autobuild.buildroot.net/results/542e97923620b2135fe5c846ad97c324cc108f43 |
arm | unknown | NOK | http://autobuild.buildroot.net/results/93d88fcfe723e91846a68a9d87de585a741f3c5b |
arc | wampcc-1.6 | NOK | http://autobuild.buildroot.net/results/c3b67d8a5faf7ff06b08a0591f22b1fa4963c2ee | ORPH
or1k | zeromq-4.3.2 | NOK | http://autobuild.buildroot.net/results/538474abda90082eec91ca9017e91b4427e4f54b |
Classification of failures by reason for 2020.02.x
--------------------------------------------------
host-grpc-1.25.0 | 2
dvb-apps-3d43b280298c39a67d... | 1
libopenssl-1.1.1g | 1
rocksdb-6.6.4 | 1
unknown | 1
wireshark-3.2.5 | 1
Detail of failures for 2020.02.x
--------------------------------
arch | reason | OK? | url | orph?
-------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
i586 | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/7b024a5d29e8b34b1cd4a38748f0cff50d190cce |
x86_64 | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/4cf5f67c209f0b57b8258b5b17904ca89d20c4f3 |
arc | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/f861127b08d8e6834ef5095b3ce3b41f937570fd |
m68k | libopenssl-1.1.1g | NOK | http://autobuild.buildroot.net/results/215e654d0cc6ae6a92f3bb76afdd9e08eff81629 |
arm | rocksdb-6.6.4 | NOK | http://autobuild.buildroot.net/results/5d7de599f661a25bdbfd8671dc7d2063c4b534b1 |
xtensa | unknown | NOK | http://autobuild.buildroot.net/results/8a6c02123389dc5fc904b8ef6641238396253c7f |
powerpc | wireshark-3.2.5 | NOK | http://autobuild.buildroot.net/results/5c23163da760a12045d060b3e0c35733f8c2d909 | ORPH
Classification of failures by reason for 2020.05.x
--------------------------------------------------
qt5base-5.14.2 | 3
dvb-apps-3d43b280298c39a67d... | 2
assimp-5.0.1 | 1
luabitop-1.0.2-1 | 1
spandsp-20180108 | 1
strace-5.7 | 1
unknown | 1
uvw-2.5.0_libuv-v1.37 | 1
Detail of failures for 2020.05.x
--------------------------------
arch | reason | OK? | url | orph?
-------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
mips64el | assimp-5.0.1 | NOK | http://autobuild.buildroot.net/results/1c95733bc05c123fc745128f9e1c9e97d2966505 |
x86_64 | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/68c77ff4779a1c092e4e70b4960e1507c05ea74e |
riscv32 | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/f6b4dceace9b1bed639b3e88cb119f6c8152b385 |
arm | luabitop-1.0.2-1 | NOK | http://autobuild.buildroot.net/results/1df8908ec3df76de491f91342ac575bd3b950a98 |
arm | qt5base-5.14.2 | NOK | http://autobuild.buildroot.net/results/52afc5803d8af0dda4466713816f855894c6c8c9 |
x86_64 | qt5base-5.14.2 | NOK | http://autobuild.buildroot.net/results/65102b89f3b05bb9d75a2b5d950647cf3cf45b6d |
aarch64_be | qt5base-5.14.2 | NOK | http://autobuild.buildroot.net/results/b97b53fdb5229ed3c17ded85b72f397d89db82d9 |
i686 | spandsp-20180108 | NOK | http://autobuild.buildroot.net/results/4709b532d57758751865c565233daac376c1c669 |
aarch64_be | strace-5.7 | NOK | http://autobuild.buildroot.net/results/499efc6a086e1ca89bd97df4ee2fb6906fd6c448 |
i586 | unknown | NOK | http://autobuild.buildroot.net/results/a08f91365e6a964143769a0b0edc579dbe7ce32e |
powerpc | uvw-2.5.0_libuv-v1.37 | NOK | http://autobuild.buildroot.net/results/cb30ca01f748750e5b65ce61d0129384cb6382c1 |
Classification of failures by reason for next
---------------------------------------------
domoticz-2020.1 | 3
assimp-5.0.1 | 2
keepalived-2.1.4 | 2
qt5base-5.15.0 | 2
tio-1.32 | 2
belle-sip-4.3.1 | 1
bitcoin-0.19.0.1 | 1
dvb-apps-3d43b280298c39a67d... | 1
ffmpeg-4.3.1 | 1
gdb-arc-2020.03-release-gdb | 1
guile-3.0.4 | 1
host-guile-3.0.4 | 1
libglib2-2.64.4 | 1
opencv3-3.4.9 | 1
pistache-f2f5a50fbfb5b8ef6c... | 1
rocksdb-6.10.1 | 1
unknown | 1
Detail of failures for next
---------------------------
arch | reason | OK? | url | orph?
-------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
mips64el | assimp-5.0.1 | NOK | http://autobuild.buildroot.net/results/e981ded75b0eb7ae32c9344f06b433b93c935a09 |
mips64el | assimp-5.0.1 | NOK | http://autobuild.buildroot.net/results/dc01116c400ce0cfb1924b4fbe381b4a0f75f684 |
xtensa | belle-sip-4.3.1 | NOK | http://autobuild.buildroot.net/results/08eb90470d677c19bb26ef6979f235c54ccfbc1c |
arc | bitcoin-0.19.0.1 | NOK | http://autobuild.buildroot.net/results/fb518a6b146bc5acd7c58f649107bc5cfef13a03 |
mipsel | domoticz-2020.1 | NOK | http://autobuild.buildroot.net/results/f460ecf1b1fb7833f07add07fcf672922941be2b |
arm | domoticz-2020.1 | NOK | http://autobuild.buildroot.net/results/38abf582fa15642bef86909fd2591671193d3dea |
nios2 | domoticz-2020.1 | NOK | http://autobuild.buildroot.net/results/641893d9a672849b3309db67a56ca715df0bed6a |
powerpc | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/30dff1af8a34a6bcde3c90596b7534bcb3c41547 |
arm | ffmpeg-4.3.1 | NOK | http://autobuild.buildroot.net/results/5c7113a8c615265f38b5f2559f11b9a49c6c46c3 |
arc | gdb-arc-2020.03-release-gdb | NOK | http://autobuild.buildroot.net/results/e1782b001b083f013b6eb010f74b1531f90c7b8f | ORPH
arm | guile-3.0.4 | NOK | http://autobuild.buildroot.net/results/1baae0947f9e66319cc3b0e255132e1979c724ef | ORPH
powerpc | host-guile-3.0.4 | NOK | http://autobuild.buildroot.net/results/fcfdae77e267751eed73bcbd3cdf74231d5ac1b4 | ORPH
aarch64 | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/28b699878d686c950ce4d1370eeb5723139c5428 |
arm | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/19113d8f234cdbdc5bd9bbee217022b6aacf67b2 |
riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/3a7a916c36e66fc4e640ef3199ca876ee8022625 |
mipsel | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/fbc153427c64746581af3defda0760ed46fd0668 |
mipsel | pistache-f2f5a50fbfb5b8ef6c... | NOK | http://autobuild.buildroot.net/results/06e01ab680ee2a3b501cf4bcd1c748f1e048adf4 | ORPH
x86_64 | qt5base-5.15.0 | NOK | http://autobuild.buildroot.net/results/56e560e80edb01ef62c7099ceb9ff1cc9c193ff4 |
arm | qt5base-5.15.0 | NOK | http://autobuild.buildroot.net/results/b68818b602e3edc5731128fa0f98c429c111217e |
arm | rocksdb-6.10.1 | NOK | http://autobuild.buildroot.net/results/1635c35a5d20f9b23611b90732536e4678268e8f |
sparc | tio-1.32 | NOK | http://autobuild.buildroot.net/results/91f174b4aa0341c860928293a783282422b19440 |
sparc64 | tio-1.32 | NOK | http://autobuild.buildroot.net/results/37e108ffdd835529c604afd0d4ebe646dc8f937d |
arc | unknown | NOK | http://autobuild.buildroot.net/results/7e39e4fd11bfbea2be95030ebc1e74316414d522 |
Gitlab CI results for 2020-08-14
================================
--
http://autobuild.buildroot.net
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Analysis of build results
2020-08-15 8:01 [Buildroot] [autobuild.buildroot.net] Daily results for 2020-08-14 Thomas Petazzoni
@ 2020-08-15 22:09 ` Thomas Petazzoni
2020-08-15 22:14 ` Thomas Petazzoni
` (7 more replies)
0 siblings, 8 replies; 20+ messages in thread
From: Thomas Petazzoni @ 2020-08-15 22:09 UTC (permalink / raw
To: buildroot
Hello,
Frank, Gwenhael, Romain, Adam, ARC maintainers, Peter, there are some
questions/issues for you below.
Everybody else: please help fixing autobuilder issues !
See below some preliminary analysis of all build failures that occurred
on August 14.
On Sat, 15 Aug 2020 08:01:40 -0000
Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> master | 121 | 67 | 0 | 188 |
So we're still at about ~30% of failures, which isn't exactly good.
> arch | reason | OK? | url | orph?
> -------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
> arm | am33x-cm3-11107db2f1e9e58ee... | NOK | http://autobuild.buildroot.net/results/2899bcd58dcce8a1b820c1f310e1af7ebec1e1f0 | ORPH
/nvme/rc-buildroot-test/scripts/instance-1/output-1/host/lib/gcc/arm-buildroot-linux-gnueabihf/10.2.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: src/foundation/startup.o: in function `reset_handler':
/nvme/rc-buildroot-test/scripts/instance-1/output-1/build/am33x-cm3-11107db2f1e9e58ee75d4fe9cc38423c9a6e4365/src/foundation/startup.c:177: undefined reference to `memcpy'
Looking at the history of this failure:
http://autobuild.buildroot.net/?reason=am33x-cm3%
We had some failures until November 2019, with a different error. And
then since yesterday (August 14), two failures with this memcpy()
issue. Interestingly, the two failed builds are using gcc 10. At line
177 in startup.c, we have:
for(puldest = &_start_data; puldest < &_end_data; )
{
*puldest++ = *pulsrc++;
}
I.e, we don't have a call to memcpy(), but gcc detects it's a memory
copy, and generates a call to memcpy().
I'm not sure what's the right gcc option to make it not emit such
memcpy() function call...
> mips64el | assimp-5.0.1 | NOK | http://autobuild.buildroot.net/results/a9cdf1454920a264447665a241d0904a83a2fd06 |
Error message:
relocation truncated to fit: R_MIPS_CALL16
This build issue occurs only on mips64, but several variants of the
architecture, and with both uClibc and glibc.
It seems like we're hitting the issue described at
https://lists.debian.org/debian-mips/2016/11/msg00008.html, and we
already have a work around for assimp for m68k:
# relocation truncated to fit: R_68K_GOT16O
ifeq ($(BR2_m68k),y)
ASSIMP_CXXFLAGS += -mxgot
endif
Should we do the same for mips64 ?
> aarch64 | avahi-0.8 | NOK | http://autobuild.buildroot.net/results/b31aae410feaef5ff70a8b644b1be337e4e27338 | ORPH
This is being worked by Adam, he has proposed a patch, but I made some
comments.
> x86_64 | boost-1.73.0 | NOK | http://autobuild.buildroot.net/results/84eb9bb82255878d6a58772cb96d253a5c02f625 |
> x86_64 | boost-1.73.0 | NOK | http://autobuild.buildroot.net/results/2ddfabda83a42d06b6b9689bc83882c59d1b8db6 |
> x86_64 | boost-1.73.0 | NOK | http://autobuild.buildroot.net/results/ce3f75b5a259924924c934e784b58feed2705be8 |
A wonderful:
./boost/thread/thread_time.hpp:32:60: internal compiler error: Segmentation fault
This is failing only with this toolchain, which uses gcc 6.2.0. We're
using the version 2016.11-19 of this toolchain, which is really old,
and Mentor Graphics has published newer versions
(https://sourcery.mentor.com/GNUToolchain/subscription51456) but they
are no longer publicly available.
So I would advocate for dropping support for this toolchain. I'll send
a patch doing that.
> arm | cvs-1.12.13 | NOK | http://autobuild.buildroot.net/results/81e50a5b565fba0b5703730671d9e9dd86db3b93 | ORPH
> arm | dnsmasq-2.81 | NOK | http://autobuild.buildroot.net/results/119aeffa1c3d1eaad929cc40af073c71b46cd17b |
> riscv32 | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/b2e4b144b4270cee0e1efb29ca86da322e403213 |
> xtensa | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/2ac9a7f329289532c8a3a75257f349e5662efb70 |
> mips64el | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/e2ea73ab636d3493ef0c1db07d2fb4fba1bbbbab |
> riscv32 | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/44863a6c6bcf0021298fcd9dba7b2b10ef1dbc93 |
> m68k | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/5cdeb12ba89285a96c4eeefce47bf72a86e2d1f7 |
> arm | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/e71f315ebd29230c746f687e457e898b75fbc464 |
> microblazeel | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/d6001c4f5e294524739ff422e192786f76fe8a92 |
This was a download issue. I've placed a dvb-apps tarball on
sources.buildroot.net. However, our CDN is still caching the
non-existence of this file, so we need those cache results to expire
for the build issues to disappear.
> arm | eigen-3.3.7 | NOK | http://autobuild.buildroot.net/results/0b972b4e63cac9ae95dcac78e031d7b19e2e4e0d |
Detects Fortran (even though that dependency is not expressed in the
eigen package), but fails to use it.
It would be good to explicitly disable using Fortran in this package.
Romain, is this something you could have a look at ?
> mips | gr-osmosdr-0.2.0 | NOK | http://autobuild.buildroot.net/results/3bb8d678aaa782b70c14a8f9cd3e1df2e55bc613 |
mips-linux-gnu-g++: ERROR: unsafe header/library path used in cross-compilation: '-isystem' '/usr/include'
mips-linux-gnu-g++: ERROR: unsafe header/library path used in cross-compilation: '-isystem' '/usr/include'
Gwenhael, could you take care of this, at least do some preliminary
analysis to find where this bogus -isystem invocation comes from ?
> arm | gvfs-1.44.1 | NOK | http://autobuild.buildroot.net/results/5cedf537d2e947a2a7f492611ec4a8323c6e2b97 | ORPH
/home/peko/autobuild/instance-1/output-1/host/bin/meson --internal msgfmthelper daemon/org.gtk.vfs.file-operations.policy.in daemon/org.gtk.vfs.file-operations.policy xml /home/peko/autobuild/instance-1/output-1/build/gvfs-1.44.1/po
msgfmt: cannot locate ITS rules for daemon/org.gtk.vfs.file-operations.policy.in
This is with BR2_SYSTEM_ENABLE_NLS=y, so we have the full gettext
available. There is some background at
https://github.com/mesonbuild/meson/issues/1565.
> i686 | host-elixir-1.9.4 | NOK | http://autobuild.buildroot.net/results/a3a37eb724ca5689f8e83c9b2af04d07afa80315 |
make[1]: Entering directory '/tmp/instance-1/output-1/build/host-elixir-1.9.4'
make[1]: erlc: Command not found
We have this once in a while, on different machines:
http://autobuild.buildroot.net/?reason=host-elixir%
Weird that it doesn't appear more often. Is there some kind of race condition?
Frank: you added the host-elixir package, could you have a look ?
> powerpc64 | host-grpc-1.30.2 | NOK | http://autobuild.buildroot.net/results/37847b16d8ece2f4f6ed34ef15c0a185e13a9055 |
> arm | host-grpc-1.30.2 | NOK | http://autobuild.buildroot.net/results/b920d98e17e99f32c535cf046dd0e83d80271dd7 |
> aarch64 | host-grpc-1.30.2 | NOK | http://autobuild.buildroot.net/results/d76edbda32622ff7cae2e8ac7a39e3fb46590796 |
This is the infamous host-grpc build issue on Yann's machine. Adam, I
thought you had made some progress with this? Do you have a status?
Some ideas/leads?
> aarch64_be | host-mender-artifact-3.4.0 | NOK | http://autobuild.buildroot.net/results/6c2fe35b309ae06eb4ada9a9292e03b7aa77a1b5 |
This was fixed by 235636409fddadfdfcaaaaf69f815fc349bcd69f.
> riscv64 | ibm-sw-tpm2-1563 | NOK | http://autobuild.buildroot.net/results/d01139419fdb0976754ee69dd35f8b8e78716820 |
> arm | ibm-sw-tpm2-1563 | NOK | http://autobuild.buildroot.net/results/139eec08e9a138f59dcd8b91503716e73dad547f |
Both fixed by 19bd08900448aa45b506320ad2ab912f789e6e5e.
> mipsel | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/453d38d0ef5b2a3825bc5f923a6b59055c651b11 |
> arm | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/34cfaf0e7dd459f62792fc414df604c8ff04fc86 |
> arc | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/79bde26aca95860a2e77cc9d70de97387c6a1be0 |
> riscv64 | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/9b2ef7932c9fd74d72214b831ac203d3c74dd4ce |
> aarch64 | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/5dd83b33ef54a4a6ecf0be47adb3a4672a5bb067 |
> powerpc64 | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/4567e3b0a0510e8a615781178ff5bbbd835a92c3 |
> aarch64_be | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/bbd1597534df46895a6736629ffc44bcc0150618 |
> arm | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/c8e994a3d78910a2239211386b4ca6688ad8bb05 |
Fixed by
https://git.buildroot.org/buildroot/commit/?id=97b3e2be0cb53415ab20ba4ae0d8638c087f7819
> arc | kismet-2016-07-R1 | NOK | http://autobuild.buildroot.net/results/07dca0689044777cd6533dfe244f22abc7c3084d | ORPH
> powerpc | kismet-2016-07-R1 | NOK | http://autobuild.buildroot.net/results/50e314b341fb46acfc81c84b6aff3381cb89cf75 | ORPH
> xtensa | kismet-2016-07-R1 | NOK | http://autobuild.buildroot.net/results/718dd77dd44cd4bc43761900c1e0746074de038c | ORPH
socket.h:289:33: error: flexible array member 'cmsghdr::__cmsg_data' not at end of 'struct<unnamed>'
Reported in Debian as well:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954636, but not fixed.
> arm | kmsxx-cb0786049f960f2bd3836... | NOK | http://autobuild.buildroot.net/results/7777cd9496e8f8cdb093c3f82c550eebedda0b5d |
Fixed by d82fa9e022f7f7781df8f1124430aa31688bf827
> x86_64 | libcamera-96fab38e02792a109... | NOK | http://autobuild.buildroot.net/results/c28500d4cc55fbd2bac87f2c11759ddc9163bc91 |
/home/peko/autobuild/instance-1/output-1/host/x86_64-buildroot-linux-gnu/sysroot/usr/include/glib-2.0/glib/gatomic.h:128:15: error: variable 'gapg_temp_atomic' set but not used [-Werror=unused-but-set-variable]
Meh, it is built with -Werror... and the issue is actually in a header
from libglib2, so nothing that libcamera can fix.
> riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/2f05d672560a9e9dfb4412146b73f36667fe7e29 |
> riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/4ba63b6df6229462cee9be880bec89216307acb3 |
> riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/0839ee8b268dd010bef243d4b91a2a86f6e22655 |
> riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/be8ce63d6053ecff4e51e210dfaf58a4a8f772bb |
> riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/79d035ef9ae878d593c330f4b2e690d05651673d |
> riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/0d1525c2e73a03650a1999c118108cb19fe7673d |
> riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/5ee78c831db40d3e7fbe11d3538f9f311a886969 |
> riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/e1c56bce298ea0276edb46b48b8d0681d2b539e1 |
Fixed by
https://git.buildroot.org/buildroot/commit/?id=e7d631c0df1698b4edc94f148e7247869430e108
> arc | log4cplus-2.0.5 | NOK | http://autobuild.buildroot.net/results/a7732fdb2ba526a114d9fb759814236c5332f8d7 |
undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)'
This is happening only on ARC700. Perhaps a variant of ARC that doesn't
support atomic instructions?
ARC maintainers, could you have a look please ?
> riscv64 | mpv-0.29.1 | NOK | http://autobuild.buildroot.net/results/d50171c7a90b38daf6b1c7af97dd61c816fcfac3 |
/tmp/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-musl/9.2.0/../../../../riscv64-buildroot-linux-musl/bin/ld: video/out/vo_libmpv.c.19.o: undefined reference to symbol '__atomic_compare_exchange_1@@LIBATOMIC_1.0'
/tmp/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-musl/9.2.0/../../../../riscv64-buildroot-linux-musl/bin/ld: /tmp/instance-1/output-1/host/riscv64-buildroot-linux-musl/sysroot/lib64/libatomic.so.1: error adding symbols: DSO missing from command line
mpv has a:
depends on BR2_TOOLCHAIN_HAS_ATOMIC || BR2_TOOLCHAIN_HAS_SYNC_8
probably it should link against libatomic when available ? It means
that RISC-V 64 doesn't have support for sync 8 built-ins ?
> arc | opencv-2.4.13.7 | NOK | http://autobuild.buildroot.net/results/949630bb8bd63eed740abee4600deb238a6cbb0b |
> arc | opencv-2.4.13.7 | NOK | http://autobuild.buildroot.net/results/db622456c121cef9ed54931abb5c59603b25e1a8 |
> powerpc64 | opencv-2.4.13.7 | NOK | http://autobuild.buildroot.net/results/52d99beb5c7512429264e265545ddc0f05d53781 |
grfmt_jpeg2000.cpp:341:71: error: lvalue required as unary '&' operand
Needs investigation.
> arc | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/e21dae6b7680d720b00558212a42206f6aaaa107 |
> powerpc64le | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/87a49185211d0238aeb028f0c3607f3fa05e8c61 |
Same issue as with opencv:
grfmt_jpeg2000.cpp:380:71: error: lvalue required as unary '&' operand
> nios2 | pistache-f2f5a50fbfb5b8ef6c... | NOK | http://autobuild.buildroot.net/results/a1bb21a275e78de450f73e30821cbadb3a796d95 | ORPH
-- Looking for __atomic_load_8 in atomic
-- Looking for __atomic_load_8 in atomic - not found
CMake Error at CMakeModules/CheckAtomic.cmake:76 (message):
Host compiler appears to require libatomic for 64-bit operations, but
cannot find it.
Call Stack (most recent call first):
CMakeLists.txt:19 (include)
Needs to link against libatomic perhaps ?
> i686 | qt5base-5.15.0 | NOK | http://autobuild.buildroot.net/results/48165633b841ce6468b7c34d7e47a6fb2a4555ef |
> arm | qt5base-5.15.0 | NOK | http://autobuild.buildroot.net/results/bcf68bf4cbb7cb6d1bf902ac6c288806d6c50588 |
Peter (Seiderer), any idea ?
/home/buildroot/autobuild/run/instance-2/output-1/build/qt5base-5.15.0/include/QtCore/../../src/corelib/kernel/qmetatype.h:1160:135: error: ambiguous class template instantiation for 'struct QtMetaTypePrivate::ContainerCapabilitiesImpl<QList<QVariant>, void>'
> aarch64 | qt5wayland-5.15.0 | NOK | http://autobuild.buildroot.net/results/f673d4bd730b029bda29357f0b1442cc22475895 |
Checking for wayland-scanner... yes
Checking for EGL 1.5 with Wayland Platform... no
Project ERROR: Test config.qtwayland_client.tests.dmabuf-server-buffer tries to use undeclared library 'drm'
Meh :/
> arm | rocksdb-6.10.1 | NOK | http://autobuild.buildroot.net/results/7014f905b9a678cec0699f4bb1d9b6d61535704e |
> arm | rocksdb-6.10.1 | NOK | http://autobuild.buildroot.net/results/3776d2302f389691db972de35e077dcf2a07afab |
> arm | rocksdb-6.10.1 | NOK | http://autobuild.buildroot.net/results/72f6f1aca4f1c9e19850ceccef7fed756af0e403 |
Ouch:
during RTL pass: cprop_hardreg
db/memtable.cc:232:1: internal compiler error: in extract_constrain_insn, at recog.c:2205
Could someone figure out if this gcc 8.3 issue still exists ?
> aarch64_be | supertux-0.6.0 | NOK | http://autobuild.buildroot.net/results/0f02877a665b2281266df4b23c72a7c113906c31 |
/tmp/instance-0/output-1/build/supertux-0.6.0/src/editor/object_settings.cpp:223:26: error: 'remove_if' is not a member of 'std'
m_options.erase(std::remove_if(m_options.begin(), m_options.end(),
Romain, supertux is your thing, could you have a look ?
> sparc64 | tio-1.32 | NOK | http://autobuild.buildroot.net/results/028efb98838163b0c697bba30cedbc4f0704748d |
Gah: error: redefinition of 'struct termio'
> arm | unknown | NOK | http://autobuild.buildroot.net/results/0333faabe50ac103324085cc219fbfe06a1718bb |
This looks like a top-level parallel build failure, the log is not long
enough to show the real problem.
> powerpc64le | unknown | NOK | http://autobuild.buildroot.net/results/542e97923620b2135fe5c846ad97c324cc108f43 |
Ditto.
> arm | unknown | NOK | http://autobuild.buildroot.net/results/93d88fcfe723e91846a68a9d87de585a741f3c5b |
And again. I'm not sure how to improve this. Upload the full build log
? This could be huge :-/
> arc | wampcc-1.6 | NOK | http://autobuild.buildroot.net/results/c3b67d8a5faf7ff06b08a0591f22b1fa4963c2ee | ORPH
/home/test/autobuild/run/instance-3/output-1/host/lib/gcc/arc-buildroot-linux-uclibc/9.3.1/../../../../arc-buildroot-linux-uclibc/bin/ld: ../libs/wampcc/libwampcc.so.6.0.0: undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)'
collect2: error: ld returned 1 exit status
This looks very similar to the log4cplus build issue above, also
happens only on ARC:
http://autobuild.buildroot.net/?reason=wampcc-1.6
ARC maintainers, could you have a look ?
> or1k | zeromq-4.3.2 | NOK | http://autobuild.buildroot.net/results/538474abda90082eec91ca9017e91b4427e4f54b |
Broken binutils:
/home/test/autobuild/run/instance-0/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.32 assertion fail elf32-or1k.c:2331
Would be useful to test with newer binutils.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Analysis of build results
2020-08-15 22:09 ` [Buildroot] [autobuild.buildroot.net] Analysis of build results Thomas Petazzoni
@ 2020-08-15 22:14 ` Thomas Petazzoni
2020-08-17 9:19 ` Gwenhael Goavec-Merou
` (6 subsequent siblings)
7 siblings, 0 replies; 20+ messages in thread
From: Thomas Petazzoni @ 2020-08-15 22:14 UTC (permalink / raw
To: buildroot
On Sun, 16 Aug 2020 00:09:14 +0200
Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> > arc | kismet-2016-07-R1 | NOK | http://autobuild.buildroot.net/results/07dca0689044777cd6533dfe244f22abc7c3084d | ORPH
> > powerpc | kismet-2016-07-R1 | NOK | http://autobuild.buildroot.net/results/50e314b341fb46acfc81c84b6aff3381cb89cf75 | ORPH
> > xtensa | kismet-2016-07-R1 | NOK | http://autobuild.buildroot.net/results/718dd77dd44cd4bc43761900c1e0746074de038c | ORPH
>
> socket.h:289:33: error: flexible array member 'cmsghdr::__cmsg_data' not at end of 'struct<unnamed>'
>
> Reported in Debian as well:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954636, but not fixed.
I had a closer look. Our old/legacy version of Kismet does this:
typedef struct {
struct cmsghdr header;
int fd;
} __attribute__((packed)) cmsg_fd;
struct cmsghdr is defined in socket.h like this:
struct cmsghdr
{
size_t cmsg_len; /* Length of data in cmsg_data plus length
of cmsghdr structure.
!! The type should be socklen_t but the
definition of the kernel is incompatible
with this. */
int cmsg_level; /* Originating protocol. */
int cmsg_type; /* Protocol specific type. */
#if __glibc_c99_flexarr_available
__extension__ unsigned char __cmsg_data __flexarr; /* Ancillary data. */
#endif
};
So, if __glibc_c99_flexarr_available, there is a flexible array member
at the end of cmsghdr, which makes it illegal to have a "int fd" field
after "struct cmsghdr header" in the cmsg_fd structure defined by
kismet.
It seems like the (old) kismet code was written before
__glibc_c99_flexarr_available. This __glibc_c99_flexarr_available
define is defined like this in <sys/cdefs.h>
/* Support for flexible arrays.
Headers that should use flexible arrays only if they're "real"
(e.g. only if they won't affect sizeof()) should test
#if __glibc_c99_flexarr_available. */
#if defined __STDC_VERSION__ && __STDC_VERSION__ >= 199901L
# define __flexarr []
# define __glibc_c99_flexarr_available 1
#elif __GNUC_PREREQ (2,97)
/* GCC 2.97 supports C99 flexible array members as an extension,
even when in C89 mode or compiling C++ (any version). */
# define __flexarr []
# define __glibc_c99_flexarr_available 1
#elif defined __GNUC__
/* Pre-2.97 GCC did not support C99 flexible arrays but did have
an equivalent extension with slightly different notation. */
# define __flexarr [0]
# define __glibc_c99_flexarr_available 1
#else
/* Some other non-C99 compiler. Approximate with [1]. */
# define __flexarr [1]
# define __glibc_c99_flexarr_available 0
#endif
So it seems like by playing with a -std= gcc option, we could
potentially get rid of this. It would however be good to understand
starting which gcc version this started failing (at least gcc 9.x fails
to build) and therefore which change of default standard caused the
breakage.
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Analysis of build results
2020-08-15 22:09 ` [Buildroot] [autobuild.buildroot.net] Analysis of build results Thomas Petazzoni
2020-08-15 22:14 ` Thomas Petazzoni
@ 2020-08-17 9:19 ` Gwenhael Goavec-Merou
2020-08-17 9:40 ` Thomas Petazzoni
2020-08-17 12:18 ` Asaf Kahlon
` (5 subsequent siblings)
7 siblings, 1 reply; 20+ messages in thread
From: Gwenhael Goavec-Merou @ 2020-08-17 9:19 UTC (permalink / raw
To: buildroot
Thomas, all
On Sun, 16 Aug 2020 00:09:14 +0200
Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> Hello,
>
> Frank, Gwenhael, Romain, Adam, ARC maintainers, Peter, there are some
> questions/issues for you below.
>
> Everybody else: please help fixing autobuilder issues !
>
> See below some preliminary analysis of all build failures that occurred
> on August 14.
>
[...]
>
> > mips | gr-osmosdr-0.2.0 | NOK | http://autobuild.buildroot.net/results/3bb8d678aaa782b70c14a8f9cd3e1df2e55bc613 |
>
> mips-linux-gnu-g++: ERROR: unsafe header/library path used in cross-compilation: '-isystem' '/usr/include'
> mips-linux-gnu-g++: ERROR: unsafe header/library path used in cross-compilation: '-isystem' '/usr/include'
>
> Gwenhael, could you take care of this, at least do some preliminary
> analysis to find where this bogus -isystem invocation comes from ?
>
I have, by the past, often and again now, searched for the solution. Seems a problem with cmake:
debian stable with cmake 3.13.4 -> fail
debian stable with cmake provided by buildroot (force support/dependencies/check-host-cmake.mk) -> success
I search for a way to have cmake more verbose to determine where the -isystem is added...
Gwen
[...]
>
> 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] 20+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Analysis of build results
2020-08-17 9:19 ` Gwenhael Goavec-Merou
@ 2020-08-17 9:40 ` Thomas Petazzoni
2020-08-17 9:51 ` Gwenhael Goavec-Merou
0 siblings, 1 reply; 20+ messages in thread
From: Thomas Petazzoni @ 2020-08-17 9:40 UTC (permalink / raw
To: buildroot
Hello,
On Mon, 17 Aug 2020 11:19:40 +0200
Gwenhael Goavec-Merou <gwenj@trabucayre.com> wrote:
> > > mips | gr-osmosdr-0.2.0 | NOK | http://autobuild.buildroot.net/results/3bb8d678aaa782b70c14a8f9cd3e1df2e55bc613 |
> >
> > mips-linux-gnu-g++: ERROR: unsafe header/library path used in cross-compilation: '-isystem' '/usr/include'
> > mips-linux-gnu-g++: ERROR: unsafe header/library path used in cross-compilation: '-isystem' '/usr/include'
> >
> > Gwenhael, could you take care of this, at least do some preliminary
> > analysis to find where this bogus -isystem invocation comes from ?
> >
> I have, by the past, often and again now, searched for the solution. Seems a problem with cmake:
> debian stable with cmake 3.13.4 -> fail
> debian stable with cmake provided by buildroot (force support/dependencies/check-host-cmake.mk) -> success
>
> I search for a way to have cmake more verbose to determine where the -isystem is added...
Do you know which distro/version uses cmake 3.13.4 so that we can try
to reproduce the issue ?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Analysis of build results
2020-08-17 9:40 ` Thomas Petazzoni
@ 2020-08-17 9:51 ` Gwenhael Goavec-Merou
0 siblings, 0 replies; 20+ messages in thread
From: Gwenhael Goavec-Merou @ 2020-08-17 9:51 UTC (permalink / raw
To: buildroot
On Mon, 17 Aug 2020 11:40:11 +0200
Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> Hello,
>
> On Mon, 17 Aug 2020 11:19:40 +0200
> Gwenhael Goavec-Merou <gwenj@trabucayre.com> wrote:
>
> > > > mips | gr-osmosdr-0.2.0 | NOK | http://autobuild.buildroot.net/results/3bb8d678aaa782b70c14a8f9cd3e1df2e55bc613 |
> > >
> > > mips-linux-gnu-g++: ERROR: unsafe header/library path used in cross-compilation: '-isystem' '/usr/include'
> > > mips-linux-gnu-g++: ERROR: unsafe header/library path used in cross-compilation: '-isystem' '/usr/include'
> > >
> > > Gwenhael, could you take care of this, at least do some preliminary
> > > analysis to find where this bogus -isystem invocation comes from ?
> > >
> > I have, by the past, often and again now, searched for the solution. Seems a problem with cmake:
> > debian stable with cmake 3.13.4 -> fail
> > debian stable with cmake provided by buildroot (force support/dependencies/check-host-cmake.mk) -> success
> >
> > I search for a way to have cmake more verbose to determine where the -isystem is added...
>
> Do you know which distro/version uses cmake 3.13.4 so that we can try
> to reproduce the issue ?
>
debian stable (buster) use this one.
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Thanks
Gwen
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Analysis of build results
2020-08-15 22:09 ` [Buildroot] [autobuild.buildroot.net] Analysis of build results Thomas Petazzoni
2020-08-15 22:14 ` Thomas Petazzoni
2020-08-17 9:19 ` Gwenhael Goavec-Merou
@ 2020-08-17 12:18 ` Asaf Kahlon
2020-08-17 12:52 ` Thomas Petazzoni
2020-08-17 20:54 ` Peter Seiderer
` (4 subsequent siblings)
7 siblings, 1 reply; 20+ messages in thread
From: Asaf Kahlon @ 2020-08-17 12:18 UTC (permalink / raw
To: buildroot
Hello,
On Sun, Aug 16, 2020 at 1:09 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello,
>
> Frank, Gwenhael, Romain, Adam, ARC maintainers, Peter, there are some
> questions/issues for you below.
>
> Everybody else: please help fixing autobuilder issues !
>
> See below some preliminary analysis of all build failures that occurred
> on August 14.
>
> On Sat, 15 Aug 2020 08:01:40 -0000
> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
>
> > master | 121 | 67 | 0 | 188 |
>
> So we're still at about ~30% of failures, which isn't exactly good.
>
>
> > arch | reason | OK? | url | orph?
> > -------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
> > arm | am33x-cm3-11107db2f1e9e58ee... | NOK | http://autobuild.buildroot.net/results/2899bcd58dcce8a1b820c1f310e1af7ebec1e1f0 | ORPH
>
> /nvme/rc-buildroot-test/scripts/instance-1/output-1/host/lib/gcc/arm-buildroot-linux-gnueabihf/10.2.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: src/foundation/startup.o: in function `reset_handler':
> /nvme/rc-buildroot-test/scripts/instance-1/output-1/build/am33x-cm3-11107db2f1e9e58ee75d4fe9cc38423c9a6e4365/src/foundation/startup.c:177: undefined reference to `memcpy'
>
> Looking at the history of this failure:
>
> http://autobuild.buildroot.net/?reason=am33x-cm3%
>
> We had some failures until November 2019, with a different error. And
> then since yesterday (August 14), two failures with this memcpy()
> issue. Interestingly, the two failed builds are using gcc 10. At line
> 177 in startup.c, we have:
>
> for(puldest = &_start_data; puldest < &_end_data; )
> {
> *puldest++ = *pulsrc++;
> }
>
> I.e, we don't have a call to memcpy(), but gcc detects it's a memory
> copy, and generates a call to memcpy().
>
> I'm not sure what's the right gcc option to make it not emit such
> memcpy() function call...
>
>
> > mips64el | assimp-5.0.1 | NOK | http://autobuild.buildroot.net/results/a9cdf1454920a264447665a241d0904a83a2fd06 |
>
> Error message:
>
> relocation truncated to fit: R_MIPS_CALL16
>
> This build issue occurs only on mips64, but several variants of the
> architecture, and with both uClibc and glibc.
>
> It seems like we're hitting the issue described at
> https://lists.debian.org/debian-mips/2016/11/msg00008.html, and we
> already have a work around for assimp for m68k:
>
> # relocation truncated to fit: R_68K_GOT16O
> ifeq ($(BR2_m68k),y)
> ASSIMP_CXXFLAGS += -mxgot
> endif
>
> Should we do the same for mips64 ?
>
> > aarch64 | avahi-0.8 | NOK | http://autobuild.buildroot.net/results/b31aae410feaef5ff70a8b644b1be337e4e27338 | ORPH
>
> This is being worked by Adam, he has proposed a patch, but I made some
> comments.
>
> > x86_64 | boost-1.73.0 | NOK | http://autobuild.buildroot.net/results/84eb9bb82255878d6a58772cb96d253a5c02f625 |
> > x86_64 | boost-1.73.0 | NOK | http://autobuild.buildroot.net/results/2ddfabda83a42d06b6b9689bc83882c59d1b8db6 |
> > x86_64 | boost-1.73.0 | NOK | http://autobuild.buildroot.net/results/ce3f75b5a259924924c934e784b58feed2705be8 |
>
> A wonderful:
>
> ./boost/thread/thread_time.hpp:32:60: internal compiler error: Segmentation fault
>
> This is failing only with this toolchain, which uses gcc 6.2.0. We're
> using the version 2016.11-19 of this toolchain, which is really old,
> and Mentor Graphics has published newer versions
> (https://sourcery.mentor.com/GNUToolchain/subscription51456) but they
> are no longer publicly available.
>
> So I would advocate for dropping support for this toolchain. I'll send
> a patch doing that.
>
> > arm | cvs-1.12.13 | NOK | http://autobuild.buildroot.net/results/81e50a5b565fba0b5703730671d9e9dd86db3b93 | ORPH
> > arm | dnsmasq-2.81 | NOK | http://autobuild.buildroot.net/results/119aeffa1c3d1eaad929cc40af073c71b46cd17b |
> > riscv32 | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/b2e4b144b4270cee0e1efb29ca86da322e403213 |
> > xtensa | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/2ac9a7f329289532c8a3a75257f349e5662efb70 |
> > mips64el | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/e2ea73ab636d3493ef0c1db07d2fb4fba1bbbbab |
> > riscv32 | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/44863a6c6bcf0021298fcd9dba7b2b10ef1dbc93 |
> > m68k | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/5cdeb12ba89285a96c4eeefce47bf72a86e2d1f7 |
> > arm | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/e71f315ebd29230c746f687e457e898b75fbc464 |
> > microblazeel | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/d6001c4f5e294524739ff422e192786f76fe8a92 |
>
> This was a download issue. I've placed a dvb-apps tarball on
> sources.buildroot.net. However, our CDN is still caching the
> non-existence of this file, so we need those cache results to expire
> for the build issues to disappear.
>
> > arm | eigen-3.3.7 | NOK | http://autobuild.buildroot.net/results/0b972b4e63cac9ae95dcac78e031d7b19e2e4e0d |
>
> Detects Fortran (even though that dependency is not expressed in the
> eigen package), but fails to use it.
>
> It would be good to explicitly disable using Fortran in this package.
> Romain, is this something you could have a look at ?
>
> > mips | gr-osmosdr-0.2.0 | NOK | http://autobuild.buildroot.net/results/3bb8d678aaa782b70c14a8f9cd3e1df2e55bc613 |
>
> mips-linux-gnu-g++: ERROR: unsafe header/library path used in cross-compilation: '-isystem' '/usr/include'
> mips-linux-gnu-g++: ERROR: unsafe header/library path used in cross-compilation: '-isystem' '/usr/include'
>
> Gwenhael, could you take care of this, at least do some preliminary
> analysis to find where this bogus -isystem invocation comes from ?
>
> > arm | gvfs-1.44.1 | NOK | http://autobuild.buildroot.net/results/5cedf537d2e947a2a7f492611ec4a8323c6e2b97 | ORPH
>
> /home/peko/autobuild/instance-1/output-1/host/bin/meson --internal msgfmthelper daemon/org.gtk.vfs.file-operations.policy.in daemon/org.gtk.vfs.file-operations.policy xml /home/peko/autobuild/instance-1/output-1/build/gvfs-1.44.1/po
> msgfmt: cannot locate ITS rules for daemon/org.gtk.vfs.file-operations.policy.in
>
> This is with BR2_SYSTEM_ENABLE_NLS=y, so we have the full gettext
> available. There is some background at
> https://github.com/mesonbuild/meson/issues/1565.
>
> > i686 | host-elixir-1.9.4 | NOK | http://autobuild.buildroot.net/results/a3a37eb724ca5689f8e83c9b2af04d07afa80315 |
>
> make[1]: Entering directory '/tmp/instance-1/output-1/build/host-elixir-1.9.4'
> make[1]: erlc: Command not found
>
> We have this once in a while, on different machines:
> http://autobuild.buildroot.net/?reason=host-elixir%
>
> Weird that it doesn't appear more often. Is there some kind of race condition?
>
> Frank: you added the host-elixir package, could you have a look ?
>
> > powerpc64 | host-grpc-1.30.2 | NOK | http://autobuild.buildroot.net/results/37847b16d8ece2f4f6ed34ef15c0a185e13a9055 |
> > arm | host-grpc-1.30.2 | NOK | http://autobuild.buildroot.net/results/b920d98e17e99f32c535cf046dd0e83d80271dd7 |
> > aarch64 | host-grpc-1.30.2 | NOK | http://autobuild.buildroot.net/results/d76edbda32622ff7cae2e8ac7a39e3fb46590796 |
>
> This is the infamous host-grpc build issue on Yann's machine. Adam, I
> thought you had made some progress with this? Do you have a status?
> Some ideas/leads?
>
> > aarch64_be | host-mender-artifact-3.4.0 | NOK | http://autobuild.buildroot.net/results/6c2fe35b309ae06eb4ada9a9292e03b7aa77a1b5 |
>
> This was fixed by 235636409fddadfdfcaaaaf69f815fc349bcd69f.
>
> > riscv64 | ibm-sw-tpm2-1563 | NOK | http://autobuild.buildroot.net/results/d01139419fdb0976754ee69dd35f8b8e78716820 |
> > arm | ibm-sw-tpm2-1563 | NOK | http://autobuild.buildroot.net/results/139eec08e9a138f59dcd8b91503716e73dad547f |
>
> Both fixed by 19bd08900448aa45b506320ad2ab912f789e6e5e.
>
> > mipsel | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/453d38d0ef5b2a3825bc5f923a6b59055c651b11 |
> > arm | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/34cfaf0e7dd459f62792fc414df604c8ff04fc86 |
> > arc | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/79bde26aca95860a2e77cc9d70de97387c6a1be0 |
> > riscv64 | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/9b2ef7932c9fd74d72214b831ac203d3c74dd4ce |
> > aarch64 | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/5dd83b33ef54a4a6ecf0be47adb3a4672a5bb067 |
> > powerpc64 | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/4567e3b0a0510e8a615781178ff5bbbd835a92c3 |
> > aarch64_be | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/bbd1597534df46895a6736629ffc44bcc0150618 |
> > arm | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/c8e994a3d78910a2239211386b4ca6688ad8bb05 |
>
> Fixed by
> https://git.buildroot.org/buildroot/commit/?id=97b3e2be0cb53415ab20ba4ae0d8638c087f7819
>
>
> > arc | kismet-2016-07-R1 | NOK | http://autobuild.buildroot.net/results/07dca0689044777cd6533dfe244f22abc7c3084d | ORPH
> > powerpc | kismet-2016-07-R1 | NOK | http://autobuild.buildroot.net/results/50e314b341fb46acfc81c84b6aff3381cb89cf75 | ORPH
> > xtensa | kismet-2016-07-R1 | NOK | http://autobuild.buildroot.net/results/718dd77dd44cd4bc43761900c1e0746074de038c | ORPH
>
> socket.h:289:33: error: flexible array member 'cmsghdr::__cmsg_data' not at end of 'struct<unnamed>'
>
> Reported in Debian as well:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954636, but not fixed.
>
> > arm | kmsxx-cb0786049f960f2bd3836... | NOK | http://autobuild.buildroot.net/results/7777cd9496e8f8cdb093c3f82c550eebedda0b5d |
>
> Fixed by d82fa9e022f7f7781df8f1124430aa31688bf827
>
> > x86_64 | libcamera-96fab38e02792a109... | NOK | http://autobuild.buildroot.net/results/c28500d4cc55fbd2bac87f2c11759ddc9163bc91 |
>
> /home/peko/autobuild/instance-1/output-1/host/x86_64-buildroot-linux-gnu/sysroot/usr/include/glib-2.0/glib/gatomic.h:128:15: error: variable 'gapg_temp_atomic' set but not used [-Werror=unused-but-set-variable]
>
> Meh, it is built with -Werror... and the issue is actually in a header
> from libglib2, so nothing that libcamera can fix.
>
> > riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/2f05d672560a9e9dfb4412146b73f36667fe7e29 |
> > riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/4ba63b6df6229462cee9be880bec89216307acb3 |
> > riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/0839ee8b268dd010bef243d4b91a2a86f6e22655 |
> > riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/be8ce63d6053ecff4e51e210dfaf58a4a8f772bb |
> > riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/79d035ef9ae878d593c330f4b2e690d05651673d |
> > riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/0d1525c2e73a03650a1999c118108cb19fe7673d |
> > riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/5ee78c831db40d3e7fbe11d3538f9f311a886969 |
> > riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/e1c56bce298ea0276edb46b48b8d0681d2b539e1 |
>
> Fixed by
> https://git.buildroot.org/buildroot/commit/?id=e7d631c0df1698b4edc94f148e7247869430e108
>
>
> > arc | log4cplus-2.0.5 | NOK | http://autobuild.buildroot.net/results/a7732fdb2ba526a114d9fb759814236c5332f8d7 |
>
> undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)'
>
> This is happening only on ARC700. Perhaps a variant of ARC that doesn't
> support atomic instructions?
>
> ARC maintainers, could you have a look please ?
>
> > riscv64 | mpv-0.29.1 | NOK | http://autobuild.buildroot.net/results/d50171c7a90b38daf6b1c7af97dd61c816fcfac3 |
>
> /tmp/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-musl/9.2.0/../../../../riscv64-buildroot-linux-musl/bin/ld: video/out/vo_libmpv.c.19.o: undefined reference to symbol '__atomic_compare_exchange_1@@LIBATOMIC_1.0'
> /tmp/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-musl/9.2.0/../../../../riscv64-buildroot-linux-musl/bin/ld: /tmp/instance-1/output-1/host/riscv64-buildroot-linux-musl/sysroot/lib64/libatomic.so.1: error adding symbols: DSO missing from command line
>
> mpv has a:
>
> depends on BR2_TOOLCHAIN_HAS_ATOMIC || BR2_TOOLCHAIN_HAS_SYNC_8
>
> probably it should link against libatomic when available ? It means
> that RISC-V 64 doesn't have support for sync 8 built-ins ?
>
> > arc | opencv-2.4.13.7 | NOK | http://autobuild.buildroot.net/results/949630bb8bd63eed740abee4600deb238a6cbb0b |
> > arc | opencv-2.4.13.7 | NOK | http://autobuild.buildroot.net/results/db622456c121cef9ed54931abb5c59603b25e1a8 |
> > powerpc64 | opencv-2.4.13.7 | NOK | http://autobuild.buildroot.net/results/52d99beb5c7512429264e265545ddc0f05d53781 |
>
> grfmt_jpeg2000.cpp:341:71: error: lvalue required as unary '&' operand
>
> Needs investigation.
>
> > arc | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/e21dae6b7680d720b00558212a42206f6aaaa107 |
> > powerpc64le | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/87a49185211d0238aeb028f0c3607f3fa05e8c61 |
>
> Same issue as with opencv:
>
> grfmt_jpeg2000.cpp:380:71: error: lvalue required as unary '&' operand
>
> > nios2 | pistache-f2f5a50fbfb5b8ef6c... | NOK | http://autobuild.buildroot.net/results/a1bb21a275e78de450f73e30821cbadb3a796d95 | ORPH
>
> -- Looking for __atomic_load_8 in atomic
> -- Looking for __atomic_load_8 in atomic - not found
> CMake Error at CMakeModules/CheckAtomic.cmake:76 (message):
> Host compiler appears to require libatomic for 64-bit operations, but
> cannot find it.
> Call Stack (most recent call first):
> CMakeLists.txt:19 (include)
>
> Needs to link against libatomic perhaps ?
>
> > i686 | qt5base-5.15.0 | NOK | http://autobuild.buildroot.net/results/48165633b841ce6468b7c34d7e47a6fb2a4555ef |
> > arm | qt5base-5.15.0 | NOK | http://autobuild.buildroot.net/results/bcf68bf4cbb7cb6d1bf902ac6c288806d6c50588 |
>
> Peter (Seiderer), any idea ?
>
> /home/buildroot/autobuild/run/instance-2/output-1/build/qt5base-5.15.0/include/QtCore/../../src/corelib/kernel/qmetatype.h:1160:135: error: ambiguous class template instantiation for 'struct QtMetaTypePrivate::ContainerCapabilitiesImpl<QList<QVariant>, void>'
>
>
> > aarch64 | qt5wayland-5.15.0 | NOK | http://autobuild.buildroot.net/results/f673d4bd730b029bda29357f0b1442cc22475895 |
>
> Checking for wayland-scanner... yes
> Checking for EGL 1.5 with Wayland Platform... no
> Project ERROR: Test config.qtwayland_client.tests.dmabuf-server-buffer tries to use undeclared library 'drm'
>
> Meh :/
>
> > arm | rocksdb-6.10.1 | NOK | http://autobuild.buildroot.net/results/7014f905b9a678cec0699f4bb1d9b6d61535704e |
> > arm | rocksdb-6.10.1 | NOK | http://autobuild.buildroot.net/results/3776d2302f389691db972de35e077dcf2a07afab |
> > arm | rocksdb-6.10.1 | NOK | http://autobuild.buildroot.net/results/72f6f1aca4f1c9e19850ceccef7fed756af0e403 |
>
> Ouch:
>
> during RTL pass: cprop_hardreg
> db/memtable.cc:232:1: internal compiler error: in extract_constrain_insn, at recog.c:2205
>
> Could someone figure out if this gcc 8.3 issue still exists ?
>
>
> > aarch64_be | supertux-0.6.0 | NOK | http://autobuild.buildroot.net/results/0f02877a665b2281266df4b23c72a7c113906c31 |
>
> /tmp/instance-0/output-1/build/supertux-0.6.0/src/editor/object_settings.cpp:223:26: error: 'remove_if' is not a member of 'std'
> m_options.erase(std::remove_if(m_options.begin(), m_options.end(),
>
> Romain, supertux is your thing, could you have a look ?
>
>
> > sparc64 | tio-1.32 | NOK | http://autobuild.buildroot.net/results/028efb98838163b0c697bba30cedbc4f0704748d |
>
> Gah: error: redefinition of 'struct termio'
>
> > arm | unknown | NOK | http://autobuild.buildroot.net/results/0333faabe50ac103324085cc219fbfe06a1718bb |
>
> This looks like a top-level parallel build failure, the log is not long
> enough to show the real problem.
>
> > powerpc64le | unknown | NOK | http://autobuild.buildroot.net/results/542e97923620b2135fe5c846ad97c324cc108f43 |
>
> Ditto.
>
> > arm | unknown | NOK | http://autobuild.buildroot.net/results/93d88fcfe723e91846a68a9d87de585a741f3c5b |
>
> And again. I'm not sure how to improve this. Upload the full build log
> ? This could be huge :-/
>
> > arc | wampcc-1.6 | NOK | http://autobuild.buildroot.net/results/c3b67d8a5faf7ff06b08a0591f22b1fa4963c2ee | ORPH
>
> /home/test/autobuild/run/instance-3/output-1/host/lib/gcc/arc-buildroot-linux-uclibc/9.3.1/../../../../arc-buildroot-linux-uclibc/bin/ld: ../libs/wampcc/libwampcc.so.6.0.0: undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)'
> collect2: error: ld returned 1 exit status
>
> This looks very similar to the log4cplus build issue above, also
> happens only on ARC:
>
> http://autobuild.buildroot.net/?reason=wampcc-1.6
>
> ARC maintainers, could you have a look ?
>
> > or1k | zeromq-4.3.2 | NOK | http://autobuild.buildroot.net/results/538474abda90082eec91ca9017e91b4427e4f54b |
>
> Broken binutils:
>
> /home/test/autobuild/run/instance-0/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.32 assertion fail elf32-or1k.c:2331
>
> Would be useful to test with newer binutils.
I tried both with binutils 2.33.1 and binutils 2.34.
Both failed with the same error...
>
> 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
Regards,
Asaf.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Analysis of build results
2020-08-17 12:18 ` Asaf Kahlon
@ 2020-08-17 12:52 ` Thomas Petazzoni
0 siblings, 0 replies; 20+ messages in thread
From: Thomas Petazzoni @ 2020-08-17 12:52 UTC (permalink / raw
To: buildroot
Hello Asaf,
On Mon, 17 Aug 2020 15:18:41 +0300
Asaf Kahlon <asafka7@gmail.com> wrote:
> > > or1k | zeromq-4.3.2 | NOK | http://autobuild.buildroot.net/results/538474abda90082eec91ca9017e91b4427e4f54b |
> >
> > Broken binutils:
> >
> > /home/test/autobuild/run/instance-0/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.32 assertion fail elf32-or1k.c:2331
> >
> > Would be useful to test with newer binutils.
> I tried both with binutils 2.33.1 and binutils 2.34.
> Both failed with the same error...
Thanks for the additional research! I guess the next steps are:
- Report the bug to binutils upstream
- Identify if there is a work-around. But while for gcc issues we
often work-around by disabling optimizations, for binutils it is not
always possible to find a simple work-around.
If there's no workaround, then we can add a
BR2_TOOLCHAIN_HAS_BINUTILS_BUG_xyz Config.in bool and add the
appropriate dependencies.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Analysis of build results
2020-08-15 22:09 ` [Buildroot] [autobuild.buildroot.net] Analysis of build results Thomas Petazzoni
` (2 preceding siblings ...)
2020-08-17 12:18 ` Asaf Kahlon
@ 2020-08-17 20:54 ` Peter Seiderer
2020-08-17 21:30 ` Thomas Petazzoni
2020-08-17 21:15 ` Peter Seiderer
` (3 subsequent siblings)
7 siblings, 1 reply; 20+ messages in thread
From: Peter Seiderer @ 2020-08-17 20:54 UTC (permalink / raw
To: buildroot
Hello Thomas, *,
On Sun, 16 Aug 2020 00:09:14 +0200, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> > i686 | qt5base-5.15.0 | NOK | http://autobuild.buildroot.net/results/48165633b841ce6468b7c34d7e47a6fb2a4555ef |
> > arm | qt5base-5.15.0 | NOK | http://autobuild.buildroot.net/results/bcf68bf4cbb7cb6d1bf902ac6c288806d6c50588 |
>
> Peter (Seiderer), any idea ?
>
> /home/buildroot/autobuild/run/instance-2/output-1/build/qt5base-5.15.0/include/QtCore/../../src/corelib/kernel/qmetatype.h:1160:135: error: ambiguous class template instantiation for 'struct QtMetaTypePrivate::ContainerCapabilitiesImpl<QList<QVariant>, void>'
>
Could not reproduce the failures locally, but they are still from the host qmake tool
compile (not from the cross-compile), maybe the equivalent to
'depends on BR2_TOOLCHAIN_GCC_AT_LEAST_5' for the host compiler is needed?
Regards,
Peter
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Analysis of build results
2020-08-15 22:09 ` [Buildroot] [autobuild.buildroot.net] Analysis of build results Thomas Petazzoni
` (3 preceding siblings ...)
2020-08-17 20:54 ` Peter Seiderer
@ 2020-08-17 21:15 ` Peter Seiderer
2020-08-17 21:43 ` Romain Naour
` (2 subsequent siblings)
7 siblings, 0 replies; 20+ messages in thread
From: Peter Seiderer @ 2020-08-17 21:15 UTC (permalink / raw
To: buildroot
Hello Thomas, *,
On Sun, 16 Aug 2020 00:09:14 +0200, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> > aarch64 | qt5wayland-5.15.0 | NOK | http://autobuild.buildroot.net/results/f673d4bd730b029bda29357f0b1442cc22475895 |
>
> Checking for wayland-scanner... yes
> Checking for EGL 1.5 with Wayland Platform... no
> Project ERROR: Test config.qtwayland_client.tests.dmabuf-server-buffer tries to use undeclared library 'drm'
>
> Meh :/
Known problem, reported upstream (see [1]) and hack/workaround suggested ([2])...
Regards,
Peter
[1] https://bugreports.qt.io/browse/QTBUG-83303
[2] https://codereview.qt-project.org/c/qt/qtwayland/+/296213
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Analysis of build results
2020-08-17 20:54 ` Peter Seiderer
@ 2020-08-17 21:30 ` Thomas Petazzoni
2020-08-17 21:57 ` Peter Seiderer
0 siblings, 1 reply; 20+ messages in thread
From: Thomas Petazzoni @ 2020-08-17 21:30 UTC (permalink / raw
To: buildroot
On Mon, 17 Aug 2020 22:54:00 +0200
Peter Seiderer <ps.report@gmx.net> wrote:
> > Peter (Seiderer), any idea ?
> >
> > /home/buildroot/autobuild/run/instance-2/output-1/build/qt5base-5.15.0/include/QtCore/../../src/corelib/kernel/qmetatype.h:1160:135: error: ambiguous class template instantiation for 'struct QtMetaTypePrivate::ContainerCapabilitiesImpl<QList<QVariant>, void>'
> >
>
> Could not reproduce the failures locally, but they are still from the host qmake tool
> compile (not from the cross-compile), maybe the equivalent to
> 'depends on BR2_TOOLCHAIN_GCC_AT_LEAST_5' for the host compiler is needed?
Do you have confirmation that this error is related to the compiler
having to be gcc >= 5.x ?
If that's the case, we can add a dependency to BR2_HOST_GCC_AT_LEAST_5.
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Analysis of build results
2020-08-15 22:09 ` [Buildroot] [autobuild.buildroot.net] Analysis of build results Thomas Petazzoni
` (4 preceding siblings ...)
2020-08-17 21:15 ` Peter Seiderer
@ 2020-08-17 21:43 ` Romain Naour
2020-08-19 11:47 ` Fabrice Fontaine
2020-08-20 9:22 ` [Buildroot] " Frank Vanbever
7 siblings, 0 replies; 20+ messages in thread
From: Romain Naour @ 2020-08-17 21:43 UTC (permalink / raw
To: buildroot
Hi Thomas, All,
Le 16/08/2020 ? 00:09, Thomas Petazzoni a ?crit?:
> Hello,
>
> Frank, Gwenhael, Romain, Adam, ARC maintainers, Peter, there are some
> questions/issues for you below.
>
> Everybody else: please help fixing autobuilder issues !
>
> See below some preliminary analysis of all build failures that occurred
> on August 14.
>
> On Sat, 15 Aug 2020 08:01:40 -0000
> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
>
>> master | 121 | 67 | 0 | 188 |
>
> So we're still at about ~30% of failures, which isn't exactly good.
>
>
>> x86_64 | boost-1.73.0 | NOK | http://autobuild.buildroot.net/results/84eb9bb82255878d6a58772cb96d253a5c02f625 |
>> x86_64 | boost-1.73.0 | NOK | http://autobuild.buildroot.net/results/2ddfabda83a42d06b6b9689bc83882c59d1b8db6 |
>> x86_64 | boost-1.73.0 | NOK | http://autobuild.buildroot.net/results/ce3f75b5a259924924c934e784b58feed2705be8 |
>
> A wonderful:
>
> ./boost/thread/thread_time.hpp:32:60: internal compiler error: Segmentation fault
>
> This is failing only with this toolchain, which uses gcc 6.2.0. We're
> using the version 2016.11-19 of this toolchain, which is really old,
> and Mentor Graphics has published newer versions
> (https://sourcery.mentor.com/GNUToolchain/subscription51456) but they
> are no longer publicly available.
>
> So I would advocate for dropping support for this toolchain. I'll send
> a patch doing that.
+1
>
>> arm | eigen-3.3.7 | NOK | http://autobuild.buildroot.net/results/0b972b4e63cac9ae95dcac78e031d7b19e2e4e0d |
>
> Detects Fortran (even though that dependency is not expressed in the
> eigen package), but fails to use it.
>
> It would be good to explicitly disable using Fortran in this package.
> Romain, is this something you could have a look at ?
This is not an obvious fix, eigen try to detect libblas dependency and check for
Fortran compiler because the complete list of supported languages is not
provided (project(Eigen3))
https://gitlab.kitware.com/cmake/cmake/-/issues/18348
I'm not sure why we define unconditionally CMAKE_CXX_COMPILER even if
BR2_INSTALL_LIBSTDCPP is not set, while CMAKE_Fortran_COMPILER is set only when
TOOLCHAIN_HAS_FORTRAN is set.
https://git.buildroot.net/buildroot/tree/support/misc/toolchainfile.cmake.in#n70
>
>
>> aarch64_be | supertux-0.6.0 | NOK | http://autobuild.buildroot.net/results/0f02877a665b2281266df4b23c72a7c113906c31 |
>
> /tmp/instance-0/output-1/build/supertux-0.6.0/src/editor/object_settings.cpp:223:26: error: 'remove_if' is not a member of 'std'
> m_options.erase(std::remove_if(m_options.begin(), m_options.end(),
>
> Romain, supertux is your thing, could you have a look ?
Already fixed by 14552122ac46028b78f05eeed1154da2ba87b174
Best regards,
Romain
>
> Thanks,
>
> Thomas
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Analysis of build results
2020-08-17 21:30 ` Thomas Petazzoni
@ 2020-08-17 21:57 ` Peter Seiderer
0 siblings, 0 replies; 20+ messages in thread
From: Peter Seiderer @ 2020-08-17 21:57 UTC (permalink / raw
To: buildroot
Hello Thomas,
On Mon, 17 Aug 2020 23:30:48 +0200, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> On Mon, 17 Aug 2020 22:54:00 +0200
> Peter Seiderer <ps.report@gmx.net> wrote:
>
> > > Peter (Seiderer), any idea ?
> > >
> > > /home/buildroot/autobuild/run/instance-2/output-1/build/qt5base-5.15.0/include/QtCore/../../src/corelib/kernel/qmetatype.h:1160:135: error: ambiguous class template instantiation for 'struct QtMetaTypePrivate::ContainerCapabilitiesImpl<QList<QVariant>, void>'
> > >
> >
> > Could not reproduce the failures locally, but they are still from the host qmake tool
> > compile (not from the cross-compile), maybe the equivalent to
> > 'depends on BR2_TOOLCHAIN_GCC_AT_LEAST_5' for the host compiler is needed?
>
> Do you have confirmation that this error is related to the compiler
> having to be gcc >= 5.x ?
No...., any chance to gather the host compiler versions from the autobuild reports?
Regards,
Peter
>
> If that's the case, we can add a dependency to BR2_HOST_GCC_AT_LEAST_5.
>
> Thomas
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Analysis of build results
2020-08-15 22:09 ` [Buildroot] [autobuild.buildroot.net] Analysis of build results Thomas Petazzoni
` (5 preceding siblings ...)
2020-08-17 21:43 ` Romain Naour
@ 2020-08-19 11:47 ` Fabrice Fontaine
2020-08-19 20:31 ` [Buildroot] [arc-buildroot] " Alexey Brodkin
2020-08-20 9:22 ` [Buildroot] " Frank Vanbever
7 siblings, 1 reply; 20+ messages in thread
From: Fabrice Fontaine @ 2020-08-19 11:47 UTC (permalink / raw
To: buildroot
Hi Thomas,
Le dim. 16 ao?t 2020 ? 00:09, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> a ?crit :
>
> Hello,
>
> Frank, Gwenhael, Romain, Adam, ARC maintainers, Peter, there are some
> questions/issues for you below.
>
> Everybody else: please help fixing autobuilder issues !
>
> See below some preliminary analysis of all build failures that occurred
> on August 14.
>
> On Sat, 15 Aug 2020 08:01:40 -0000
> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
>
> > master | 121 | 67 | 0 | 188 |
>
> So we're still at about ~30% of failures, which isn't exactly good.
>
>
> > arch | reason | OK? | url | orph?
> > -------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
> > arm | am33x-cm3-11107db2f1e9e58ee... | NOK | http://autobuild.buildroot.net/results/2899bcd58dcce8a1b820c1f310e1af7ebec1e1f0 | ORPH
>
> /nvme/rc-buildroot-test/scripts/instance-1/output-1/host/lib/gcc/arm-buildroot-linux-gnueabihf/10.2.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: src/foundation/startup.o: in function `reset_handler':
> /nvme/rc-buildroot-test/scripts/instance-1/output-1/build/am33x-cm3-11107db2f1e9e58ee75d4fe9cc38423c9a6e4365/src/foundation/startup.c:177: undefined reference to `memcpy'
>
> Looking at the history of this failure:
>
> http://autobuild.buildroot.net/?reason=am33x-cm3%
>
> We had some failures until November 2019, with a different error. And
> then since yesterday (August 14), two failures with this memcpy()
> issue. Interestingly, the two failed builds are using gcc 10. At line
> 177 in startup.c, we have:
>
> for(puldest = &_start_data; puldest < &_end_data; )
> {
> *puldest++ = *pulsrc++;
> }
>
> I.e, we don't have a call to memcpy(), but gcc detects it's a memory
> copy, and generates a call to memcpy().
>
> I'm not sure what's the right gcc option to make it not emit such
> memcpy() function call...
>
>
> > mips64el | assimp-5.0.1 | NOK | http://autobuild.buildroot.net/results/a9cdf1454920a264447665a241d0904a83a2fd06 |
>
> Error message:
>
> relocation truncated to fit: R_MIPS_CALL16
>
> This build issue occurs only on mips64, but several variants of the
> architecture, and with both uClibc and glibc.
>
> It seems like we're hitting the issue described at
> https://lists.debian.org/debian-mips/2016/11/msg00008.html, and we
> already have a work around for assimp for m68k:
>
> # relocation truncated to fit: R_68K_GOT16O
> ifeq ($(BR2_m68k),y)
> ASSIMP_CXXFLAGS += -mxgot
> endif
>
> Should we do the same for mips64 ?
>
> > aarch64 | avahi-0.8 | NOK | http://autobuild.buildroot.net/results/b31aae410feaef5ff70a8b644b1be337e4e27338 | ORPH
>
> This is being worked by Adam, he has proposed a patch, but I made some
> comments.
>
> > x86_64 | boost-1.73.0 | NOK | http://autobuild.buildroot.net/results/84eb9bb82255878d6a58772cb96d253a5c02f625 |
> > x86_64 | boost-1.73.0 | NOK | http://autobuild.buildroot.net/results/2ddfabda83a42d06b6b9689bc83882c59d1b8db6 |
> > x86_64 | boost-1.73.0 | NOK | http://autobuild.buildroot.net/results/ce3f75b5a259924924c934e784b58feed2705be8 |
>
> A wonderful:
>
> ./boost/thread/thread_time.hpp:32:60: internal compiler error: Segmentation fault
>
> This is failing only with this toolchain, which uses gcc 6.2.0. We're
> using the version 2016.11-19 of this toolchain, which is really old,
> and Mentor Graphics has published newer versions
> (https://sourcery.mentor.com/GNUToolchain/subscription51456) but they
> are no longer publicly available.
>
> So I would advocate for dropping support for this toolchain. I'll send
> a patch doing that.
>
> > arm | cvs-1.12.13 | NOK | http://autobuild.buildroot.net/results/81e50a5b565fba0b5703730671d9e9dd86db3b93 | ORPH
> > arm | dnsmasq-2.81 | NOK | http://autobuild.buildroot.net/results/119aeffa1c3d1eaad929cc40af073c71b46cd17b |
> > riscv32 | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/b2e4b144b4270cee0e1efb29ca86da322e403213 |
> > xtensa | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/2ac9a7f329289532c8a3a75257f349e5662efb70 |
> > mips64el | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/e2ea73ab636d3493ef0c1db07d2fb4fba1bbbbab |
> > riscv32 | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/44863a6c6bcf0021298fcd9dba7b2b10ef1dbc93 |
> > m68k | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/5cdeb12ba89285a96c4eeefce47bf72a86e2d1f7 |
> > arm | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/e71f315ebd29230c746f687e457e898b75fbc464 |
> > microblazeel | dvb-apps-3d43b280298c39a67d... | NOK | http://autobuild.buildroot.net/results/d6001c4f5e294524739ff422e192786f76fe8a92 |
>
> This was a download issue. I've placed a dvb-apps tarball on
> sources.buildroot.net. However, our CDN is still caching the
> non-existence of this file, so we need those cache results to expire
> for the build issues to disappear.
>
> > arm | eigen-3.3.7 | NOK | http://autobuild.buildroot.net/results/0b972b4e63cac9ae95dcac78e031d7b19e2e4e0d |
>
> Detects Fortran (even though that dependency is not expressed in the
> eigen package), but fails to use it.
>
> It would be good to explicitly disable using Fortran in this package.
> Romain, is this something you could have a look at ?
>
> > mips | gr-osmosdr-0.2.0 | NOK | http://autobuild.buildroot.net/results/3bb8d678aaa782b70c14a8f9cd3e1df2e55bc613 |
>
> mips-linux-gnu-g++: ERROR: unsafe header/library path used in cross-compilation: '-isystem' '/usr/include'
> mips-linux-gnu-g++: ERROR: unsafe header/library path used in cross-compilation: '-isystem' '/usr/include'
>
> Gwenhael, could you take care of this, at least do some preliminary
> analysis to find where this bogus -isystem invocation comes from ?
>
> > arm | gvfs-1.44.1 | NOK | http://autobuild.buildroot.net/results/5cedf537d2e947a2a7f492611ec4a8323c6e2b97 | ORPH
>
> /home/peko/autobuild/instance-1/output-1/host/bin/meson --internal msgfmthelper daemon/org.gtk.vfs.file-operations.policy.in daemon/org.gtk.vfs.file-operations.policy xml /home/peko/autobuild/instance-1/output-1/build/gvfs-1.44.1/po
> msgfmt: cannot locate ITS rules for daemon/org.gtk.vfs.file-operations.policy.in
>
> This is with BR2_SYSTEM_ENABLE_NLS=y, so we have the full gettext
> available. There is some background at
> https://github.com/mesonbuild/meson/issues/1565.
This issue can be fixed by
https://patchwork.ozlabs.org/project/buildroot/patch/20200725230618.3640682-2-aduskett at gmail.com.
It is due to the host-gettext-gnu package using the /usr/share/gettext
path and some of the autobuilders missing
/usr/share/gettext/its/polkit.its.
>
> > i686 | host-elixir-1.9.4 | NOK | http://autobuild.buildroot.net/results/a3a37eb724ca5689f8e83c9b2af04d07afa80315 |
>
> make[1]: Entering directory '/tmp/instance-1/output-1/build/host-elixir-1.9.4'
> make[1]: erlc: Command not found
>
> We have this once in a while, on different machines:
> http://autobuild.buildroot.net/?reason=host-elixir%
>
> Weird that it doesn't appear more often. Is there some kind of race condition?
>
> Frank: you added the host-elixir package, could you have a look ?
>
> > powerpc64 | host-grpc-1.30.2 | NOK | http://autobuild.buildroot.net/results/37847b16d8ece2f4f6ed34ef15c0a185e13a9055 |
> > arm | host-grpc-1.30.2 | NOK | http://autobuild.buildroot.net/results/b920d98e17e99f32c535cf046dd0e83d80271dd7 |
> > aarch64 | host-grpc-1.30.2 | NOK | http://autobuild.buildroot.net/results/d76edbda32622ff7cae2e8ac7a39e3fb46590796 |
>
> This is the infamous host-grpc build issue on Yann's machine. Adam, I
> thought you had made some progress with this? Do you have a status?
> Some ideas/leads?
>
> > aarch64_be | host-mender-artifact-3.4.0 | NOK | http://autobuild.buildroot.net/results/6c2fe35b309ae06eb4ada9a9292e03b7aa77a1b5 |
>
> This was fixed by 235636409fddadfdfcaaaaf69f815fc349bcd69f.
>
> > riscv64 | ibm-sw-tpm2-1563 | NOK | http://autobuild.buildroot.net/results/d01139419fdb0976754ee69dd35f8b8e78716820 |
> > arm | ibm-sw-tpm2-1563 | NOK | http://autobuild.buildroot.net/results/139eec08e9a138f59dcd8b91503716e73dad547f |
>
> Both fixed by 19bd08900448aa45b506320ad2ab912f789e6e5e.
>
> > mipsel | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/453d38d0ef5b2a3825bc5f923a6b59055c651b11 |
> > arm | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/34cfaf0e7dd459f62792fc414df604c8ff04fc86 |
> > arc | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/79bde26aca95860a2e77cc9d70de97387c6a1be0 |
> > riscv64 | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/9b2ef7932c9fd74d72214b831ac203d3c74dd4ce |
> > aarch64 | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/5dd83b33ef54a4a6ecf0be47adb3a4672a5bb067 |
> > powerpc64 | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/4567e3b0a0510e8a615781178ff5bbbd835a92c3 |
> > aarch64_be | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/bbd1597534df46895a6736629ffc44bcc0150618 |
> > arm | keepalived-2.1.4 | NOK | http://autobuild.buildroot.net/results/c8e994a3d78910a2239211386b4ca6688ad8bb05 |
>
> Fixed by
> https://git.buildroot.org/buildroot/commit/?id=97b3e2be0cb53415ab20ba4ae0d8638c087f7819
>
>
> > arc | kismet-2016-07-R1 | NOK | http://autobuild.buildroot.net/results/07dca0689044777cd6533dfe244f22abc7c3084d | ORPH
> > powerpc | kismet-2016-07-R1 | NOK | http://autobuild.buildroot.net/results/50e314b341fb46acfc81c84b6aff3381cb89cf75 | ORPH
> > xtensa | kismet-2016-07-R1 | NOK | http://autobuild.buildroot.net/results/718dd77dd44cd4bc43761900c1e0746074de038c | ORPH
>
> socket.h:289:33: error: flexible array member 'cmsghdr::__cmsg_data' not at end of 'struct<unnamed>'
>
> Reported in Debian as well:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954636, but not fixed.
>
> > arm | kmsxx-cb0786049f960f2bd3836... | NOK | http://autobuild.buildroot.net/results/7777cd9496e8f8cdb093c3f82c550eebedda0b5d |
>
> Fixed by d82fa9e022f7f7781df8f1124430aa31688bf827
>
> > x86_64 | libcamera-96fab38e02792a109... | NOK | http://autobuild.buildroot.net/results/c28500d4cc55fbd2bac87f2c11759ddc9163bc91 |
>
> /home/peko/autobuild/instance-1/output-1/host/x86_64-buildroot-linux-gnu/sysroot/usr/include/glib-2.0/glib/gatomic.h:128:15: error: variable 'gapg_temp_atomic' set but not used [-Werror=unused-but-set-variable]
>
> Meh, it is built with -Werror... and the issue is actually in a header
> from libglib2, so nothing that libcamera can fix.
>
> > riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/2f05d672560a9e9dfb4412146b73f36667fe7e29 |
> > riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/4ba63b6df6229462cee9be880bec89216307acb3 |
> > riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/0839ee8b268dd010bef243d4b91a2a86f6e22655 |
> > riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/be8ce63d6053ecff4e51e210dfaf58a4a8f772bb |
> > riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/79d035ef9ae878d593c330f4b2e690d05651673d |
> > riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/0d1525c2e73a03650a1999c118108cb19fe7673d |
> > riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/5ee78c831db40d3e7fbe11d3538f9f311a886969 |
> > riscv64 | libglib2-2.64.4 | NOK | http://autobuild.buildroot.net/results/e1c56bce298ea0276edb46b48b8d0681d2b539e1 |
>
> Fixed by
> https://git.buildroot.org/buildroot/commit/?id=e7d631c0df1698b4edc94f148e7247869430e108
>
>
> > arc | log4cplus-2.0.5 | NOK | http://autobuild.buildroot.net/results/a7732fdb2ba526a114d9fb759814236c5332f8d7 |
>
> undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)'
>
> This is happening only on ARC700. Perhaps a variant of ARC that doesn't
> support atomic instructions?
>
> ARC maintainers, could you have a look please ?
>
> > riscv64 | mpv-0.29.1 | NOK | http://autobuild.buildroot.net/results/d50171c7a90b38daf6b1c7af97dd61c816fcfac3 |
>
> /tmp/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-musl/9.2.0/../../../../riscv64-buildroot-linux-musl/bin/ld: video/out/vo_libmpv.c.19.o: undefined reference to symbol '__atomic_compare_exchange_1@@LIBATOMIC_1.0'
> /tmp/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/riscv64-buildroot-linux-musl/9.2.0/../../../../riscv64-buildroot-linux-musl/bin/ld: /tmp/instance-1/output-1/host/riscv64-buildroot-linux-musl/sysroot/lib64/libatomic.so.1: error adding symbols: DSO missing from command line
>
> mpv has a:
>
> depends on BR2_TOOLCHAIN_HAS_ATOMIC || BR2_TOOLCHAIN_HAS_SYNC_8
>
> probably it should link against libatomic when available ? It means
> that RISC-V 64 doesn't have support for sync 8 built-ins ?
>
> > arc | opencv-2.4.13.7 | NOK | http://autobuild.buildroot.net/results/949630bb8bd63eed740abee4600deb238a6cbb0b |
> > arc | opencv-2.4.13.7 | NOK | http://autobuild.buildroot.net/results/db622456c121cef9ed54931abb5c59603b25e1a8 |
> > powerpc64 | opencv-2.4.13.7 | NOK | http://autobuild.buildroot.net/results/52d99beb5c7512429264e265545ddc0f05d53781 |
>
> grfmt_jpeg2000.cpp:341:71: error: lvalue required as unary '&' operand
>
> Needs investigation.
>
> > arc | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/e21dae6b7680d720b00558212a42206f6aaaa107 |
> > powerpc64le | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/87a49185211d0238aeb028f0c3607f3fa05e8c61 |
>
> Same issue as with opencv:
>
> grfmt_jpeg2000.cpp:380:71: error: lvalue required as unary '&' operand
>
> > nios2 | pistache-f2f5a50fbfb5b8ef6c... | NOK | http://autobuild.buildroot.net/results/a1bb21a275e78de450f73e30821cbadb3a796d95 | ORPH
>
> -- Looking for __atomic_load_8 in atomic
> -- Looking for __atomic_load_8 in atomic - not found
> CMake Error at CMakeModules/CheckAtomic.cmake:76 (message):
> Host compiler appears to require libatomic for 64-bit operations, but
> cannot find it.
> Call Stack (most recent call first):
> CMakeLists.txt:19 (include)
>
> Needs to link against libatomic perhaps ?
>
> > i686 | qt5base-5.15.0 | NOK | http://autobuild.buildroot.net/results/48165633b841ce6468b7c34d7e47a6fb2a4555ef |
> > arm | qt5base-5.15.0 | NOK | http://autobuild.buildroot.net/results/bcf68bf4cbb7cb6d1bf902ac6c288806d6c50588 |
>
> Peter (Seiderer), any idea ?
>
> /home/buildroot/autobuild/run/instance-2/output-1/build/qt5base-5.15.0/include/QtCore/../../src/corelib/kernel/qmetatype.h:1160:135: error: ambiguous class template instantiation for 'struct QtMetaTypePrivate::ContainerCapabilitiesImpl<QList<QVariant>, void>'
>
>
> > aarch64 | qt5wayland-5.15.0 | NOK | http://autobuild.buildroot.net/results/f673d4bd730b029bda29357f0b1442cc22475895 |
>
> Checking for wayland-scanner... yes
> Checking for EGL 1.5 with Wayland Platform... no
> Project ERROR: Test config.qtwayland_client.tests.dmabuf-server-buffer tries to use undeclared library 'drm'
>
> Meh :/
>
> > arm | rocksdb-6.10.1 | NOK | http://autobuild.buildroot.net/results/7014f905b9a678cec0699f4bb1d9b6d61535704e |
> > arm | rocksdb-6.10.1 | NOK | http://autobuild.buildroot.net/results/3776d2302f389691db972de35e077dcf2a07afab |
> > arm | rocksdb-6.10.1 | NOK | http://autobuild.buildroot.net/results/72f6f1aca4f1c9e19850ceccef7fed756af0e403 |
>
> Ouch:
>
> during RTL pass: cprop_hardreg
> db/memtable.cc:232:1: internal compiler error: in extract_constrain_insn, at recog.c:2205
>
> Could someone figure out if this gcc 8.3 issue still exists ?
>
>
> > aarch64_be | supertux-0.6.0 | NOK | http://autobuild.buildroot.net/results/0f02877a665b2281266df4b23c72a7c113906c31 |
>
> /tmp/instance-0/output-1/build/supertux-0.6.0/src/editor/object_settings.cpp:223:26: error: 'remove_if' is not a member of 'std'
> m_options.erase(std::remove_if(m_options.begin(), m_options.end(),
>
> Romain, supertux is your thing, could you have a look ?
>
>
> > sparc64 | tio-1.32 | NOK | http://autobuild.buildroot.net/results/028efb98838163b0c697bba30cedbc4f0704748d |
>
> Gah: error: redefinition of 'struct termio'
>
> > arm | unknown | NOK | http://autobuild.buildroot.net/results/0333faabe50ac103324085cc219fbfe06a1718bb |
>
> This looks like a top-level parallel build failure, the log is not long
> enough to show the real problem.
>
> > powerpc64le | unknown | NOK | http://autobuild.buildroot.net/results/542e97923620b2135fe5c846ad97c324cc108f43 |
>
> Ditto.
>
> > arm | unknown | NOK | http://autobuild.buildroot.net/results/93d88fcfe723e91846a68a9d87de585a741f3c5b |
>
> And again. I'm not sure how to improve this. Upload the full build log
> ? This could be huge :-/
>
> > arc | wampcc-1.6 | NOK | http://autobuild.buildroot.net/results/c3b67d8a5faf7ff06b08a0591f22b1fa4963c2ee | ORPH
>
> /home/test/autobuild/run/instance-3/output-1/host/lib/gcc/arc-buildroot-linux-uclibc/9.3.1/../../../../arc-buildroot-linux-uclibc/bin/ld: ../libs/wampcc/libwampcc.so.6.0.0: undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)'
> collect2: error: ld returned 1 exit status
>
> This looks very similar to the log4cplus build issue above, also
> happens only on ARC:
>
> http://autobuild.buildroot.net/?reason=wampcc-1.6
>
> ARC maintainers, could you have a look ?
>
> > or1k | zeromq-4.3.2 | NOK | http://autobuild.buildroot.net/results/538474abda90082eec91ca9017e91b4427e4f54b |
>
> Broken binutils:
>
> /home/test/autobuild/run/instance-0/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.32 assertion fail elf32-or1k.c:2331
>
> Would be useful to test with newer binutils.
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Best Regards,
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] [arc-buildroot] [autobuild.buildroot.net] Analysis of build results
2020-08-19 11:47 ` Fabrice Fontaine
@ 2020-08-19 20:31 ` Alexey Brodkin
2020-08-19 21:33 ` Alexey Brodkin
2020-09-11 8:39 ` Thomas Petazzoni
0 siblings, 2 replies; 20+ messages in thread
From: Alexey Brodkin @ 2020-08-19 20:31 UTC (permalink / raw
To: buildroot
Hi Thomas, all,
> > arc | log4cplus-2.0.5 | NOK | http://autobuild.buildroot.net/results/a7732fdb2ba526a114d9fb759814236c5332f8d7/ |
>
> undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)'
>
> This is happening only on ARC700. Perhaps a variant of ARC that doesn't
> support atomic instructions?
>
> ARC maintainers, could you have a look please ?
>
> > arc | wampcc-1.6 | NOK | http://autobuild.buildroot.net/results/c3b67d8a5faf7ff06b08a0591f22b1fa4963c2ee/ | ORPH
>
> /home/test/autobuild/run/instance-3/output-1/host/lib/gcc/arc-buildroot-linux-uclibc/9.3.1/../../../../arc-buildroot-linux-uclibc/bin/ld: ../libs/wampcc/libwampcc.so.6.0.0: undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)'
> collect2: error: ld returned 1 exit status
>
> This looks very similar to the log4cplus build issue above, also
> happens only on ARC: http://autobuild.buildroot.net/?reason=wampcc-1.6
>
> ARC maintainers, could you have a look ?
Ok so that happens because of misconfiguration of libstdc++.
When it gets configured we use not true final Buildroot's GCC (read-on...)
but just an intermediate "xgcc". And so when libstdc++ is checking for
atomics support it gets this:
-------------------------------->8-----------------------------
cat << EOF > /tmp/yourfilehere
int
main ()
{
#if __GCC_ATOMIC_INT_LOCK_FREE <= 1
# error atomic int not always lock free
#endif
return 0;
}
EOF
configure:81594: .../output/build/host-gcc-final-arc-2020.03-release/build/./gcc/xgcc \
-B.../output/build/host-gcc-final-arc-2020.03-release/build/./gcc/ \
-B.../output/host/arc-buildroot-linux-uclibc/bin/ \
-B.../output/host/arc-buildroot-linux-uclibc/lib/ \
-isystem .../output/host/arc-buildroot-linux-uclibc/include \
-isystem .../output/host/arc-buildroot-linux-uclibc/sys-include \
-c -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os conftest.c >&5
conftest.c: In function 'main':
conftest.c:240:13: error: #error atomic int not always lock free
240 | # error atomic int not always lock free
| ^~~~~
-------------------------------->8-----------------------------
And that's because "xgcc" uses its default configuration, i.e. "-mcpu=arc700",
and this one is w/o atomics. To make GCC using atomics we need to pass an extra option
to the driver with "-matomics" and... we do it via wrapper, see:
-------------------------------->8-----------------------------
strace -s 1000 .../output/host/bin/arc-linux-gcc -c test.c 2> >(grep execve)
execve(".../output/host/bin/arc-linux-gcc", [".../output/host/bin/arc-linux-gcc", "-c", "test.c"], [/* 136 vars */]) = 0
execve(".../output/host/bin/arc-linux-gcc.br_real", [".../output/host/bin/arc-linux-gcc.br_real", "--sysroot", ".../output/host/arc-buildroot-linux-uclibc/sysroot", "-matomic", "-Wl,-z,max-page-size=8192", "-c", "test.c"], [/* 136 vars */]) = 0
-------------------------------->8-----------------------------
Note how "arc-linux-gcc" nicely takes care of implicit handling of extra options.
So I guess it's clear what was the reason. What's not clear is how to solve
that problem properly, any guesses/hints?
In the meantime I'll be looking at opencv issues.
-Alexey
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] [arc-buildroot] [autobuild.buildroot.net] Analysis of build results
2020-08-19 20:31 ` [Buildroot] [arc-buildroot] " Alexey Brodkin
@ 2020-08-19 21:33 ` Alexey Brodkin
2020-09-11 8:39 ` Thomas Petazzoni
1 sibling, 0 replies; 20+ messages in thread
From: Alexey Brodkin @ 2020-08-19 21:33 UTC (permalink / raw
To: buildroot
Hi Thomas, all,
> Hi Thomas, all,
>
> > > arc | log4cplus-2.0.5 | NOK | http://autobuild.buildroot.net/results/a7732fdb2ba526a114d9fb759814236c5332f8d7/ |
> >
> > undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)'
> >
> > This is happening only on ARC700. Perhaps a variant of ARC that doesn't
> > support atomic instructions?
> >
> > ARC maintainers, could you have a look please ?
> >
> > > arc | wampcc-1.6 | NOK | http://autobuild.buildroot.net/results/c3b67d8a5faf7ff06b08a0591f22b1fa4963c2ee/ | ORPH
> >
> > /home/test/autobuild/run/instance-3/output-1/host/lib/gcc/arc-buildroot-linux-uclibc/9.3.1/../../../../arc-buildroot-linux-uclibc/bin/ld: ../libs/wampcc/libwampcc.so.6.0.0: undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)'
> > collect2: error: ld returned 1 exit status
> >
> > This looks very similar to the log4cplus build issue above, also
> > happens only on ARC: http://autobuild.buildroot.net/?reason=wampcc-1.6
> >
> > ARC maintainers, could you have a look ?
>
> Ok so that happens because of misconfiguration of libstdc++.
>
> When it gets configured we use not true final Buildroot's GCC (read-on...)
> but just an intermediate "xgcc". And so when libstdc++ is checking for
> atomics support it gets this:
> -------------------------------->8-----------------------------
> cat << EOF > /tmp/yourfilehere
> int
> main ()
> {
> #if __GCC_ATOMIC_INT_LOCK_FREE <= 1
> # error atomic int not always lock free
> #endif
> return 0;
> }
> EOF
>
> configure:81594: .../output/build/host-gcc-final-arc-2020.03-release/build/./gcc/xgcc \
> -B.../output/build/host-gcc-final-arc-2020.03-release/build/./gcc/ \
> -B.../output/host/arc-buildroot-linux-uclibc/bin/ \
> -B.../output/host/arc-buildroot-linux-uclibc/lib/ \
> -isystem .../output/host/arc-buildroot-linux-uclibc/include \
> -isystem .../output/host/arc-buildroot-linux-uclibc/sys-include \
> -c -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os conftest.c >&5
> conftest.c: In function 'main':
> conftest.c:240:13: error: #error atomic int not always lock free
> 240 | # error atomic int not always lock free
> | ^~~~~
> -------------------------------->8-----------------------------
>
> And that's because "xgcc" uses its default configuration, i.e. "-mcpu=arc700",
> and this one is w/o atomics. To make GCC using atomics we need to pass an extra option
> to the driver with "-matomics" and... we do it via wrapper, see:
> -------------------------------->8-----------------------------
> strace -s 1000 .../output/host/bin/arc-linux-gcc -c test.c 2> >(grep execve)
> execve(".../output/host/bin/arc-linux-gcc", [".../output/host/bin/arc-linux-gcc", "-c", "test.c"], [/* 136 vars */]) = 0
> execve(".../output/host/bin/arc-linux-gcc.br_real", [".../output/host/bin/arc-linux-gcc.br_real", "--sysroot", ".../output/host/arc-buildroot-linux-uclibc/sysroot", "-matomic", "-Wl,-z,max-page-size=8192", "-c", "test.c"], [/* 136 vars */]) = 0
> -------------------------------->8-----------------------------
>
> Note how "arc-linux-gcc" nicely takes care of implicit handling of extra options.
>
> So I guess it's clear what was the reason. What's not clear is how to solve
> that problem properly, any guesses/hints?
>
> In the meantime I'll be looking at opencv issues.
And as for OpenCV it's an upstream problem, see https://github.com/opencv/opencv/issues/17984.
Well and Fabrice already fixed that :)
1. OpenCV: https://git.buildroot.org/buildroot/commit?id=521854251f5a1e1082dbed503772969cd5797c41
2. OpenCV3: https://git.buildroot.org/buildroot/commit/?id=594201acb5b4b59bf43fc7c8c024b6e42c0569e7
So we're good now :)
-Alexey
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Analysis of build results
2020-08-15 22:09 ` [Buildroot] [autobuild.buildroot.net] Analysis of build results Thomas Petazzoni
` (6 preceding siblings ...)
2020-08-19 11:47 ` Fabrice Fontaine
@ 2020-08-20 9:22 ` Frank Vanbever
7 siblings, 0 replies; 20+ messages in thread
From: Frank Vanbever @ 2020-08-20 9:22 UTC (permalink / raw
To: buildroot
Hi Thomas,
On Sunday, 16 August 2020 00:09:14 CEST Thomas Petazzoni wrote:
> > i686 | host-elixir-1.9.4 | NOK |
> > http://autobuild.buildroot.net/results/a3a37eb724ca5689f8e83c9b2af04d
> > 07afa80315 |
> make[1]: Entering directory
> '/tmp/instance-1/output-1/build/host-elixir-1.9.4' make[1]: erlc: Command
> not found
>
> We have this once in a while, on different machines:
> http://autobuild.buildroot.net/?reason=host-elixir%
>
> Weird that it doesn't appear more often. Is there some kind of race
> condition?
>
> Frank: you added the host-elixir package, could you have a look ?
I found some time to take a look at this. It seems that the root cause for the
problem is that all of these configs have BR2_PER_PACKAGE_DIRECTORIES set.
It seems that ELIXIR_DEPENDENCIES should be changed to
HOST_ELIXIR_DEPENDENCIES in elixir.mk to ensure that it's picked up correctly
in the per-package build.
I've got a patch ready to submit, I'll do that asap.
Br,
Frank
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] [arc-buildroot] [autobuild.buildroot.net] Analysis of build results
2020-08-19 20:31 ` [Buildroot] [arc-buildroot] " Alexey Brodkin
2020-08-19 21:33 ` Alexey Brodkin
@ 2020-09-11 8:39 ` Thomas Petazzoni
2020-10-02 15:16 ` Alexey Brodkin
1 sibling, 1 reply; 20+ messages in thread
From: Thomas Petazzoni @ 2020-09-11 8:39 UTC (permalink / raw
To: buildroot
Hello,
On Wed, 19 Aug 2020 20:31:17 +0000
Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote:
> Ok so that happens because of misconfiguration of libstdc++.
>
> When it gets configured we use not true final Buildroot's GCC (read-on...)
> but just an intermediate "xgcc". And so when libstdc++ is checking for
> atomics support it gets this:
> -------------------------------->8-----------------------------
> cat << EOF > /tmp/yourfilehere
> int
> main ()
> {
> #if __GCC_ATOMIC_INT_LOCK_FREE <= 1
> # error atomic int not always lock free
> #endif
> return 0;
> }
> EOF
>
> configure:81594: .../output/build/host-gcc-final-arc-2020.03-release/build/./gcc/xgcc \
> -B.../output/build/host-gcc-final-arc-2020.03-release/build/./gcc/ \
> -B.../output/host/arc-buildroot-linux-uclibc/bin/ \
> -B.../output/host/arc-buildroot-linux-uclibc/lib/ \
> -isystem .../output/host/arc-buildroot-linux-uclibc/include \
> -isystem .../output/host/arc-buildroot-linux-uclibc/sys-include \
> -c -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os conftest.c >&5
> conftest.c: In function 'main':
> conftest.c:240:13: error: #error atomic int not always lock free
> 240 | # error atomic int not always lock free
> | ^~~~~
> -------------------------------->8-----------------------------
>
> And that's because "xgcc" uses its default configuration, i.e. "-mcpu=arc700",
> and this one is w/o atomics. To make GCC using atomics we need to pass an extra option
> to the driver with "-matomics" and... we do it via wrapper, see:
> -------------------------------->8-----------------------------
> strace -s 1000 .../output/host/bin/arc-linux-gcc -c test.c 2> >(grep execve)
> execve(".../output/host/bin/arc-linux-gcc", [".../output/host/bin/arc-linux-gcc", "-c", "test.c"], [/* 136 vars */]) = 0
> execve(".../output/host/bin/arc-linux-gcc.br_real", [".../output/host/bin/arc-linux-gcc.br_real", "--sysroot", ".../output/host/arc-buildroot-linux-uclibc/sysroot", "-matomic", "-Wl,-z,max-page-size=8192", "-c", "test.c"], [/* 136 vars */]) = 0
> -------------------------------->8-----------------------------
>
> Note how "arc-linux-gcc" nicely takes care of implicit handling of extra options.
>
> So I guess it's clear what was the reason. What's not clear is how to solve
> that problem properly, any guesses/hints?
Thanks for the research!
Wouldn't this be normally handled by having a --with-atomic option
passed to gcc, which would ensure that the compiler enables -matomic,
without having to pass this flag explicitly ?
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] [arc-buildroot] [autobuild.buildroot.net] Analysis of build results
2020-09-11 8:39 ` Thomas Petazzoni
@ 2020-10-02 15:16 ` Alexey Brodkin
2020-10-06 18:57 ` Arnout Vandecappelle
0 siblings, 1 reply; 20+ messages in thread
From: Alexey Brodkin @ 2020-10-02 15:16 UTC (permalink / raw
To: buildroot
Hi Thomas, all,
> > Ok so that happens because of misconfiguration of libstdc++.
> >
> > When it gets configured we use not true final Buildroot's GCC (read-on...)
> > but just an intermediate "xgcc". And so when libstdc++ is checking for
> > atomics support it gets this:
> > -------------------------------->8-----------------------------
> > cat << EOF > /tmp/yourfilehere
> > int
> > main ()
> > {
> > #if __GCC_ATOMIC_INT_LOCK_FREE <= 1
> > # error atomic int not always lock free
> > #endif
> > return 0;
> > }
> > EOF
> >
> > configure:81594: .../output/build/host-gcc-final-arc-2020.03-release/build/./gcc/xgcc \
> > -B.../output/build/host-gcc-final-arc-2020.03-release/build/./gcc/ \
> > -B.../output/host/arc-buildroot-linux-uclibc/bin/ \
> > -B.../output/host/arc-buildroot-linux-uclibc/lib/ \
> > -isystem .../output/host/arc-buildroot-linux-uclibc/include \
> > -isystem .../output/host/arc-buildroot-linux-uclibc/sys-include \
> > -c -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os conftest.c >&5
> > conftest.c: In function 'main':
> > conftest.c:240:13: error: #error atomic int not always lock free
> > 240 | # error atomic int not always lock free
> > | ^~~~~
> > -------------------------------->8-----------------------------
> >
> > And that's because "xgcc" uses its default configuration, i.e. "-mcpu=arc700",
> > and this one is w/o atomics. To make GCC using atomics we need to pass an extra option
> > to the driver with "-matomics" and... we do it via wrapper, see:
> > -------------------------------->8-----------------------------
> > strace -s 1000 .../output/host/bin/arc-linux-gcc -c test.c 2> >(grep execve)
> > execve(".../output/host/bin/arc-linux-gcc", [".../output/host/bin/arc-linux-gcc", "-c", "test.c"], [/* 136 vars */]) = 0
> > execve(".../output/host/bin/arc-linux-gcc.br_real", [".../output/host/bin/arc-linux-gcc.br_real", "--sysroot", ".../output/host/arc-buildroot-linux-uclibc/sysroot", "-matomic", "-Wl,-z,max-page-size=8192", "-c", "test.c"], [/* 136 vars */]) = 0
> > -------------------------------->8-----------------------------
> >
> > Note how "arc-linux-gcc" nicely takes care of implicit handling of extra options.
> >
> > So I guess it's clear what was the reason. What's not clear is how to solve
> > that problem properly, any guesses/hints?
>
> Thanks for the research!
>
> Wouldn't this be normally handled by having a --with-atomic option
> passed to gcc, which would ensure that the compiler enables -matomic,
> without having to pass this flag explicitly ?
Finally I was able to spend some more time on that. So it looks like a kind of
regression due to https://git.buildroot.org/buildroot/commit/?id=c568b4f37fa6d7f51e6d14d33d7eb75dfe26d7bf
where we moved "-matomic" from TARGET_ABI to ARCH_TOOLCHAIN_WRAPPER_OPTS.
The point is (and it could be seen from my previous explanation above) libstdc++ is being built by
temporary cross-compiler (xgcc) instead of preperly installed wrappers for real tools.
That's why whatever we put in ARCH_TOOLCHAIN_WRAPPER_OPTS makes no sense, while CFLAGS_FOR_TARGET
where we add contents of TARGET_ABI do make "xgcc" using "-matomic".
So far we know what's wrong. The question now what could be a good solution?
Revert offending commit?
-Alexey
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] [arc-buildroot] [autobuild.buildroot.net] Analysis of build results
2020-10-02 15:16 ` Alexey Brodkin
@ 2020-10-06 18:57 ` Arnout Vandecappelle
0 siblings, 0 replies; 20+ messages in thread
From: Arnout Vandecappelle @ 2020-10-06 18:57 UTC (permalink / raw
To: buildroot
On 02/10/2020 17:16, Alexey Brodkin wrote:
>
> Hi Thomas, all,
>
>>> Ok so that happens because of misconfiguration of libstdc++.
[snip]
>> Wouldn't this be normally handled by having a --with-atomic option
>> passed to gcc, which would ensure that the compiler enables -matomic,
>> without having to pass this flag explicitly ?
>
> Finally I was able to spend some more time on that. So it looks like a kind of
> regression due to https://git.buildroot.org/buildroot/commit/?id=c568b4f37fa6d7f51e6d14d33d7eb75dfe26d7bf
> where we moved "-matomic" from TARGET_ABI to ARCH_TOOLCHAIN_WRAPPER_OPTS.
>
> The point is (and it could be seen from my previous explanation above) libstdc++ is being built by
> temporary cross-compiler (xgcc) instead of preperly installed wrappers for real tools.
> That's why whatever we put in ARCH_TOOLCHAIN_WRAPPER_OPTS makes no sense, while CFLAGS_FOR_TARGET
> where we add contents of TARGET_ABI do make "xgcc" using "-matomic".
>
> So far we know what's wrong. The question now what could be a good solution?
The good solution is to add the -matomic explicitly in host-gcc-final's
CFLAGS_FOR_TARGET.
Regards,
Arnout
> Revert offending commit?
>
> -Alexey
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2020-10-06 18:57 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-08-15 8:01 [Buildroot] [autobuild.buildroot.net] Daily results for 2020-08-14 Thomas Petazzoni
2020-08-15 22:09 ` [Buildroot] [autobuild.buildroot.net] Analysis of build results Thomas Petazzoni
2020-08-15 22:14 ` Thomas Petazzoni
2020-08-17 9:19 ` Gwenhael Goavec-Merou
2020-08-17 9:40 ` Thomas Petazzoni
2020-08-17 9:51 ` Gwenhael Goavec-Merou
2020-08-17 12:18 ` Asaf Kahlon
2020-08-17 12:52 ` Thomas Petazzoni
2020-08-17 20:54 ` Peter Seiderer
2020-08-17 21:30 ` Thomas Petazzoni
2020-08-17 21:57 ` Peter Seiderer
2020-08-17 21:15 ` Peter Seiderer
2020-08-17 21:43 ` Romain Naour
2020-08-19 11:47 ` Fabrice Fontaine
2020-08-19 20:31 ` [Buildroot] [arc-buildroot] " Alexey Brodkin
2020-08-19 21:33 ` Alexey Brodkin
2020-09-11 8:39 ` Thomas Petazzoni
2020-10-02 15:16 ` Alexey Brodkin
2020-10-06 18:57 ` Arnout Vandecappelle
2020-08-20 9:22 ` [Buildroot] " Frank Vanbever
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.