Reputation: 205
I have an executable with four shared libraries and the dependency tree look like this: Executable app does a dlopen of foo.so
and bar.so
. foo.so
in turn links to fooHelper.so
and bar.so
links to barHelper.so
.
Now, the issue is that fooHelper.so
and barHelper.so
have some of the same symbols. For instance, let us say we have a func
with different implementations in fooHelper.so
and barHelper.so
. Is there a way to force foo.so
to use fooHelper.so
's implementation and bar.so
to use barHelper.so
's? What happens at present is that depending on the order of linking of the helpers, only one of the implementations of func
is used by both foo.so
and bar.so
. This is because of the default Unix linkage model, if the definition of a symbol is already loaded, then any other definitions from shared libraries loaded subsequently are just discarded. Basically, func
will be picked up from the helper library linked first. I need a way to explicitly specify the appropriate mapping without changing the source code of the shared libraries.
I'm working on Linux with g++ 4.4.
Upvotes: 1
Views: 431
Reputation: 213375
Is there a way to force foo.so to use fooHelper.so's implementation and bar.so to use barHelper.so's?
Yes: that's what RTLD_LOCAL
is for (when dlopen
ing foo.so
and bar.so
).
RTLD_LOCAL
This is the converse of RTLD_GLOBAL, and the default if neither flag
is specified. Symbols defined in this library are not made available
to resolve references in subsequently loaded libraries.
Upvotes: 3
Reputation: 3701
If both funcs happen to be in the same name-space, you're in a bit of trouble - if you are programming in C. The term to look for is "function overloading". There have been previous discussions on this topic, e.g. this one: function overloading in C
EDIT: http://litdream.blogspot.de/2007/03/dynamic-loading-using-dlopen-api-in-c.html
Upvotes: 0