The GCC OpenMP runtime (libgomp) should be a banned library for GCCcore (only)

[ocaisa]

There are different API possibilities for OpenMP and they shouldn't be mixed. For GCCcore level, we shouldn't allow the OpenMP runtime to be linked as we create the possibility for strange behaviour if used as a dependency for an application that uses another runtime.

[ocaisa]

So, I guess it should be banned from GCCcore and then removed from the banned list for GCC

[ocaisa]

This is really only an issue when considering Clang, as Clang is interoperable with libgomp.so and by default creates a symlink for libgomp.so to it's own library.
The current thinking is that for Clang we will implement something similar to GCCcore, building a complete LLVM (including the compiler frontends) but disable creating the symlink. Then we have a compiler wrapper bundle easyconfig and use that to restore the symlink. That way anything sitting at the compiler level and using OpenMP will get the Clang runtime consistently even if they link against something in GCCcore that also uses OpenMP (even with RPATH this is a load race, and this setup should ensure that Clang wins when it should).

[Thyre]

This is really only an issue when considering Clang, as Clang is interoperable with libgomp.so and by default creates a symlink for libgomp.so to it's own library.

Shouldn't this affect all LLVM-based compilers then? See this example (note that my toolchain is built without EB here):

$ cat hello-world.c
#include <stdio.h>
#include <omp.h>

void hello_world()
{
    #pragma omp critical
    printf( "Hello World from thread %d\n", omp_get_thread_num() );
}


int main( void )
{
    #pragma omp parallel
    hello_world();
}
$ module load Clang
$ clang -fopenmp=libgomp ./hello-world.c
$ ldd ./a.out                              
        linux-vdso.so.1 (0x00007ffd87ddd000)
        libgomp.so.1 => /lib/x86_64-linux-gnu/libgomp.so.1 (0x0000798b0d619000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000798b0d200000)
        /lib64/ld-linux-x86-64.so.2 (0x0000798b0d689000)
$ module load oneAPI

Lmod is automatically replacing "LLVM/18.1.2" with "oneAPI/2024.1".

$ icx -fopenmp=libgomp hello-world.c
$ ldd ./a.out
        linux-vdso.so.1 (0x00007ffd971d8000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x0000761ae9412000)
        libgomp.so.1 => /lib/x86_64-linux-gnu/libgomp.so.1 (0x0000761ae93c8000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000761ae9000000)
        /lib64/ld-linux-x86-64.so.2 (0x0000761ae951a000)

In both cases, libgomp.so is linked. This would mean that AOCC would be affected the same way. NVHPC probably doesn't offer this interoperability, but I'm not sure.

One interesting thing to note: When trying out Clang 19-trunk on my machine, it properly links against the LLVM libomp.so. I don't know if some changed flags caused this, though I'm quite sure all versions on my machine share the same flags. But even then, choosing -fopenmp=libgomp changes runtime behavior, as described (easybuilders/easybuild#640 (comment))

[ocaisa]

I suspect you know more about this than me! So what happens if you are just giving -fopenmp rather than specifying the library to link against?

The issue I am considering here is specific to GCCcore which is not a compiler in the EasyBuild sense. My concern would be that if an application uses GCCcore it may link against the GCCcore libgomp (particularly in an RPATH scenario), if that application is then a dependency of something else which uses Clang then we may end up with mixed OpenMP runtimes. If we do not allow the use of OpenMP until we get to the compiler level then we should have well defined and consistent (default) behaviour.

[Thyre]

I suspect you know more about this than me! So what happens if you are just giving -fopenmp rather than specifying the library to link against?

We can freely choose the library we want to use during the Clang CMake call. By default, the LLVM OpenMP runtime is used. This probably also works for Flang in a similar fashion.

https://github.com/llvm/llvm-project/blob/main/clang/CMakeLists.txt#L273

The issue I am considering here is specific to GCCcore which is not a compiler in the EasyBuild sense. My concern would be that if an application uses GCCcore it may link against the GCCcore libgomp (particularly in an RPATH scenario), if that application is then a dependency of something else which uses Clang then we may end up with mixed OpenMP runtimes. If we do not allow the use of OpenMP until we get to the compiler level then we should have well defined and consistent (default) behaviour.

Agreed. We should only allow OpenMP once a toolchain has been selected. Then, we can ensure that everything is linked with the same OpenMP runtime.