I've been following the fix proposed by Bernhard in this thread: https://gcc.gnu.org/pipermail/fortran/2021-April/055907.html
to allow static linking of Fortran codes compiled with -fopenmp. (I know that static linking of OpenMP codes isn't guaranteed to work, but this fix has worked well for me anyway.) This fix seems to no longer work with glibc >= 2.34 - I think because the functionality of libpthread has been integrated into libc: https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html When compiling the simple test code from that thread with glibc 2.34 or newer I get a segfault: $ cat omp.f90 use omp_lib !$omp parallel write(*,*) "thread ", omp_get_thread_num() !$omp end parallel end $ gfortran -o omp -fopenmp omp.f90 -static -Wl,--whole-archive -lpthread - Wl,--no-whole-archive && OMP_NUM_THREADS=2 ./omp ./../../gcc-13-source/gcc-13-20220710/libgomp/config/linux/../../allocator.c: 102: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ./../../gcc-13-source/gcc-13-20220710/libgomp/oacc-profiling.c:137: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking thread 0 thread 1 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x467b0f in ??? #1 0x0 in ??? Segmentation fault (core dumped) Tracking this down in gdb it seems that pthread_mutex_destroy() is called, but that symbol is null. >From comment #9 in this PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909#c9 I figured out a workaround, which is to create a C file with this content: #include "pthread.h" #define nullptr ((void*)0) void pthread_workaround() { pthread_mutex_destroy((pthread_mutex_t *) nullptr); } which defines a function pthread_workaround() which calls pthread_mutex_destroy(), but which itself it never called. Compiling that C code, and linking with the Fortran allows the test code to run successfully. $ gcc -c -o fix.o -fopenmp fix.c $ gfortran -c -o omp.o -fopenmp omp.f90 $ gfortran -o omp -fopenmp -static omp.o fix.o ./../../gcc-13-source/gcc-13-20220710/libgomp/config/linux/../../allocator.c: 102: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ./../../gcc-13-source/gcc-13-20220710/libgomp/oacc-profiling.c:137: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking $ OMP_NUM_THREADS=2 ./omp thread 0 thread 1 My understanding of glibc, pthreads, etc. etc. is insufficient to know if this is a good and/or safe workaround, but I figured I'd share it here in case: a) it's useful to anyone; b) it's indicative of a bug in gfortran; c) anyone has a more elegant solution! -Andrew -- * Andrew Benson: https://abensonca.github.io * Galacticus: https://bitbucket.org/abensonca/galacticus
