Thread: Problems with Perl
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. 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? 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. These events are illustrated in an script(1) capture file, which I have edited down to a version I have attached here. ++ kevin -- 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 WhiteheadScript started on Fri Nov 10 10:53:00 2000 [kevin@glynnis OLAP]$ cd pgsql [kevin@glynnis pgsql]$ make clean ... snip ... [kevin@glynnis pgsql]$ make ... snip ... make[4]: Leaving directory `/PG/OLAP/pgsql/src/interfaces/libpq' make -f Makefile all make[4]: Entering directory `/PG/OLAP/pgsql/src/interfaces/perl5' Skip blib/lib/Pg.pm (unchanged) /usr/bin/perl -I/usr/lib/perl5/5.00503/i386-linux -I/usr/lib/perl5/5.00503 /usr/lib/perl5/5.00503/ExtUtils/xsubpp -typemap/usr/lib/perl5/5.00503/ExtUtils/typemap -typemap typemap Pg.xs >xstmp.c && mv xstmp.c Pg.c cc -c -I../libpq -I../../include -Dbool=char -DHAS_BOOL -I/usr/local/include -O2 -DVERSION=\"1.8.0\" -DXS_VERSION=\"1.8.0\"-fpic -I/usr/lib/perl5/5.00503/i386-linux/CORE Pg.c Running Mkbootstrap for Pg () chmod 644 Pg.bs LD_RUN_PATH="/PG/OLAP/pgsql/src/interfaces/perl5/../libpq" cc -o blib/arch/auto/Pg/Pg.so -shared -L/usr/local/lib Pg.o -L/PG/OLAP/pgsql/src/interfaces/perl5/../libpq -lpq /usr/bin/ld: cannot open output file blib/arch/auto/Pg/Pg.so: Permission denied collect2: ld returned 1 exit status make[4]: *** [blib/arch/auto/Pg/Pg.so] Error 1 make[4]: Leaving directory `/PG/OLAP/pgsql/src/interfaces/perl5' make[3]: *** [all] Error 2 make[3]: Leaving directory `/PG/OLAP/pgsql/src/interfaces/perl5' make[2]: *** [all] Error 2 make[2]: Leaving directory `/PG/OLAP/pgsql/src/interfaces' make[1]: *** [all] Error 2 make[1]: Leaving directory `/PG/OLAP/pgsql/src' make: *** [all] Error 2 [kevin@glynnis pgsql]$ su Password: [root@glynnis pgsql]# cd src/interfaces/perl5 [root@glynnis perl5]# ls -l total 252 drwxr-xr-x 2 kevin users 1024 Nov 9 08:55 CVS -rw-r--r-- 1 kevin users 3517 May 31 20:07 Changes -rw-r--r-- 1 kevin users 2080 Oct 24 09:59 GNUmakefile -rw-r--r-- 1 kevin users 137 May 31 20:07 MANIFEST -rw-r--r-- 1 kevin users 21422 Nov 10 10:58 Makefile -rw-r--r-- 1 kevin users 1601 Jun 10 11:01 Makefile.PL -rw-r--r-- 1 kevin users 0 Nov 10 10:58 Pg.bs -rw-r--r-- 1 kevin users 72362 Nov 10 10:58 Pg.c -rw-r--r-- 1 kevin users 85208 Nov 10 10:58 Pg.o -rw-r--r-- 1 kevin users 18124 Sep 27 1998 Pg.pm -rw-r--r-- 1 kevin users 18921 Oct 24 10:00 Pg.xs -rw-r--r-- 1 kevin users 4824 Sep 27 1998 README drwxr-xr-x 5 root root 1024 Nov 9 09:07 blib drwxr-xr-x 3 kevin users 1024 Oct 29 12:09 examples -rw-r--r-- 1 kevin users 0 Nov 10 10:58 pm_to_blib -rw-r--r-- 1 kevin users 7795 Oct 24 10:00 ppport.h -rw-r--r-- 1 kevin users 7095 Mar 10 2000 test.pl -rw-r--r-- 1 kevin users 381 Sep 27 1998 typemap [root@glynnis perl5]# rm -rf blib [root@glynnis perl5]# exit exit [kevin@glynnis pgsql]$ make ... snip ... make -f Makefile all make[4]: Entering directory `/PG/OLAP/pgsql/src/pl/plperl' ***** * Cannot build PL/Perl because libperl is not a shared library. * Skipped. ***** make[4]: Leaving directory `/PG/OLAP/pgsql/src/pl/plperl' make[3]: Leaving directory `/PG/OLAP/pgsql/src/pl/plperl' make[2]: Leaving directory `/PG/OLAP/pgsql/src/pl' make[1]: Leaving directory `/PG/OLAP/pgsql/src' All of PostgreSQL successfully made. Ready to install. [kevin@glynnis pgsql]$ su Password: [root@glynnis pgsql]# make install ... snip ... Thank you for choosing PostgreSQL, the most advanced open source database engine. [root@glynnis pgsql]# exit exit [kevin@glynnis pgsql]$ Script done on Fri Nov 10 11:01:23 2000
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