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

From Peter Eisentraut
Subject Re: Strip -mmacosx-version-min options from plperl build
Date
Msg-id 3c567776-e16a-0b9f-afd0-711e673f4fb3@enterprisedb.com
Whole thread Raw
In response to Re: Strip -mmacosx-version-min options from plperl build  (Andres Freund <andres@anarazel.de>)
Responses Re: Strip -mmacosx-version-min options from plperl build
List pgsql-hackers
On 20.08.22 23:44, Andres Freund wrote:
> On 2022-08-20 16:53:31 -0400, Tom Lane wrote:
>> Andres Freund <andres@anarazel.de> writes:
>>> Maybe a daft question: Why do want any of the -l flags other than -lperl? With
>>> the patch configure spits out the following on my debian system:
>>
>>> checking for CFLAGS to compile embedded Perl... -DDEBIAN
>>> checking for flags to link embedded Perl...   -L/usr/lib/x86_64-linux-gnu/perl/5.34/CORE -lperl -ldl -lm -lpthread
-lc-lcrypt
 
>>
>>> those libraries were likely relevant to build libperl, but don't look relevant
>>> for linking to it dynamically.
>>
>> I'm certain that there are/were platforms that insist on those libraries
>> being mentioned anyway.  Maybe they are all obsolete now?
> 
> I don't think any of the supported platforms require it for stuff used inside
> the shared library (and we'd be in trouble if so, check e.g. libpq.pc). But of
> course that's different if there's inline function / macros getting pulled in.
> 
> Which turns out to be an issue on AIX. All the -l flags added by perl can be
> removed for xlc, but for gcc, -lpthreads (or -pthread) it is required.
> 
> Tried it on Solaris (32 bit, not sure if there's a 64bit perl available),
> works.

Does that mean my proposed patch (v2) is adequate for these platforms, 
or does it need further analysis?



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Strip -mmacosx-version-min options from plperl build
Next
From: Jacob Champion
Date:
Subject: Re: [PATCH] Expose port->authn_id to extensions and triggers