A few questions on shared libraries: recursion, relative paths & duplicate names.

[Simon Hill <yacwroy at gmail dot com>]

I have a few related questions regarding specifying the location of
shared library files (".so"s).


It is possible to link shared libraries recursively.

It is possible to link shared libraries using relative paths. (using
-rpath $ORIGIN/<PATH> from ld).
I just found out how to do this here:
http://stackoverflow.com/questions/6311016/building-a-simple-hello-world-esque-example-of-using-lds-option-rpath-with-o
My project illustrating this:
http://dl.dropbox.com/u/31990648/SourceForge/project.zip



My questions are: (I tried solving these myself, and on coding forums,
but I can't get conclusive answers either way)



1) Is it possible to combine recursive and relative linking, so that
every link in the linking "tree" is directly relative to the location
of the immediate ancestor?

For example, if main.run links to (requires) bar.so, and bar.so links
to foo.so, can the location of foo.so be specified in bar.so and be
relative to bar.so? Even if main.run's link to bar.so is also
relative?

For example, something similar to the following:

Build Commands:
========
g++ -c -o obj/foo.o  src/foo.cpp -fPIC
g++ -c -o obj/bar.o  src/bar.cpp -fPIC
g++ -c -o obj/main.o src/main.cpp

g++ -shared -o lib/foo/foo.so obj/foo.o -Wl,-soname,foo.so
g++ -shared -o lib/bar/bar.so obj/bar.o -Wl,-soname,bar.so
-Wl,-rpath,$ORIGIN/../foo -l:foo.so
g++ -o run/main.run obj/main.o -Wl,-rpath,$ORIGIN/../lib/bar -l:bar.so
========
(Note: I use -l: as I read somewhere that this how you specify the
entire filename (sans prefix "lib" and suffix ".so") - not sure if
this is the right way)

Resulting file structure (libs and run only):
========
cwd/
... lib/
... ... foo/
... ... ... foo.so
... ... bar/
... ... ... bar.so
... run/
... ... main.run
========
Where:
- main.run finds bar.so by <PATH TO [main.run]>/../lib/bar/bar.so
- bar.so finds foo.so by <PATH TO [bar.so]>/../foo/foo.so

I tried a similar example here:
http://stackoverflow.com/questions/6323603/ld-using-rpath-origin-inside-a-shared-library-recursive
My project attempting this:
http://dl.dropbox.com/u/31990648/SourceForge/rpath_origin_recursive/project.zip



2) Secondly, if a new version of bar.so is built that instead requires
zug.so, at a different location than bar.so (preferably still using
relative paths), is it possible to have main.run built so that it is
capable of adapting and using the new bar.so? Even if some symbols
that were in foo.so are now in bar.so, and some that were in bar.so
are now in zug.so?

I'm guessing not (but hoping so), since it seems that after build-time
linking main.run seems to have both foo.so and bar.so listed as
dependencies in main.run (seen in readelf -d main.run when using
absolute paths). I'm just wondering if there is a way to force this.

Aside: what're the right terms to disambiguate build-time linking (ie,
ld), initial-runtime-linking (ie, execve) and mid-runtime-linking (ie,
dlopen)?



3) Lastly, is there any way to link to multiple shared libraries that
share the same filename but different (relative) paths without
requiring those libraries to know what directory they are inside (ie,
their soname (if they have one) doesn't include any path information)?
Mainly to avoid accidental name shadowing (I personally have a
different reason, but explaining it would take a while).



Thanks,
Simon Hill.