避免Unix中的标准库冲突 [英] Avoiding standard library conflicts in unix

问题描述

我有一个共享库(so)对象，该对象公开了C API(extern "C").它不使用API​​中的C ++，也不抛出异常.在内部，它确实使用C ++，尤其是std::map和其他容器，以及一些琐碎的模板.

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.

我的目标是能够将该库提供给Unix中的任何程序(我为每个目标linux发行版编译多个版本)，而不会导致加载程序(例如，用即使它是用其他版本的标准库编译的也应该可以正常工作.

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:

1. 静态链接libstdc ++和libgcc

2. 使用了链接描述文件来标记所有本地符号，但从API导出的C-ABI符号除外

1. Statically linked both libstdc++ and libgcc

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

我现在的问题是:如果加载程序使用标准库的不同版本(主要/次要/完全不同)，是否足以让我在内部使用C ++并避免所有冲突?如果我使用C ++ 14或更高版本并遵循上述步骤怎么办?

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?

推荐答案

我现在的问题是:如果加载程序使用标准库的不同版本(主要/次要/完全不同)，是否足以让我在内部使用C ++并避免所有冲突?

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:

1. std::和nm -C --undefined-only <my.so>中没有意外的未定义符号.
2. 您的库不会使用nm -C --defined-only --extern-only <my.so>从C ++标准库导出任何符号.还有您不希望其导出的任何符号.
3. readelf -d <my.so>没有意外的必需共享库.

1. That there are no unexpected undefined symbols from std:: with nm -C --undefined-only <my.so>.
2. 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.
3. That there are no unexpected required shared libraries with readelf -d <my.so>.

如果我使用C ++ 14或更新的版本并遵循上述步骤怎么办?

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.

这篇关于避免Unix中的标准库冲突的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！