From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 7 06:09:16 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C185B16A41C; Thu, 7 Jul 2005 06:09:16 +0000 (GMT) (envelope-from vd@datamax.bg) Received: from jengal.datamax.bg (jengal.datamax.bg [82.103.104.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D2CA43D46; Thu, 7 Jul 2005 06:09:15 +0000 (GMT) (envelope-from vd@datamax.bg) Received: from sinanica.bg.datamax (sinanica.bg.datamax [192.168.10.1]) by jengal.datamax.bg (Postfix) with QMQP id 7E9FF87CA; Thu, 7 Jul 2005 09:09:14 +0300 (EEST) Received: (nullmailer pid 3517 invoked by uid 1004); Thu, 07 Jul 2005 06:09:14 -0000 Date: Thu, 7 Jul 2005 09:09:14 +0300 From: Vasil Dimov To: Tom Schutter Message-ID: <20050707060914.GA3480@sinanica.bg.datamax> References: <20050706054753.GA69973@sinanica.bg.datamax> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 5.4-STABLE User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org, phantom@FreeBSD.org Subject: Re: linking libjava.so RPATH problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vd@datamax.bg List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2005 06:09:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jul 06, 2005 at 10:29:20AM -0600, Tom Schutter wrote: > On 7/5/05, Vasil Dimov wrote: > > On Tue, Jul 05, 2005 at 03:55:26PM -0600, Tom Schutter wrote: > > > I am having problems linking in the Java JVM libraries (libjava.so, > > > libverify.so, libjvm.so) into my executable. > > > > > > With these options added to my gcc command: > > > -L/usr/local/jdk1.4.2/jre/lib/i386 -ljava -lverify > > > -L/usr/local/jdk1.4.2/jre/lib/i386/server -ljvm > > > > > > It links ok, but when I try to run it I get: > > > $ ./testme > > > /libexec/ld-elf.so.1: Shared object "libjava.so" not found, required by > > > "testme" > > > > > > At this point ldd tells me: > > > $ ldd testme > > > testme: > > > libm.so.3 =3D> /lib/libm.so.3 (0x2807c000) > > > libjava.so =3D> not found (0x0) > > > libverify.so =3D> not found (0x0) > > > libjvm.so =3D> not found (0x0) > > > libpthread.so.1 =3D> /usr/lib/libpthread.so.1 (0x28097000) > > > libc.so.5 =3D> /lib/libc.so.5 (0x280bb000) > > > > > > Using -Xlinker -rpath -Xlinker PATH_TO_JRE_DIR, I can tell my executable to > > > look in the JRE dir for libjvm.so. I have verified that RPATH has been set > > > in the executable using objdump: > > > $ objdump -x testme | grep RPATH > > > RPATH /usr/local/jdk1.4.2/jre/lib/i386:/usr/local/jdk1.4.2/jre/lib/i386/server > > > > > > But when I run the executable, it cannot find libjvm.so: > > > $ ./testme > > > /libexec/ld-elf.so.1: Shared object "libjvm.so" not found, required by > > > "libjava.so" > > > > > > At this point ldd tells me: > > > $ ldd ./testme > > > ./testme: > > > libm.so.3 =3D> /lib/libm.so.3 (0x2807c000) > > > libjava.so =3D> /usr/local/jdk1.4.2/jre/lib/i386/libjava.so (0x28097000) > > > libverify.so =3D> /usr/local/jdk1.4.2/jre/lib/i386/libverify.so > > > (0x280b5000) > > > libjvm.so =3D> > > > /usr/local/jdk1.4.2/jre/lib/i386/server/libjvm.so (0x280ca000) > > > libpthread.so.1 =3D> /usr/lib/libpthread.so.1 (0x28702000) > > > libc.so.5 =3D> /lib/libc.so.5 (0x28726000) > > > libjvm.so =3D> not found (0x0) > > > libverify.so =3D> not found (0x0) > > > libjvm.so =3D> not found (0x0) > > > libstdc++.so.4 =3D> /usr/lib/libstdc++.so.4 (0x28800000) > > > > > > Note that at this point on Linux, testme runs ok. > > > > > > If I set LD_LIBRARY_PATH, the libraries are found (no output is correct): > > > $ LD_LIBRARY_PATH=3D/usr/local/jdk1.4.2/jre/lib/i386:/usr/local/jdk1.4.2/jre/lib/i386/server > > > ./testme > > > $ > > > > > > My questions are: > > > > > > 1) Why is the RPATH in the executable being ignored? > > > > Here are my suggestions: > > > > It is not being ignored, as you see: libjava.so, libverify.so and > > libjvm.so were found in /usr/local/jdk1.4.2/jre/lib/i386/ > > > > > 2) When I add the -rpath, I get two copies of a libjvm.so reference in testme, > > > one that resolves correctly, and one that doesn't. Why? > > > > What happens is that libjava.so "depends" on libjvm.so and libverify.so > > itself: > > % ldd /usr/local/jdk1.4.2/jre/lib/i386/libjava.so > > /usr/local/jdk1.4.2/jre/lib/i386/libjava.so: > > libjvm.so => not found (0x0) > > libverify.so => not found (0x0) > > > > and libverify.so "depends" on libjvm.so itself: > > % ldd /usr/local/jdk1.4.2/jre/lib/i386/libverify.so > > /usr/local/jdk1.4.2/jre/lib/i386/libverify.so: > > libjvm.so => not found (0x0) > > > > So, after finding libjava.so, libverify.so and libjvm.so, required by > > "testme" executable (thanks to its RPATH) the linker sees that > > libjava.so itself depends on libjvm.so and libverify.so and: > > 1. does not notice that they are already found/loaded > > 2. does not use the rpath in "testme" > > 3. starts looking for them in the standard path and does not find them > > > > > 3) What is the correct way of linking in libjvm.so? > > > > In my point of view the libjava.so and libverify.so shared objects are > > incorrect in the way that they depend on some shared objects, that are > > not located in the standard path *AND* libjava.so and libverify.so do > > not have RPATH in themselves. > > > > 1. Recompile libjava.so and libverify.so without -L... -l..., it is not > > needed anyway. > > OR > > 2. Recompile libjava.so and libverify.so with -L... -l..., but also add > > -rpath > > OR > > 3. Use ldconfig -m (see ldconfig_paths in rc.conf(5)) > > OR > > 4. Use LD_LIBRARY_PATH > > > > > Thanks, > > > -- > > > Tom Schutter > > This is making more sense now. > > 1) Does the fact that the linker does not realize that the libraries > have already been found indicate a bug in the linker? If so, how do I > best report it? I cannot think of any sensible reason for this behavior, so I guess it would be good if it can be "fixed" without breaking something else :) You best report it by creating a patch and using send-pr(1) to submit it. > 2) Because libjava.so and libverify.so were compiled by the java/jdk14 > port, your suggestions on recompiling those libraries should be done > within that framework. (This part is for you Alexey). Yes, I meant that you hack the port's Makefile and if something good comes out publish your changes with send-pr(1) :) > 3) For now, I will try using ldconfig, but I think that the better > solution is to fix the creation of the shared libraries. > > -- > Tom Schutter -----BEGIN PGP SIGNATURE----- iD8DBQFCzMcKFw6SP/bBpCARAviQAJ9SXLAegyH8o10+ikSJD1Pg1KbYwgCgr+LY raZMoJREpiETsKG8VEJGdVk= =hKrK -----END PGP SIGNATURE-----