Thread: PL/Perl without shared libperl.a
Has anyone got advice on building postgres 7.1 with PL/Perl support WITHOUT having one's perl installation built with a shared libperl.a? I'm happy enough to build a special libperl.a for postgresql's use, but I don't want my general perl build to use it since perl's documentation notes a significant performance hit when using a shared libperl. If anyone's been able to do this I"d appreciate advice. Environment: Debian Linux 2.2r2, Perl 5.6.0 built from scratch. Thanks. -- -------------------------------------------------------------- Andrew J. Perrin - Programmer/Analyst, Desktop Support Children's Primary Care Research Group, UNC - Chapel Hill (919)966-9394 * andrew_perrin@unc.edu
Andrew Perrin <andrew_perrin@unc.edu> writes:
> Has anyone got advice on building postgres 7.1 with PL/Perl support
> WITHOUT having one's perl installation built with a shared libperl.a?
Try repeating the Perl build with shared-lib selected and then just
installing the resulting libperl.so beside libperl.a. However:
> I'm happy enough to build a special libperl.a for postgresql's use, but
> I don't want my general perl build to use it since perl's documentation
> notes a significant performance hit when using a shared libperl.
That advice is doubtless platform-specific, and I think it may well be
horsepucky for Intel-based Linux. Isn't *all* code built
position-independent on that platform?
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...
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > > I'm happy enough to build a special libperl.a for postgresql's use, but > > I don't want my general perl build to use it since perl's documentation > > notes a significant performance hit when using a shared libperl. > > That advice is doubtless platform-specific, and I think it may well be > horsepucky for Intel-based Linux. Isn't *all* code built > position-independent on that platform? No. > 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. 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. Ian
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
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
Ian Lance Taylor <ian@airs.com> writes:
> 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.
Hmm. Or perhaps we could just go ahead and try to build libperl.so,
but not abort the make if it fails. The reason for the shlib test
originally was that we didn't want the whole build of Postgres to blow
up if we couldn't link libperl.so. Seems like you end up with no
libperl.so either way, so perhaps we could hack the Makefile to not
treat link failure as fatal. The trick is that it's a makefile
generated by MakeMaker and not entirely under our control...
regards, tom lane
Alan Young <alany@harleypig.idiglobal.com> writes:
> plperl.c: In function `plperl_init_all':
> plperl.c:195: `my_perl' undeclared (first use in this function)
my_perl appears nowhere in the Postgres sources. I think you have
some sort of Perl-related breakage. Try asking some Perl gurus...
regards, tom lane
Tom Lane writes: > Hmm. Or perhaps we could just go ahead and try to build libperl.so, > but not abort the make if it fails. The reason for the shlib test > originally was that we didn't want the whole build of Postgres to blow > up if we couldn't link libperl.so. Seems like you end up with no > libperl.so either way, so perhaps we could hack the Makefile to not > treat link failure as fatal. The trick is that it's a makefile > generated by MakeMaker and not entirely under our control... Or we could get rid of that makefile and write our own. MakeMaker is a piece of gar^H^H^Hoverengineering anyway. I have such a makefile worked out as a proof of concept I did a while ago. I find it a lot better in many ways already. What I would suggest in any case is that we test at configure time (no time like configure time) whether libperl is shared (using the current, official mechanism). If not, we print a warning message and disable the build. If the user wants to try it anyway we could provide some way to override it, e.g., (stupid) --with-perl=i_want_plperl, or they could go into the directory and build it there. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
On Fri, 11 May 2001, Tom Lane wrote: > 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... Can you tell me how to fix this particular problem in compiling plperl? I've tried both a threading and non-threading compile of perl as well as a shared and non-shared compile (both 5.6.0 and 5.6.1) and get the same response everytime. The only hint I can find says that you can't do a threaded and shared perl at the same time, but none of the discussions mentioned plperl and it was 2 years old. Thanks for your time. In file included from plperl.c:80: /usr/lib/perl5/5.6.1/i686-linux-thread-multi/CORE/perl.h:469: warning: `USE_LOCALE' redefined ../../../src/include/config.h:38: warning: this is the location of the previous definition In file included from plperl.c:80: /usr/lib/perl5/5.6.1/i686-linux-thread-multi/CORE/perl.h:2155: warning: `DEBUG' redefined ../../../src/include/utils/elog.h:23: warning: this is the location of the previous definition plperl.c: In function `plperl_init_all': plperl.c:195: `my_perl' undeclared (first use in this function) plperl.c:195: (Each undeclared identifier is reported only once plperl.c:195: for each function it appears in.) plperl.c: In function `plperl_init_safe_interp': plperl.c:243: warning: passing arg 2 of `perl_parse' from incompatible pointer type plperl.c:251: `my_perl' undeclared (first use in this function) plperl.c: In function `plperl_create_sub': plperl.c:320: `my_perl' undeclared (first use in this function) plperl.c: In function `plperl_init_shared_libs': plperl.c:387: `my_perl' undeclared (first use in this function) plperl.c:387: warning: passing arg 3 of `Perl_newXS' from incompatible pointer type plperl.c:388: warning: passing arg 3 of `Perl_newXS' from incompatible pointer type plperl.c: In function `plperl_call_perl_func': plperl.c:399: `my_perl' undeclared (first use in this function) plperl.c: In function `plperl_func_handler': plperl.c:500: `my_perl' undeclared (first use in this function) plperl.c: In function `plperl_build_tuple_argument': plperl.c:2159: `my_perl' undeclared (first use in this function) make[1]: *** [plperl.o] Error 1 make[1]: Leaving directory `/home/src/postgresql-7.1/src/pl/plperl' make: *** [all] Error 2
On Fri, 11 May 2001, Tom Lane wrote:
> Andrew Perrin <andrew_perrin@unc.edu> writes:
> > Has anyone got advice on building postgres 7.1 with PL/Perl support
> > WITHOUT having one's perl installation built with a shared libperl.a?
>
> Try repeating the Perl build with shared-lib selected and then just
> installing the resulting libperl.so beside libperl.a. However:
>
> > I'm happy enough to build a special libperl.a for postgresql's use, but
> > I don't want my general perl build to use it since perl's documentation
> > notes a significant performance hit when using a shared libperl.
>
> That advice is doubtless platform-specific, and I think it may well be
> horsepucky for Intel-based Linux. Isn't *all* code built
> position-independent on that platform?
I'm afraid I'm way out of my depth here, so I'll leave it as "I don't
know".
>
> 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...
>
Well, what I've done as of now is to build perl with a shared libperl, but
not do the make install step; then configure postgresql with:
--with-perl
--with-libraries=/usr/src/perl-5.6.0
and I hand-edited Makefile.PL in src/pl/plperl to get rid of the check for
$Config{shlib} or whatever it was.
These steps let postgresql COMPILE fine; I haven't had a chance to test it
yet so don't know the outcome.
> regards, tom lane
>
Thanks for your help.
----------------------------------------------------------------------
Andrew J Perrin - Ph.D. Candidate, UC Berkeley, Dept. of Sociology
(Soon: Asst Professor of Sociology, U of North Carolina, Chapel Hill)
andrew_perrin@unc.edu - http://www.unc.edu/~aperrin