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