Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 909453 - openmp error in crossdev when compiling for aarch64 musl
Summary: openmp error in crossdev when compiling for aarch64 musl
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: ARM64 Linux
: Normal normal
Assignee: Cross compilation support
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-07-01 18:30 UTC by Nezar
Modified: 2025-04-21 06:24 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nezar 2023-07-01 18:30:37 UTC
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?
Comment 1 Nezar 2023-07-01 19:15:43 UTC
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
Comment 2 Larry the Git Cow gentoo-dev 2025-04-21 06:20:15 UTC
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(+)
Comment 3 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2025-04-21 06:24:01 UTC
(The change above is just for people hitting this error in other contexts, FWIW.)

I think there's still other improvements to make here.