Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uQtvk-002OEu-1A for pgsql-bugs@arkaria.postgresql.org; Sun, 15 Jun 2025 20:26:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uQtvg-00DyEP-M3 for pgsql-bugs@arkaria.postgresql.org; Sun, 15 Jun 2025 20:26:13 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uQtvg-00DyEH-DL for pgsql-bugs@lists.postgresql.org; Sun, 15 Jun 2025 20:26:13 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uQtve-002EkL-29 for pgsql-bugs@lists.postgresql.org; Sun, 15 Jun 2025 20:26:12 +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 55FKQ16Y311721; Sun, 15 Jun 2025 16:26:01 -0400 From: Tom Lane To: Charles Samborski cc: pgsql-bugs@lists.postgresql.org Subject: Re: Lower priority of the configure option --with-libraries causes wrong lib resolution In-reply-to: <70f2155f-27ca-4534-b33d-7750e20633d7@demurgos.net> References: <70f2155f-27ca-4534-b33d-7750e20633d7@demurgos.net> Comments: In-reply-to Charles Samborski message dated "Sun, 15 Jun 2025 16:20:11 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <311719.1750019161.1@sss.pgh.pa.us> Date: Sun, 15 Jun 2025 16:26:01 -0400 Message-ID: <311720.1750019161@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Charles Samborski writes: > Swapping the two flags so the order is `-L/postgres-deps/lib -L/usr/lib` > fixes the build. I consider it very surprising that that libraries > passed with `--with-libraries` have lower priority, I would expect > explicitly requested libraries to have the highest priority. Ugh. > First, `/usr/lib` is added in the clang configuration [1]. It is > retrieved from `/usr/bin/llvm-config --ldflags`. I would pin the blame here. This code should not be messing with the global LDFLAGS. -L switches from llvm-config should probably go into LLVM_LIBS instead, so that they're only applied while linking llvmjit.so. (Compare the handling of -L switches from python or perl: those go into python_libspec or perl_embed_ldflags, they're not applied globally.) Can you check whether a change along that line fixes the problem in your environment? > My workaround is to update the configure script to instead prepend > `LIBDIRS` at the start of `LDFLAGS` using `LDFLAGS="$LIBDIRS $LDFLAGS"`. I don't think we'd accept that: it seems about as likely to break builds as fix them. Notably, users might've themselves modified LDFLAGS to contain -L switches. While that's not good practice IMO, we shouldn't make changes that are more sweeping than necessary. regards, tom lane