我正在编写一个应用程序，我想在 rhel7 上使用 GCC 4.8。我的问题是我需要使用第 3 方共享库，该库是使用基于 rhel6 的 GCC 4.4 构建的。
【问题讨论】：
new int 与 4.8.5 中的 delete 匹配会发生什么，反之亦然？在界面上使用 extern "C" 并不是一个神奇的修复方法，因为在 C 语言中允许使用 int*。
有人建议我在我的应用程序之间创建一个接口 以及使用 extern "C" 来避免在 c++03 之间切换的 ABI 问题的库 到 c++11，并且只在接口中传递简单的 C 结构。
这是一个有意义的建议，因为在 C++ 接口中保持 ABI 兼容性太难了。
但他们也建议我可能需要复制和链接 来自 rhel6 机器的 libstdc++ 和 libgcc 自第 3 方 lib （和我的界面）是使用这些构建的。这就是我困惑的地方。
libgcc 和 libstdc++ 都保持向后兼容性（除非在 GCC5 中，但这不是您的情况），因此第 3 方库应该可以与 RHEL7 库一起正常工作。
鉴于 libstdc++ 的主要版本 (libName.so.major.minor.x.z) 和 libgcc 在 rhel6 和 7 上是一样的，我真的需要复制它们吗 从rhel6到7？
否（见上文）。
我不能在 rhel6 上构建我的界面，然后将其复制 将第 3 方库用于 rhel7（不复制旧的 libstdc++/libgcc）？
是的，这会起作用。
我的意思是，因为使用旧的 libstdc++/libgcc 构建的东西 应该是向前兼容的，不是吗？
正确（他们通常说“新版本的标准库向后兼容，即使用旧库编译的软件将继续工作”）。
我会遇到问题 (ABI) 吗？
如果您设法将在一个 libstdc++ 中创建的 STL 对象传递给另一个，您将遇到奇怪的错误。但是，如果您的库和第 3 方库都具有纯 C 接口，这应该不是问题（因为 STL 对象无法逃脱其包含的库）。
如果我确实需要从 rhel6 复制 libstdc++ 和 libgcc， 并将新旧版本链接在一起——我该怎么做？ 会有静态链接新版本的建议吗？
这将是不必要的负担。
【讨论】：