* [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
* 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
* [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 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] 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
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.