[Buildroot] Analysis of build results for 2021-08-17

[Thomas Petazzoni <thomas.petazzoni@bootlin.com>]

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