This morning's update from glibc-2.36-r3 to glibc-2.36-r4 failed on all crossdev targets, with variety of errors suggesting major malfunction of cross-compilation setup. I'll focus on cross-aarch64-unknown-linux-gnu/glibc-2.36-r4 here for clarity: Excerpt from /tmp/portage/cross-aarch64-unknown-linux-gnu/glibc-2.36-r4/temp/build.log (full log attached): * Package: cross-aarch64-unknown-linux-gnu/glibc-2.36-r4:2.2 * Repository: crossdev * Maintainer: toolchain@gentoo.org * USE: abi_x86_64 amd64 crypt elibc_glibc kernel_linux multiarch ssp static-libs userland_GNU * FEATURES: network-sandbox nostrip preserve-libs sandbox userpriv usersandbox [...] gcc -pipe -O2 -Wl,-O1 -Wl,--as-needed ../sysdeps/aarch64/start.S -c -U_FORTIFY_SOURCE -I../include -I/tmp/portage/cross-aarch64-unknown-linux-gnu/glibc-2.36-r4/work/build-arm64-aarch64-unknown-linux-gnu-nptl/csu -I/tmp/portage/cross-aarch64-unknown-linux-gnu/glibc-2.36-r4/work/build-arm64-aarch64-unknown-linux-gnu-nptl -I../sysdeps/unix/sysv/linux/aarch64 -I../sysdeps/aarch64/nptl -I../sysdeps/unix/sysv/linux/generic -I../sysdeps/unix/sysv/linux/wordsize-64 -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/aarch64/fpu -I../sysdeps/aarch64 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754/ldbl-128 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.1/include -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.1/include-fixed -isystem /usr/aarch64-unknown-linux-gnu/usr/include -D_LIBC_REENTRANT -include /tmp/portage/cross-aarch64-unknown-linux-gnu/glibc-2.36-r4/work/build-arm64-aarch64-unknown-linux-gnu-nptl/libc-modules.h -DMODULE_NAME=libc -include ../include/libc-symbols.h -DPIC -DSHARED -DTOP_NAMESPACE=glibc -DASSEMBLER -I/tmp/portage/cross-aarch64-unknown-linux-gnu/glibc-2.36-r4/work/build-arm64-aarch64-unknown-linux-gnu-nptl/csu/. -Werror=undef -Wa,--noexecstack -Werror=undef -Wa,--noexecstack -o /tmp/portage/cross-aarch64-unknown-linux-gnu/glibc-2.36-r4/work/build-arm64-aarch64-unknown-linux-gnu-nptl/csu/start.os -MD -MP -MF /tmp/portage/cross-aarch64-unknown-linux-gnu/glibc-2.36-r4/work/build-arm64-aarch64-unknown-linux-gnu-nptl/csu/start.os.dt -MT /tmp/portage/cross-aarch64-unknown-linux-gnu/glibc-2.36-r4/work/build-arm64-aarch64-unknown-linux-gnu-nptl/csu/start.os [...] ../sysdeps/aarch64/start.S: Assembler messages: ../sysdeps/aarch64/start.S:48: Error: bad register expression ../sysdeps/aarch64/start.S:49: Error: expecting operand after ','; got nothing ../sysdeps/aarch64/start.S:50: Error: expecting operand after ','; got nothing ../sysdeps/aarch64/start.S:53: Error: too many memory references for `mov' ../sysdeps/aarch64/start.S:56: Error: no such instruction: `ldr x1,[sp,' [...] The emerge log shows that nothing has merged or been attempted in cross-aarch64-unknown-linux-gnu/* since the successful cross-aarch64-unknown-linux-gnu/glibc-2.36-r3 build+merge, until today's failed attempt at cross-aarch64-unknown-linux-gnu/glibc-2.36-r4. The crossdev targets were set up to use binutils 2.38 on a first round of failures, and there was no change in symptoms after eselecting binutils 2.39 for all targets. sys-libs/glibc-2.36-r3 built and installed for all these targets on Sept 22, and cross-compilation of applications still succeeds for all these targets. However, glibc-2.36-r3 builds now fail for all targets with similar/same symptoms. Current installed versions for cross-aarch64-unknown-linux-gnu: $ equery l cross-aarch64-unknown-linux-gnu/\* * Searching for * in cross-aarch64-unknown-linux-gnu ... [I-O] [ ] cross-aarch64-unknown-linux-gnu/binutils-2.38-r2:2.38 [I-O] [ ] cross-aarch64-unknown-linux-gnu/binutils-2.39-r2:2.39 [I-O] [ ] cross-aarch64-unknown-linux-gnu/gcc-12.2.0:12 [I-O] [ ] cross-aarch64-unknown-linux-gnu/glibc-2.36-r3:2.2 [I-O] [ ] cross-aarch64-unknown-linux-gnu/linux-headers-5.19:0 Targets failing: cross-aarch64-unknown-linux-gnu/glibc-2.36-r4:2.2/2.2::crossdev cross-aarch64_be-unknown-linux-gnu/glibc-2.36-r4:2.2/2.2::crossdev cross-armeb-linux-gnueabihf/glibc-2.36-r4:2.2/2.2::crossdev cross-armv6zk-hardfloat-linux-gnueabi/glibc-2.36-r4:2.2/2.2::crossdev cross-armv6zk-softfloat-linux-gnueabi/glibc-2.36-r4:2.2/2.2::crossdev cross-armv7a-unknown-linux-gnueabihf/glibc-2.36-r4:2.2/2.2::crossdev cross-m68k-unknown-linux-gnu/glibc-2.36-r4:2.2/2.2::crossdev cross-mips-unknown-linux-gnu/glibc-2.36-r4:2.2/2.2::crossdev cross-powerpc-unknown-linux-gnu/glibc-2.36-r4:2.2/2.2::crossdev cross-powerpc64-unknown-linux-gnu/glibc-2.36-r4:2.2/2.2::crossdev cross-riscv32-unknown-linux-gnu/glibc-2.36-r4:2.2/2.2::crossdev cross-riscv64-unknown-linux-gnu/glibc-2.36-r4:2.2/2.2::crossdev cross-s390x-unknown-linux-gnu/glibc-2.36-r4:2.2/2.2::crossdev (logs available for all failed builds on request)
Created attachment 815788 [details] /tmp/cross-aarch64-unknown-linux-gnu_glibc-2.36-r4_build.log
Also failing on retest after downgrades to sys-apps/portage-3.0.37 and sys-apps/portage-3.0.36. The previous successes on Sept 22 were with sys-apps/portage-3.0.36. Today's failures are with sys-apps/portage-3.0.38.
This glitch was caused by the following clause in my local make.conf: # set by hand 20220925 # as much as possible, make sure clang never masks out gcc. CC=gcc CXX=g++ which was motivated by a flub in sys-devel/llvm-15.0.1 to the effect that # ls -l /usr/lib/llvm/15/bin/cc lrwxrwxrwx 1 root root 5 Sep 24 08:26 /usr/lib/llvm/15/bin/cc -> clang which in concert with /etc/env.d/60llvm-9984 arranged for clang-15 to mask out /usr/bin/cc. This flub, in turn, exposed a substantive bug in either clang-15 or openssh (or both), which is explored at https://bugzilla.mindrot.org/show_bug.cgi?id=3475 ("clang-15 amd64 ED25519 signature verification nondeterministic spurious failure"). Takeaways: (1) Don't supply override definitions for CC and CXX in make.conf when using crossdev (and probably for other reasons/scenarios too). (2) Fix path collisions and other package-specific defects as locally as possible -- in this case, in sys-devel/llvm.
