How does relative RPATH work ?
Hi,
I'm using ld 5.8-1.294 on solaris 8.
I have a shared object with the following traits:
- run location: /net/A/B/C/D/E/libx.so
- install location: /net/a/b/c/libx.so
- dynamically depends on: /net/a/x/y/liby.so
If I need the runtime loader to find liby.so without having to specify a absolute search path (in production software /net/a will be replaced by another location, for example), then should this be the correct options on link line:
-R../../x/y -ly // relative to the location where libx.so resides
or is it:
-R../../../../../a/x/y -ly // relative to the location where libx.so is run from
If the latter is correct, then how do you suggest that we record relative search path information since the location where the pprogram/library is invoked from is not going to be known to the person building the program/library.
Thanks for help,
Prabal.
[935 byte] By [
prabal_k_b] at [2007-11-26 7:51:23]
# 1
Use the $ORIGIN macro with the -R option to specify the "current location".
Since $ is a special character to the shell and in makefiles, you usually need one or more escapes. Here is a sample makefile usage:
[code]libZ.so: $(OBJS)
CC -G -R \$$ORIGIN/../lib -o libZ.so $(OBJS) [/code]
# 2
Hi,
Thanks for the prompt response!
However, I don't think $ORIGIN can help much here.
Let us say, the producion software is installed at:
/net/cad-org/platform/tools/lib/libx.so
and it depends on:
/net/cad-org/platform/tools/utils/lib/liby.so
The user can run the software from any place and provided the program that loads libx.so does so by an explicit dlopen (it can figure out the path to x.so by backtracking to the installation root - /net/cad-org/platform/tools in this case), then there is no need so far to know anything about the "current location".
However, since libx.so does _not_ dlopen liby.so, but instead loads it via the runtime loader, the relative position of liby.so w.r.t the "current location" (or, working directory, where the program is run from) is no longer constant. Instead it depends on the current location. So, I don't see how $ORIGIN would help here.
Please correct me if I missed something here.
Thank you,
Prabal.
# 3
Sorry I wasn't clear. The $ORIGIN symbol expands to the directory in which the object (main program or shared library) originated.
If you build libX.so with a runpath of $ORIGIN/../foo/bar, all dependent libraries will be looked for in directory ../foo/bar relative to where libX.so is located. It doesn't matter where the main program is located in this example.
Managing shared libraries is too big a topic to cover thoroughly in a note in a forum. You can find details in the Linker and Libraries Guide at http://docs.sun.com/
Search for "linker libraries guide" in "titles only", then pick the one for your Solaris version. You can explore it on line, or download the pdf file.
For information about runpath and $ORIGIN, look in the index for "search paths".
