如果不公开std符号，则在旧系统上运行最近编译的.so。

Question

我的目标是使用最近的C++特性，如智能指针(至少std::shared_ptr)，用于linux，所以库应该在多个发行版上运行(显然，每个平台都会重新编译)。我瞄准的最老的gcc是4.4.x因为我需要支持RHEL6。对于这样的简单程序，似乎支持智能指针。

#include <iostream>
#include <memory>

int main()
{
    std::shared_ptr<int> aa;
    return 0;
}

我的库将公开一个C++ (extern)，我在API中不使用异常或C++类型。我是静态地链接libstdc++和libgcc并标记除API导出的符号以外的所有本地符号。。

我现在有另一个问题:在上述情况下，用较新的gcc (例如5.0甚至6.0)编译的库会在一个老的系统上工作，比如RHEL6，默认安装了gcc 4.4.x 可靠

理论上，使用更新的C++特性，但不公开符号或API中的任何特性都是可行的，但我不太确定，我宁愿问。

Answer 1

是。

实际上，关于你的情况的Red发布了一篇博客文章：

依赖第三方库或插件接口的用户仍然使用旧的ABI，他们可以用-D_GLIBCXX_USE_CXX11_ABI=0构建他们的代码，一切都应该很好。在大多数情况下，由于链接器的错误()抱怨涉及__cxx11的未解决符号，需要使用此标志时非常明显。 更改C++11的计划是让soname (和现有的二进制接口)单独使用，并使用不同的损坏名称来表示新的ABI。

由于您使用libstdc++静态编译，所有应用程序都将可靠地工作，或者无法链接。当发生这种情况时，请更改编译标志以添加_GLIBCXX_USE_CXX11_ABI=0。

总之，您不应该关心API的更改，而应该只关心ABI的更改。这一次，GNU团队做对了！

Answer 2

假设您在相同的发行版(即libc、libpthread等)上编译和运行库，那么它应该完全正常工作，唯一需要关心的是libgcc (gcc运行时库)。如果版本不同，如1.1和1.2，则可能会有不同的行为。所以，确保你在同一个版本上，即gcc-5/6没有带来任何新版本的libgcc，我没有意识到什么，我倾向于认为它在任何地方都是第1版，所以这里不用担心。