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@xxxxxxx> 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
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
