Hi,
On 2022-05-06 14:00:43 -0400, Tom Lane wrote:
> I wrote:
> > Oh, I have a theory about this: I bet your Homebrew installation
> > has a recent OpenLDAP version that only supplies libldap not libldap_r.
> > In that case, configure will still find libldap_r available and will
> > bind libpq to it, and you get the observed result. The configure
> > check is not sophisticated enough to realize that it's finding chunks
> > of two different OpenLDAP installations.
>
> After thinking about this for awhile, it seems like the best solution
> is to make configure proceed like this:
>
> 1. Find libldap.
> 2. Detect whether it's OpenLDAP 2.5 or newer.
> 3. If not, try to find libldap_r.
>
> There are various ways we could perform step 2, but I think the most
> reliable is to try to link to some function that's present in 2.5
> but not before. (In particular, this doesn't require any strong
> assumptions about whether the installation's header files match the
> library.) After a quick dig in 2.4 and 2.5, it looks like
> ldap_verify_credentials() would serve.
Why do we continue to link the backend to ldap when we find ldap_r, given that
we know that it can cause problems for extension libraries using libpq? I did
a cursory search of the archives without finding an answer. ISTM that we'd be
more robust if we used your check from above to decide when to use ldap (so we
don't use an older ldap_r), and use ldap_r for both FE and BE otherwise.
Greetings,
Andres Freund