Re: Strip -mmacosx-version-min options from plperl build - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Strip -mmacosx-version-min options from plperl build
Date
Msg-id 1181344.1661381760@sss.pgh.pa.us
Whole thread Raw
In response to Re: Strip -mmacosx-version-min options from plperl build  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Strip -mmacosx-version-min options from plperl build
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> On 2022-08-24 We 09:30, Tom Lane wrote:
>> Presumably this is caused by not having
>> > -Wl,--export-all-symbols
>> which is something we ought to be injecting for ourselves if we
>> aren't doing anything to export the magic-block constant explicitly.
>> But I too am confused why we haven't seen this elsewhere.

> Me too. I note that we have -Wl,--out-implib=libplperl.a but we don't
> appear to do anything with libplperl.a.

I've poked around and formed a vague theory, based on noting this
from the ld(1) man page:

       --export-all-symbols
           ... When symbols are
           explicitly exported via DEF files or implicitly exported via
           function attributes, the default is to not export anything else
           unless this option is given.

So we could explain the behavior if, say, plperl's _PG_init were
explicitly marked with __attribute__((visibility("default"))) while
its Pg_magic_func was not.  That would work anyway as long as
--export-all-symbols was being used at link time, and would produce
the observed symptom as soon as it wasn't.

Now, seeing that both of those functions are surely marked with
PGDLLEXPORT in the source code, how could such a state of affairs
arise?  What I'm thinking about is that _PG_init's marking will be
determined by the extern declaration for it in fmgr.h, while
Pg_magic_func's marking will be determined by the extern declaration
obtained from expanding PG_MODULE_MAGIC.  And there are a boatload
of Perl-specific header files read between those points in plperl.c.

In short: if the Cygwin Perl headers redefine PGDLLEXPORT (unlikely)
or somehow #define "__attribute__()" or "visibility()" into no-ops
(perhaps more likely) then we could explain this failure, and that
would also explain why it doesn't fail elsewhere.

I can't readily check this, since I have no idea exactly which version
of the Perl headers lorikeet uses.

            regards, tom lane



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: shadow variables - pg15 edition
Next
From: Nikita Glukhov
Date:
Subject: Re: SQL/JSON features for v15