From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Annoying build warnings from latest Apple toolchain
In-reply-to: <1111721.1695941929@sss.pgh.pa.us>
References: <467042.1695766998@sss.pgh.pa.us>
 <673900.1695841549@sss.pgh.pa.us> <687188.1695847964@sss.pgh.pa.us>
 <20230928203213.47bn2pv45mkmxtz7@alap3.anarazel.de>
 <1095659.1695933968@sss.pgh.pa.us>
 <20230928222248.jw6s7yktpfsfczha@alap3.anarazel.de>
 <1111721.1695941929@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Thu, 28 Sep 2023 18:58:49 -0400"
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <1289427.1696003997.0@sss.pgh.pa.us>
Date: Fri, 29 Sep 2023 12:14:40 -0400
Message-ID: <1289531.1696004080@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1289531.1696004080%40sss.pgh.pa.us>
Precedence: bulk

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1289427.1696003997.1@sss.pgh.pa.us>

I wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On 2023-09-28 16:46:08 -0400, Tom Lane wrote:
>>> Well, it's only important on platforms where we can't restrict
>>> libpq.so from exporting all symbols.  I don't know how close we are
>>> to deciding that such cases are no longer interesting to worry about.
>>> Makefile.shlib seems to know how to do it everywhere except Windows,
>>> and I imagine we know how to do it over in the MSVC scripts.

>> Hm, then I'd argue that we don't need to care about it anymore. The meson
>> build does the necessary magic on windows, as do the current msvc scripts.

> If we take that argument seriously, then I'm inclined to adjust my
> upthread patch for Makefile.global.in so that it removes the extra
> inclusions of libpgport/libpgcommon everywhere, not only macOS.
> The rationale would be that it's not worth worrying about ABI
> stability details on any straggler platforms.

Looking closer, it's only since v16 that we have export list support
on all officially-supported platforms.  Therefore, I think the prudent
thing to do in the back branches is use the patch I posted before,
to suppress the duplicate -l switches only on macOS.  In HEAD,
I propose we simplify life by doing it everywhere, as attached.

			regards, tom lane


------- =_aaaaaaaaaa0
Content-Type: text/x-diff; name="v2-fix-duplicate-library-linkage.patch";
	charset="us-ascii"
Content-ID: <1289427.1696003997.2@sss.pgh.pa.us>
Content-Description: v2-fix-duplicate-library-linkage.patch
Content-Transfer-Encoding: quoted-printable

diff --git a/src/Makefile.global.in b/src/Makefile.global.in
index 18240b5fef..7b66590801 100644
--- a/src/Makefile.global.in
+++ b/src/Makefile.global.in
@@ -589,19 +589,27 @@ endif
 libpq =3D -L$(libpq_builddir) -lpq
 =

 # libpq_pgport is for use by client executables (not libraries) that use =
libpq.
-# We force clients to pull symbols from the non-shared libraries libpgpor=
t
-# and libpgcommon rather than pulling some libpgport symbols from libpq j=
ust
-# because libpq uses those functions too.  This makes applications less
-# dependent on changes in libpq's usage of pgport (on platforms where we
-# don't have symbol export control for libpq).  To do this we link to
-# pgport before libpq.  This does cause duplicate -lpgport's to appear
-# on client link lines, since that also appears in $(LIBS).
+# We used to use this to force libpgport and libpgcommon to be linked bef=
ore
+# libpq, ensuring that clients would pull symbols from those libraries ra=
ther
+# than possibly getting them from libpq (and thereby having an unwanted
+# dependency on which symbols libpq uses).  However, now that we can prev=
ent
+# libpq from exporting those symbols on all platforms of interest, we don=
't
+# worry about that anymore.  The previous technique resulted in duplicate
+# libraries in link commands, since those libraries also appear in $(LIBS=
).
+# Some platforms warn about that, so avoiding those warnings is now more
+# important.  Hence, $(libpq_pgport) is now equivalent to $(libpq), but w=
e
+# still recommend using it for client executables in case some other reas=
on
+# appears to handle them differently.
+libpq_pgport =3D $(libpq)
+
 # libpq_pgport_shlib is the same idea, but for use in client shared libra=
ries.
+# We need those clients to use the shlib variants.  (Ideally, users of th=
is
+# macro would strip libpgport and libpgcommon from $(LIBS), but no harm i=
s
+# done if they don't, since they will have satisfied all their references
+# from these libraries.)
 ifdef PGXS
-libpq_pgport =3D -L$(libdir) -lpgcommon -lpgport $(libpq)
 libpq_pgport_shlib =3D -L$(libdir) -lpgcommon_shlib -lpgport_shlib $(libp=
q)
 else
-libpq_pgport =3D -L$(top_builddir)/src/common -lpgcommon -L$(top_builddir=
)/src/port -lpgport $(libpq)
 libpq_pgport_shlib =3D -L$(top_builddir)/src/common -lpgcommon_shlib -L$(=
top_builddir)/src/port -lpgport_shlib $(libpq)
 endif
 =


------- =_aaaaaaaaaa0--