No libldap_r in OpenLDAP 2.5 - use LDAP_API_FEATURE_X_OPENLDAP_REENTRANT from ldap_features.h
libpq does use libldap, coming from openldap. In the release
announcement for Openldap 2.5 ,
https://www.openldap.org/software/release/announce.html , is written
that libldap_r has been merged with libldap . In turn on a system
with OpenLDAP 2.4, after installing OpenLDAP 2.5, libldap is for v2.5
and libldap_r i for v2.4 . On such systems Libpq links with
libldap_r-2.4-releng.so.2 , while Postgresql Postgresql 13.4 is linked
with libldap-2.5 .
The release notes for Postgresql 13.4 ,
https://www.postgresql.org/docs/13/release-13-4.html, contain:
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [d0a02bdb8] 2021-07-09 12:38:55 -0400
Branch: REL_14_STABLE [5620ec833] 2021-07-09 12:38:55 -0400
Branch: REL_13_STABLE [55cccdfdf] 2021-07-09 12:38:55 -0400
Branch: REL_12_STABLE [a5377e7f7] 2021-07-09 12:38:55 -0400
Branch: REL_11_STABLE [b69e8ad6c] 2021-07-09 12:38:55 -0400
Branch: REL_10_STABLE [7e0b53ad6] 2021-07-09 12:38:55 -0400
Branch: REL9_6_STABLE [cd5d3aefa] 2021-07-09 12:38:55 -0400
Branch: master [31e8cfac5] 2021-07-09 14:15:41 -0400
Branch: REL_14_STABLE [7f2eca6f9] 2021-07-09 14:15:41 -0400
Branch: REL_13_STABLE [cbcf5ffb1] 2021-07-09 14:15:41 -0400
Branch: REL_12_STABLE [83a8bf24e] 2021-07-09 14:15:41 -0400
Branch: REL_11_STABLE [29a4fbd46] 2021-07-09 14:15:41 -0400
Branch: REL_10_STABLE [911488b42] 2021-07-09 14:15:41 -0400
Branch: REL9_6_STABLE [8c9c20899] 2021-07-09 14:15:41 -0400
Branch: master [53c38a086] 2021-07-09 16:59:07 -0400
Branch: REL_14_STABLE [9ffad7ae7] 2021-07-09 16:59:07 -0400
Branch: REL_13_STABLE [32d0bdbfc] 2021-07-09 16:59:07 -0400
Branch: REL_12_STABLE [e82cde74d] 2021-07-09 16:59:08 -0400
Branch: REL_11_STABLE [2c28c689f] 2021-07-09 16:59:08 -0400
Branch: REL_10_STABLE [56533fce7] 2021-07-09 16:59:08 -0400
Branch: REL9_6_STABLE [3c612d9f6] 2021-07-09 16:59:08 -0400
Branch: master [9f6be2e79] 2021-07-10 13:19:30 -0400
Branch: REL_14_STABLE [ebc346e5b] 2021-07-10 13:19:31 -0400
Branch: REL_13_STABLE [9fca23c1d] 2021-07-10 13:19:31 -0400
Branch: REL_12_STABLE [03fc042eb] 2021-07-10 13:19:31 -0400
Branch: REL_11_STABLE [946f62f2f] 2021-07-10 13:19:31 -0400
-->
<para>
Fix <application>configure</application> to work with OpenLDAP 2.5,
which no longer has a separate <filename>libldap_r</filename>
library (Adrian Ho, Tom Lane)
</para>
<para>
If there is no <filename>libldap_r</filename> library, we now
silently assume that <filename>libldap</filename> is thread-safe.
</para>
</listitem>
The current postgres’/configure.ac logic is: if libldap_r is availabe,
then use it, otherwise use libldap.
Searching with nm -D in libldap-2.4-releng.so,
libldap_r-2.4-releng.so, and libldap-2.5.releng.so I find that in the
former the symbol ldap_compare is not versioned, while the latter
contains ldap_compare@@OPENLDAP_2.5.releng . This could be used as
criterion, whether to skip ldap_r .
Moreover, the installed ldap_features.h file contains:
/* is -lldap reentrant or not */
#define LDAP_API_FEATURE_X_OPENLDAP_REENTRANT 1
/* is -lldap thread safe or not */
#define LDAP_API_FEATURE_X_OPENLDAP_THREAD_SAFE 1
I propose, instead of looking for the presence of libldap_r, to check
the feature macro, and if libldap is reentrant, not to use libldap_r .
Greetings
Дилян
Dilyan Palauzov <Dilyan.Palauzov@aegee.org> writes:
The current postgres/configure.ac logic is: if libldap_r is availabe,
then use it, otherwise use libldap.
Right.
I propose, instead of looking for the presence of libldap_r, to check
the feature macro, and if libldap is reentrant, not to use libldap_r .
Why? This seems more fragile (i.e., it adds an assumption that the
visible header file matches the available libraries), and if there is
a concrete benefit, you did not say what that is.
regards, tom lane
Hello Tom,
on my system I have installed first OpenLDAP 2.4, and then in addition
OpenLDAP 2.5. The problem is, that postgresql (daemon) links with
libldap-2.5, and libpq links with libldap_r-2.4 . So any executable
(e.g. php) which links with both libldap and libpq, loads at the end at
the same time libldap-2.5 andl libldap_r-2.4 - two different versions.
This is not good.
When libldap( 2.5) is reentrant, and when libldap_r-2.4 is present,
libldap_r-2.4 shall not be used for linking.
Greetings
Дилян
Show quoted text
On Wed, 2021-08-25 at 02:29 -0400, Tom Lane wrote:
Dilyan Palauzov <Dilyan.Palauzov@aegee.org> writes:
The current postgres/configure.ac logic is: if libldap_r is
availabe,
then use it, otherwise use libldap.Right.
I propose, instead of looking for the presence of libldap_r, to
check
the feature macro, and if libldap is reentrant, not to use
libldap_r .Why? This seems more fragile (i.e., it adds an assumption that the
visible header file matches the available libraries), and if there is
a concrete benefit, you did not say what that is.regards, tom lane
=?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= <dilyan.palauzov@aegee.org> writes:
Hello Tom,
on my system I have installed first OpenLDAP 2.4, and then in addition
OpenLDAP 2.5.
Doesn't sound like a particularly good idea. How are you going to
get their header files to coexist? What if configure sees the wrong
header file for the library it picks up?
regards, tom lane
Hello Tom,
I run Linux from Scratch system. All old binaries, are linked with
libldap(_r)-2.4, all new things get linked towards libldap-2.5 . So
the configuration step always sees libldap-2.5 as most current (and its
header files). I can in theory point the build process to versioned-
headers, but I do not have to.
The problem here is, that libldap_r-2.4, libldap-2.4, and libldap-2.5
are installed on the system. I want that libpq.so is not linked with
libldap_r-2.4, but with libldap-2.5.
Greetings
Dilyan Palauzov
Show quoted text
On Wed, 2021-08-25 at 10:15 -0400, Tom Lane wrote:
=?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-
8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?=
<dilyan.palauzov@aegee.org> writes:Hello Tom,
on my system I have installed first OpenLDAP 2.4, and then in
addition
OpenLDAP 2.5.Doesn't sound like a particularly good idea. How are you going to
get their header files to coexist? What if configure sees the wrong
header file for the library it picks up?regards, tom lane
=?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= <dilyan.palauzov@aegee.org> writes:
I run Linux from Scratch system. All old binaries, are linked with
libldap(_r)-2.4, all new things get linked towards libldap-2.5 . So
the configuration step always sees libldap-2.5 as most current (and its
header files). I can in theory point the build process to versioned-
headers, but I do not have to.
The problem here is, that libldap_r-2.4, libldap-2.4, and libldap-2.5
are installed on the system. I want that libpq.so is not linked with
libldap_r-2.4, but with libldap-2.5.
If that is your plan, then you should have only the 2.5 libldap-devel
support installed, not 2.4. In particular, that would mean that you
shouldn't have any .so symlinks for the 2.4 libraries, which should
cause configure not to see them.
regards, tom lane
On Wed, Aug 25, 2021 at 10:36:40AM -0400, Tom Lane wrote:
If that is your plan, then you should have only the 2.5 libldap-devel
support installed, not 2.4. In particular, that would mean that you
shouldn't have any .so symlinks for the 2.4 libraries, which should
cause configure not to see them.
Linux From Scratch puts all experience burden to the user, so they
don't have a clear package experience AFAIK. And I guess that the OP
just used that:
https://linuxfromscratch.org/blfs/view/svn/server/openldap.html
Perhaps this documentation needs some improvement, I don't know.
--
Michael
Michael Paquier <michael@paquier.xyz> writes:
On Wed, Aug 25, 2021 at 10:36:40AM -0400, Tom Lane wrote:
If that is your plan, then you should have only the 2.5 libldap-devel
support installed, not 2.4. In particular, that would mean that you
shouldn't have any .so symlinks for the 2.4 libraries, which should
cause configure not to see them.
Linux From Scratch puts all experience burden to the user, so they
don't have a clear package experience AFAIK. And I guess that the OP
just used that:
https://linuxfromscratch.org/blfs/view/svn/server/openldap.html
Perhaps this documentation needs some improvement, I don't know.
Yeah, it doesn't look like that doc has any notion of development
vs. run-only installs. Maybe the underlying packaging doesn't either.
Anyway, on better-run distros there would be such a separation.
What you'd typically find in a Linux installation of a base openldap
package is (from my RHEL8 box):
$ ls -lF /usr/lib64/libldap*
lrwxrwxrwx. 1 root root 22 Jul 11 13:46 /usr/lib64/libldap-2.4.so.2 -> libldap-2.4.so.2.10.10*
-rwxr-xr-x. 1 root root 324968 Jul 11 13:47 /usr/lib64/libldap-2.4.so.2.10.10*
lrwxrwxrwx. 1 root root 24 Jul 11 13:46 /usr/lib64/libldap_r-2.4.so.2 -> libldap_r-2.4.so.2.10.10*
-rwxr-xr-x. 1 root root 349704 Jul 11 13:47 /usr/lib64/libldap_r-2.4.so.2.10.10*
while the -dev or -devel subpackage contains these versionless
symlinks:
lrwxrwxrwx. 1 root root 16 Jul 11 13:47 /usr/lib64/libldap.so -> libldap-2.4.so.2*
lrwxrwxrwx. 1 root root 18 Jul 11 13:47 /usr/lib64/libldap_r.so -> libldap_r-2.4.so.2*
along with the library' header files (in /usr/include) and maybe
some other developer-only files such as pkgconfig files.
Since the base-package library files all have versioned names,
it's possible to install base openldap packages of different
major versions without conflict. But the versionless symlinks
*would* conflict, so a proper packaging setup would prevent
you from installing both 2.4 and 2.5 openldap-devel.
It's the versionless symlinks that will be consulted by packages
building against the library, which is why building Postgres should
work if you get rid of the 2.4-era libldap_r.so link and keep only the
2.5-era libldap.so one. Obviously you'd better have the 2.5 include
files and so on along with that.
In short here: your problem arises because you've got inconsistent
subsets of development files in place. I'm allergic to the proposed
behavior change in our configure script because it gets rid of one
failure mode for such inconsistent library file sets at the cost of
creating a different one (i.e. headers not consistent with libraries).
That does not seem like an improvement.
regards, tom lane