I'm one of the people who works on packaging OpenLDAP for Debian, and I'm
trying to figure out what the right way to deal with libldap and libldap_r
would be. Here's the problem that Debian has (which I expect is shared by
As I understand it, libldap_r is the thread-safe library and libldap is
not thread-safe, so threaded applications have to link with libldap_r.
However, libldap and libldap_r both contain the same symbols and don't use
symbol versioning. So if both are loaded into the same process space at
the same time, it's undefined which library is called, which can cause all
sorts of problems.
Therefore, for modules like nss-ldap that are loaded into the process
space of almost every system process, there is no good option for which
library to link against in the presence of both libraries: Linking with
libldap because nss-ldap isn't threaded means that threaded applications
that link with libldap_r may resolve symbols to the wrong library.
Threaded applications may also get undefined results if they call NSS
functions. But linking nss-ldap with with libldap_r to be safe for
threaded applications will cause problems for any application linked with
Note that nss-ldap is just an example, useful because it's fairly
obvious. The same problem applies to any situation where multiple
libraries may be mingled in a process space: PAM-using servers with
pam-ldap, Apache with mod_ldap and mod_python or mod_perl loading LDAP
What's the recommended way of dealing with this problem? I'd like
whatever solution we use to be something that you're comfortable with.
It's worth noting, btw, that glibc provides stubs for pthread functions,
allowing libraries that need to be thread-safe in threaded programs but
not in unthreaded programs to gain back the speed lost to locking when
running without threads. In order to use this, the library should *not*
be linked directly with the pthread library. glibc will provide stubs
that do nothing if libpthread isn't loaded, and if it is, they will be
transparently replaced by the correct threading code. This would
eliminate the need to have two separate libraries.
However, glibc only provides these stubs for a limited number of
functions, and libldap_r currently references pthread functions outside of
that set. I believe the other symbols may only be used in the code that
supports slapd, although I could be wrong.
Attached is the list of functions for which stubs are provided.
Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>