(reposting due to mailing list issues)
Florian Weimer <fweimer(a)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
>>>>> 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
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?
Associate Software Engineer
Red Hat Czech