【发布时间】：2012-02-02 00:50:27
【问题描述】：
我一直在构建一个 C++ 库，我想将它作为单个 .so 文件分发给我的用户，并希望该 .so 文件在大多数情况下与发行版无关。因此，我一直在静态链接第 3 方库（但仍然动态链接到标准库）
现在它在 CentOS 6.2（64 位）上使用 g++ 构建良好，但在 CentOS 5.3 上构建时遇到问题。编译正常，但出现链接器错误：
cpu_timer.cpp:(.text+0x288): undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<long double>(long double)'
我已经对该错误进行了一些搜索，这似乎是标准库本身的版本控制问题。我的代码，或者更确切地说是 boost::thread 的代码，正在尝试调用 CentOS 5.3 中包含的标准库中不存在的新版本。
可以理解。所以我需要：
- 静态链接到 C++ 标准库（我已经对此进行了一些研究，这对 64 位系统来说是一个巨大的痛苦。大多数 64 位系统中包含的 libstdc++.a 不是使用 -fPIC 构建的，@987654321 @. 我必须自己构建 libstdc++.a。呃...
- 将 boost::timer 恢复为更兼容的版本。我主要将它用于便携式互斥锁，所以我不需要前沿的 boost::thread 功能。但这有其自身的问题：在 boost 网站上，他们在哪里记录了他们对标准库的依赖关系（以及哪些版本）。他们有记录吗？我好像找不到资料。另外，这是一个明智的选择吗？标准库还能给我带来哪些令人讨厌的惊喜？
鉴于我的目标（尽可能接近发行版不可知论者），您会推荐哪条路线？
【问题讨论】：
-
"他们在 boost 网站上的什么地方记录了他们对标准库的依赖关系（以及哪些版本）。他们有记录吗？" 标准库是 标准化——他们为什么需要这样做？ API 没有发生重大变化，只有 ABI 发生了变化，这超出了任何库的控制范围。
-
@ildjarn 也许，ABI 的变化是我的问题，而不是库界面的变化。无论哪种方式，我认为它不会改变我解决问题所需要做的事情，而且我仍然希望使用某种版本控制方案，即使对于标准库也是如此。除了 C++0x 之类的标准之外，是否没有其他版本？在这种情况下，ABI 更改是 CentOS 5.3 和 6.2 之间的唯一区别吗？
-
不同标准库版本之间可能会有各种 API 变化，但它们不是重大变化。实际上，ABI 更改是您的问题，我特别提到了这一点，以便您可以在线搜索一些内容。我不知道有什么办法可以解决这个问题，这正是 *nix 上的大多数程序都是开源的原因——因此它们可以被构建并链接到用户系统上存在的标准库。
标签： c++ boost static-linking dynamic-linking libstdc++