From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ian Lance Taylor <ian(at)airs(dot)com> |
Cc: | Andrew Perrin <andrew_perrin(at)unc(dot)edu>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: PL/Perl without shared libperl.a |
Date: | 2001-05-11 19:00:58 |
Message-ID: | 6462.989607658@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Ian Lance Taylor <ian(at)airs(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jason | 2001-05-11 19:06:46 | Web Hosting That Supports PostgreSQL |
Previous Message | Gilles DAROLD | 2001-05-11 18:48:59 | Oracle to pg update |