| 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: | Whole Thread | Raw Message | 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 |