Description of problem: glibc provides stubs for pthread_mutex_init(), lock and unlock, so that library that have no information on whether their caller uses threads, can provide locking when needed. That means, that the following program will compile and run without linking to libpthread. #include <pthread.h> int main() { pthread_mutex_t mutex; pthread_mutex_init(&mutex, NULL); return 0; } However, with this approach a library cannot use a recursive mutex, because the mutex needs to be provided attributes which can only be initialized with pthread_mutexattr_init() which isn't available in glibc. That is, the following program cannot compile without libpthread. Note that this program is identical to above, but uses a recursive mutex. #include <pthread.h> int main() { pthread_mutex_t mutex; pthread_mutexattr_t attr; pthread_mutexattr_init(&attr); pthread_mutexattr_settype (&attr, PTHREAD_MUTEX_RECURSIVE_NP); pthread_mutex_init(&mutex, &attr); return 0; } How reproducible: Compile the second program provided. Actual results: $ gcc c.c /tmp/ccsjztYf.o: In function `main': c.c:(.text+0x10): undefined reference to `pthread_mutexattr_init' c.c:(.text+0x21): undefined reference to `pthread_mutexattr_settype' Expected results: Should compile as expected.
Have you tried using PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP, avoiding the attribute? It's not portable (hence the _NP), but it should work in this scenario.
(In reply to Florian Weimer from comment #1) > Have you tried using PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP, avoiding the > attribute? It's not portable (hence the _NP), but it should work in this > scenario. I have not tried the static initializers, but they were not an option for the project that the above code comes from.
(In reply to Nikos Mavrogiannopoulos from comment #2) > (In reply to Florian Weimer from comment #1) > > Have you tried using PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP, avoiding the > > attribute? It's not portable (hence the _NP), but it should work in this > > scenario. > > I have not tried the static initializers, but they were not an option for > the project that the above code comes from. Could you elaborate why? I would like to understand how we can improve this on the glibc side.
(In reply to Florian Weimer from comment #3) > (In reply to Nikos Mavrogiannopoulos from comment #2) > > (In reply to Florian Weimer from comment #1) > > > Have you tried using PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP, avoiding the > > > attribute? It's not portable (hence the _NP), but it should work in this > > > scenario. > > > > I have not tried the static initializers, but they were not an option for > > the project that the above code comes from. > Could you elaborate why? I would like to understand how we can improve this > on the glibc side. Actually I was wrong on that. The mutex is created dynamically (in the context of a "context" structure), but indeed the attributes could have been initialized statically. So that addresses the issue; sorry for the false alarm.
(In reply to Nikos Mavrogiannopoulos from comment #4) > Actually I was wrong on that. The mutex is created dynamically (in the > context of a "context" structure), but indeed the attributes could have been > initialized statically. So that addresses the issue; sorry for the false > alarm. Thanks for the clarification. As the current glibc features suffice for your purposes, I'm closing this bug.