Date: Fri, 11 Feb 2005 21:35:03 +0100 From: Anton Berezin <tobez@freebsd.org> To: Sven Willenberger <sven@dmv.com> Cc: freebsd-ports@freebsd.org Subject: Re: databases/p5-postgresql-plperl links to wrong libperl.so Message-ID: <20050211203503.GA79170@heechee.tobez.org> In-Reply-To: <1108138215.10866.20.camel@lanshark.dmv.com> References: <1108135462.10866.12.camel@lanshark.dmv.com> <510442EEF15A0237A0138D49@rambutan.pingpong.net> <1108138215.10866.20.camel@lanshark.dmv.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050211203503.GA79170>