David Edelsohn wrote: > > ibm-clang links against libpthread.a as well: > > $ ldd /opt/IBM/openxlC/17.1.1/bin/.ibm-clang.orig > > /opt/IBM/openxlC/17.1.1/bin/.ibm-clang.orig needs: > > /usr/lib/libpthreads.a(shr_xpg5_64.o) > > /usr/opt/zlibNX/lib/libz.a(libz.so.1) > > /usr/lib/libcurses.a(shr42_64.o) > > /usr/lib/libiconv.a(shr4_64.o) > > /usr/lib/libc++.a(shr_64.o) > > /usr/lib/libc++abi.a(libc++abi.so.1) > > /usr/lib/libc.a(shr_64.o) > > /usr/lib/libpthreads.a(_shr_xpg5_64.o) > > /usr/lib/libc++.a(libc++.so.1) > > /usr/lib/libunwind.a(libunwind.so.1) > > /usr/lib/libc.a(_shr_64.o) > > /unix > > /usr/lib/libcrypt.a(shr_64.o) > > > > I have asked the IBM Clang team why ibm-clang depends on libpthreads.
The reason is that - For a library, it is a normal expectation nowadays that it is multithread-safe. - Making a library multithread-safe (without major hacks) means to do locking or to call pthread_once / call_once in some places. - The ISO C 11 threading functions in libc have some drawbacks compared to the pthread functions. [1] So most developer prefer to rely on the POSIX threads API. - Since AIX does not have the POSIX mutex functions in libc and does not support weak symbols like in ELF, this means a dependency to pthread_mutex_lock or pthread_once. - Accordingly, in the list of libraries above, 3 libraries need pthread* symbols: $ nm -X 64 /usr/lib/libc++abi.a | grep ' U ' | grep pthread_mutex pthread_mutex_lock U - pthread_mutex_unlock U - $ nm -X 64 /usr/lib/libc++.a | grep ' U ' | grep pthread_mutex pthread_mutex_destroy U - pthread_mutex_init U - pthread_mutex_lock U - pthread_mutex_trylock U - pthread_mutex_unlock U - pthread_mutexattr_destroy U - pthread_mutexattr_init U - pthread_mutexattr_settype U - $ nm -X 64 /usr/opt/zlibNX/lib/libz.a | grep ' U ' | grep pthread_mutex pthread_mutex_destroy U - pthread_mutex_init U - pthread_mutex_lock U - pthread_mutex_unlock U - Bruno [1] Lock initialization is clumsy. The return value of a thread is only an 'int', not a pointer. Etc.