I was setting up a cross-compile chain using crossdev for aarch64 musl device. The exact target is: aarch64-gentoo-linux-musl. The host was a glibc amd64 gentoo. After setting up the cross compiler, attempting to emerge almost any package using the cross-compile chain `emerge-aarch64-gentoo-linux-musl`, including updating system packages, fails with the message: ``` [code] * Messages for package app-crypt/libb2-0.98.1-r3 merged to /usr/aarch64-gentoo-linux-musl/: * Your current compiler does not support OpenMP! * Enable OpenMP support by building sys-devel/gcc with USE="openmp". * ERROR: app-crypt/libb2-0.98.1-r3::gentoo failed (pretend phase): * Active compiler does not have required support for OpenMP [/code] ``` However, attempting to do as the error message does not work either. After running `USE="openmp" emerge-aarch64-gentoo-linux-musl sys-devel/gcc` does not fix the issue. I ended up fixing this issue by adding the "openmp" USE flag to the cross compiler, running `USE="openmp" emerge --oneshot cross-aarch64-gentoo-linux-musl/gcc` Maybe this should be set as a default flag?
Apologies for not providing a `emerge --info`. I had already fixed the problem when I made this bug report, but thought it would be good to post here for visibility and adding a permanent fix
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=37dded9b48c93a67b9a32b5eca2b1ef0fc6e8b9e commit 37dded9b48c93a67b9a32b5eca2b1ef0fc6e8b9e Author: Sam James <sam@gentoo.org> AuthorDate: 2025-04-21 06:10:28 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-04-21 06:18:14 +0000 sys-devel/gcc: add fixincludes patch to 15 too to fix openmp on regular cross targets Using lu_zero's repro instructions ... ``` $ crossdev -C riscv64 $ crossdev riscv64 -s3 $ find /usr -name pthread.h # to make sure glibc isn't doing something strange $ riscv64-unknown-linux-gnu-gcc -E - <<<"#include <pthread.h>" # this should work $ crossdev -C riscv64 $ crossdev riscv64 -s3 --g 15.0.1_pre20250418-r1 $ find /usr -name pthread.h # to make sure glibc isn't doing something strange $ riscv64-unknown-linux-gnu-gcc -E - <<<"#include <pthread.h>" # this should fail because it looks only on the compiler dir ``` ... we see that openmp.h is missing and --disable-libgomp was passed because our test in toolchain.eclass was failing: ``` # Make sure target has pthreads support: bug #326757, bug #335883 # There shouldn't be a chicken & egg problem here as openmp won't # build without a C library, and you can't build that w/o # already having a compiler... if ! is_crosscompile || $(tc-getCPP ${CTARGET}) -E - <<<"#include <pthread.h>" >& /dev/null ; then confgcc+=( $(use_enable openmp libgomp) ) else # Force disable as the configure script can be dumb, bug #359855 confgcc+=( --disable-libgomp ) fi ``` Adding in the gcc-13-fix-cross-fixincludes.patch patch we're already using for other versions fixes it by adding /usr/${CHOST}/usr/include in the search path of the stage1 crossdev GCC. We may still want to add a workaround in toolchain.eclass like: ``` - $(tc-getCPP ${CTARGET}) -E - <<<"#include <pthread.h>" >& /dev/null + $(tc-getCPP ${CTARGET}) -I/usr/${CTARGET}/usr/include -E - <<<"#include <pthread.h>" >& /dev/null ``` Or maybe add some warning if it failed when weren't expecting it to on some targets. I'll move this patch to gcc-patches at some point. Bug: https://gcc.gnu.org/PR115416 Bug: https://bugs.gentoo.org/326757 Bug: https://bugs.gentoo.org/335883 Bug: https://bugs.gentoo.org/905118 Bug: https://bugs.gentoo.org/909453 Bug: https://bugs.gentoo.org/925204 Bug: https://bugs.gentoo.org/926059 Thanks-to: Luca Barbato <lu_zero@gentoo.org> Signed-off-by: Sam James <sam@gentoo.org> sys-devel/gcc/gcc-15.0.1_pre20250418-r1.ebuild | 1 + 1 file changed, 1 insertion(+)
(The change above is just for people hitting this error in other contexts, FWIW.) I think there's still other improvements to make here.