https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125324
Bug ID: 125324
Summary: -fcoarray=shared should imply -pthread /
gfortran.dg/coarray_51.f90 FAILs with undefined
reference to `pthread_mutex_trylock'
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jvdelisle at gcc dot gnu.org
Target Milestone: ---
Cross ref: PR125310 is a FAIL about the same file, but there the issue is that
libcaf_mem itself is not available.
* * *
On our tester x86-64/Linux tester fails with:
/tmp/build/b0d5f4e5/src/gcc-mainline/libgfortran/caf/shmem.c:1509:(.text+0x2a72):
undefined reference to `pthread_mutex_trylock'
/tmp/build/b0d5f4e5/src/gcc-mainline/libgfortran/caf/shmem.c:1566:(.text+0x2ce4):
undefined reference to `pthread_mutex_trylock'
* * *
I think -fcoarray=shared should imply -pthread, similar to what we use
elsewhere,
e.g. gcc.cc has:
/* Linking to libgomp implies pthreads. This is particularly important
for targets that use different start files and suchlike. */
#ifndef GOMP_SELF_SPECS
#define GOMP_SELF_SPECS \
"%{fopenacc|fopenmp|%:gt(%{ftree-parallelize-loops=*:%*} 1): " \
"-pthread}"
#endif
→ The natural location seems to be lang_specific_driver in
fortran/gfortranspec.cc as we already handle other libraries there, e.g.
libgfortran linking.
* * *
I am not completely sure why it fail here (x86-64) but I think the issue is
that the glibc is older - the build-with GLIBC seems to be 2.27 (to make it
installable also on old systems) albeit I thought the testsuite run was with a
newer GLIBC.
In any case, only glibc 2.34 removed libpthread →
https://developers.redhat.com/articles/2021/12/17/why-glibc-234-removed-libpthread
And I bet that some other systems out there also (still) require linking some
thread library.
