On Sunday 2016-08-28 15:03, Howard Chu wrote:
- Killing non-threaded libldap in openldap for real
If not,
- Should curl have used -lldap_r instead of -lldap?
Is curl already multithreaded? On Ubuntu curl is built with libldap_r already. If curl is a threaded program then yes, it should use libldap_r.
Apologies if I was unclear - I do mean libcurl, not /usr/bin/curl.
"""libcurl is thread safe but has no internal thread synchronization. [...] you must never use a single handle from more than one thread at any given time.""" (The same is true for PAM, for example.)
Because libcurl cannot know if the calling program is threaded or not, Debian already made the change (which propagated to Ubuntu) to abolish libldap and only use libldap_r:
lrwxrwxrwx 1 18 Jan 17 2016 libldap-2.4.so.2 -> libldap_r-2.4.so.2 lrwxrwxrwx 1 11 Jan 17 2016 libldap.a -> libldap_r.a lrwxrwxrwx 1 12 Jan 17 2016 libldap.so -> libldap_r.so
This way, "-lldap" on the linker line is always resolved to libldap_r-2.4.so.2, which is why you will see the _r variant in readelf/ldd etc.
- Should Linux distributions make libldap and libldap_r be the same thing?
I'm wary of doing that, but I suppose thread support on Linux today is a lot more stable than it was 7-15 years ago.
The question really just is, will the openldap project combine ldap and ldap_r, or do distributions have to copy the Debian-style solution?