From owner-freebsd-ports@FreeBSD.ORG Fri Feb 11 22:09:38 2005 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 935A216A4D3; Fri, 11 Feb 2005 22:09:38 +0000 (GMT) Received: from heechee.tobez.org (heechee.tobez.org [217.157.39.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 088EC43D39; Fri, 11 Feb 2005 22:09:37 +0000 (GMT) (envelope-from tobez@tobez.org) Received: by heechee.tobez.org (Postfix, from userid 1001) id 72B32125465; Fri, 11 Feb 2005 23:09:35 +0100 (CET) Date: Fri, 11 Feb 2005 23:09:35 +0100 From: Anton Berezin To: Sven Willenberger Message-ID: <20050211220935.GB79170@heechee.tobez.org> Mail-Followup-To: Anton Berezin , Sven Willenberger , Palle Girgensohn , freebsd-ports@freebsd.org, pgsql-general@postgresql.org References: <1108135462.10866.12.camel@lanshark.dmv.com> <510442EEF15A0237A0138D49@rambutan.pingpong.net> <1108138215.10866.20.camel@lanshark.dmv.com> <20050211203503.GA79170@heechee.tobez.org> <1108158115.10863.40.camel@lanshark.dmv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1108158115.10863.40.camel@lanshark.dmv.com> User-Agent: Mutt/1.4.2.1i X-Powered-By: FreeBSD http://www.freebsd.org/ cc: Palle Girgensohn cc: pgsql-general@postgresql.org cc: freebsd-ports@freebsd.org Subject: Re: databases/p5-postgresql-plperl links to wrong libperl.so X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2005 22:09:38 -0000 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 > > > > 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