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 1nn2G7-0000Ky-Fu for pgsql-hackers@arkaria.postgresql.org; Fri, 06 May 2022 18:00: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 1nn2G4-00033U-Kx for pgsql-hackers@arkaria.postgresql.org; Fri, 06 May 2022 18:00:52 +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 1nn2G4-00033K-C8 for pgsql-hackers@lists.postgresql.org; Fri, 06 May 2022 18:00:52 +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 1nn2Fy-0005Db-NB for pgsql-hackers@postgresql.org; Fri, 06 May 2022 18:00:51 +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 246I0h6X2957309; Fri, 6 May 2022 14:00:43 -0400 From: Tom Lane To: Peter Eisentraut cc: pgsql-hackers Subject: Re: configure openldap crash warning In-reply-to: <2360302.1651678212@sss.pgh.pa.us> References: <1832824.1651500238@sss.pgh.pa.us> <2358598.1651677372@sss.pgh.pa.us> <2360302.1651678212@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Wed, 04 May 2022 11:30:12 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2957307.1651860043.1@sss.pgh.pa.us> Date: Fri, 06 May 2022 14:00:43 -0400 Message-ID: <2957308.1651860043@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > Oh, I have a theory about this: I bet your Homebrew installation > has a recent OpenLDAP version that only supplies libldap not libldap_r. > In that case, configure will still find libldap_r available and will > bind libpq to it, and you get the observed result. The configure > check is not sophisticated enough to realize that it's finding chunks > of two different OpenLDAP installations. After thinking about this for awhile, it seems like the best solution is to make configure proceed like this: 1. Find libldap. 2. Detect whether it's OpenLDAP 2.5 or newer. 3. If not, try to find libldap_r. There are various ways we could perform step 2, but I think the most reliable is to try to link to some function that's present in 2.5 but not before. (In particular, this doesn't require any strong assumptions about whether the installation's header files match the library.) After a quick dig in 2.4 and 2.5, it looks like ldap_verify_credentials() would serve. Barring objections, I'll make a patch for that. BTW, I was a little distressed to read this in the 2.4 headers: ** If you fail to define LDAP_THREAD_SAFE when linking with ** -lldap_r or define LDAP_THREAD_SAFE when linking with -lldap, ** provided header definations and declarations may be incorrect. That's not something we do or ever have done, AFAIK. Given the lack of complaints and the fact that 2.4 is more or less EOL, I don't feel a strong need to worry about it; but it might be something to keep in mind in case we get bug reports. regards, tom lane