C++ 避免unix中的标准库冲突

我有一个共享库（so）对象，它公开了一个C API（

extern“C”

）。它不使用API中的C++，也不抛出异常。在内部它使用C++，尤其是<代码> STD:：MAP< /Cl>和其他容器，加上一些普通的模板。 我的目标是能够将这个库提供给unix中的任何程序（我为每个目标linux发行版编译多个版本），而不会出现加载程序的标准库符号问题（即，使用

dlopen

加载我的库的程序应能正常运行，即使它是用标准库的另一个版本编译的）

以下是我通过四处阅读所做的：

静态链接libstdc++和libgcc

使用链接器脚本将所有符号标记为本地符号，但从API导出的C-ABI符号除外

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或更近期的一些东西，遵循上述过程，那该怎么办？ 我现在的问题是：这是否足以让我在内部使用C++，并且如果加载程序使用标准库的不同（主/次/完全不同）版本，则避免所有冲突？

这应该足够了。但请确认：

使用

nm-C的
std:：
中没有意外的未定义符号-仅未定义

<> LI>您的库不从C++标准库导出任何符号，代码。以及任何您不希望导出的符号。

与

readelf-d

没有意外需要的共享库

如果我使用C++14或更新的东西，并遵循前面提到的过程，会怎么样

---

只要您验证库使用和导出的符号，此方法就可以正常工作。

我通常看到程序在某些“$LIB”文件夹中发送它们自己版本的库，然后使用

LD_PRELOAD=“/usr/$LIB/libstdc++.so.6…”

喜欢。我想使用docker或是一种方法。@KamilCuk这太恶心了。他们应该了解

-Wl，-rpath=$ORIGIN

。