Re: PL/Perl without shared libperl.a - Mailing list pgsql-general

From Tom Lane
Subject Re: PL/Perl without shared libperl.a
Date
Msg-id 6462.989607658@sss.pgh.pa.us
Whole thread Raw
In response to Re: PL/Perl without shared libperl.a  (Ian Lance Taylor <ian@airs.com>)
Responses Re: PL/Perl without shared libperl.a  (Ian Lance Taylor <ian@airs.com>)
List pgsql-general
Ian Lance Taylor <ian@airs.com> writes:
>> I believe you could actually use a non-shared libperl.a on Intel Linux;
>> just dike out the test for shared-ness in plperl's Makefile.PL.
>> The reason it's there is we couldn't think of a direct test for
>> position-independent code, which is the real requirement...

> I don't have context, so I'm not sure why that would be the real
> requirement.  Position independent code is a mechanism to make shared
> libraries more efficient.  Most ELF systems support creating shared
> libraries with position dependent code.  It's just less efficient.

Hm.  Most of the systems I've dealt with will refuse to build a shared
library from position-dependent code.  If libperl.a contains PIC code
then plperl can build a plperl.so that contains libperl linked directly
into its .so, rather than using a cross-reference to a shared
libperl.so.  But with non-PIC libperl, you're flat out of luck.
At least on non-ELF systems.

> It's possible to test whether you can build a shared library with
> position dependent code, if that is of interest.  The GNU binutils
> linker testsuite has such a test.

And on a non-GNU-binutils platform, how do we do that?  On any platform,
how do we determine what kind of code libperl.a actually contains?

            regards, tom lane

pgsql-general by date:

Previous
From: Gilles DAROLD
Date:
Subject: Oracle to pg update
Next
From: ryan@paymentalliance.net
Date:
Subject: VACUUM notices