Re: Annoying build warnings from latest Apple toolchain

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Annoying build warnings from latest Apple toolchain
Дата
Msg-id 673900.1695841549@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Annoying build warnings from latest Apple toolchain  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Annoying build warnings from latest Apple toolchain  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
I wrote:
> Since updating to Xcode 15.0, my macOS machines have been
> spitting a bunch of linker-generated warnings. ...
> some program links complain

> ld: warning: ignoring duplicate libraries: '-lpgcommon', '-lpgport'

I found that this is being caused by the libpq_pgport hack in
Makefile.global.in, which ensures that libpgcommon and libpgport
get linked before libpq.  The comment freely admits that it results in
linking libpgcommon and libpgport twice.  Now, AFAICS that whole hack
is unnecessary on any platform where we know how to do symbol export
control, because then libpq won't expose any of the troublesome
symbols to begin with.  So we can resolve the problem by just not
doing that on macOS, as in the attached draft patch.  I've confirmed
that this suppresses the duplicate-libraries warnings on Xcode 15.0
without creating any issues on older macOS (though I'm only in a
position to test as far back as Catalina).

The patch is written to change things only on macOS, but I wonder
if we should be more aggressive and change it for all platforms
where we have symbol export control (which is almost everything
these days).  I doubt it'd make any noticeable difference in
build time, but doing that would give us more test coverage
which would help expose any weak spots.

I've not yet looked at the meson build infrastructure to
see if it needs a corresponding change.

            regards, tom lane

diff --git a/src/Makefile.global.in b/src/Makefile.global.in
index 18240b5fef..cded651755 100644
--- a/src/Makefile.global.in
+++ b/src/Makefile.global.in
@@ -589,19 +589,31 @@ endif
 libpq = -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 libpgport
+# We want clients to pull symbols from the non-shared libraries libpgport
 # and libpgcommon rather than pulling some libpgport symbols from libpq just
 # 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
+# dependent on changes in libpq's usage of pgport.  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).
+# on client link lines, since that also appears in $(LIBS).  On platforms
+# where we have symbol export control for libpq, the whole exercise is
+# unnecessary because libpq won't expose any of these symbols.  Currently,
+# only macOS warns about duplicate library references, so we only suppress
+# the duplicates on macOS.
+ifeq ($(PORTNAME),darwin)
+libpq_pgport = $(libpq)
+else ifdef PGXS
+libpq_pgport = -L$(libdir) -lpgcommon -lpgport $(libpq)
+else
+libpq_pgport = -L$(top_builddir)/src/common -lpgcommon -L$(top_builddir)/src/port -lpgport $(libpq)
+endif
+
 # libpq_pgport_shlib is the same idea, but for use in client shared libraries.
+# We need those clients to use the shlib variants, even on macOS.  (Ideally,
+# users of this macro would strip libpgport and libpgcommon from $(LIBS),
+# but no harm is done if they don't.)
 ifdef PGXS
-libpq_pgport = -L$(libdir) -lpgcommon -lpgport $(libpq)
 libpq_pgport_shlib = -L$(libdir) -lpgcommon_shlib -lpgport_shlib $(libpq)
 else
-libpq_pgport = -L$(top_builddir)/src/common -lpgcommon -L$(top_builddir)/src/port -lpgport $(libpq)
 libpq_pgport_shlib = -L$(top_builddir)/src/common -lpgcommon_shlib -L$(top_builddir)/src/port -lpgport_shlib $(libpq)
 endif


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Eager page freeze criteria clarification
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Eager page freeze criteria clarification