= Proposed System Wide Change: OpenLDAP without Non-threaded Libraries = https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries
Owner(s): * Matus Honek <mhonek at redhat dot com>
OpenLDAP will not ship non-threaded version of libldap. Instead, libldap will be built with the same threading support as libldap_r.
== Detailed description == After this change the non-threaded version of libldap will not be shipped any more. Instead, this library will rather be built the same way as the threaded libldap_r. This has been previously discussed in Bugzilla [https://bugzilla.redhat.com/show_bug.cgi?id=1370065] and other distributions where this change already happened. Upstream still supports non-threaded version of their library as it might be used on processors where threads are not supported. However, when these two versions happen to be loaded at the same time (as discussed about Curl in the Bugzilla) symbol names overlap which may result in unpredictable behaviour. Immediate solution would be to symlink libldap to libldap_r, however SONAME of the library would be the same, hence breaking dependencies of other packages. For that reason the solution hereby proposed should be the most convenient one.
== Scope == * Proposal owners: update SPEC file so that non-threaded libldap is replaced with threaded one.
* Other developers: None. Issues should not occur.
* Release engineering: [https://pagure.io/releng/issue/7253]
** List of deliverables: N/A
* Policies and guidelines: None.
* Trademark approval: (not needed for this Change)
On 07/03/2018 10:13 AM, Jan Kurik wrote:
= Proposed System Wide Change: OpenLDAP without Non-threaded Libraries = https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries
OpenLDAP will not ship non-threaded version of libldap. Instead, libldap will be built with the same threading support as libldap_r.
Why is this a system-wide change? Is it actually about linking applications and libraries against libldap_r instead of libdap?
Thanks, Florian
On Tue, Jul 03, 2018 at 11:26:02AM +0200, Florian Weimer wrote:
On 07/03/2018 10:13 AM, Jan Kurik wrote:
= Proposed System Wide Change: OpenLDAP without Non-threaded Libraries = https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries
OpenLDAP will not ship non-threaded version of libldap. Instead, libldap will be built with the same threading support as libldap_r.
Why is this a system-wide change? Is it actually about linking applications and libraries against libldap_r instead of libdap?
No, the change says that anything that links to libldap will continue to do that, but that libldap will now be a copy of libdap_r, differing only the so-name.
Zbyszek
On 07/10/2018 10:19 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Jul 03, 2018 at 11:26:02AM +0200, Florian Weimer wrote:
On 07/03/2018 10:13 AM, Jan Kurik wrote:
= Proposed System Wide Change: OpenLDAP without Non-threaded Libraries = https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries
OpenLDAP will not ship non-threaded version of libldap. Instead, libldap will be built with the same threading support as libldap_r.
Why is this a system-wide change? Is it actually about linking applications and libraries against libldap_r instead of libdap?
No, the change says that anything that links to libldap will continue to do that, but that libldap will now be a copy of libdap_r, differing only the so-name.
I don't see that. The idea of the symbolic link is explicitly rejected, which I think implies also the use of a copy.
Thanks, Florian
On Tue, Jul 10, 2018 at 10:28:40PM +0200, Florian Weimer wrote:
On 07/10/2018 10:19 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Jul 03, 2018 at 11:26:02AM +0200, Florian Weimer wrote:
On 07/03/2018 10:13 AM, Jan Kurik wrote:
= Proposed System Wide Change: OpenLDAP without Non-threaded Libraries = https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries
OpenLDAP will not ship non-threaded version of libldap. Instead, libldap will be built with the same threading support as libldap_r.
Why is this a system-wide change? Is it actually about linking applications and libraries against libldap_r instead of libdap?
No, the change says that anything that links to libldap will continue to do that, but that libldap will now be a copy of libdap_r, differing only the so-name.
I don't see that. The idea of the symbolic link is explicitly rejected, which I think implies also the use of a copy.
The way I understand this: right now there's two libraries: libldap_r (threaded) and libldap (nonthreaded) proposed state: two libraries: libldap_r (threaded) and libldap (threaded) So anything which links to libldap will continue to do that, but despite the name, libldap will really similar to libldap_r.
Zbyszek
On 07/10/2018 10:41 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Jul 10, 2018 at 10:28:40PM +0200, Florian Weimer wrote:
On 07/10/2018 10:19 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Jul 03, 2018 at 11:26:02AM +0200, Florian Weimer wrote:
On 07/03/2018 10:13 AM, Jan Kurik wrote:
= Proposed System Wide Change: OpenLDAP without Non-threaded Libraries = https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries
OpenLDAP will not ship non-threaded version of libldap. Instead, libldap will be built with the same threading support as libldap_r.
Why is this a system-wide change? Is it actually about linking applications and libraries against libldap_r instead of libdap?
No, the change says that anything that links to libldap will continue to do that, but that libldap will now be a copy of libdap_r, differing only the so-name.
I don't see that. The idea of the symbolic link is explicitly rejected, which I think implies also the use of a copy.
The way I understand this: right now there's two libraries: libldap_r (threaded) and libldap (nonthreaded) proposed state: two libraries: libldap_r (threaded) and libldap (threaded) So anything which links to libldap will continue to do that, but despite the name, libldap will really similar to libldap_r.
Matus, would you please clarify what the plan is here? Thanks.
Florian
(reposting due to mailing list issues)
Florian Weimer fweimer@redhat.com writes:
On 07/10/2018 10:41 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Jul 10, 2018 at 10:28:40PM +0200, Florian Weimer wrote:
On 07/10/2018 10:19 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Jul 03, 2018 at 11:26:02AM +0200, Florian Weimer wrote:
On 07/03/2018 10:13 AM, Jan Kurik wrote:
= Proposed System Wide Change: OpenLDAP without Non-threaded Libraries = https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries
OpenLDAP will not ship non-threaded version of libldap. Instead, libldap will be built with the same threading support as libldap_r.
Why is this a system-wide change? Is it actually about linking applications and libraries against libldap_r instead of libdap?
No, the change says that anything that links to libldap will continue to do that, but that libldap will now be a copy of libdap_r, differing only the so-name.
I don't see that. The idea of the symbolic link is explicitly rejected, which I think implies also the use of a copy.
The way I understand this: right now there's two libraries: libldap_r (threaded) and libldap (nonthreaded) proposed state: two libraries: libldap_r (threaded) and libldap (threaded) So anything which links to libldap will continue to do that, but despite the name, libldap will really similar to libldap_r.
Matus, would you please clarify what the plan is here? Thanks.
Florian is right, the idea is to make changes to the source code (probably a downstream patch will be needed) such that the threaded library will be built twice, once with libldap soname and once with libldap_r soname, and the non-threaded libldap won't be shipped at all.
The non-threaded version basically provides a subset of capabilities of the threaded version, which are additionally thread safe (i.e. mutexes). There shouldn't be really any noticeable change.
Does this make sense?
On Tuesday, July 17, 2018 2:24:04 PM CEST Matus Honek wrote:
Florian is right, the idea is to make changes to the source code (probably a downstream patch will be needed) such that the threaded library will be built twice, once with libldap soname and once with libldap_r soname, and the non-threaded libldap won't be shipped at all.
The non-threaded version basically provides a subset of capabilities of the threaded version, which are additionally thread safe (i.e. mutexes). There shouldn't be really any noticeable change.
Does this make sense?
So can it happen that both the libraries will be loaded at the same time by a single process (one of them for example through libcurl)?
Will everything work as expected in this case?
Kamil
On 07/17/2018 04:08 PM, Kamil Dudka wrote:
On Tuesday, July 17, 2018 2:24:04 PM CEST Matus Honek wrote:
Florian is right, the idea is to make changes to the source code (probably a downstream patch will be needed) such that the threaded library will be built twice, once with libldap soname and once with libldap_r soname, and the non-threaded libldap won't be shipped at all.
The non-threaded version basically provides a subset of capabilities of the threaded version, which are additionally thread safe (i.e. mutexes). There shouldn't be really any noticeable change.
Does this make sense?
So can it happen that both the libraries will be loaded at the same time by a single process (one of them for example through libcurl)?
Will everything work as expected in this case?
It's certainly quite risky, and many things can go wrong (dlopen of the dormant copy of the library, ELF constructors running twice).
Matus, have you considered turning libldap.so into a linker script (referencing libdap_r.so) and libldap-2.4.so.2 into a stub which only depends on libldap_r-2.4.so.2? The dynamic linker will then search libldap_r if the application links against libldap.
Thanks, Florian
* Florian Weimer:
On 07/17/2018 04:08 PM, Kamil Dudka wrote:
On Tuesday, July 17, 2018 2:24:04 PM CEST Matus Honek wrote:
Florian is right, the idea is to make changes to the source code (probably a downstream patch will be needed) such that the threaded library will be built twice, once with libldap soname and once with libldap_r soname, and the non-threaded libldap won't be shipped at all.
The non-threaded version basically provides a subset of capabilities of the threaded version, which are additionally thread safe (i.e. mutexes). There shouldn't be really any noticeable change.
Does this make sense?
So can it happen that both the libraries will be loaded at the same time by a single process (one of them for example through libcurl)?
Will everything work as expected in this case?
It's certainly quite risky, and many things can go wrong (dlopen of the dormant copy of the library, ELF constructors running twice).
Matus, have you considered turning libldap.so into a linker script (referencing libdap_r.so) and libldap-2.4.so.2 into a stub which only depends on libldap_r-2.4.so.2? The dynamic linker will then search libldap_r if the application links against libldap.
FYI, I have a downstream patch for this which is undergoing review.
Thanks, Florian
-
Florian Weimer -
Jan Kurik -
Kamil Dudka -
Matus Honek -
Zbigniew Jędrzejewski-Szmek