Tom Lane <tgl@sss.pgh.pa.us> writes:
> 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.
That's true. I was wondering what the real requirement is. I guess
it is whether the code in libperl.a can be used directly to build a
shared library.
> > 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?
The test case is independent of the GNU binutils. It's there to make
sure the GNU linker works correctly, but in principle it can be used
to test other linkers. But that doesn't seem to be what you need to
test.
As far as I know, there is no simple way to test whether libperl.a is
compiled as position independent code or not. But it would be fairly
easy to test whether you can build a shared library using libperl.a,
by writing a little test case which does just that. The test could be
run at run time or at configure time.
Ian
