rpath for library loading

Philipp Kraus

unread,

Dec 17, 2012, 3:53:58 AM12/17/12

to

Hello,

I hope somebody can explain me a little bit the loader process for
shared libraries.
I have got a library "libmylib.so", this depends on some other libs. I
have set the rpath
to "./". If I run "ldd libmylib.so" all depend libraries will be found.
I do not need to setup
any environment variables. All *.so files are in the same directory.

If I load my "libmylib.so" in my application I get an error that the
depend libraries are not
found. IMHO the rpath flag tells the library in which directory the
library should be found, so
in my case rpath is "./" the library should be found relative to
"libmylib.so" eg:

/home/my/lib/libmylib.so
/home/my/lib/libmydepend.so

ldd libmylib.so shows
libmydepend.so => ./libmydepend.so

So on loading libmylib.so the libmydepend.so should be also loaded
Do I understand it correct?

Thanks

Phil

Richard Kettlewell

unread,

Dec 17, 2012, 5:42:50 AM12/17/12

to

Philipp Kraus <philip...@flashpixx.de> writes:
> I hope somebody can explain me a little bit the loader process for
> shared libraries. I have got a library "libmylib.so", this depends on
> some other libs. I have set the rpath to "./". If I run "ldd
> libmylib.so" all depend libraries will be found. I do not need to
> setup any environment variables. All *.so files are in the same
> directory.
>
> If I load my "libmylib.so" in my application I get an error that the
> depend libraries are not found. IMHO the rpath flag tells the library
> in which directory the library should be found, so in my case rpath is
> "./" the library should be found relative to "libmylib.so" eg:

An rpath of . means it looks in the current directory at the time of
execution, not in the same location as the object containing the rpath.

--
http://www.greenend.org.uk/rjk/

Philipp Kraus

unread,

Dec 17, 2012, 7:36:54 AM12/17/12

to

That's bad. Can I add a flag that the rpath should be relative to the other
DLL? Under OSX I use @loader_path

Thanks

Phil

Richard Kettlewell

unread,

Dec 17, 2012, 8:26:23 AM12/17/12

to

I don’t think there’s any way to do this. But I don’t yet understand
why you need it: if your application can find the first library, and the
library it depends upon is in the same directory, surely it will find
that by the same means as it found the first.

--
http://www.greenend.org.uk/rjk/

Rainer Weikusat

unread,

Dec 17, 2012, 10:03:34 AM12/17/12

to

Philipp Kraus <philip...@flashpixx.de> writes:
> On 2012-12-17 11:42:50 +0100, Richard Kettlewell said:

[...]

>> An rpath of . means it looks in the current directory at the time of
>> execution, not in the same location as the object containing the rpath.
>
> That's bad. Can I add a flag that the rpath should be relative to the other
> DLL?

,----
| RPATH TOKEN EXPANSION
| The runtime linker provides a number of tokens that can be used
| in an rpath specification (DT_RPATH or DT_RUNPATH).
|
| $ORIGIN
| ld.so understands the string $ORIGIN (or equivalently
| ${ORIGIN}) in an rpath specification to mean the
| directory containing the application executable. Thus,
| an application located in somedir/app could be compiled
| with gcc -Wl,-rpath,'$ORIGIN/../lib' so that it finds an
| associated shared library in somedir/lib no matter where
| somedir is located in the directory hierarchy.
`---- [ld.so(8)]

BTW, a 'shared object' is something very much different than a
'dynamic link libray' which often isn't/ can't be shared dynamically
because it doesn't use position-independent code.