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
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>
Comments: In-reply-to Adrian Ho <ml+postgresql@03s.net>
	message dated "Wed, 07 Jul 2021 15:54:59 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1860065.1625677051.1@sss.pgh.pa.us>
Date: Wed, 07 Jul 2021 12:57:31 -0400
Message-ID: <1860066.1625677051@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1860066.1625677051%40sss.pgh.pa.us>
Precedence: bulk

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