On Wed, Sep 01, 2021 at 08:59:57AM +0000, REIX, Tony wrote:
> Here is a new patch, using the export.txt whenever it does exist.
> I have tested it with v13.4 : it's OK.
> Patch for 14beta3 should be the same since there was no change for
> src/Makefile.shlib between v13 and v14.
Thanks. This looks good. I'm attaching what I intend to push, which just
adds a log message and some cosmetic changes compared to your version. Here
are the missing symbols restored by the patch:
pg_encoding_to_char
pg_utf_mblen
pg_char_to_encoding
pg_valid_server_encoding
pg_valid_server_encoding_id
I was ambivalent about whether to back-patch to v13 or to stop at v14, but I
decided that v13 should have this change. We should expect sad users when
libpq lacks a documented symbol. Complaints about loss of undocumented
symbols (e.g. pqParseInput3) are unlikely, and we're even less likely to have
users opposing reintroduction of long-documented symbols. An alternative
would be to have v13 merge the symbol lists, like your original proposal, so
we're not removing even undocumented symbols. I doubt applications have
accrued dependencies on libpq-internal symbols in the year since v13 appeared,
particularly since those symbols are inaccessible on Linux. Our AIX export
lists never included libpgport or libpgcommon symbols.
Author: Noah Misch <n...@leadboat.com>
Commit: Noah Misch <n...@leadboat.com>
AIX: Fix missing libpq symbols by respecting SHLIB_EXPORTS.
We make each AIX shared library export all globals found in .o files
that originate in the library. That doesn't include symbols acquired by
-lpgcommon_shlib. That is good on average, but it became a problem for
libpq when commit e6afa8918c461c1dd80c5063a950518fa4e950cd moved five
official libpq API symbols into src/common. Fix this by implementing
the SHLIB_EXPORTS mechanism for AIX, so affected libraries export the
same symbols that they export on Linux. This reintroduces symbols
pg_encoding_to_char, pg_utf_mblen, pg_char_to_encoding,
pg_valid_server_encoding, and pg_valid_server_encoding_id. Back-patch
to v13, where the aforementioned commit first appeared. While a minor
release is usually the wrong time to add or remove symbol exports in
libpq or libecpg, we should expect users to want each documented symbol.
Tony Reix
Discussion:
https://postgr.es/m/pr3pr02mb6396742e2fc3e77d37a920bc86...@pr3pr02mb6396.eurprd02.prod.outlook.com
diff --git a/src/Makefile.shlib b/src/Makefile.shlib
index 29a7f6d..6b79db1 100644
--- a/src/Makefile.shlib
+++ b/src/Makefile.shlib
@@ -329,7 +329,11 @@ $(shlib): $(OBJS) | $(SHLIB_PREREQS)
rm -f $(stlib)
$(LINK.static) $(stlib) $^
$(RANLIB) $(stlib)
+ifeq (,$(SHLIB_EXPORTS))
$(MKLDEXPORT) $(stlib) $(shlib) >$(exports_file)
+else
+ ( echo '#! $(shlib)'; $(AWK) '/^[^#]/ {printf "%s\n",$$1}'
$(SHLIB_EXPORTS) ) >$(exports_file)
+endif
$(COMPILER) -o $(shlib) $(stlib) -Wl,-bE:$(exports_file) $(LDFLAGS)
$(LDFLAGS_SL) $(SHLIB_LINK)
rm -f $(stlib)
$(AR) $(AROPT) $(stlib) $(shlib)
diff --git a/src/port/README b/src/port/README
index c446b46..97f18a6 100644
--- a/src/port/README
+++ b/src/port/README
@@ -28,5 +28,5 @@ applications.
from libpgport are linked first. This avoids having applications
dependent on symbols that are _used_ by libpq, but not intended to be
exported by libpq. libpq's libpgport usage changes over time, so such a
-dependency is a problem. Windows, Linux, and macOS use an export list to
-control the symbols exported by libpq.
+dependency is a problem. Windows, Linux, AIX, and macOS use an export
+list to control the symbols exported by libpq.
