Created attachment 569134 [details] build log and emerge --info output As per subject, I am getting the mentioned build error in cross-aarch64-unknown-linux-gnu/glibc-2.28-r5, which comes as part of the sys-devel/crossdev 20181202 update. In short, the message goes like this, and as far as I can understand it looks like it is looking for two instructions missing from the assembly code. I am also attaching the full build log as well as emerge -pqv '=cross-aarch64-unknown-linux-gnu/glibc-2.28-r5::crossdev. Thanks ../sysdeps/unix/sysv/linux/aarch64/__read_tp.S: Assembler messages: ../sysdeps/unix/sysv/linux/aarch64/__read_tp.S:23: Error: no such instruction: `mrs x0,tpidr_el0' make[2]: *** [/var/tmp/portage/cross-aarch64-unknown-linux-gnu/glibc-2.28-r5/work/build-arm64-aarch64-unknown-linux-gnu-nptl/sysd-rules:7: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/glibc-2.28-r5/work/build-arm64-aarch64-unknown-linux-gnu-nptl/csu/__read_tp.o] Error 1 make[2]: *** Waiting for unfinished jobs.... check_fds.c: Assembler messages: check_fds.c:81: Error: no such instruction: `brk ' make[2]: *** [../o-iterator.mk:9: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/glibc-2.28-r5/work/build-arm64-aarch64-unknown-linux-gnu-nptl/csu/check_fds.o] Error 1 In file included from [01m[K../include/errno.h:25[m[K, from [01m[K../csu/libc-tls.c:20[m[K, from [01m[K../sysdeps/aarch64/libc-tls.c:19[m[K: [01m[K../sysdeps/aarch64/libc-tls.c:[m[K In function ‘[01m[K__tls_get_addr[m[K’: [01m[K../sysdeps/aarch64/nptl/tls.h:91:19:[m[K [01;31m[Kerror: [m[K__builtin_thread_pointer is not supported on this target (((tcbhead_t *) [01;31m[K__builtin_thread_pointer ()[m[K)->dtv) [01;31m[K^~~~~~~~~~~~~~~~~~~~~~~~~~~[m[K [01m[K../sysdeps/aarch64/libc-tls.c:30:16:[m[K [01;36m[Knote: [m[Kin expansion of macro ‘[01m[KTHREAD_DTV[m[K’ dtv_t *dtv = [01;36m[KTHREAD_DTV[m[K (); [01;36m[K^~~~~~~~~~[m[K ../csu/libc-tls.c: Assembler messages: ../csu/libc-tls.c:192: Error: no such instruction: `msr tpidr_el0,%r14' make[2]: *** [/var/tmp/portage/cross-aarch64-unknown-linux-gnu/glibc-2.28-r5/work/build-arm64-aarch64-unknown-linux-gnu-nptl/sysd-rules:451: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/glibc-2.28-r5/work/build-arm64-aarch64-unknown-linux-gnu-nptl/csu/libc-tls.o] Error 1 In file included from [01m[K../sysdeps/aarch64/nptl/tls.h:37[m[K,
Is it an old crossdev install? Note, your build system tries to build cross-glibc with a native compiler: > x86_64-pc-linux-gnu-gcc -march=ivybridge -pipe -O2 -fno-strict-aliasing -Wl,-O1 -Wl,--as-needed ../sysdeps/unix/sysv/linux/aarch64/__read_tp.S -c ... Do you have working aarch64-unknown-linux-gnu-gcc cross-compiler installed? Looking at configure log you don't. > checking for aarch64-unknown-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc -march=ivybridge -pipe -O2 -fno-strict-aliasing -Wl,-O1 -Wl,--as-needed Make sure 'aarch64-unknown-linux-gnu-gcc -v' works for you. If it does not we can debug it further.
*** Bug 680366 has been marked as a duplicate of this bug. ***
I am glad you spotted it. It was actually an easy fix from there. Basically I had to make a symlink of /usr/bin/aarch64-unknown-linux-gnu-gcc-8.3.0 to /usr/bin/aarch64-unknown-linux-gnu-gcc and it worked after that. Thanks and sorry for raising a bug that apparently wasn't.
Thanks for pointing me in this direction. After reading this resolution, I believe the root cause of the issue to be that upgrading the host-built cross-compiler does not update the symlinks without a version suffix. You can see in the screenshot I attached that after an upgrade of my cross-compiler from 8.2.0 to 8.3.0, several of the symlinks are still pointing to the old version, namely the gcc and g++ ones! How can we make sure these symlinks do not have to be manually updated when upgrading the cross-compiler?
Created attachment 569160 [details] broken_symlinks.png
It probably is a toolchain.eclass bug that triggers when you --depclean active cross-compiler (and newer version is already installed but is not activated for some reason). Usually the workaround is to run something like # gcc-config -l # check if cross-tollchain is active # gcc-config armv7a-unknown-linux-gnueabihf-8.3.0 I suspect that our do_gcc_config() does something odd at least for cross case: https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/toolchain.eclass#n2265 I'll add a bit of debugging into that snippet and see what happens.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bbc72dc75013128bb0a235010690db8b5cac7e30 commit bbc72dc75013128bb0a235010690db8b5cac7e30 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-07-12 22:17:03 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-07-12 23:37:33 +0000 toolchain.eclass: update active cross-gcc on uninstall gcc-config-2 changed /usr/bin/gcc from a binary to symlink in commit b907ef80bc421df23515afc4c306e4d96c67649 ("Convert binary wrapper to a symlink wrapper.") Before the above change /usr/bin/gcc worked in both cases when active cross-gcc is being uninstalled. After the above change symlink becomes dangling. The change runs `gcc-config` more aggressively. Reported-by: Pietro Closes: https://bugs.gentoo.org/680360 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> eclass/toolchain.eclass | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
