From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Let's stop with the retail rebuilds of src/port/ files already
Date: Thu, 27 Sep 2018 15:48:36 -0400
Message-ID: <19581.1538077716@sss.pgh.pa.us> (raw)
In-Reply-To: <6570.1538020985@sss.pgh.pa.us>
References: <13022.1538003440@sss.pgh.pa.us>
<20180926231331.pngbiyqaawrxgnwf@alap3.anarazel.de>
<6570.1538020985@sss.pgh.pa.us>
I wrote:
> Here's a partial patch for that: it adds the third build variant
> to src/port/ and teaches libpq to use it. We'd want to likewise
> modify src/common/ and fix up other callers such as ecpg, but this
> seems to be enough to test whether the idea works or not.
> ...
> What I think would make sense is to push this and see what the
> buildfarm thinks of it. If there are unfixable problems then
> we won't have wasted time fleshing out the concept. Otherwise,
> I'll do the remaining pieces.
Well, the buildfarm did turn up one problem: on really old macOS
(cf prairiedog) the libpq link step fails with
ld: symbols names listed in -exported_symbols_list: exports.list not in linked objects
_pqsignal
Apparently, with that linker, the exported symbols list is resolved
against just what is found in the listed *.o files, not anything pulled
in from a library file.
Now, the question that raises in my mind is why is libpq.so exporting
pqsignal() at all? Probably there was once a reason for it, but nowadays
I would think that any client program using pqsignal() should get it
from -lpgport, not from libpq. Having more than one place to get it from
seems more likely to create issues than solve them. And we certainly
do not document it as a function available from libpq.
So my recommendation is to remove pqsignal from libpq's exports.txt.
I've verified that prairiedog builds happily with that change,
confirming my expectation that all consumers of the symbol can get it
from someplace else.
Now, if we go forward with that solution, there will be issues with
some other things that libpq exports without having defined itself:
src/backend/utils/mb/wchar.c:
pg_utf_mblen
src/backend/utils/mb/encnames.c:
pg_encoding_to_char
pg_char_to_encoding
pg_valid_server_encoding
pg_valid_server_encoding_id
Now, I'd already had my eye on those two files, because after applying a
similar fix for src/common/, those two files would be the only ones that
libpq needs to symlink from somewhere else.
What I was thinking of proposing was to move those two files out of the
backend and into src/common/, thereby normalizing their status as
modules available in both frontend and backend, and removing the need
for a special build rule for them in libpq. (initdb could be simplified
too.) Per this discovery, we'd need to also remove these symbols from
libpq's exports list, meaning that clients *must* get them from -lpgcommon
not from libpq.
There's a small chance that this'd break third-party clients that
are using these symbols out of libpq. We've never documented them
as being available, but somebody might be using them anyway.
If that does happen, it could be repaired by linking against -lpgcommon
along with libpq, but it'd possibly still make people unhappy.
Comments?
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, pgsql-hackers@lists.postgresql.org
Subject: Re: Let's stop with the retail rebuilds of src/port/ files already
In-Reply-To: <19581.1538077716@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox