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 -
There are ibm_clang and ibm_clang_r (previous xlc and xlc_r) to compile with and without thread safe. If IBM Clang team
chose to only provide a thread safe version of libc++, okay, but that doesn't seem like a fundamental requirement.
zlibNX is another can of worms.
David