Packaging libldap and libldap_r

[Russ Allbery <rra@stanford.edu>]

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
other distributors):

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
libldap.

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
modules, etc.

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.

pthread_attr_destroy
pthread_attr_getdetachstate
pthread_attr_getinheritsched
pthread_attr_getschedparam
pthread_attr_getschedpolicy
pthread_attr_getscope
pthread_attr_init
pthread_attr_setdetachstate
pthread_attr_setinheritsched
pthread_attr_setschedparam
pthread_attr_setschedpolicy
pthread_attr_setscope
pthread_cond_broadcast
pthread_cond_destroy
pthread_cond_init
pthread_cond_signal
pthread_cond_timedwait
pthread_cond_wait
pthread_condattr_destroy
pthread_condattr_init
pthread_equal
pthread_exit
pthread_getschedparam
pthread_mutex_destroy
pthread_mutex_init
pthread_mutex_lock
pthread_mutex_unlock
pthread_self
pthread_setcancelstate
pthread_setcanceltype
pthread_setschedparam

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>