I have the following setup:
prog -> dynamically links to library A (version 1)
-> loads plugin library at runtime (via dlopen)
plugin -> statically links to library A (version 2)
I load the plugin library at runtime into prog with dlopen and import my test function lib2():
void * soPlugin = dlopen( "libplugin.so", RTLD_NOW|RTLD_LOCAL );
FlibFunc * pluginFunc = (FlibFunc*)dlsym( soPlugin, "lib2" );
Library A has a function printSomething() that's called from both prog and plugin, but is implemented slightly differently in version 1 and version 2 of library A.
When I now execute the printSomething() from prog, I get the output of Library A, version 1 variant of printSomething().
When I call the imported plugin function lib2(), which internally calls printSomething(), I'd except the output of the Library A, version 2 variant of printSomething().
However, again, the printSomething() from version 1 is executed. Thus I conclude, that when importing the symbols from the plugin at runtime the dynamic linker detects that already a shared library function named printSomething() is loaded and just reuses that.
(In my real application this behaviour causes segfaults because version 1 and 2 are no longer binary compatible and I access incompatible memory structures).
Question: Can I somehow force dlopen() to load all symbols from the plugin and ignore possible existing symbol duplicates?
A full minimalistic test is attached to the respective github issue:
https://github.com/ghorwin/MasterSim/issues/2
PS: I've read the usual references like
- C++ Dynamic Shared Library on Linux
- are runtime linking library globals shared among plugins loaded with dlopen?
- Dynamic Shared Library compilation with g++
but that specific problem isn't discussed there.
