Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mJcE3-0000v4-Ua for pgsql-bugs@arkaria.postgresql.org; Fri, 27 Aug 2021 13:48:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mJcE2-0003Mp-LL for pgsql-bugs@arkaria.postgresql.org; Fri, 27 Aug 2021 13:48:54 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mJcE2-0003Mh-F9 for pgsql-bugs@lists.postgresql.org; Fri, 27 Aug 2021 13:48:54 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mJcDv-0001Mj-2l for pgsql-bugs@lists.postgresql.org; Fri, 27 Aug 2021 13:48:53 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 17RDlbfh747767; Fri, 27 Aug 2021 09:47:37 -0400 From: Tom Lane To: Michael Paquier cc: =?utf-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= , pgsql-bugs@lists.postgresql.org Subject: Re: No libldap_r in OpenLDAP 2.5 - use LDAP_API_FEATURE_X_OPENLDAP_REENTRANT from ldap_features.h In-reply-to: References: <20210825052142.Horde.fX47Irhz5YmXoRVbIbyYUJm@webmail.aegee.org> <520273.1629872978@sss.pgh.pa.us> <3894d2a91d141b0fe454da01b3b7faad6fa9d07a.camel@aegee.org> <544882.1629900910@sss.pgh.pa.us> <8bf71cb05679342f8a09206cb03fc727d5d52830.camel@aegee.org> <545973.1629902200@sss.pgh.pa.us> Comments: In-reply-to Michael Paquier message dated "Fri, 27 Aug 2021 10:02:22 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <747765.1630072057.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Aug 2021 09:47:37 -0400 Message-ID: <747766.1630072057@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Michael Paquier 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 -> libld= ap-2.4.so.2* lrwxrwxrwx. 1 root root 18 Jul 11 13:47 /usr/lib64/libldap_r.so -> lib= ldap_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