Re: Strip -mmacosx-version-min options from plperl build
От | Peter Eisentraut |
---|---|
Тема | Re: Strip -mmacosx-version-min options from plperl build |
Дата | |
Msg-id | 3c567776-e16a-0b9f-afd0-711e673f4fb3@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Strip -mmacosx-version-min options from plperl build (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Strip -mmacosx-version-min options from plperl build
|
Список | 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 по дате отправления: