I have a shared library libmylib.so
which uses libstdc++.so
There is another shared library that contains symbols with the same names of the symbols of libstdc++.so
. The library name is libmystd.so
libmystd.so
is loaded first, and then I use dlopen
in order to open libmylib.so
The problem is that the symbols are loaded from libmystd.so
instead of libstdc++.so
. How can I tell dlopen
to search for the symbols in libstdc++.so
first instead of libmystd.so
This is how I open libmylib.so
using dlopen
myHandle = dlopen("libmylib.so", RTLD_GLOBAL | RTLD_NOW)
Then I call a function from this shared library, but it crashes because the std::vercotr
destructor is called from libmystd.so
instead of libstdc++.so
0xedb4e936 _ZNSt6vectorISsSaISsEED2Ev + 76 libmystd.so
0xeb9494ff _ZN10MySymbolESs + 1db libmylib.so
How can I tell dlopen to search for the symbols in libstdc++.so first instead of libmystd.so
You can load libstdc++.so
first, and then its symbols will "win".
Presumably this is a problem for you because you want some other code to use libmystd.so
instead of libstdc++.so
.
There is really no way to mix two separate instances of C++ runtime in a single process safely. Any approach that will appear to work will have hidden gotcha's and will not really work (and debugging this will be painful).
The only sane approach is to either build code for exactly one of the implementations (and use that implementation), or to have two separate processes (each using the implementation it was compiled for) and use some form of inter-process communication between them.