问不同版本的GCC在链接/运行时的风险？

EN

正如普雷托里安在下面的评论中指出的那样，devtoolset的使用实际上解决了我最初在这个答案中描述的问题。我已经更正了答案。

由于这些库的4.4和4.7版本之间的一些不匹配，我的程序会有错误的风险吗？

是。100%不支持链接到较新的libstdc++.so，然后尝试运行较旧的a。如果你的程序中的任何对象或它使用的任何库都是用GCC 4.7编译的，并链接到4.7版本的libstdc++.so，那么你需要在运行时使用4.7 (或更高版本)的libstdc++.so。它可能甚至不会运行，但如果它运行了，由于不兼容，可能会有静默的bug。但这对你来说不是问题，因为你没有链接到GCC 4.7的libstdc++.so，见下文。

在GCC 4.7的libc和libstdc++版本中，我可以通过静态链接来解决这个问题吗？

libstdc++？

1)你只需要为libstdc++这么做，因为没有"GCC 4.7版的libc“这回事。Glibc是一个与GCC完全不同的项目。当你使用GCC 4.7时，你并没有使用不同的libc，你仍然在使用CentOS 6.4的系统libc。(顺便说一句，glibc维护者强烈反对静态链接glibc，而且glibc的一些特性在静态链接时将不起作用。)

2)静态链接libstdc++可以解决这个问题，但您不需要这样做，因为这就是Red Hat Developer Toolset (devtoolset)为您做的事情。devtoolset的全部意义在于，它允许您在不创建对较新的libstdc++库的任何运行时依赖项的情况下，使用较新的GCC和较新的libstdc++。编译后的可执行文件只需要RHEL/CentOS上始终存在的libstdc++.so系统版本，即使是没有安装devtoolset的系统也是如此。( devtoolset所做的是将所有新的libstdc++特性打包到一个名为libstdc++_nonshared.a的静态库中，以便静态链接到系统libstdc++.so中没有的所有部分，而其他所有部分将来自系统libstdc++.so)。

如果你没有使用devtoolset，那么另一个替代静态链接libstdc++的选择就是将较新的libstdc++.so与你的代码一起发布，并确保首先找到它(例如，通过将你的代码与引用较新的libstdc++.so的RPATH链接起来)。但是使用devtoolset就不需要了。

如果/当我的代码动态加载的其他库使用系统范围的GCC 4.4包提供的较旧的

/ libstdc++时，这是否会给我自己带来其他问题？

在使用devtoolset时不会有这样的问题，因为您总是使用较旧的libstdc++，因此不会有冲突。