Re: BUG #17083: [PATCH] PostgreSQL fails to build with OpenLDAP 2.5.x

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Adrian Ho <ml+postgresql(at)03s(dot)net>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17083: [PATCH] PostgreSQL fails to build with OpenLDAP 2.5.x
Date: 2021-07-08 07:53:11
Message-ID: 68D22062-EC78-47C5-BC46-EF2F77193E19@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> On 7 Jul 2021, at 18:57, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Adrian Ho <ml+postgresql(at)03s(dot)net> writes:
>> Thanks, Tom, that turned out to only require one additional line, since
>> $LIBS is already being saved and restored around that block:
>
> I poked at this a bit further and realized that it's got a showstopper
> problem: in OpenLDAP 2.4, ldap_simple_bind() exists in both libldap.so
> and libldap_r.so. Thus, if we were dealing with an installation that
> does not have a thread-safe libldap, the patched configure would
> incorrectly seize on libldap.so as being an acceptable substitute,
> allowing weird hard-to-diagnose failures at runtime.
>
> IOW, while it might look from our existing coding like there's something
> about ldap_simple_bind() that is tied to reentrancy, there isn't. How
> else can we determine whether an OpenLDAP library is reentrant, if we
> can no longer depend on the _r suffix?

Couldn't we add a version check to find if we have < 2.5 or >= 2.5, and adjust
libs accordingly? Alternatively we could perhaps check for
LDAP_API_FEATURE_X_OPENLDAP_REENTRANT which IIUC when set defines -lldap to be
reentrant.

--
Daniel Gustafsson https://vmware.com/

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2021-07-08 08:04:54 Re: BUG #17083: [PATCH] PostgreSQL fails to build with OpenLDAP 2.5.x
Previous Message Etsuro Fujita 2021-07-08 07:49:39 Re: The case when AsyncAppend exists also in the qual of Async ForeignScan