From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: configure openldap crash warning
In-reply-to: <2358598.1651677372@sss.pgh.pa.us>
References: <fedacd7c-2a38-25c9-e7ff-dea549d0e979@enterprisedb.com>
 <1832824.1651500238@sss.pgh.pa.us>
 <f2393be8-2b92-1ee6-0812-324cf7660f24@enterprisedb.com>
 <2358598.1651677372@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Wed, 04 May 2022 11:16:12 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2360301.1651678212.1@sss.pgh.pa.us>
Date: Wed, 04 May 2022 11:30:12 -0400
Message-ID: <2360302.1651678212@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2360302.1651678212%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
>> I tried building with Homebrew-supplied openldap.  What ends up 
>> happening is that the postgres binary is indeed linked with openldap, 
>> but libpq still is linked against the OS-supplied LDAP framework. 
>> (Checked with "otool -L" in each case.)  Can someone else reproduce 
>> this, too?

> [ it works with MacPorts ]

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.

Not sure about a good fix.  If we had a way to detect which library
file AC_CHECK_LIB finds, we could verify that libldap and libldap_r
come from the same directory ... but I don't think we have that.

			regards, tom lane