Problems with Perl

Kevin O'Gorman wrote:

It appears that something is messed up with regard to Perl
support on my system. Two things are happening, which may
or may not be related.

They are not related.

1) There is a complaint during make that
*****
* Cannot build PL/Perl because libperl is not a shared library.
* Skipped.
*****
I'm running a pretty vanilla RedHat 6.1 setup. What should
I do about that?

There are a couple of alternatives to get pl/perl (server-side perl
functions) built -- but none are real good for PostgreSQL 7.0.x.

2) Because _something_ was made for Perl, the 'make install'
has to be root. Okay. But this is leaving some stuff behind
that is owned by root. When I attempt a subsequent
'make clean; make' I get into permissions trouble, and have
to delete these things manually.

This would be the _client_side_ perl interface, Pg. Pg allows a perl
script to access the PostgreSQL server. PL/Perl allows the server to
run perl scripts as a procedural language inside the database system.

Two different animals.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Kevin O'Gorman writes:

2) Because _something_ was made for Perl, the 'make install'
has to be root. Okay. But this is leaving some stuff behind
that is owned by root. When I attempt a subsequent
'make clean; make' I get into permissions trouble, and have
to delete these things manually.

Yes, this is definitely broken. I just read that old thread ("[HACKERS]
perl interface bug?", 14 October 1998), and it was already considered
questionable then.

To recap, the Pg.so thing needs to know where libpq lives. If you link
with libpq out of the source tree then Pg.so forever tries to find libpq
there. So you relink Pg.so during 'make install' when libpq is already
installed at it's final location.

If I'm not completely mistaken, this behaviour could really only happen on
HPUX. Also on other platforms you would normally have to point
LD_LIBRARY_PATH to $(libdir) in order to get anything at all working.

Theoretically we could fix this now by sneaking the $(rpath) make variable
in to MakeMaker somehow, perhaps via OTHERLDFLAGS. However, the flag in
this variable is supposed to be used by the compiler driver -- if Perl
decides to use 'ld' to link the module you lose.

More to the point, 'rpath' is currently undefined on HPUX because HPUX
uses 'ld' to link shared libraries, but the shared library link uses
$(rpath), so it would break. Perhaps to start with, is there a way to use
the compiler driver to link shared libraries on HPUX?

And then, do we want to risk tricking around with MakeMaker, or should we
go for an HPUX specific fix?

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:

More to the point, 'rpath' is currently undefined on HPUX because HPUX
uses 'ld' to link shared libraries, but the shared library link uses
$(rpath), so it would break. Perhaps to start with, is there a way to use
the compiler driver to link shared libraries on HPUX?

I suppose you could do it that way if you were using gcc, but AFAICS
from its man page, the vendor cc has no switch to build libraries of
any sort. Just .o and executable files...

A bigger problem is that if interfaces/perl5 builds itself to refer to
an installed libpq to begin with, there'll be no way to run its selftest
without installing libpq first.

And then, do we want to risk tricking around with MakeMaker, or should we
go for an HPUX specific fix?

The real issue here is that make install builds new files in the source
tree. Perhaps "make install" should do a "make clean" after rebuilding
and installing.

Bear in mind that if we ever start using libtool, we will have this
problem all over the tree, not just in interfaces/perl5. At least on
HPUX, libtool's standard behavior is to relink just before install.
I would imagine that the other platforms with rpath capability would
do the same thing. So a perl-only solution may be pointless.

regards, tom lane

Tom Lane writes:

A bigger problem is that if interfaces/perl5 builds itself to refer to
an installed libpq to begin with, there'll be no way to run its selftest
without installing libpq first.

Actually, there are only a few platforms where this does work at all,
namely on AIX, FreeBSD <2.2, HPUX, SunOS 4, and Unixware 2. (information
decoded from Libtool sources) These platforms record the path where the
library was originally found. On all other platforms, shared libraries
are only searched in explicitly specified locations ("rpath") or some
default places (/usr/lib), *not* in the place it was found at link-time.

Furthermore, in order to run the self-test you need a running postmaster,
and you probably have libpq installed by the time you have a postmaster
up.

The real issue here is that make install builds new files in the source
tree. Perhaps "make install" should do a "make clean" after rebuilding
and installing.

Building new files during install is certainly unclean, but the real
problem is that you need to be root to install the Perl module, but not
for the rest (necessarily), so the rebuilt files are root-owned. Running
clean after install ought to work, but we could probably do better.

In fact, it would generally be better to get the rpath in there for any
platform, because otherwise we're back to ground zero where people need to
set up LD_LIBRARY_PATH in order for the Perl module to work.

Bear in mind that if we ever start using libtool, we will have this
problem all over the tree, not just in interfaces/perl5. At least on
HPUX, libtool's standard behavior is to relink just before install.
I would imagine that the other platforms with rpath capability would
do the same thing. So a perl-only solution may be pointless.

On my system (Linux) and on FreeBSD 4.1.1 (hub.org) libtool does exactly
what our code does: it installs the library file and creates two
symlinks. Relinking will only happen on the platforms listed above.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Peter Eisentraut wrote:

Kevin O'Gorman writes:

2) Because _something_ was made for Perl, the 'make install'
has to be root. Okay. But this is leaving some stuff behind
that is owned by root. When I attempt a subsequent
'make clean; make' I get into permissions trouble, and have
to delete these things manually.

Yes, this is definitely broken. I just read that old thread ("[HACKERS]
perl interface bug?", 14 October 1998), and it was already considered
questionable then.

To recap, the Pg.so thing needs to know where libpq lives. If you link
with libpq out of the source tree then Pg.so forever tries to find libpq
there. So you relink Pg.so during 'make install' when libpq is already
installed at it's final location.

If I'm not completely mistaken, this behaviour could really only happen on
HPUX. Also on other platforms you would normally have to point
LD_LIBRARY_PATH to $(libdir) in order to get anything at all working.

Well, I had the behavior on my RedHat 6.1 system. That's Linux, of course.
Is that what you mean, or is it that the current behavior is there so that
HPUX can be supported?

Theoretically we could fix this now by sneaking the $(rpath) make variable
in to MakeMaker somehow, perhaps via OTHERLDFLAGS. However, the flag in
this variable is supposed to be used by the compiler driver -- if Perl
decides to use 'ld' to link the module you lose.

More to the point, 'rpath' is currently undefined on HPUX because HPUX
uses 'ld' to link shared libraries, but the shared library link uses
$(rpath), so it would break. Perhaps to start with, is there a way to use
the compiler driver to link shared libraries on HPUX?

And then, do we want to risk tricking around with MakeMaker, or should we
go for an HPUX specific fix?

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

--
Kevin O'Gorman (805) 650-6274 mailto:kogorman@pacbell.net
Permanent e-mail forwarder: mailto:Kevin.O'Gorman.64@Alum.Dartmouth.org
At school: mailto:kogorman@cs.ucsb.edu
Web: http://www.cs.ucsb.edu/~kogorman/index.html
Web: http://trixie.kosman.via.ayuda.com/~kevin/index.html

"There is a freedom lying beyond circumstance,
derived from the direct intuition that life can
be grounded upon its absorption in what is
changeless amid change"
-- Alfred North Whitehead