Re: PL/Perl without shared libperl.a
От | Tom Lane |
---|---|
Тема | Re: PL/Perl without shared libperl.a |
Дата | |
Msg-id | 6462.989607658@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: PL/Perl without shared libperl.a (Ian Lance Taylor <ian@airs.com>) |
Ответы |
Re: PL/Perl without shared libperl.a
|
Список | 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 по дате отправления: