Jan Engelhardt wrote:
A given (threaded) program makes use of libldap_r. It now also wants to make use of, say, libcurl. On certain systems, libcurl happens to be linked against libldap (not _r).
Eventually, both libldap and libldap_r end up in the process image of my program, and a symbol like "ldap_init" may point to the function of either library file. The threaded program may end up unexpectedly been given the non-threaded functions, depending on how the runtime linker loaded said libraries and binds the symbols. (I am seeing crashes in a large program's initialization because of this.)
There is a 7-year old post indicating libldap should get locking/ be replaced by libldap_r. http://www.openldap.org/lists/openldap-devel/200909/msg00018.html To date, openldap still consists of the two libraries. What are the preferred options to go forward here?
- 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.
- 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.
- Should libldap and libldap_r be augmented by ELF symbol versions?
- All of the above? :)