Re: Strip -mmacosx-version-min options from plperl build

On 2022-08-24 We 18:56, Tom Lane wrote:
> 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.
>
> 			



It's built against cygwin perl 5.32.


I don't see anything like that in perl.h. It's certainly using
__attribute__() a lot.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com