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

On Fri, Feb 11, 2005 at 04:41:55PM -0500, Sven Willenberger wrote:
> 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(dot)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)

> > 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.

> 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.

Alright. It is not plperl folks fault, shared libraries and binaries do
things differently. Consider:

$ cat >binary.c
int main() {}
^D

$ gcc binary.c -Wl,-E -L/usr/local/lib \
/usr/local/lib/perl5/5.6.2/mach/auto/DynaLoader/DynaLoader.a \
-L/usr/local/lib/perl5/5.6.2/mach/CORE -lperl -lm -lcrypt -lutil \
-o binary

$ ldd ./binary
./binary:
libperl.so => /usr/lib/libperl.so (0x28066000)
libm.so.2 => /usr/lib/libm.so.2 (0x280fe000)
libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x28119000)
libutil.so.3 => /usr/lib/libutil.so.3 (0x28132000)
libc.so.4 => /usr/lib/libc.so.4 (0x2813b000)

$ cat >lib.c
int hello() { return 0; }
^D

$ gcc -fpic -DPIC -shared -Wl,-x,-soname,liblib.so.0 lib.c \
-Wl,-E -L/usr/local/lib \
/usr/local/lib/perl5/5.6.2/mach/auto/DynaLoader/DynaLoader.a \
-L/usr/local/lib/perl5/5.6.2/mach/CORE -lperl -lm -lcrypt -lutil \
-o liblib.so.0

$ ldd ./liblib.so.0
./liblib.so.0:
libperl.so => /usr/lib/libperl.so (0x28105000)
libm.so.2 => /usr/lib/libm.so.2 (0x2819d000)
libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x281b8000)
libutil.so.3 => /usr/lib/libutil.so.3 (0x281d1000)

Now, with -R things a-changing:

$ gcc -fpic -DPIC -shared -Wl,-x,-soname,liblib.so.0 lib.c \
-Wl,-E -L/usr/local/lib \
/usr/local/lib/perl5/5.6.2/mach/auto/DynaLoader/DynaLoader.a \
-L/usr/local/lib/perl5/5.6.2/mach/CORE -lperl -lm -lcrypt -lutil \
-R /usr/local/lib/perl5/5.6.2/mach/CORE \
-o liblib.so.0

$ ldd ./liblib.so.0
./liblib.so.0:
libperl.so => /usr/local/lib/perl5/5.6.2/mach/CORE/libperl.so (0x28105000)
libm.so.2 => /usr/lib/libm.so.2 (0x281ca000)
libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x281e5000)
libutil.so.3 => /usr/lib/libutil.so.3 (0x281fe000)

I am not that proficient with ld.so to know why it is like that, but the
easiest thing would be to persuade plperl to add that -R somewhere.

\Anton.
--
The moronity of the universe is a monotonically increasing function. --
Jarkko Hietaniemi