databases/p5-postgresql-plperl links to wrong libperl.so

[Sven Willenberger]

On Fri, 2005-02-11 at 21:35 +0100, Anton Berezin wrote:
> On Fri, Feb 11, 2005 at 11:10:15AM -0500, Sven Willenberger wrote:
> > On Fri, 2005-02-11 at 16:46 +0100, Palle Girgensohn wrote:
> > > --On fredag, februari 11, 2005 10.24.22 -0500 Sven Willenberger 
> > > <sven at dmv.com> wrote:
> 
> > > > FreeBSD 4.10
> > > > Postgresql 7.4.7
> > > > Perl 5.8.6_2 (from ports)
> 
> > > > When building databases/p5-postgresql-plperl the resultant plperl.so
> > > > (/usr/local/lib/postgresql/plperl.so) links to the libperl.so
> > > > in /usr/lib instead of /usr/local/lib/perl5/5.8.6/mach/CORE/.
> 
> > > > ldd /usr/local/lib/postgresql/plperl.so
> > > > /usr/local/lib/postgresql/plperl.so:
> > > >         libperl.so => /usr/lib/libperl.so (0x2810b000)
> > > >         libm.so.2 => /usr/lib/libm.so.2 (0x281a3000)
> > > >         libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x281be000)
> > > >         libutil.so.3 => /usr/lib/libutil.so.3 (0x281d7000)
> 
> > > > the configure script used by postgresql itself tests for the lib
> > > > directory via:
> > > >|> perl -MConfig -e 'print $Config{archlibexp}'
> > > > /usr/local/lib/perl5/5.8.6/mach
> 
> > > > so it appears to find it ... is something in ports overriding this
> > > > location or is there something I can -Define to have it use the correct
> > > > libperl.so?
> 
> > > I'd say this is a bug in the perl port. Just like it relinks the perl 
> > > binary, it should ultimately relink the libperl.so file.
> 
> I don't think so.  All symlinking that is done with /usr/bin/perl* does
> not disrupt functioning of the base system perl, only modifies the
> defaults used.  One can still do /usr/bin/perl5.005_03 and it will work
> perfectly.  Destroying /usr/lib/libperl.so will change that.
> 
> So I'd say, it is one of two things:
> 
> 1. _Either_ Sven has LD_LIBRARY_PATH set in his or global environment in
>    such a way that it includes /usr/lib in there.  If this is the case,
>    removing it would solve the problem.  The reason to not have /usr/lib
>    in LD_LIBRARY_PATH and for the described error to occur is two-fold:
>    first, /usr/lib is already in ldconfig cache, so having it in
>    LD_LIBRARY_PATH has no purpose;  secondly, LD_LIBRARY_PATH takes
>    precedence over any libraries linked with explicit directory
>    information, which is an intended behavior.
> 
This is not the case, so this one can be ruled out as a cause.

> 2. _Or_ plperl does not go all the way to be a conformant perl-embedding
>    application.  It looks at $Config{archlibexp}, but it does not follow
>    directions described in perlembed(1).  In this case it's linking
>    should be fixed to respect that.
> 
> \Anton.

This does seem to be the case. I built postgresqql from source this time
rather than ports with ./configure --with-perl --with-openssl and, as
you point out, the congigure does find its way to the CORE directory but
the end product still links to the /usr/lib/libperl.so location. 

The output from the lines building plperl are:

plperl.c: In function `compile_plperl_function':
plperl.c:541: warning: cast to pointer from integer of different size
plperl.c:730: warning: cast from pointer to integer of different size
gcc -O2 -fno-strict-aliasing -fpic -DPIC -I.
-I/usr/local/lib/perl5/5.8.6/mach/CORE -I../../../src/include   -c -o
eloglvl.o eloglvl.c
/usr/bin/perl /usr/local/lib/perl5/5.8.6/ExtUtils/xsubpp
-typemap /usr/local/lib/perl5/5.8.6/ExtUtils/typemap SPI.xs >SPI.c
gcc -O2 -fno-strict-aliasing -fpic -DPIC -I.
-I/usr/local/lib/perl5/5.8.6/mach/CORE -I../../../src/include   -c -o
SPI.o SPI.c
ar cr libplperl.a `lorder plperl.o eloglvl.o SPI.o | tsort`
ranlib libplperl.a
gcc -O2 -fno-strict-aliasing -fpic -DPIC -shared
-Wl,-x,-soname,libplperl.so.0 plperl.o eloglvl.o SPI.o
-L../../../src/port -Wl,-E
-L/usr/local/lib /usr/local/lib/perl5/5.8.6/mach/auto/DynaLoader/DynaLoader.a -L/usr/local/lib/perl5/5.8.6/mach/CORE -lperl -lm -lcrypt -lutil  -R/usr/local/pgsql/lib -o libplperl.so.0
rm -f libplperl.so
ln -s libplperl.so.0 libplperl.so

So somewhere in there it is preferentially picking the /usr/lib location
rather than the mach/CORE location. I am cc'ing the postgresql list on
this as well; at any rate it does not seem to be a port-specific or
perl-installation specific error here.

Sven Willenberger