* [Buildroot] [autobuild.buildroot.net] Daily results for 2021-08-17
@ 2021-08-18 6:57 Thomas Petazzoni
2021-08-18 10:25 ` Thomas Petazzoni
2021-08-18 21:44 ` [Buildroot] Analysis of build " Thomas Petazzoni
0 siblings, 2 replies; 18+ messages in thread
From: Thomas Petazzoni @ 2021-08-18 6:57 UTC (permalink / raw)
To: buildroot
Hello,
Autobuild statistics for 2021-08-17
===================================
branch | OK | NOK | TIM | TOT |
2021.02.x | 34 | 7 | 0 | 41 |
2021.05.x | 35 | 7 | 0 | 42 |
master | 186 | 30 | 5 | 221 |
next | 34 | 27 | 1 | 62 |
Classification of failures by reason for master
-----------------------------------------------
host-sentry-cli-1.57.0 | 6
mongodb | 4
mpv-0.33.1 | 3
gdb-10.1 | 2
gobject-introspection-1.68.0 | 2
host-cairo-1.16.0 | 2
ripgrep-0.8.1 | 2
zeromq-4.3.4 | 2
capnproto-0.8.0 | 1
eigen-3.3.7 | 1
harfbuzz-2.8.2 | 1
host-llvm | 1
libmodsecurity-3.0.5 | 1
libvirt-7.4.0 | 1
openal-1.21.1 | 1
openmpi-4.0.0 | 1
openvmtools-10.3.5-10430147 | 1
qt5base-5.15.2 | 1
unknown | 1
xvisor-0.3.0 | 1
Detail of failures for master
-----------------------------
arch | reason | OK? | url | orph?
-------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
riscv64 | capnproto-0.8.0 | NOK | http://autobuild.buildroot.net/results/c28dd04c453827c58c078b0808739d780c87690d |
arm | eigen-3.3.7 | NOK | http://autobuild.buildroot.net/results/8354da225d1e5e337aa7ea62a7e6524fb5f1135f |
riscv32 | gdb-10.1 | NOK | http://autobuild.buildroot.net/results/21647e2a661dc198f6f6f37f3c767faa449cde65 | ORPH
riscv64 | gdb-10.1 | NOK | http://autobuild.buildroot.net/results/21bb9fd1a2e4a9e43ec21ac0477406086bb5ef91 | ORPH
x86_64 | gobject-introspection-1.68.0 | NOK | http://autobuild.buildroot.net/results/b749049b0484f1e3d097b2d25d15082f52398f39 | ORPH
mips | gobject-introspection-1.68.0 | NOK | http://autobuild.buildroot.net/results/e5a96a3c7bbdf999ca47e3da0e2067a6763714b3 | ORPH
arm | harfbuzz-2.8.2 | NOK | http://autobuild.buildroot.net/results/e2dbf859ae5ea9408ac7bf1554c110b0477bb497 | ORPH
xtensa | host-cairo-1.16.0 | NOK | http://autobuild.buildroot.net/results/00096bad2d9eee90c07761fc8c7f9eafe8782dac |
mips64el | host-cairo-1.16.0 | NOK | http://autobuild.buildroot.net/results/c1d61387edf1f79522f7d9df82c90c9cd67bba2d |
aarch64 | host-llvm | TIM | http://autobuild.buildroot.net/results/c97386a8a1092a3ee4735720cafad62eb6cd2721 |
s390x | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/38ccbf255a868e823d441f9e3dc6f1949edf3978 |
powerpc | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/1d1708d0d6464271b4b0c4e992b58040f9cf8cca |
arm | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/d5c8b9bcceb3317a07713190a0b2a918e44976c7 |
nios2 | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/cd7d3f81de5d98bb4a5b519ee8edb8e1e05aa303 |
microblazeel | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/f00eef7a67b3de664d4c5ef1e5328abfa96b274c |
mips64el | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/e3d48d2f67314e8e533a2c6194829e27bb4c1fa8 |
m68k | libmodsecurity-3.0.5 | NOK | http://autobuild.buildroot.net/results/b92980a563fe7ee331e70f288ce041be0bf29d40 |
i686 | libvirt-7.4.0 | NOK | http://autobuild.buildroot.net/results/2349c55a4a42f08ca52700c60cda3065b0c4bd88 |
aarch64 | mongodb | TIM | http://autobuild.buildroot.net/results/d5040c9ee89e401f897daecf58d823489d6ff52b |
aarch64 | mongodb | TIM | http://autobuild.buildroot.net/results/5f5edc8a61827480f1a8b0c2c448976d446964c2 |
aarch64 | mongodb | TIM | http://autobuild.buildroot.net/results/8e3fc4996d86be79b09ebf7e74bbc244a08b4670 |
arm | mongodb | TIM | http://autobuild.buildroot.net/results/8f41dba464a725ca3dfae20cbbe7a387639dfc9e |
arc | mpv-0.33.1 | NOK | http://autobuild.buildroot.net/results/fb10eb81ddc77576c6e23519c26c6db774d6f8e5 |
arm | mpv-0.33.1 | NOK | http://autobuild.buildroot.net/results/e5c15228f42a73f8c34b26630b2074c30e5f5966 |
mips64el | mpv-0.33.1 | NOK | http://autobuild.buildroot.net/results/5008324c586b70e71ea5fe3030f0355c87daa96f |
or1k | openal-1.21.1 | NOK | http://autobuild.buildroot.net/results/6a2809f8eefdeeaca8a4c61130a8d85511685cfc |
mipsel | openmpi-4.0.0 | NOK | http://autobuild.buildroot.net/results/2f96654c2238c115060aafc3cf10f71457c585f7 | ORPH
i586 | openvmtools-10.3.5-10430147 | NOK | http://autobuild.buildroot.net/results/eb3dfe679536b578a0f16762312a96ada7162095 |
riscv32 | qt5base-5.15.2 | NOK | http://autobuild.buildroot.net/results/568f7fceebb06deb0755e8d3757c761608faeec7 |
mips64el | ripgrep-0.8.1 | NOK | http://autobuild.buildroot.net/results/e069c1a3433431b8055520a87f989b4eeefd7a4a |
mips64el | ripgrep-0.8.1 | NOK | http://autobuild.buildroot.net/results/8bab232eb98b164df300581ae019254bde7c8ca3 |
or1k | unknown | NOK | http://autobuild.buildroot.net/results/92c086b0c5c2a298a82a6eb9c289dc53c58a5e5e |
arm | xvisor-0.3.0 | NOK | http://autobuild.buildroot.net/results/306e1a107abfad392f97e8d8d987d6e17ec80012 |
or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/f6d9c3b1e7be0e3c722f79bad7b89c7f1bd0f2f0 |
or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/c6b4f37e30b7c6f803d32e6d9d0dec8e15e7ec30 |
Classification of failures by reason for 2021.02.x
--------------------------------------------------
host-sentry-cli-1.57.0 | 2
iostat-2.2 | 1
openvmtools-10.3.5-10430147 | 1
python-pybind-2.6.1 | 1
qt5location-5.15.2 | 1
trace-cmd-trace-cmd-v2.9.1 | 1
Detail of failures for 2021.02.x
--------------------------------
arch | reason | OK? | url | orph?
-------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
powerpc64le | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/89b0c7a11593e6a6c554806b703df8ac4f0336e9 |
i586 | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/6b14f8aec98a7fdd45d23746cf86e1b50e51c29e |
microblazeel | iostat-2.2 | NOK | http://autobuild.buildroot.net/results/f94137858a7a602b3d55d48c9d0cd84dd9f3b424 |
x86_64 | openvmtools-10.3.5-10430147 | NOK | http://autobuild.buildroot.net/results/05ae1b96367c992fa7a97b5da03f8c0e1acb832a |
microblazeel | python-pybind-2.6.1 | NOK | http://autobuild.buildroot.net/results/1c024ef8e53300ed3f80495e96f24f10576b62a3 |
x86_64 | qt5location-5.15.2 | NOK | http://autobuild.buildroot.net/results/fae21dd69641ecc729c64ef073e6662fe99cfea1 |
sparc64 | trace-cmd-trace-cmd-v2.9.1 | NOK | http://autobuild.buildroot.net/results/6a868f4e2306196be81fd214f6ddda2416c5e34b |
Classification of failures by reason for 2021.05.x
--------------------------------------------------
gobject-introspection-1.64.1 | 2
host-sentry-cli-1.57.0 | 2
android-tools-4.2.2+git2013... | 1
mono-6.12.0.90 | 1
qpid-proton-0.33.0 | 1
Detail of failures for 2021.05.x
--------------------------------
arch | reason | OK? | url | orph?
-------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
powerpc64 | android-tools-4.2.2+git2013... | NOK | http://autobuild.buildroot.net/results/4b8b4c245ca279feeb7572abe2b2963e2aaaca24 |
x86_64 | gobject-introspection-1.64.1 | NOK | http://autobuild.buildroot.net/results/ac296714731151b63a063438c2ee3bf73a14eba2 | ORPH
s390x | gobject-introspection-1.64.1 | NOK | http://autobuild.buildroot.net/results/040c1cbff25c1c2bfb05b701d9d763ad4c49a583 | ORPH
arc | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/2554f8f9d2849bfc4948df368e4f6f73fd43044f |
m68k | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/415df41b2d9a0520f2df3ecb0ba15e379ccec390 |
arm | mono-6.12.0.90 | NOK | http://autobuild.buildroot.net/results/18b017dd5b9c1d8d6c91303ea4f1fdd3e1b086e0 |
arm | qpid-proton-0.33.0 | NOK | http://autobuild.buildroot.net/results/145f0583ea412fba20d565fac0bac9c3f21ea261 |
Classification of failures by reason for next
---------------------------------------------
libebml-1.4.2 | 12
host-libcap-2.52 | 3
sdl2-2.0.14 | 2
capnproto-0.8.0 | 1
ffmpeg-4.4 | 1
gobject-introspection-1.68.0 | 1
guile-3.0.4 | 1
harfbuzz-2.8.2 | 1
host-cairo-1.16.0 | 1
host-sentry-cli-1.57.0 | 1
libbpf-0.4.0 | 1
libmediaart-1.9.4 | 1
qpdf | 1
refpolicy-2.20210203 | 1
Detail of failures for next
---------------------------
arch | reason | OK? | url | orph?
-------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
riscv64 | capnproto-0.8.0 | NOK | http://autobuild.buildroot.net/results/a09dc881c8cae437e7377632c86e5159f58d8005 |
mipsel | ffmpeg-4.4 | NOK | http://autobuild.buildroot.net/results/3b729cf7c45c59caca269b398d7e26301a725143 |
x86_64 | gobject-introspection-1.68.0 | NOK | http://autobuild.buildroot.net/results/fd72dcd5f9ccef266e6300b15040425fa3313ddb | ORPH
riscv32 | guile-3.0.4 | NOK | http://autobuild.buildroot.net/results/6945079da142733ab0ee77e6cf503dfa8fd36c17 | ORPH
arm | harfbuzz-2.8.2 | NOK | http://autobuild.buildroot.net/results/3d884e49b0d8f9485d3ed68f1198eb6179122f57 | ORPH
arm | host-cairo-1.16.0 | NOK | http://autobuild.buildroot.net/results/002b6a88a23fb1311c31ef14d792cba0900a44dd |
sparc | host-libcap-2.52 | NOK | http://autobuild.buildroot.net/results/c5013a4d9a7dd2305bab8d9aa43104fd5f353bcf |
arc | host-libcap-2.52 | NOK | http://autobuild.buildroot.net/results/2511a7ec0b4fc29133a4fc99160beb47c5681f02 |
powerpc | host-libcap-2.52 | NOK | http://autobuild.buildroot.net/results/e0d8cb350072ea90c331824a6790c792d60d885d |
m68k | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/0ff73f9bc7264fa53d0297eb54ceca4d1261b874 |
i686 | libbpf-0.4.0 | NOK | http://autobuild.buildroot.net/results/29075722cbe34782fc0a79ac61562d7828d2b9cd |
i586 | libebml-1.4.2 | NOK | http://autobuild.buildroot.net/results/8b615eb0eea66cae7c31d9ce5d48eca8c5f0e82d |
powerpc64le | libebml-1.4.2 | NOK | http://autobuild.buildroot.net/results/5fcf8e3923e8ce33338271846904139e15b81849 |
mipsel | libebml-1.4.2 | NOK | http://autobuild.buildroot.net/results/4f8897ed82629876042457862717ffaaa2ad45d6 |
powerpc | libebml-1.4.2 | NOK | http://autobuild.buildroot.net/results/9eba4b4935f36d23e5a760ce5567501d556fd578 |
m68k | libebml-1.4.2 | NOK | http://autobuild.buildroot.net/results/2840467638490f2a4024de83192bfed32436973b |
m68k | libebml-1.4.2 | NOK | http://autobuild.buildroot.net/results/f24595dab2e0774606afee65814097acc66663dc |
mips64el | libebml-1.4.2 | NOK | http://autobuild.buildroot.net/results/d3ede7a124550be7682bd38ed993c37b3bdf0fe0 |
powerpc64le | libebml-1.4.2 | NOK | http://autobuild.buildroot.net/results/07211fc9881303410db79ea5781bd668c59feff2 |
sh4 | libebml-1.4.2 | NOK | http://autobuild.buildroot.net/results/fb3d811d1077373f28ea6fe6ecfe41d34cd7a01d |
nios2 | libebml-1.4.2 | NOK | http://autobuild.buildroot.net/results/4f5e05fb4dd060e61a72d74c2cae3a8c2f480099 |
s390x | libebml-1.4.2 | NOK | http://autobuild.buildroot.net/results/b810862764ad9c762a652fa0d74e66fbb53d683e |
powerpc | libebml-1.4.2 | NOK | http://autobuild.buildroot.net/results/a228f8012e7eeb9a1eb70e4db8270318f861b0fe |
mipsel | libmediaart-1.9.4 | NOK | http://autobuild.buildroot.net/results/4408c40d4c12a683e4be5c550b59237b420b0a6f |
riscv32 | qpdf | TIM | http://autobuild.buildroot.net/results/1f78a886e719d26586324c972178cac5cc3a1336 |
arc | refpolicy-2.20210203 | NOK | http://autobuild.buildroot.net/results/2a95e8b43636c8b1a64e41077649895d4f839801 |
arc | sdl2-2.0.14 | NOK | http://autobuild.buildroot.net/results/fd3769e48d28ff32d6d607e5bfa5dcd47d60b93b |
sh4 | sdl2-2.0.14 | NOK | http://autobuild.buildroot.net/results/79505f4740ac4ea75d24249c107a9fb8b7e1f70f |
--
http://autobuild.buildroot.net
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Buildroot] [autobuild.buildroot.net] Daily results for 2021-08-17
2021-08-18 6:57 [Buildroot] [autobuild.buildroot.net] Daily results for 2021-08-17 Thomas Petazzoni
@ 2021-08-18 10:25 ` Thomas Petazzoni
2021-08-18 11:05 ` Yann E. MORIN
2021-08-18 21:44 ` [Buildroot] Analysis of build " Thomas Petazzoni
1 sibling, 1 reply; 18+ messages in thread
From: Thomas Petazzoni @ 2021-08-18 10:25 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 18 Aug 2021 06:57:22 -0000
Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> Detail of failures for next
> ---------------------------
>
> arch | reason | OK? | url | orph?
> -------------+--------------------------------+-----+---------------------------------------------------------------------------------+-------
[...]
> sparc | host-libcap-2.52 | NOK | http://autobuild.buildroot.net/results/c5013a4d9a7dd2305bab8d9aa43104fd5f353bcf |
> arc | host-libcap-2.52 | NOK | http://autobuild.buildroot.net/results/2511a7ec0b4fc29133a4fc99160beb47c5681f02 |
> powerpc | host-libcap-2.52 | NOK | http://autobuild.buildroot.net/results/e0d8cb350072ea90c331824a6790c792d60d885d |
I am confused by these host-libcap issues, as I'm not able to
reproduce. I tried on my local machine, and the host binaries have the
proper RPATH. Thinking it might be a machine/distro specific issue, I
tried on the gcc160 machine, which has reported build issues, and I
tried building the exact defconfig of one of the build failures, and
host-libcap builds just fine.
So, I'm confused :/ Any idea ?
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Buildroot] [autobuild.buildroot.net] Daily results for 2021-08-17
2021-08-18 10:25 ` Thomas Petazzoni
@ 2021-08-18 11:05 ` Yann E. MORIN
2021-08-18 20:18 ` Thomas Petazzoni
0 siblings, 1 reply; 18+ messages in thread
From: Yann E. MORIN @ 2021-08-18 11:05 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: buildroot
Thomas, All,
On 2021-08-18 12:25 +0200, Thomas Petazzoni spake thusly:
> On Wed, 18 Aug 2021 06:57:22 -0000
> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> > sparc | host-libcap-2.52 | NOK | http://autobuild.buildroot.net/results/c5013a4d9a7dd2305bab8d9aa43104fd5f353bcf |
> > arc | host-libcap-2.52 | NOK | http://autobuild.buildroot.net/results/2511a7ec0b4fc29133a4fc99160beb47c5681f02 |
> > powerpc | host-libcap-2.52 | NOK | http://autobuild.buildroot.net/results/e0d8cb350072ea90c331824a6790c792d60d885d |
>
> I am confused by these host-libcap issues, as I'm not able to
> reproduce. I tried on my local machine, and the host binaries have the
> proper RPATH. Thinking it might be a machine/distro specific issue, I
> tried on the gcc160 machine, which has reported build issues, and I
> tried building the exact defconfig of one of the build failures, and
> host-libcap builds just fine.
>
> So, I'm confused :/ Any idea ?
Not sure the exact reason, but notice that the failures occur at install
time, not build time. And even then, the Makefile is still trying to
compile some stuff.
libcap is a generic package, and I noticed that the build and install
commands do not use the same environment:
define HOST_LIBCAP_BUILD_CMDS
$(HOST_MAKE_ENV) $(HOST_CONFIGURE_OPTS) $(MAKE) -C $(@D) \
$(HOST_LIBCAP_MAKE_FLAGS)
endef
define HOST_LIBCAP_INSTALL_CMDS
$(HOST_MAKE_ENV) $(MAKE) -C $(@D) $(HOST_LIBCAP_MAKE_FLAGS) install
endef
So I wonder if, at least for sanity sake, we should not just add
$(HOST_CONFIGURE_OPTS) in the environment for the install commands too.
Also, notice spurious errors from ldconfig:
/sbin/ldconfig
/sbin/ldconfig.real: Can't create temporary cache file /etc/ld.so.cache~: Permission denied
make[5]: [Makefile:162: install-shared-psx] Error 1 (ignored)
(ldconfig is a wrapper around ldconfig.real, specific to debian and.or
ubuntu I guess)
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Buildroot] [autobuild.buildroot.net] Daily results for 2021-08-17
2021-08-18 11:05 ` Yann E. MORIN
@ 2021-08-18 20:18 ` Thomas Petazzoni
2021-08-18 21:04 ` Yann E. MORIN
0 siblings, 1 reply; 18+ messages in thread
From: Thomas Petazzoni @ 2021-08-18 20:18 UTC (permalink / raw)
To: Yann E. MORIN; +Cc: buildroot
Hello,
On Wed, 18 Aug 2021 13:05:58 +0200
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
> Not sure the exact reason, but notice that the failures occur at install
> time, not build time.
I did try with "make host-libcap", which includes the installation
step, and I even tried to do a full build of one of the failing
defconfigs. The build failed, but much much later, on a completely
unrelated package. And manually checking the RPATH of the host-libcap
binaries: they are correct.
> And even then, the Makefile is still trying to
> compile some stuff.
>
> libcap is a generic package, and I noticed that the build and install
> commands do not use the same environment:
>
> define HOST_LIBCAP_BUILD_CMDS
> $(HOST_MAKE_ENV) $(HOST_CONFIGURE_OPTS) $(MAKE) -C $(@D) \
> $(HOST_LIBCAP_MAKE_FLAGS)
> endef
>
> define HOST_LIBCAP_INSTALL_CMDS
> $(HOST_MAKE_ENV) $(MAKE) -C $(@D) $(HOST_LIBCAP_MAKE_FLAGS) install
> endef
>
> So I wonder if, at least for sanity sake, we should not just add
> $(HOST_CONFIGURE_OPTS) in the environment for the install commands too.
I'm not sure how that could cause an issue, as I'm building on the same
machine, same defconfig.
> Also, notice spurious errors from ldconfig:
>
> /sbin/ldconfig
> /sbin/ldconfig.real: Can't create temporary cache file /etc/ld.so.cache~: Permission denied
> make[5]: [Makefile:162: install-shared-psx] Error 1 (ignored)
>
> (ldconfig is a wrapper around ldconfig.real, specific to debian and.or
> ubuntu I guess)
Right, but the absence/presence of the RPATH should normally not be
affected by this, I believe.
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Buildroot] [autobuild.buildroot.net] Daily results for 2021-08-17
2021-08-18 20:18 ` Thomas Petazzoni
@ 2021-08-18 21:04 ` Yann E. MORIN
2021-08-23 20:55 ` Arnout Vandecappelle
0 siblings, 1 reply; 18+ messages in thread
From: Yann E. MORIN @ 2021-08-18 21:04 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: buildroot
Thomas, All,
On 2021-08-18 22:18 +0200, Thomas Petazzoni spake thusly:
> On Wed, 18 Aug 2021 13:05:58 +0200
> "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
> > Not sure the exact reason, but notice that the failures occur at install
> > time, not build time.
> I did try with "make host-libcap", which includes the installation
> step, and I even tried to do a full build of one of the failing
> defconfigs. The build failed, but much much later, on a completely
> unrelated package. And manually checking the RPATH of the host-libcap
> binaries: they are correct.
Here too.
> > And even then, the Makefile is still trying to
> > compile some stuff.
> >
> > libcap is a generic package, and I noticed that the build and install
> > commands do not use the same environment:
> >
> > define HOST_LIBCAP_BUILD_CMDS
> > $(HOST_MAKE_ENV) $(HOST_CONFIGURE_OPTS) $(MAKE) -C $(@D) \
> > $(HOST_LIBCAP_MAKE_FLAGS)
> > endef
> >
> > define HOST_LIBCAP_INSTALL_CMDS
> > $(HOST_MAKE_ENV) $(MAKE) -C $(@D) $(HOST_LIBCAP_MAKE_FLAGS) install
> > endef
> >
> > So I wonder if, at least for sanity sake, we should not just add
> > $(HOST_CONFIGURE_OPTS) in the environment for the install commands too.
>
> I'm not sure how that could cause an issue, as I'm building on the same
> machine, same defconfig.
Well, it has an impact: the file sthat are built at build time and
install time have different compile lines:
For example, cap_magic.o at build time, from:
http://autobuild.buildroot.org/results/e0d8cb350072ea90c331824a6790c792d60d885d/build-end.log
gcc -O2
-I/data/buildroot-autobuilder/instance-0/output-1/host/include -Dlinux
-Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline
-Wshadow -g -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual
-Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs
-Winline -Wshadow -g -Dlinux -Wall -Wwrite-strings -Wpointer-arith
-Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes
-Wnested-externs -Winline -Wshadow -g -fPIC
-I/data/buildroot-autobuilder/instance-0/output-1/build/host-libcap-2.52/libcap/../libcap/include/uapi
-I/data/buildroot-autobuilder/instance-0/output-1/build/host-libcap-2.52/libcap/../libcap/include
-DLIBRARY_VERSION=\"libcap-2.52\"
-DSHARED_LOADER=\"/lib64/ld-linux-x86-64.so.2\" -c execable.c -o
cap_magic.o
Which get linked with:
gcc -Wl,-x -shared -O2
-I/data/buildroot-autobuilder/instance-0/output-1/host/include -Dlinux
-Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline
-Wshadow -g -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual
-Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs
-Winline -Wshadow -g -Dlinux -Wall -Wwrite-strings -Wpointer-arith
-Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes
-Wnested-externs -Winline -Wshadow -g
-L/data/buildroot-autobuilder/instance-0/output-1/host/lib
-Wl,-rpath,/data/buildroot-autobuilder/instance-0/output-1/host/lib
-L/data/buildroot-autobuilder/instance-0/output-1/build/host-libcap-2.52/libcap
-L/data/buildroot-autobuilder/instance-0/output-1/build/host-libcap-2.52/libcap/../libcap
-L/data/buildroot-autobuilder/instance-0/output-1/build/host-libcap-2.52/libcap/../libcap
-Wl,-soname,libpsx.so.2 -o libpsx.so.2.52 ../psx/psx.o psx_magic.o
--entry=__so_start -lpthread -Wl,-wrap,pthread_create
And now at install time:
gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall
-Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline
-Wshadow -g -fPIC
-I/data/buildroot-autobuilder/instance-0/output-1/build/host-libcap-2.52/libcap/../libcap/include/uapi
-I/data/buildroot-autobuilder/instance-0/output-1/build/host-libcap-2.52/libcap/../libcap/include
-DLIBRARY_VERSION=\"libcap-2.52\"
-DSHARED_LOADER=\"/lib64/ld-linux-x86-64.so.2\" -c execable.c -o
cap_magic.o
which is now linked with:
gcc -Wl,-x -shared -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline
-Wshadow -g
-L/data/buildroot-autobuilder/instance-0/output-1/build/host-libcap-2.52/libcap/../libcap
-Wl,-soname,libcap.so.2 -o libcap.so.2.52 cap_alloc.o cap_proc.o
cap_extint.o cap_flag.o cap_text.o cap_file.o cap_magic.o
--entry=__so_start
So, the first properly gets our LDFLAGS, the second, not. Pasing
TARGET_CONFIGURE_OPTS at install time would solve^whide the issue,
though.
But OK, what are the dependencies of cap_magic.o?
cap_magic.o: execable.h execable.c loader.txt
execable.h and .c are not generated, so they are terminal dependencies.
loader.txt is generated. And it is generated twice (still form the same
build):
make[3]: Entering directory '/data/buildroot-autobuilder/instance-0/output-1/build/host-libcap-2.52/libcap'
gcc -o empty empty.c
objcopy --dump-section .interp=/dev/stdout empty > loader.txt
[...]
make[3]: Leaving directory '/data/buildroot-autobuilder/instance-0/output-1/build/host-libcap-2.52/libcap'
/usr/bin/make libpsx.so
make[3]: Entering directory '/data/buildroot-autobuilder/instance-0/output-1/build/host-libcap-2.52/libcap'
objcopy --dump-section .interp=/dev/stdout empty > loader.txt
[...]
Wha?
So, it believes loader.txt is out of date wrt a file named 'empty'
(which is generated from a trivial C file empty.c)
So, becasue loader.txt is re-generated a second time, some files are
re-built at install time. Which explains why we get an issue.
But then, why is it out of date, at all? I really got stuck there...
Could it be that this is a parallel build issue? I doubt it, though...
I'm out of clues now, so I'll let a godd night's sleep try to solve
this....
Regards,
Yann E. MORIN.
> > Also, notice spurious errors from ldconfig:
> >
> > /sbin/ldconfig
> > /sbin/ldconfig.real: Can't create temporary cache file /etc/ld.so.cache~: Permission denied
> > make[5]: [Makefile:162: install-shared-psx] Error 1 (ignored)
> >
> > (ldconfig is a wrapper around ldconfig.real, specific to debian and.or
> > ubuntu I guess)
>
> Right, but the absence/presence of the RPATH should normally not be
> affected by this, I believe.
Nope, nope.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] Analysis of build results for 2021-08-17
2021-08-18 6:57 [Buildroot] [autobuild.buildroot.net] Daily results for 2021-08-17 Thomas Petazzoni
2021-08-18 10:25 ` Thomas Petazzoni
@ 2021-08-18 21:44 ` Thomas Petazzoni
2021-08-18 22:24 ` Giulio Benetti
2021-08-19 9:27 ` Arnout Vandecappelle
1 sibling, 2 replies; 18+ messages in thread
From: Thomas Petazzoni @ 2021-08-18 21:44 UTC (permalink / raw)
To: buildroot, Matthew Weber, Fabrice Fontaine, Adam Duskett,
Herve Codina, Giulio Benetti, Bernd Kuhls, Gwenhael Goavec-Merou,
Arnout Vandecappelle, Eric Le Bihan
Hello,
Matt, Fabrice, Adam, Hervé, Giulio, Bernd, Gwenhael, Arnout, Eric, see
below! :-)
On Wed, 18 Aug 2021 06:57:22 -0000
Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> branch | OK | NOK | TIM | TOT |
> 2021.02.x | 34 | 7 | 0 | 41 |
> 2021.05.x | 35 | 7 | 0 | 42 |
> master | 186 | 30 | 5 | 221 |
We're doing really good on the master branch now. Let's see what we
have left!
> riscv64 | capnproto-0.8.0 | NOK | http://autobuild.buildroot.net/results/c28dd04c453827c58c078b0808739d780c87690d |
Some ucontext issue:
src/kj/async.c++:765:27: error: cannot convert 'ucontext_t*' to 'ucontext*'
I looked into it a bit, and asked on musl's IRC channel, see the
conversation at https://paste.ack.tf/fd7109, but I couldn't really come
to a conclusion. Essentially, they say that musl does not support
ucontext, which contradicts our:
config BR2_TOOLCHAIN_USES_MUSL
bool
[...]
select BR2_TOOLCHAIN_HAS_UCONTEXT
But we have a number of packages that do have a dependency on
BR2_TOOLCHAIN_HAS_UCONTEXT and that build with musl. So I'm rather
puzzled.
> arm | eigen-3.3.7 | NOK | http://autobuild.buildroot.net/results/8354da225d1e5e337aa7ea62a7e6524fb5f1135f |
-- Check for working Fortran compiler: /usr/bin/gfortran
-- Check for working Fortran compiler: /usr/bin/gfortran -- broken
We probably need to tell this package to not even check for a fortran
compiler. Matt, you are the maintainer of this package, could you have
a look?
> riscv32 | gdb-10.1 | NOK | http://autobuild.buildroot.net/results/21647e2a661dc198f6f6f37f3c767faa449cde65 | ORPH
> riscv64 | gdb-10.1 | NOK | http://autobuild.buildroot.net/results/21bb9fd1a2e4a9e43ec21ac0477406086bb5ef91 | ORPH
Fabrice recently submitted a patch on this, but I made some comments.
Fabrice, could you respin a new iteration?
> x86_64 | gobject-introspection-1.68.0 | NOK | http://autobuild.buildroot.net/results/b749049b0484f1e3d097b2d25d15082f52398f39 | ORPH
I guess this one is the X86 Core i7 issue, which Adam has been
discussing with us for quite some time. Adam, is this correct?
> mips | gobject-introspection-1.68.0 | NOK | http://autobuild.buildroot.net/results/e5a96a3c7bbdf999ca47e3da0e2067a6763714b3 | ORPH
qemu-mips: Unable to reserve 0x80000000 bytes of virtual address space at 0x1000 (Success) for use as guest address space (check yourvirtual memory ulimit setting, min_mmap_addr or reserve less using -R option)
Adam: does that ring a bell? On my side, I would have no problem adding
restriction on the set of architectures supported in
BR2_PACKAGE_GOBJECT_INTROSPECTION_ARCH_SUPPORTS.
> arm | harfbuzz-2.8.2 | NOK | http://autobuild.buildroot.net/results/e2dbf859ae5ea9408ac7bf1554c110b0477bb497 | ORPH
Fixed by 6454eacf1018ec9be9d4f833e7a8f0a21a47f167.
> xtensa | host-cairo-1.16.0 | NOK | http://autobuild.buildroot.net/results/00096bad2d9eee90c07761fc8c7f9eafe8782dac |
> mips64el | host-cairo-1.16.0 | NOK | http://autobuild.buildroot.net/results/c1d61387edf1f79522f7d9df82c90c9cd67bba2d |
cannot delete non-empty directory: share/gettext
could not make way for new symlink: share/gettext
Seems like a per-package issue. Hm, I think Fabrice you looked into
this. Hervé, any input?
> aarch64 | host-llvm | TIM | http://autobuild.buildroot.net/results/c97386a8a1092a3ee4735720cafad62eb6cd2721 |
This timeout doesn't happen very often:
http://autobuild.buildroot.net/?reason=host-llvm% It seems like a real
timeout, not too surprising from a massive package such as LLVM.
> s390x | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/38ccbf255a868e823d441f9e3dc6f1949edf3978 |
> powerpc | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/1d1708d0d6464271b4b0c4e992b58040f9cf8cca |
> arm | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/d5c8b9bcceb3317a07713190a0b2a918e44976c7 |
> nios2 | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/cd7d3f81de5d98bb4a5b519ee8edb8e1e05aa303 |
> microblazeel | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/f00eef7a67b3de664d4c5ef1e5328abfa96b274c |
> mips64el | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/e3d48d2f67314e8e533a2c6194829e27bb4c1fa8 |
As it's been failing for a very long time, I submitted a patch to drop
this package.
> m68k | libmodsecurity-3.0.5 | NOK | http://autobuild.buildroot.net/results/b92980a563fe7ee331e70f288ce041be0bf29d40 |
/tmp/ccix98g9.s: Assembler messages:
/tmp/ccix98g9.s: Fatal error: Tried to convert PC relative branch to absolute jump
Another toolchain issue... Adding Giulio in the loop.
> i686 | libvirt-7.4.0 | NOK | http://autobuild.buildroot.net/results/2349c55a4a42f08ca52700c60cda3065b0c4bd88 |
gettext issue. Fabrice, perhaps?
> aarch64 | mongodb | TIM | http://autobuild.buildroot.net/results/d5040c9ee89e401f897daecf58d823489d6ff52b |
> aarch64 | mongodb | TIM | http://autobuild.buildroot.net/results/5f5edc8a61827480f1a8b0c2c448976d446964c2 |
> aarch64 | mongodb | TIM | http://autobuild.buildroot.net/results/8e3fc4996d86be79b09ebf7e74bbc244a08b4670 |
> arm | mongodb | TIM | http://autobuild.buildroot.net/results/8f41dba464a725ca3dfae20cbbe7a387639dfc9e |
This timeout happens quite often, but apparently on AArch64 and ARM
builds, see http://autobuild.buildroot.net/?reason=mongodb
James, do you think you can try to manually build one of these
configurations, and see what happens?
> arc | mpv-0.33.1 | NOK | http://autobuild.buildroot.net/results/fb10eb81ddc77576c6e23519c26c6db774d6f8e5 |
You manually enabled the feature 'vaapi-drm', but the autodetection check failed.
> arm | mpv-0.33.1 | NOK | http://autobuild.buildroot.net/results/e5c15228f42a73f8c34b26630b2074c30e5f5966 |
You manually enabled the feature 'vaapi', but the autodetection check failed.
> mips64el | mpv-0.33.1 | NOK | http://autobuild.buildroot.net/results/5008324c586b70e71ea5fe3030f0355c87daa96f |
You manually enabled the feature 'vaapi-drm', but the autodetection check failed.
Bernd, or Fabrice, any idea?
> or1k | openal-1.21.1 | NOK | http://autobuild.buildroot.net/results/6a2809f8eefdeeaca8a4c61130a8d85511685cfc |
/data/buildroot-autobuilder/instance-0/output-1/per-package/openal/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: CMakeFiles/OpenAL.dir/al/filter.cpp.o: pc-relative relocation against dynamic symbol alFilteri
/data/buildroot-autobuilder/instance-0/output-1/per-package/openal/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: CMakeFiles/OpenAL.dir/al/filter.cpp.o: pc-relative relocation against dynamic symbol alGetFilteri
/data/buildroot-autobuilder/instance-0/output-1/per-package/openal/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
Toolchain issue. Giulio, an idea ?
> mipsel | openmpi-4.0.0 | NOK | http://autobuild.buildroot.net/results/2f96654c2238c115060aafc3cf10f71457c585f7 | ORPH
checking alignment of Fortran type(test_mpi_handle)... configure: error: Can not determine alignment of type(test_mpi_handle) when cross-compiling
Gwenhael, Arnout, you are the folks who looked at Fortran stuff :-)
> i586 | openvmtools-10.3.5-10430147 | NOK | http://autobuild.buildroot.net/results/eb3dfe679536b578a0f16762312a96ada7162095 |
/home/buildroot/autobuild/instance-3/output-1/build/openvmtools-10.3.5-10430147/lib/include/vm_assert.h:331:7: error: static assertion failed: "sizeof (unixTime->tv_sec) == 4"
331 | _Static_assert(e, #e); \
Another package not ready with 64-bit time_t it seems.
We clearly don't have the latest version of open-vm-tools, but it
hasn't been fixed upstream:
https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/lib/hgfs/hgfsUtil.c#L117
This issue is discussed at
https://github.com/vmware/open-vm-tools/issues/430. The
meta-openembedded layer has the patch
./meta-networking/recipes-support/open-vm-tools/open-vm-tools/0001-Make-HgfsConvertFromNtTimeNsec-aware-of-64-bit-time_.patch
to fix this.
Anyone volunteering to fix this?
> riscv32 | qt5base-5.15.2 | NOK | http://autobuild.buildroot.net/results/568f7fceebb06deb0755e8d3757c761608faeec7 |
thread/qfutex_p.h:116:30: error: '__NR_futex' was not declared in this scope; did you mean '_q_futex'?
116 | int result = syscall(__NR_futex, addr, op | FUTEX_PRIVATE_FLAG, val, val2, addr2, val3);
| ^~~~~~~~~~
| _q_futex
Need to explore why __NR_futex is not available on RISC-V 32-bit and
what we're supposed to use instead.
> mips64el | ripgrep-0.8.1 | NOK | http://autobuild.buildroot.net/results/e069c1a3433431b8055520a87f989b4eeefd7a4a |
> mips64el | ripgrep-0.8.1 | NOK | http://autobuild.buildroot.net/results/8bab232eb98b164df300581ae019254bde7c8ca3 |
linking mips:isa64r2 module with previous mips:isa64r6 modules
Aaah, ah, found something. I'll send a patch!
> or1k | unknown | NOK | http://autobuild.buildroot.net/results/92c086b0c5c2a298a82a6eb9c289dc53c58a5e5e |
Top-level parallel build, no idea what the issue is.
> arm | xvisor-0.3.0 | NOK | http://autobuild.buildroot.net/results/306e1a107abfad392f97e8d8d987d6e17ec80012 |
/tmp/instance-0/output-1/host/lib/gcc/arm-buildroot-linux-gnueabihf/11.1.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: /tmp/instance-0/output-1/build/xvisor-0.3.0/drivers/input/mouse/psmouse-base.c:783: undefined reference to `alps_detect'
Could someone have a look ?
> or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/f6d9c3b1e7be0e3c722f79bad7b89c7f1bd0f2f0 |
> or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/c6b4f37e30b7c6f803d32e6d9d0dec8e15e7ec30 |
Giulio ?
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Buildroot] Analysis of build results for 2021-08-17
2021-08-18 21:44 ` [Buildroot] Analysis of build " Thomas Petazzoni
@ 2021-08-18 22:24 ` Giulio Benetti
2021-08-18 22:26 ` Giulio Benetti
` (3 more replies)
2021-08-19 9:27 ` Arnout Vandecappelle
1 sibling, 4 replies; 18+ messages in thread
From: Giulio Benetti @ 2021-08-18 22:24 UTC (permalink / raw)
To: Thomas Petazzoni, buildroot, Matthew Weber, Fabrice Fontaine,
Adam Duskett, Herve Codina, Giulio Benetti, Bernd Kuhls,
Gwenhael Goavec-Merou, Arnout Vandecappelle, Eric Le Bihan
Hello Thomas,
On 8/18/21 11:44 PM, Thomas Petazzoni wrote:
> Hello,
>
> Matt, Fabrice, Adam, Hervé, Giulio, Bernd, Gwenhael, Arnout, Eric, see
> below! :-)
>
> On Wed, 18 Aug 2021 06:57:22 -0000
> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
>
>> branch | OK | NOK | TIM | TOT |
>> 2021.02.x | 34 | 7 | 0 | 41 |
>> 2021.05.x | 35 | 7 | 0 | 42 |
>> master | 186 | 30 | 5 | 221 |
>
> We're doing really good on the master branch now. Let's see what we
> have left!
>
[SNIP]
>> m68k | libmodsecurity-3.0.5 | NOK | http://autobuild.buildroot.net/results/b92980a563fe7ee331e70f288ce041be0bf29d40 |
>
> /tmp/ccix98g9.s: Assembler messages:
> /tmp/ccix98g9.s: Fatal error: Tried to convert PC relative branch to absolute jump
>
> Another toolchain issue... Adding Giulio in the loop.
>
I'm reproducing it now.
>> or1k | openal-1.21.1 | NOK | http://autobuild.buildroot.net/results/6a2809f8eefdeeaca8a4c61130a8d85511685cfc |
>
> /data/buildroot-autobuilder/instance-0/output-1/per-package/openal/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: CMakeFiles/OpenAL.dir/al/filter.cpp.o: pc-relative relocation against dynamic symbol alFilteri
> /data/buildroot-autobuilder/instance-0/output-1/per-package/openal/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: CMakeFiles/OpenAL.dir/al/filter.cpp.o: pc-relative relocation against dynamic symbol alGetFilteri
> /data/buildroot-autobuilder/instance-0/output-1/per-package/openal/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: final link failed: bad value
> collect2: error: ld returned 1 exit status
>
> Toolchain issue. Giulio, an idea ?
This waits for you to release new OpenRisc Bootlin toolchain. At
Buildroot level all OpenRisc patches we're covered(on gcc 11.1.0 too
from yesterday). So with that you should be able to create the new
Bootlin OpenRisc Toolchain that will also enable -mcmodel=large for
libgeos and protobuf, basically they will be both re-enabled for
OpenRisc :-)
>> i586 | openvmtools-10.3.5-10430147 | NOK | http://autobuild.buildroot.net/results/eb3dfe679536b578a0f16762312a96ada7162095 |
>
> /home/buildroot/autobuild/instance-3/output-1/build/openvmtools-10.3.5-10430147/lib/include/vm_assert.h:331:7: error: static assertion failed: "sizeof (unixTime->tv_sec) == 4"
> 331 | _Static_assert(e, #e); \
>
> Another package not ready with 64-bit time_t it seems.
Yep
> We clearly don't have the latest version of open-vm-tools, but it
> hasn't been fixed upstream:
> https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/lib/hgfs/hgfsUtil.c#L117
>
> This issue is discussed at
> https://github.com/vmware/open-vm-tools/issues/430. The
> meta-openembedded layer has the patch
> ./meta-networking/recipes-support/open-vm-tools/open-vm-tools/0001-Make-HgfsConvertFromNtTimeNsec-aware-of-64-bit-time_.patch
> to fix this.
>
> Anyone volunteering to fix this?
>
I can do that. Only that patch URL is broken but there is a PR for that
to take the patch:
https://github.com/vmware/open-vm-tools/pull/387/commits/3f0580f2546de8be7acf1bc78a55a257bc638ebe
I can deal with it. Also we don't have a maintainer for it, maybe I can
be the one.
>> or1k | unknown | NOK | http://autobuild.buildroot.net/results/92c086b0c5c2a298a82a6eb9c289dc53c58a5e5e |
>
> Top-level parallel build, no idea what the issue is.
Can somebody point me some idea on how to approach Top-level parallel
build debugging? I also have some udisks package failure due to that.
I mean, now what I do is ./br_reproduce_build SHA1, then I CTRL-C and:
# cd SHA1
# cd output
# make package-that-fails
But with Top-level I have more output-x, how can I reissue the command
and are there any trick to debug it?
>> or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/f6d9c3b1e7be0e3c722f79bad7b89c7f1bd0f2f0 |
>> or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/c6b4f37e30b7c6f803d32e6d9d0dec8e15e7ec30 |
>
> Giulio ?
Here is the same that goes for openal, external Bootlin OpenRisc
Toolchain updated must solve it.
Best regards
--
Giulio Benetti
Benetti Engineering sas
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Buildroot] Analysis of build results for 2021-08-17
2021-08-18 22:24 ` Giulio Benetti
@ 2021-08-18 22:26 ` Giulio Benetti
2021-08-19 0:01 ` Giulio Benetti
` (2 subsequent siblings)
3 siblings, 0 replies; 18+ messages in thread
From: Giulio Benetti @ 2021-08-18 22:26 UTC (permalink / raw)
To: Thomas Petazzoni, buildroot, Matthew Weber, Fabrice Fontaine,
Adam Duskett, Herve Codina, Giulio Benetti, Bernd Kuhls,
Gwenhael Goavec-Merou, Arnout Vandecappelle, Eric Le Bihan
Pardon,
On 8/19/21 12:24 AM, Giulio Benetti wrote:
> Hello Thomas,
>
> On 8/18/21 11:44 PM, Thomas Petazzoni wrote:
>> Hello,
>>
>> Matt, Fabrice, Adam, Hervé, Giulio, Bernd, Gwenhael, Arnout, Eric, see
>> below! :-)
>>
>> On Wed, 18 Aug 2021 06:57:22 -0000
>> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
>>
>>> branch | OK | NOK | TIM | TOT |
>>> 2021.02.x | 34 | 7 | 0 | 41 |
>>> 2021.05.x | 35 | 7 | 0 | 42 |
>>> master | 186 | 30 | 5 | 221 |
>>
>> We're doing really good on the master branch now. Let's see what we
>> have left!
>>
>
> [SNIP]
>
>>> m68k | libmodsecurity-3.0.5 | NOK | http://autobuild.buildroot.net/results/b92980a563fe7ee331e70f288ce041be0bf29d40 |
>>
>> /tmp/ccix98g9.s: Assembler messages:
>> /tmp/ccix98g9.s: Fatal error: Tried to convert PC relative branch to absolute jump
>>
>> Another toolchain issue... Adding Giulio in the loop.
>>
>
> I'm reproducing it now.
>
>>> or1k | openal-1.21.1 | NOK | http://autobuild.buildroot.net/results/6a2809f8eefdeeaca8a4c61130a8d85511685cfc |
>>
>> /data/buildroot-autobuilder/instance-0/output-1/per-package/openal/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: CMakeFiles/OpenAL.dir/al/filter.cpp.o: pc-relative relocation against dynamic symbol alFilteri
>> /data/buildroot-autobuilder/instance-0/output-1/per-package/openal/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: CMakeFiles/OpenAL.dir/al/filter.cpp.o: pc-relative relocation against dynamic symbol alGetFilteri
>> /data/buildroot-autobuilder/instance-0/output-1/per-package/openal/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: final link failed: bad value
>> collect2: error: ld returned 1 exit status
>>
>> Toolchain issue. Giulio, an idea ?
>
> This waits for you to release new OpenRisc Bootlin toolchain. At
> Buildroot level all OpenRisc patches we're covered(on gcc 11.1.0 too
> from yesterday). So with that you should be able to create the new
> Bootlin OpenRisc Toolchain that will also enable -mcmodel=large for
> libgeos and protobuf, basically they will be both re-enabled for
> OpenRisc :-)
>
>>> i586 | openvmtools-10.3.5-10430147 | NOK | http://autobuild.buildroot.net/results/eb3dfe679536b578a0f16762312a96ada7162095 |
>>
>> /home/buildroot/autobuild/instance-3/output-1/build/openvmtools-10.3.5-10430147/lib/include/vm_assert.h:331:7: error: static assertion failed: "sizeof (unixTime->tv_sec) == 4"
>> 331 | _Static_assert(e, #e); \
>>
>> Another package not ready with 64-bit time_t it seems.
>
> Yep
>
>> We clearly don't have the latest version of open-vm-tools, but it
>> hasn't been fixed upstream:
>> https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/lib/hgfs/hgfsUtil.c#L117
>>
>> This issue is discussed at
>> https://github.com/vmware/open-vm-tools/issues/430. The
>> meta-openembedded layer has the patch
>> ./meta-networking/recipes-support/open-vm-tools/open-vm-tools/0001-Make-HgfsConvertFromNtTimeNsec-aware-of-64-bit-time_.patch
>> to fix this.
>>
>> Anyone volunteering to fix this?
>>
>
> I can do that. Only that patch URL is broken but there is a PR for that
> to take the patch:
> https://github.com/vmware/open-vm-tools/pull/387/commits/3f0580f2546de8be7acf1bc78a55a257bc638ebe
> I can deal with it. Also we don't have a maintainer for it, maybe I can
> be the one.
We already have 1 maintainer for this Karoly Kasza(don't know if
active), but I can add myself anyway.
Best regards
--
Giulio Benetti
Benetti Engineering sas
>>> or1k | unknown | NOK | http://autobuild.buildroot.net/results/92c086b0c5c2a298a82a6eb9c289dc53c58a5e5e |
>>
>> Top-level parallel build, no idea what the issue is.
>
> Can somebody point me some idea on how to approach Top-level parallel
> build debugging? I also have some udisks package failure due to that.
> I mean, now what I do is ./br_reproduce_build SHA1, then I CTRL-C and:
> # cd SHA1
> # cd output
> # make package-that-fails
>
> But with Top-level I have more output-x, how can I reissue the command
> and are there any trick to debug it?
>
>>> or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/f6d9c3b1e7be0e3c722f79bad7b89c7f1bd0f2f0 |
>>> or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/c6b4f37e30b7c6f803d32e6d9d0dec8e15e7ec30 |
>>
>> Giulio ?
>
> Here is the same that goes for openal, external Bootlin OpenRisc
> Toolchain updated must solve it.
>
> Best regards
>
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Buildroot] Analysis of build results for 2021-08-17
2021-08-18 22:24 ` Giulio Benetti
2021-08-18 22:26 ` Giulio Benetti
@ 2021-08-19 0:01 ` Giulio Benetti
2021-08-19 13:28 ` Thomas Petazzoni
2021-08-21 23:08 ` Giulio Benetti
3 siblings, 0 replies; 18+ messages in thread
From: Giulio Benetti @ 2021-08-19 0:01 UTC (permalink / raw)
To: Thomas Petazzoni, buildroot, Matthew Weber, Fabrice Fontaine,
Adam Duskett, Herve Codina, Giulio Benetti, Bernd Kuhls,
Gwenhael Goavec-Merou, Arnout Vandecappelle, Eric Le Bihan
On 8/19/21 12:24 AM, Giulio Benetti wrote:
> Hello Thomas,
>
> On 8/18/21 11:44 PM, Thomas Petazzoni wrote:
>> Hello,
>>
>> Matt, Fabrice, Adam, Hervé, Giulio, Bernd, Gwenhael, Arnout, Eric, see
>> below! :-)
>>
>> On Wed, 18 Aug 2021 06:57:22 -0000
>> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
>>
>>> branch | OK | NOK | TIM | TOT |
>>> 2021.02.x | 34 | 7 | 0 | 41 |
>>> 2021.05.x | 35 | 7 | 0 | 42 |
>>> master | 186 | 30 | 5 | 221 |
>>
>> We're doing really good on the master branch now. Let's see what we
>> have left!
>>
>
> [SNIP]
>
>>> m68k | libmodsecurity-3.0.5 | NOK | http://autobuild.buildroot.net/results/b92980a563fe7ee331e70f288ce041be0bf29d40 |
>>
>> /tmp/ccix98g9.s: Assembler messages:
>> /tmp/ccix98g9.s: Fatal error: Tried to convert PC relative branch to absolute jump
>>
>> Another toolchain issue... Adding Giulio in the loop.
>>
>
> I'm reproducing it now.
>
>>> or1k | openal-1.21.1 | NOK | http://autobuild.buildroot.net/results/6a2809f8eefdeeaca8a4c61130a8d85511685cfc |
>>
>> /data/buildroot-autobuilder/instance-0/output-1/per-package/openal/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: CMakeFiles/OpenAL.dir/al/filter.cpp.o: pc-relative relocation against dynamic symbol alFilteri
>> /data/buildroot-autobuilder/instance-0/output-1/per-package/openal/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: CMakeFiles/OpenAL.dir/al/filter.cpp.o: pc-relative relocation against dynamic symbol alGetFilteri
>> /data/buildroot-autobuilder/instance-0/output-1/per-package/openal/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: final link failed: bad value
>> collect2: error: ld returned 1 exit status
>>
>> Toolchain issue. Giulio, an idea ?
>
> This waits for you to release new OpenRisc Bootlin toolchain. At
> Buildroot level all OpenRisc patches we're covered(on gcc 11.1.0 too
> from yesterday). So with that you should be able to create the new
> Bootlin OpenRisc Toolchain that will also enable -mcmodel=large for
> libgeos and protobuf, basically they will be both re-enabled for
> OpenRisc :-)
>
>>> i586 | openvmtools-10.3.5-10430147 | NOK | http://autobuild.buildroot.net/results/eb3dfe679536b578a0f16762312a96ada7162095 |
>>
>> /home/buildroot/autobuild/instance-3/output-1/build/openvmtools-10.3.5-10430147/lib/include/vm_assert.h:331:7: error: static assertion failed: "sizeof (unixTime->tv_sec) == 4"
>> 331 | _Static_assert(e, #e); \
>>
>> Another package not ready with 64-bit time_t it seems.
>
> Yep
>
>> We clearly don't have the latest version of open-vm-tools, but it
>> hasn't been fixed upstream:
>> https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/lib/hgfs/hgfsUtil.c#L117
>>
>> This issue is discussed at
>> https://github.com/vmware/open-vm-tools/issues/430. The
>> meta-openembedded layer has the patch
>> ./meta-networking/recipes-support/open-vm-tools/open-vm-tools/0001-Make-HgfsConvertFromNtTimeNsec-aware-of-64-bit-time_.patch
>> to fix this.
>>
>> Anyone volunteering to fix this?
>>
>
> I can do that. Only that patch URL is broken but there is a PR for that
> to take the patch:
> https://github.com/vmware/open-vm-tools/pull/387/commits/3f0580f2546de8be7acf1bc78a55a257bc638ebe
> I can deal with it.
This is fixed by:
https://patchwork.ozlabs.org/project/buildroot/patch/20210818235907.906265-1-giulio.benetti@benettiengineering.com/
--
Giulio Benetti
Benetti Engineering sas
> Also we don't have a maintainer for it, maybe I can
> be the one.
>
>>> or1k | unknown | NOK | http://autobuild.buildroot.net/results/92c086b0c5c2a298a82a6eb9c289dc53c58a5e5e |
>>
>> Top-level parallel build, no idea what the issue is.
>
> Can somebody point me some idea on how to approach Top-level parallel
> build debugging? I also have some udisks package failure due to that.
> I mean, now what I do is ./br_reproduce_build SHA1, then I CTRL-C and:
> # cd SHA1
> # cd output
> # make package-that-fails
>
> But with Top-level I have more output-x, how can I reissue the command
> and are there any trick to debug it?
>
>>> or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/f6d9c3b1e7be0e3c722f79bad7b89c7f1bd0f2f0 |
>>> or1k | zeromq-4.3.4 | NOK | http://autobuild.buildroot.net/results/c6b4f37e30b7c6f803d32e6d9d0dec8e15e7ec30 |
>>
>> Giulio ?
>
> Here is the same that goes for openal, external Bootlin OpenRisc
> Toolchain updated must solve it.
>
> Best regards
>
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Buildroot] Analysis of build results for 2021-08-17
2021-08-18 21:44 ` [Buildroot] Analysis of build " Thomas Petazzoni
2021-08-18 22:24 ` Giulio Benetti
@ 2021-08-19 9:27 ` Arnout Vandecappelle
2021-08-19 13:24 ` Thomas Petazzoni
1 sibling, 1 reply; 18+ messages in thread
From: Arnout Vandecappelle @ 2021-08-19 9:27 UTC (permalink / raw)
To: Thomas Petazzoni, buildroot, Matthew Weber, Fabrice Fontaine,
Adam Duskett, Herve Codina, Giulio Benetti, Bernd Kuhls,
Gwenhael Goavec-Merou, Eric Le Bihan
On 18/08/2021 23:44, Thomas Petazzoni wrote:
[snip]
>> xtensa | host-cairo-1.16.0 | NOK | http://autobuild.buildroot.net/results/00096bad2d9eee90c07761fc8c7f9eafe8782dac |
>> mips64el | host-cairo-1.16.0 | NOK | http://autobuild.buildroot.net/results/c1d61387edf1f79522f7d9df82c90c9cd67bba2d |
>
> cannot delete non-empty directory: share/gettext
> could not make way for new symlink: share/gettext
>
> Seems like a per-package issue. Hm, I think Fabrice you looked into
> this. Hervé, any input?
Fixed by 93351fa0b3b8b6dd10faa9a15a7a173b92cb40a0. It's not obvious since the
fix is actually in fontconfig, not cairo.
[snip]
>> mipsel | openmpi-4.0.0 | NOK | http://autobuild.buildroot.net/results/2f96654c2238c115060aafc3cf10f71457c585f7 | ORPH
>
> checking alignment of Fortran type(test_mpi_handle)... configure: error: Can not determine alignment of type(test_mpi_handle) when cross-compiling
>
> Gwenhael, Arnout, you are the folks who looked at Fortran stuff :-)
Hehe. It's not really fortran stuff, it's just cross-compilation. Probably
needs an ac_cv setting, possibly a patch to enable it.
[snip]
>> riscv32 | qt5base-5.15.2 | NOK | http://autobuild.buildroot.net/results/568f7fceebb06deb0755e8d3757c761608faeec7 |
>
> thread/qfutex_p.h:116:30: error: '__NR_futex' was not declared in this scope; did you mean '_q_futex'?
> 116 | int result = syscall(__NR_futex, addr, op | FUTEX_PRIVATE_FLAG, val, val2, addr2, val3);
> | ^~~~~~~~~~
> | _q_futex
>
> Need to explore why __NR_futex is not available on RISC-V 32-bit and
> what we're supposed to use instead.
__NR_futex64, but it's not as simple as that because you also need to make sure
64-bit time_t is used as an argument.
Regards,
Arnout
[snip]
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Buildroot] Analysis of build results for 2021-08-17
2021-08-19 9:27 ` Arnout Vandecappelle
@ 2021-08-19 13:24 ` Thomas Petazzoni
0 siblings, 0 replies; 18+ messages in thread
From: Thomas Petazzoni @ 2021-08-19 13:24 UTC (permalink / raw)
To: Arnout Vandecappelle
Cc: Bernd Kuhls, Eric Le Bihan, Herve Codina, Matthew Weber,
Gwenhael Goavec-Merou, Fabrice Fontaine, buildroot,
Giulio Benetti, Adam Duskett
Hello Arnout,
On Thu, 19 Aug 2021 11:27:27 +0200
Arnout Vandecappelle <arnout@mind.be> wrote:
> Fixed by 93351fa0b3b8b6dd10faa9a15a7a173b92cb40a0. It's not obvious since the
> fix is actually in fontconfig, not cairo.
Ah good.
> >> mipsel | openmpi-4.0.0 | NOK | http://autobuild.buildroot.net/results/2f96654c2238c115060aafc3cf10f71457c585f7 | ORPH
> >
> > checking alignment of Fortran type(test_mpi_handle)... configure: error: Can not determine alignment of type(test_mpi_handle) when cross-compiling
> >
> > Gwenhael, Arnout, you are the folks who looked at Fortran stuff :-)
>
> Hehe. It's not really fortran stuff, it's just cross-compilation. Probably
> needs an ac_cv setting, possibly a patch to enable it.
This stuff is built with CMake, so it's probably not an ac_cv_ variable.
> >> riscv32 | qt5base-5.15.2 | NOK | http://autobuild.buildroot.net/results/568f7fceebb06deb0755e8d3757c761608faeec7 |
> >
> > thread/qfutex_p.h:116:30: error: '__NR_futex' was not declared in this scope; did you mean '_q_futex'?
> > 116 | int result = syscall(__NR_futex, addr, op | FUTEX_PRIVATE_FLAG, val, val2, addr2, val3);
> > | ^~~~~~~~~~
> > | _q_futex
> >
> > Need to explore why __NR_futex is not available on RISC-V 32-bit and
> > what we're supposed to use instead.
>
> __NR_futex64, but it's not as simple as that because you also need to make sure
> 64-bit time_t is used as an argument.
Should we disable Qt5 on RISC-V 32-bit ?
Best regards,
Thomas Petazzoni
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Buildroot] Analysis of build results for 2021-08-17
2021-08-18 22:24 ` Giulio Benetti
2021-08-18 22:26 ` Giulio Benetti
2021-08-19 0:01 ` Giulio Benetti
@ 2021-08-19 13:28 ` Thomas Petazzoni
2021-08-20 14:26 ` Giulio Benetti
2021-08-21 23:08 ` Giulio Benetti
3 siblings, 1 reply; 18+ messages in thread
From: Thomas Petazzoni @ 2021-08-19 13:28 UTC (permalink / raw)
To: Giulio Benetti
Cc: Bernd Kuhls, Eric Le Bihan, Herve Codina, Matthew Weber,
Gwenhael Goavec-Merou, Fabrice Fontaine, buildroot,
Giulio Benetti, Adam Duskett
Hello,
On Thu, 19 Aug 2021 00:24:06 +0200
Giulio Benetti <giulio.benetti@benettiengineering.com> wrote:
> This waits for you to release new OpenRisc Bootlin toolchain. At
> Buildroot level all OpenRisc patches we're covered(on gcc 11.1.0 too
> from yesterday). So with that you should be able to create the new
> Bootlin OpenRisc Toolchain that will also enable -mcmodel=large for
> libgeos and protobuf, basically they will be both re-enabled for
> OpenRisc :-)
ACK, thanks for confirming.
> >> or1k | unknown | NOK | http://autobuild.buildroot.net/results/92c086b0c5c2a298a82a6eb9c289dc53c58a5e5e |
> >
> > Top-level parallel build, no idea what the issue is.
>
> Can somebody point me some idea on how to approach Top-level parallel
> build debugging? I also have some udisks package failure due to that.
> I mean, now what I do is ./br_reproduce_build SHA1, then I CTRL-C and:
> # cd SHA1
> # cd output
> # make package-that-fails
>
> But with Top-level I have more output-x, how can I reissue the command
> and are there any trick to debug it?
I would go in two steps:
(1) First see if you can reproduce without top-level parallel build,
i.e you keep BR2_PER_PACKAGE_DIRECTORIES=y, but you do the build with
"make". I am pretty sure that 95% of the issues will also be
reproducible this way, and are more related to per-package
directories than top-level parallel build.
(2) If that doesn't allow to reproduce the issue, then you'll want to
rebuild with "make -jX". However, here it would mean the issue is
really with parallel build, so it's not because one build succeeds
that another build won't fail: we might have race conditions that only
rarely happen, just like the parallel build of individual packages. Of
course, in principle with per-package directories, we are not supposed
to have this kind of race conditions, but who knows what unforeseen
issues still exist?
Best regards,
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Buildroot] Analysis of build results for 2021-08-17
2021-08-19 13:28 ` Thomas Petazzoni
@ 2021-08-20 14:26 ` Giulio Benetti
2021-08-20 22:00 ` Giulio Benetti
0 siblings, 1 reply; 18+ messages in thread
From: Giulio Benetti @ 2021-08-20 14:26 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Bernd Kuhls, Eric Le Bihan, Herve Codina, Matthew Weber,
Gwenhael Goavec-Merou, Fabrice Fontaine, buildroot,
Giulio Benetti, Adam Duskett
Hello Thomas,
On 8/19/21 3:28 PM, Thomas Petazzoni wrote:
>>>> or1k | unknown | NOK | http://autobuild.buildroot.net/results/92c086b0c5c2a298a82a6eb9c289dc53c58a5e5e |
>>>
>>> Top-level parallel build, no idea what the issue is.
This doesn't show up on my pc, but instead it ends up with openal
package build failure due to Bootlin toolchain not updated.
Basically I can't reach lapack to build because it fails early on
openal. And most of all it doesn't build with parallel top-level simply
using br-reproduce-build found here(I only have output/ instead of
output-1/ and output-2):
https://git.buildroot.net/buildroot-test/plain/utils/br-reproduce-build
I remember that other build with top parallel but not this. Can somebody
double check and tell me if it build with top parallel?
Also because on Autobuilder it shows output-1/
Thanks in advance!
--
Giulio Benetti
Benetti Engineering sas
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Buildroot] Analysis of build results for 2021-08-17
2021-08-20 14:26 ` Giulio Benetti
@ 2021-08-20 22:00 ` Giulio Benetti
0 siblings, 0 replies; 18+ messages in thread
From: Giulio Benetti @ 2021-08-20 22:00 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Bernd Kuhls, Herve Codina, Matthew Weber, Gwenhael Goavec-Merou,
Yann E. MORIN, Giulio Benetti, buildroot, Fabrice Fontaine,
Adam Duskett
Hello Thomas,
+Cc Yann,
On 8/20/21 4:26 PM, Giulio Benetti wrote:
> Hello Thomas,
>
> On 8/19/21 3:28 PM, Thomas Petazzoni wrote:
>>>>> or1k | unknown | NOK | http://autobuild.buildroot.net/results/92c086b0c5c2a298a82a6eb9c289dc53c58a5e5e |
>>>>
>>>> Top-level parallel build, no idea what the issue is.
>
> This doesn't show up on my pc, but instead it ends up with openal
> package build failure due to Bootlin toolchain not updated.
>
> Basically I can't reach lapack to build because it fails early on
> openal. And most of all it doesn't build with parallel top-level simply
> using br-reproduce-build found here(I only have output/ instead of
> output-1/ and output-2):
> https://git.buildroot.net/buildroot-test/plain/utils/br-reproduce-build
>
> I remember that other build with top parallel but not this. Can somebody
> double check and tell me if it build with top parallel?
> Also because on Autobuilder it shows output-1/
TLPB misleaded me. And I had an old buildroot-test on autobuilder(the
one build failure is happening) that didn't create output-1/ but output/
only.
But the problem is that while openal package build fails(due to external
Bootlin OpenRisc toolchain), TLPB goes on and builds LAPACK correctly.
I've checked with Yann and that's that way. So this 'unknown' is
actually openal that will be fixed once Bootlin toolchain will be updated.
Best regards
--
Giulio Benetti
Benetti Engineering sas
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Buildroot] Analysis of build results for 2021-08-17
2021-08-18 22:24 ` Giulio Benetti
` (2 preceding siblings ...)
2021-08-19 13:28 ` Thomas Petazzoni
@ 2021-08-21 23:08 ` Giulio Benetti
3 siblings, 0 replies; 18+ messages in thread
From: Giulio Benetti @ 2021-08-21 23:08 UTC (permalink / raw)
To: Thomas Petazzoni, buildroot, Matthew Weber, Fabrice Fontaine,
Adam Duskett, Herve Codina, Giulio Benetti, Bernd Kuhls,
Gwenhael Goavec-Merou, Arnout Vandecappelle, Eric Le Bihan
Hello Thomas,
On 8/19/21 12:24 AM, Giulio Benetti wrote:
>>> m68k | libmodsecurity-3.0.5 | NOK | http://autobuild.buildroot.net/results/b92980a563fe7ee331e70f288ce041be0bf29d40 |
>>
>> /tmp/ccix98g9.s: Assembler messages:
>> /tmp/ccix98g9.s: Fatal error: Tried to convert PC relative branch to absolute jump
>>
>> Another toolchain issue... Adding Giulio in the loop.
>>
>
> I'm reproducing it now.
>
This ^^^ is fixed by this patch:
https://patchwork.ozlabs.org/project/buildroot/patch/20210821230613.470903-1-giulio.benetti@benettiengineering.com/
Best regards
--
Giulio Benetti
Benetti Engineering sas
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Buildroot] [autobuild.buildroot.net] Daily results for 2021-08-17
2021-08-18 21:04 ` Yann E. MORIN
@ 2021-08-23 20:55 ` Arnout Vandecappelle
2021-08-23 22:06 ` Thomas Petazzoni
0 siblings, 1 reply; 18+ messages in thread
From: Arnout Vandecappelle @ 2021-08-23 20:55 UTC (permalink / raw)
To: Yann E. MORIN, Thomas Petazzoni; +Cc: buildroot
On 18/08/2021 23:04, Yann E. MORIN wrote:
> Thomas, All,
>
> On 2021-08-18 22:18 +0200, Thomas Petazzoni spake thusly:
>> On Wed, 18 Aug 2021 13:05:58 +0200
>> "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
>>> Not sure the exact reason, but notice that the failures occur at install
>>> time, not build time.
>> I did try with "make host-libcap", which includes the installation
>> step, and I even tried to do a full build of one of the failing
>> defconfigs. The build failed, but much much later, on a completely
>> unrelated package. And manually checking the RPATH of the host-libcap
>> binaries: they are correct.
>
> Here too.
Here too. I do notice a big difference however: in my local build, there's no
rebuild of the executables at installation time.
[snip]
> So, the first properly gets our LDFLAGS, the second, not. Pasing
> TARGET_CONFIGURE_OPTS at install time would solve^whide the issue,
> though.
>
> But OK, what are the dependencies of cap_magic.o?
>
> cap_magic.o: execable.h execable.c loader.txt
>
> execable.h and .c are not generated, so they are terminal dependencies.
>
> loader.txt is generated. And it is generated twice (still form the same
> build):
>
> make[3]: Entering directory '/data/buildroot-autobuilder/instance-0/output-1/build/host-libcap-2.52/libcap'
> gcc -o empty empty.c
> objcopy --dump-section .interp=/dev/stdout empty > loader.txt
> [...]
> make[3]: Leaving directory '/data/buildroot-autobuilder/instance-0/output-1/build/host-libcap-2.52/libcap'
> /usr/bin/make libpsx.so
> make[3]: Entering directory '/data/buildroot-autobuilder/instance-0/output-1/build/host-libcap-2.52/libcap'
> objcopy --dump-section .interp=/dev/stdout empty > loader.txt
> [...]
In my local build, it is *not* generated twice. Note that in (at least one of)
the failing build(s), it is in fact generated 4 times: twice at build time and
twice at install time.
>
> Wha?
>
> So, it believes loader.txt is out of date wrt a file named 'empty'
> (which is generated from a trivial C file empty.c)
Note that 'empty' is not regenerated, only 'loader' is...
> So, becasue loader.txt is re-generated a second time, some files are
> re-built at install time. Which explains why we get an issue.
>
> But then, why is it out of date, at all? I really got stuck there...
I have a theory, but it's a bit far out... We basically have this:
gcc -o empty empty.c
objcopy --dump-section .interp=/dev/stdout empty > loader.txt
The timestamp of 'empty' is going to be near the end of the gcc run. The
timestamp of 'loader.txt', on the other hand, is going to be all the way at the
beginning of the shell run. So, if the filesystem doesn't have nanosecond
precision, it's possible that 'empty' and 'loader.txt' have the same timestamp.
It's not a good theory, though, because make shouldn't consider 'loader.txt'
older than 'empty' if they have exactly the same timestamp.
Ooh, I just discovered something nasty! Apparently, objcopy updates the
modification time of its input file...
$ touch empty; ls -l --full-time empty loader.txt; make SHARED=yes loader.txt;
ls -l --full-time empty loader.txt
-rwxr-xr-x 1 arnout arnout 24K 2021-08-23 22:53:27.450172624 +0200 empty*
-rw-r--r-- 1 arnout arnout 28 2021-08-23 22:52:57.949935937 +0200 loader.txt
objcopy --dump-section .interp=/dev/stdout empty > loader.txt
-rwxr-xr-x 1 arnout arnout 24K 2021-08-23 22:53:27.563173530 +0200 empty*
-rw-r--r-- 1 arnout arnout 28 2021-08-23 22:53:27.563173530 +0200 loader.txt
I guess this way there is some chance that loader.txt gets a modification time
just before the updated mtime of empty...
So the solution would be to touch loader.txt just after creating it. We could
patch it like that, give it a go in the autobuilders, then send the patch upstream?
Regards,
Arnout
> Could it be that this is a parallel build issue? I doubt it, though...
>
> I'm out of clues now, so I'll let a godd night's sleep try to solve
> this....
>
> Regards,
> Yann E. MORIN.
>
>>> Also, notice spurious errors from ldconfig:
>>>
>>> /sbin/ldconfig
>>> /sbin/ldconfig.real: Can't create temporary cache file /etc/ld.so.cache~: Permission denied
>>> make[5]: [Makefile:162: install-shared-psx] Error 1 (ignored)
>>>
>>> (ldconfig is a wrapper around ldconfig.real, specific to debian and.or
>>> ubuntu I guess)
>>
>> Right, but the absence/presence of the RPATH should normally not be
>> affected by this, I believe.
>
> Nope, nope.
>
> Regards,
> Yann E. MORIN.
>
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Buildroot] [autobuild.buildroot.net] Daily results for 2021-08-17
2021-08-23 20:55 ` Arnout Vandecappelle
@ 2021-08-23 22:06 ` Thomas Petazzoni
2021-08-23 22:16 ` Arnout Vandecappelle
0 siblings, 1 reply; 18+ messages in thread
From: Thomas Petazzoni @ 2021-08-23 22:06 UTC (permalink / raw)
To: Arnout Vandecappelle; +Cc: Yann E. MORIN, buildroot
Hello,
On Mon, 23 Aug 2021 22:55:30 +0200
Arnout Vandecappelle <arnout@mind.be> wrote:
> I have a theory, but it's a bit far out... We basically have this:
>
> gcc -o empty empty.c
> objcopy --dump-section .interp=/dev/stdout empty > loader.txt
>
> The timestamp of 'empty' is going to be near the end of the gcc run. The
> timestamp of 'loader.txt', on the other hand, is going to be all the way at the
> beginning of the shell run. So, if the filesystem doesn't have nanosecond
> precision, it's possible that 'empty' and 'loader.txt' have the same timestamp.
>
> It's not a good theory, though, because make shouldn't consider 'loader.txt'
> older than 'empty' if they have exactly the same timestamp.
>
>
>
> Ooh, I just discovered something nasty! Apparently, objcopy updates the
> modification time of its input file...
>
> $ touch empty; ls -l --full-time empty loader.txt; make SHARED=yes loader.txt;
> ls -l --full-time empty loader.txt
> -rwxr-xr-x 1 arnout arnout 24K 2021-08-23 22:53:27.450172624 +0200 empty*
> -rw-r--r-- 1 arnout arnout 28 2021-08-23 22:52:57.949935937 +0200 loader.txt
> objcopy --dump-section .interp=/dev/stdout empty > loader.txt
> -rwxr-xr-x 1 arnout arnout 24K 2021-08-23 22:53:27.563173530 +0200 empty*
> -rw-r--r-- 1 arnout arnout 28 2021-08-23 22:53:27.563173530 +0200 loader.txt
>
> I guess this way there is some chance that loader.txt gets a modification time
> just before the updated mtime of empty...
>
> So the solution would be to touch loader.txt just after creating it. We could
> patch it like that, give it a go in the autobuilders, then send the patch upstream?
Wow, great investigation! Really odd that objcopy updates the mtime of
its input file, though.
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Buildroot] [autobuild.buildroot.net] Daily results for 2021-08-17
2021-08-23 22:06 ` Thomas Petazzoni
@ 2021-08-23 22:16 ` Arnout Vandecappelle
0 siblings, 0 replies; 18+ messages in thread
From: Arnout Vandecappelle @ 2021-08-23 22:16 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: Yann E. MORIN, buildroot
On 24/08/2021 00:06, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 23 Aug 2021 22:55:30 +0200
> Arnout Vandecappelle <arnout@mind.be> wrote:
>
>> I have a theory, but it's a bit far out... We basically have this:
>>
>> gcc -o empty empty.c
>> objcopy --dump-section .interp=/dev/stdout empty > loader.txt
>>
>> The timestamp of 'empty' is going to be near the end of the gcc run. The
>> timestamp of 'loader.txt', on the other hand, is going to be all the way at the
>> beginning of the shell run. So, if the filesystem doesn't have nanosecond
>> precision, it's possible that 'empty' and 'loader.txt' have the same timestamp.
>>
>> It's not a good theory, though, because make shouldn't consider 'loader.txt'
>> older than 'empty' if they have exactly the same timestamp.
>>
>>
>>
>> Ooh, I just discovered something nasty! Apparently, objcopy updates the
>> modification time of its input file...
>>
>> $ touch empty; ls -l --full-time empty loader.txt; make SHARED=yes loader.txt;
>> ls -l --full-time empty loader.txt
>> -rwxr-xr-x 1 arnout arnout 24K 2021-08-23 22:53:27.450172624 +0200 empty*
>> -rw-r--r-- 1 arnout arnout 28 2021-08-23 22:52:57.949935937 +0200 loader.txt
>> objcopy --dump-section .interp=/dev/stdout empty > loader.txt
>> -rwxr-xr-x 1 arnout arnout 24K 2021-08-23 22:53:27.563173530 +0200 empty*
>> -rw-r--r-- 1 arnout arnout 28 2021-08-23 22:53:27.563173530 +0200 loader.txt
>>
>> I guess this way there is some chance that loader.txt gets a modification time
>> just before the updated mtime of empty...
>>
>> So the solution would be to touch loader.txt just after creating it. We could
>> patch it like that, give it a go in the autobuilders, then send the patch upstream?
>
> Wow, great investigation! Really odd that objcopy updates the mtime of
> its input file, though.
The man page says:
infile
outfile
The input and output files, respectively. If you do not specify
outfile, objcopy creates a temporary file and destructively renames the result
with the name of infile.
strace shows that that is exactly what it does.
With the following command, it no longer overwrites the input file:
objcopy --dump-section .interp=loader.txt empty /dev/null
I'll spin up a patch.
Regards,
Arnout
>
> Thomas
>
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2021-08-23 22:16 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-18 6:57 [Buildroot] [autobuild.buildroot.net] Daily results for 2021-08-17 Thomas Petazzoni
2021-08-18 10:25 ` Thomas Petazzoni
2021-08-18 11:05 ` Yann E. MORIN
2021-08-18 20:18 ` Thomas Petazzoni
2021-08-18 21:04 ` Yann E. MORIN
2021-08-23 20:55 ` Arnout Vandecappelle
2021-08-23 22:06 ` Thomas Petazzoni
2021-08-23 22:16 ` Arnout Vandecappelle
2021-08-18 21:44 ` [Buildroot] Analysis of build " Thomas Petazzoni
2021-08-18 22:24 ` Giulio Benetti
2021-08-18 22:26 ` Giulio Benetti
2021-08-19 0:01 ` Giulio Benetti
2021-08-19 13:28 ` Thomas Petazzoni
2021-08-20 14:26 ` Giulio Benetti
2021-08-20 22:00 ` Giulio Benetti
2021-08-21 23:08 ` Giulio Benetti
2021-08-19 9:27 ` Arnout Vandecappelle
2021-08-19 13:24 ` Thomas Petazzoni
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.