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: <f2393be8-2b92-1ee6-0812-324cf7660f24@enterprisedb.com>
References: <fedacd7c-2a38-25c9-e7ff-dea549d0e979@enterprisedb.com>
 <1832824.1651500238@sss.pgh.pa.us>
 <f2393be8-2b92-1ee6-0812-324cf7660f24@enterprisedb.com>
Comments: In-reply-to Peter Eisentraut <peter.eisentraut@enterprisedb.com>
	message dated "Wed, 04 May 2022 16:05:45 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2358597.1651677372.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 04 May 2022 11:16:12 -0400
Message-ID: <2358598.1651677372@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2358598.1651677372%40sss.pgh.pa.us>
Precedence: bulk

Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 02.05.22 16:03, Tom Lane wrote:
>> I'm not that excited about getting rid of this warning, because to the
>> extent that anyone notices it at all, it'll motivate them to get OpenLD=
AP
>> from Homebrew or MacPorts, which seems like a good thing.

> 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?

Hmm, I just tried it with up-to-date MacPorts, and it was a *complete*
fail: I got all the deprecation warnings (so the system include headers
were used), and both postgres and libpq.dylib still ended up linked
against /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP.

But then I went "doh!" and added
  --with-includes=3D/opt/local/include --with-libraries=3D/opt/local/lib
to the configure call, and everything built the way I expected.
I'm not sure offhand if the docs include a reminder to do that when
using stuff out of MacPorts, or the equivalent for Homebrew.

We still have a bit of work to do, because this setup isn't getting
all the way through src/test/ldap/:

2022-05-04 11:01:33.407 EDT [21312] [unknown] LOG:  connection received: h=
ost=3D[local]
2022-05-04 11:01:33.457 EDT [21312] [unknown] LOG:  could not start LDAP T=
LS session: Operations error
2022-05-04 11:01:33.457 EDT [21312] [unknown] DETAIL:  LDAP diagnostics: T=
LS already started
2022-05-04 11:01:33.457 EDT [21312] [unknown] FATAL:  LDAP authentication =
failed for user "test1"
2022-05-04 11:01:33.457 EDT [21312] [unknown] DETAIL:  Connection matched =
pg_hba.conf line 1: "local all all ldap ldapurl=3D"ldaps://localhost:51335=
/dc=3Dexample,dc=3Dnet??sub?(uid=3D$username)" ldaptls=3D1"
2022-05-04 11:01:33.459 EDT [21304] LOG:  server process (PID 21312) was t=
erminated by signal 11: Segmentation fault: 11

Many of the test cases pass, but it looks like ldaps-related ones don't.
The stack trace isn't very helpful:

(lldb) bt
* thread #1, stop reason =3D ESR_EC_DABORT_EL0 (fault address: 0x0)
  * frame #0: 0x00000001b5bfc628 libsystem_pthread.dylib`pthread_rwlock_rd=
lock
    frame #1: 0x00000001054a74c4 libcrypto.3.dylib`CRYPTO_THREAD_read_lock=
 + 12

			regards, tom lane