linking libjava.so RPATH problem

Vasil Dimov vd at datamax.bg
Wed Jul 6 05:47:56 GMT 2005


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 155 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20050706/3675a864/attachment.bin


More information about the freebsd-hackers mailing list