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