linking RPATH problem

Vasil Dimov vd at
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 (,
>, 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/ Shared object "" not found, required by
> "testme"
> At this point ldd tells me:
> $ ldd testme
> testme:
> =3D> /lib/ (0x2807c000)
> =3D> not found (0x0)
> =3D> not found (0x0)
> =3D> not found (0x0)
> =3D> /usr/lib/ (0x28097000)
> =3D> /lib/ (0x280bb000)
> Using -Xlinker -rpath -Xlinker PATH_TO_JRE_DIR, I can tell my executable to
> look in the JRE dir for  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
> $ ./testme
> /libexec/ Shared object "" not found, required by
> ""
> At this point ldd tells me:
> $ ldd ./testme
> ./testme:
> =3D> /lib/ (0x2807c000)
> =3D> /usr/local/jdk1.4.2/jre/lib/i386/ (0x28097000)
> =3D> /usr/local/jdk1.4.2/jre/lib/i386/
> (0x280b5000)
> =3D>
> /usr/local/jdk1.4.2/jre/lib/i386/server/ (0x280ca000)
> =3D> /usr/lib/ (0x28702000)
> =3D> /lib/ (0x28726000)
> =3D> not found (0x0)
> =3D> not found (0x0)
> =3D> not found (0x0)
> =3D> /usr/lib/ (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:, and were found in /usr/local/jdk1.4.2/jre/lib/i386/

> 2) When I add the -rpath, I get two copies of a reference in testme,
>   one that resolves correctly, and one that doesn't.  Why?

What happens is that "depends" on and
% ldd /usr/local/jdk1.4.2/jre/lib/i386/
/usr/local/jdk1.4.2/jre/lib/i386/ => not found (0x0) => not found (0x0)

and "depends" on itself:
% ldd /usr/local/jdk1.4.2/jre/lib/i386/
/usr/local/jdk1.4.2/jre/lib/i386/ => not found (0x0)

So, after finding, and, required by
"testme" executable (thanks to its RPATH) the linker sees that itself depends on and 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

In my point of view the and shared objects are
incorrect in the way that they depend on some shared objects, that are
not located in the standard path *AND* and do
not have RPATH in themselves.

1. Recompile and without -L... -l..., it is not
needed anyway.
2. Recompile and with -L... -l..., but also add
3. Use ldconfig -m (see ldconfig_paths in rc.conf(5))

> 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 :

More information about the freebsd-hackers mailing list