]> 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)
commitc61f36d9960664a044269f4dcb1a6ad42470a078
tree71ea7eaa0a23996d7c8ff826ede7c9baf4c1e3af
parent6979736b4bcdc57e4699eadcca44b699fd1afd29
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