From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Adrian Ho <ml+postgresql(at)03s(dot)net>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17083: [PATCH] PostgreSQL fails to build with OpenLDAP 2.5.x |
Date: | 2021-07-08 19:55:27 |
Message-ID: | 2040197.1625774127@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Thu, Jul 08, 2021 at 09:53:11AM +0200, Daniel Gustafsson wrote:
>> Couldn't we add a version check to find if we have < 2.5 or >= 2.5, and adjust
>> libs accordingly? Alternatively we could perhaps check for
>> LDAP_API_FEATURE_X_OPENLDAP_REENTRANT which IIUC when set defines -lldap to be
>> reentrant.
> Would you fetch the version number directly from the library?
Yeah, that all sounds kind of fragile.
On investigation it seems that libldap_r has been around basically
forever. Even my second-oldest buildfarm animal prairiedog has got
it (indeed libldap.dylib and libldap_r.dylib are symlinks to
the same file on that platform ... hmm). My oldest animal gaur
is irrelevant to this discussion, because we don't support
--enable-thread-safety on it in the first place.
That being the case, I think we might be okay just going with the
solution in Adrian's last patch, ie use libldap_r if it's there
and otherwise assume that libldap is thread-safe. It looks
fairly unlikely that anyone will ever have an issue with that;
while if we complicate the configure probe, we might be introducing
new problems just from that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2021-07-08 20:01:21 | BUG #17095: ./configure fails thread_test.c when run under TSAN |
Previous Message | Tom Lane | 2021-07-08 17:22:06 | Re: BUG #17094: FailedAssertion at planner.c |