Re: Let's stop with the retail rebuilds of src/port/ files already

On 09/27/2018 03:48 PM, Tom Lane wrote:
> 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.
>


Seems a small enough price to pay.

cheers

andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services