pl/perl won't build under 7.1.3

On Sun, 2001-11-25 at 15:07, -wiseguy wrote:

Hi:

Why won't pl/perl build under the install for postgresql 7.1.3? My perl
installation only has libperl in the archive format (libperl.a) and the perl
makefile calls for libperl.so...building perl form scratch is not an option.
Is there a quick hack to allow pl/perl to build using libperl.a?

On some systems, you can exlpode libperl.a and rebuild is as a .so --
this works on Linux x86. I have taken the approach of building a
separate libperl.so. It is change of just a few lines to the perl rpm
spec on redhat. Then I install the .so file and use --forcperl with
Lamar's RPM spec. You didn't say what platform you are using, so I don't
know if any of the specific changes are useful to you. If they are , let
me know and I can send you a diff.

--
Karl DeBisschop
Director, Software Engineering & Development
Learning Network / Information Please
www.learningnetwork.com / www.infoplease.com

"-wiseguy" <no-one@all.net> writes:

Hi:

Why won't pl/perl build under the install for postgresql 7.1.3? My perl
installation only has libperl in the archive format (libperl.a) and the perl
makefile calls for libperl.so...building perl form scratch is not an option.
Is there a quick hack to allow pl/perl to build using libperl.a?

You need a dynamic library for dynamic extensions, you can't use a
static library.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

Hi,

I "fixed" the Makefile.PL script under src/pl/plperl and
removed the if ($Config{'useshrplib'} ne 'true') { ... } code.

This will link in the static libperl.a file. The only down side
of this is your libplperl.so file is going to be larger.

Let me know if this works for you also.

Jim

PS. Running on RedHat Linux version 4.x to 7.2 with the above hack.

"-wiseguy" <no-one@all.net> writes:

Hi:

Why won't pl/perl build under the install for postgresql 7.1.3? My

perl

installation only has libperl in the archive format (libperl.a) and

the perl

makefile calls for libperl.so...building perl form scratch is not an

option.

Is there a quick hack to allow pl/perl to build using libperl.a?

You need a dynamic library for dynamic extensions, you can't use a
static library.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

---------------------------(end of

broadcast)---------------------------

"Jim Buttafuoco" <jim@spectrumtelecorp.com> writes:

Hi,

I "fixed" the Makefile.PL script under src/pl/plperl and
removed the if ($Config{'useshrplib'} ne 'true') { ... } code.

This will link in the static libperl.a file. The only down side
of this is your libplperl.so file is going to be larger.

That's not the only downside, on most architectures it won't
work. Code used like this should be compiled with -fpic, and static
libraries rarely are.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

Ok, I believe you. I am going to try on Solaris 8 and Tru64 now. I
believe this is a real pain because I don't know of anyone that "ships"
perl with a shared lib.

"Jim Buttafuoco" <jim@spectrumtelecorp.com> writes:

Ok, I believe you. I am going to try on Solaris 8 and Tru64 now. I
believe this is a real pain because I don't know of anyone that "ships"
perl with a shared lib.

It's easy enough to get a shared perl lib if you build from source:
just say yes when the Configure script asks if you want one.

Precompiled distributions tend not to do this, though.

regards, tom lane

Tom and all,

I really have stopped "building from source" for most base packages and
try to use what is provided by the vendor (make's upgrades easier). I
think if we can build plperl with the static library and it works then
we should do so.

Again I will test with Solaris 8 (using the perl that is shipped with
it) and Tru64 (again using the perl that is shipped with it) tonight and
let you know if it works

Jim

"Jim Buttafuoco" <jim@spectrumtelecorp.com> writes:

Ok, I believe you. I am going to try on Solaris 8 and Tru64 now.

I

believe this is a real pain because I don't know of anyone that

"ships"