]> git.ipfire.org Git - thirdparty/postgresql.git/commit
configure: don't probe for libldap_r if libldap is 2.5 or newer.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 10 May 2022 22:42:02 +0000 (18:42 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 10 May 2022 22:42:02 +0000 (18:42 -0400)
commitaf9b967671533965debc9caf3e20fd65a3c71ae4
tree657fa762d9272b11bfabb9ce6acaeacfd2ebfda0
parent4695fdb40fbb1e977e7e62f7d9af1fa948230d6a
configure: don't probe for libldap_r if libldap is 2.5 or newer.

In OpenLDAP 2.5 and later, libldap itself is always thread-safe and
there's never a libldap_r.  Our existing coding dealt with that
by assuming it wouldn't find libldap_r if libldap is thread-safe.
But that rule fails to cope if there are multiple OpenLDAP versions
visible, as is likely to be the case on macOS in particular.  We'd
end up using shiny new libldap in the backend and a hoary libldap_r
in libpq.

Instead, once we've found libldap, check if it's >= 2.5 (by
probing for a function introduced then) and don't bother looking
for libldap_r if so.  While one can imagine library setups that
this'd still give the wrong answer for, they seem unlikely to
occur in practice.

Per report from Peter Eisentraut.  Back-patch to all supported branches.

Discussion: https://postgr.es/m/fedacd7c-2a38-25c9-e7ff-dea549d0e979@enterprisedb.com
configure
configure.in