Peter Eisentraut <peter.eisentr...@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 OpenLDAP
>> 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=/opt/local/include --with-libraries=/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:
host=[local]
2022-05-04 11:01:33.457 EDT [21312] [unknown] LOG: could not start LDAP TLS
session: Operations error
2022-05-04 11:01:33.457 EDT [21312] [unknown] DETAIL: LDAP diagnostics: TLS
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="ldaps://localhost:51335/dc=example,dc=net??sub?(uid=$username)"
ldaptls=1"
2022-05-04 11:01:33.459 EDT [21304] LOG: server process (PID 21312) was
terminated 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 = ESR_EC_DABORT_EL0 (fault address: 0x0)
* frame #0: 0x00000001b5bfc628 libsystem_pthread.dylib`pthread_rwlock_rdlock
frame #1: 0x00000001054a74c4 libcrypto.3.dylib`CRYPTO_THREAD_read_lock + 12
regards, tom lane
