Re: BUG #17083: [PATCH] PostgreSQL fails to build with OpenLDAP 2.5.x
От | Daniel Gustafsson |
---|---|
Тема | Re: BUG #17083: [PATCH] PostgreSQL fails to build with OpenLDAP 2.5.x |
Дата | |
Msg-id | 68D22062-EC78-47C5-BC46-EF2F77193E19@yesql.se обсуждение исходный текст |
Ответ на | Re: BUG #17083: [PATCH] PostgreSQL fails to build with OpenLDAP 2.5.x (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
> On 7 Jul 2021, at 18:57, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Adrian Ho <ml+postgresql@03s.net> writes: >> Thanks, Tom, that turned out to only require one additional line, since >> $LIBS is already being saved and restored around that block: > > I poked at this a bit further and realized that it's got a showstopper > problem: in OpenLDAP 2.4, ldap_simple_bind() exists in both libldap.so > and libldap_r.so. Thus, if we were dealing with an installation that > does not have a thread-safe libldap, the patched configure would > incorrectly seize on libldap.so as being an acceptable substitute, > allowing weird hard-to-diagnose failures at runtime. > > IOW, while it might look from our existing coding like there's something > about ldap_simple_bind() that is tied to reentrancy, there isn't. How > else can we determine whether an OpenLDAP library is reentrant, if we > can no longer depend on the _r suffix? 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. -- Daniel Gustafsson https://vmware.com/
В списке pgsql-bugs по дате отправления: