共享库与接口中的 STL 对象的 GCC 兼容性答案

【问题标题】：GCC compatibility of shared libraries with STL objects in their interface共享库与接口中的 STL 对象的 GCC 兼容性
【发布时间】：2015-11-27 13:46:14
【问题描述】：

我有一个带有 STL 对象的应用程序，用作插件编写器的 C++ 接口的一部分。

我知道最好的兼容性选择是使用 C 接口，但目前不可行。

我知道 libstdc++ 中从 GCC 3.4 到 4.8 的所有内容在 ABI 方面都高度兼容。

因此，例如，如果我使用 GCC 4.1 编译，而插件供应商编写使用 GCC 4.7 编译的代码，那么在具有对应于 GCC 4.7 或更高版本的 libstdc++ 版本的平台上，除了极端情况外，所有情况都很好，提供的 STL 使用仅限于 .so 内部，并且外部 .so 接口使用纯 C，遗憾的是我不是这种情况。

所以，我很好奇关于用作插件接口一部分的 STL 类的情况。我可以在未使用相同编译器版本（例如 4.1 和 4.8）编译的共享对象之间安全地传递 STL 对象吗？如果人们使用不同的编译器选项，我需要注意如何编译和解析模板吗？

我怀疑这会有问题。但是，GCC 人员所做的符号版本控制魔法有可能以某种方式使这项工作发挥作用。

对于这个问题，我只对 C++11 之前的编译和链接感兴趣。我也只对使用 GCC 的 Linux 和 Mac OS X 感兴趣。

【问题讨论】：

除非人们竭尽全力让它失败，否则它应该可以正常工作。
@marc 感谢您的反馈。您是否有机会提供更详细的参考或链接（或者可能依赖于此的项目）？
不过，对于 gcc >= 5.0，它不一定有效，因为它们 changed their ABI
谢谢@Walter - 乔纳森在邮件列表中指出了同样的事情，所以我知道库二进制接口在 5.0 中更改为 std::string 之类的东西。

标签： c++ gcc stl libstdc++

【解决方案1】：

我已经在 mailing list 上回答了这个问题，但正如 Marc 所说，它会起作用。

无论您是在 DSO 内部还是在接口中使用该库，都没有任何区别，该库无关紧要，并且无论哪种方式都向后兼容回 GCC 3.4。

【讨论】：

非常感谢您的回答！我会接受它，因为您是 libstdc++ 的权威。正如邮件列表中提到的，如果有任何文档，您可以向我指出您如何实现始终如一的高度 ABI 兼容性（例如，确保内存布局保持一致，内联保持一致等），那么我感激不尽。
@Jonathan Wakely 如果您遇到在 lib 中完成 new/malloc 的场景，指针会以某种方式传播到用户的应用程序并在那里完成删除/释放？我见过在同一个应用程序中有多个 libc 版本和多个内存分配器的情况，上述情况可能会导致应用程序崩溃。
@ErikAlapää，拥有多个 libc 是您的问题，而不是 libstdc++ 的问题。标准说分配函数是全局的，如果你有多个不兼容的分配函数违反了一个定义规则，那么你需要自己处理。
@JonathanWakely 我还是想指出这个问题——它已经困扰了很多程序员。