On Fri, 2005-02-11 at 23:20 +0100, Anton Berezin wrote: > On Fri, Feb 11, 2005 at 11:09:35PM +0100, Anton Berezin wrote: > > 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 > > > > > > <[EMAIL PROTECTED]> 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) > > Grrrr. What I wrote does not make any sense at all. :-( > > It is plperl fault after all, > > perl -MExtUtils::Embed -le ldopts > > clearly states > > -Wl,-R/usr/local/lib/perl5/5.6.2/mach/CORE -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 -lc -lcrypt -lutil > > Note the -R here, and the absense of it in the lines you posted. > > Anton 'need more coffee or more sleep' Berezin
Ok, I have found a couple lines in configure (4354-4356) and config/perl.m4 (31-33) that confuse me a bit as it seems that their sole purpose is to actually strip *out* the -R/usr/local/lib/perl5/5.8.6/mach/CORE portion of the linker args: pgac_tmp1=`$PERL -MExtUtils::Embed -e ldopts` pgac_tmp2=`$PERL -MConfig -e 'print $Config{ccdlflags}'` perl_embed_ldflags=`echo X"$pgac_tmp1" | sed "s/^X//;s%$pgac_tmp2%%"` now pgac_tmp1 contains what should really be the ld args for the final build/linking, pgac_tmp2 contains -Wl,-R/usr/local/lib/perl5/5.8.6/mach/CORE it looks like the sed line is stripping out pgac_tmp2 from the pgac_tmp1 leaving the system to use the default perl libperl.so. when I modified perl_embed_ldflags to not remove the -R line, the compile works and links to the proper libperl.so Sven P.S. From this point forward I will direct any followups to just the postgresql mailing list as it does not appear to FreeBSD specific at this point). ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster