问题
I have a shared library (so) object which exposes a C API (extern "C"
). It doesn't use C++ in the API nor throws exceptions. Internally it does use C++, especially std::map
and other containers, plus some trivial templates.
My goal is to be able to provide this library to any program in unix (I compile multiple versions for each target linux distro) without having standard library symbol issues with the loader program (i.e. a program which loads my library with dlopen
should function properly even if it was compiled with another version of the standard library).
Here's what I did by reading around:
- Statically linked both libstdc++ and libgcc
used a linker script to mark all symbols local except the C-ABI ones exported from the API
linker_script.lds { global: my_api_func; local: *; }
g++ shared.cpp -Wl,--version-script=vs.lds -fPIC -static-libstdc++ -static-libgcc -shared -o libshared.so
My question at this point: will this suffice to keep me using C++ internally and avoid all conflicts if the loading program uses a different (major/minor/totally different) version of the standard library? What if I use C++14 or something even more recent and follow the aforementioned procedure?
回答1:
My question at this point: will this suffice to keep me using C++ internally and avoid all conflicts if the loading program uses a different (major/minor/totally different) version of the standard library?
That should suffice. But do verify:
- That there are no unexpected undefined symbols from
std::
withnm -C --undefined-only <my.so>
. - That your library does not export any symbols from the C++ standard library with
nm -C --defined-only --extern-only <my.so>
. And any symbols you do not expect it to export. - That there are no unexpected required shared libraries with
readelf -d <my.so>
.
What if I use C++14 or something even more recent and follow the aforementioned procedure?
As long as you verify what symbols your library consumes and exports, this method is expected to work.
来源:https://stackoverflow.com/questions/51026785/avoiding-standard-library-conflicts-in-unix