[Date Prev][Date Next]
Re: libldap and libldap_r in the same process
- To: Jan Engelhardt <email@example.com>, firstname.lastname@example.org
- Subject: Re: libldap and libldap_r in the same process
- From: Howard Chu <email@example.com>
- Date: Sun, 28 Aug 2016 14:03:56 +0100
- In-reply-to: <WMfirstname.lastname@example.org>
- References: <alpine.LSU.email@example.com> <WMfirstname.lastname@example.org>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48a1
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.
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
* 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/