This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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:
My project illustrating this:

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 links to (requires), and links
to, can the location of be specified in and be
relative to Even if's link to is also

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/ obj/foo.o -Wl,-soname,
g++ -shared -o lib/bar/ obj/bar.o -Wl,-soname,
g++ -o run/ obj/main.o -Wl,-rpath,$ORIGIN/../lib/bar
(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):
... lib/
... ... foo/
... ... ...
... ... bar/
... ... ...
... run/
... ...
- finds by <PATH TO []>/../lib/bar/
- finds by <PATH TO []>/../foo/

I tried a similar example here:
My project attempting this:

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

I'm guessing not (but hoping so), since it seems that after build-time
linking seems to have both and listed as
dependencies in (seen in readelf -d 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,

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).

Simon Hill.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]