From: Tom Lane <tgl@sss.pgh.pa.us>
To: Adrian Ho <ml+postgresql@03s.net>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17083: [PATCH] PostgreSQL fails to build with OpenLDAP 2.5.x
Date: Wed, 07 Jul 2021 12:57:31 -0400
Message-ID: <1860066.1625677051@sss.pgh.pa.us> (raw)
In-Reply-To: <e78eb1f9-57b1-dae9-39c8-5dd72268be89@03s.net>
References: <17083-a19190d9591946a7@postgresql.org>
<1666182.1625579201@sss.pgh.pa.us>
<cc729116-2a2d-9edd-a32d-4066b92e4a75@03s.net>
<1677203.1625582865@sss.pgh.pa.us>
<e78eb1f9-57b1-dae9-39c8-5dd72268be89@03s.net>
Adrian Ho <ml+postgresql@03s.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?
Maybe we can decide that in 2021 such situations no longer exist in
the wild, but I'm unsure.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, ml+postgresql@03s.net, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17083: [PATCH] PostgreSQL fails to build with OpenLDAP 2.5.x
In-Reply-To: <1860066.1625677051@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox