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

[Anton Berezin]

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.

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.
-- 
The moronity of the universe is a monotonically increasing function. --
Jarkko Hietaniemi