I noticed that OpenSSL 1.1 now has an explicit dependency on Pthreads. Which means that now even our "non-threaded" libldap, when built with OpenSSL, must actually be linked with the threads library. In this age of multicore processors, is it really important to have a single-threaded LDAP library any more? Should we just make libldap_r become the standard library?
--On Monday, March 18, 2019 5:15 PM +0000 Howard Chu hyc@symas.com wrote:
I noticed that OpenSSL 1.1 now has an explicit dependency on Pthreads. Which means that now even our "non-threaded" libldap, when built with OpenSSL, must actually be linked with the threads library. In this age of multicore processors, is it really important to have a single-threaded LDAP library any more? Should we just make libldap_r become the standard library?
Using libldap_r as the standard library has been the default with many downstream linux distributions for years, so I think that's reasonable (and well tested at this point).
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 3/18/19 11:23 AM, Quanah Gibson-Mount wrote:
--On Monday, March 18, 2019 5:15 PM +0000 Howard Chu hyc@symas.com wrote:
I noticed that OpenSSL 1.1 now has an explicit dependency on Pthreads. Which means that now even our "non-threaded" libldap, when built with OpenSSL, must actually be linked with the threads library. In this age of multicore processors, is it really important to have a single-threaded LDAP library any more? Should we just make libldap_r become the standard library?
Using libldap_r as the standard library has been the default with many downstream linux distributions for years, so I think that's reasonable (and well tested at this point).
--Quanah
Similarly with Solaris, when we started shipping OpenLDAP as the supported libldap in our distribution, we have only ever shipped the libldap_r library. All of our libldap.*s files are just symlinks. As I recall, we started doing this back with the 2.4.30 release.
Doug.
On 3/18/19 5:15 PM, Howard Chu wrote:
I noticed that OpenSSL 1.1 now has an explicit dependency on Pthreads. Which means that now even our "non-threaded" libldap, when built with OpenSSL, must actually be linked with the threads library. In this age of multicore processors, is it really important to have a single-threaded LDAP library any more? Should we just make libldap_r become the standard library?
Mainstream Linux distributions started to remove libldap anyway. So +1 to abandon it.
Ciao, Michael.
Michael Ströder wrote:
On 3/18/19 5:15 PM, Howard Chu wrote:
I noticed that OpenSSL 1.1 now has an explicit dependency on Pthreads. Which means that now even our "non-threaded" libldap, when built with OpenSSL, must actually be linked with the threads library. In this age of multicore processors, is it really important to have a single-threaded LDAP library any more? Should we just make libldap_r become the standard library?
Mainstream Linux distributions started to remove libldap anyway. So +1 to abandon it.
I would probably keep "libldap" as the canonical name. We can completely drop the "libldap_r" name or just keep it as a symlink for a while, removing it after a year or so.
On Mon, Mar 18, 2019 at 05:31:34PM +0000, Howard Chu wrote:
I would probably keep "libldap" as the canonical name.
++
We can completely drop the "libldap_r" name or just keep it as a symlink for a while, removing it after a year or so.
I'd maybe make that "after a release or so" i.e. if "libldap" becomes canonical starting from 2.5, don't drop the symlink at least until 2.6.
* Howard Chu:
Michael Ströder wrote:
On 3/18/19 5:15 PM, Howard Chu wrote:
I noticed that OpenSSL 1.1 now has an explicit dependency on Pthreads. Which means that now even our "non-threaded" libldap, when built with OpenSSL, must actually be linked with the threads library. In this age of multicore processors, is it really important to have a single-threaded LDAP library any more? Should we just make libldap_r become the standard library?
Mainstream Linux distributions started to remove libldap anyway. So +1 to abandon it.
I would probably keep "libldap" as the canonical name. We can completely drop the "libldap_r" name or just keep it as a symlink for a while, removing it after a year or so.
Hasn't everyone who ships a single library standardized on libldap_r?
Fedora wants to unify libldap and libdap_r as well, and my guidance was to use a soname with libldap_r, too.
When was the last soname bump for libldap_r? Around 2008? Dropping the symbolic link would result in an unncessary (at this point) soname bump.
(Note that the symbolic links are important for glibc at least: the dynamic loader will only load one copy of the library and treat the other names as aliases.)
-
Doug Leavitt -
Florian Weimer -
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount -
Ryan Tandy