linking libjava.so RPATH problem

Thu Jul 7 06:09:16 GMT 2005

-----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 <vd at datamax.bg> 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-----