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? :)
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
