链接/运行时不同GCC版本的风险?

我使用的是英特尔的C ++编译器,它在Linux上依赖于GNU提供的libc.so和libstdc ++

这是我的问题。 要访问一些最新的C ++ 11function,我需要使用GCC 4.7或更高版本附带的libstdc ++。 但我坚持使用CentOS 6.4。

在CentOS 6.4上,GCC的本地版本是4.4。 但是使用名为“SCL”的RedHat和名为“devtoolset-1.1”的软件包,我可以在“/ opt”下安装GCC 4.7。

我以上述方式设置了使用GCC 4.7,我可以使用更新的C ++ 11function。

所以这里是我的问题:如果用户运行我的程序只有libc.so / libstdc ++的GCC 4.4版本,所以在库path中,是否有风险,我的程序将有错误,由于4.4和4.7版本之间的不匹配那些图书馆?

如果有潜在的问题,我可以通过在GCC 4.7的libc和libstdc ++版本中静态链接来解决这个问题吗? 或者,如果/当我的代码dynamic加载的其他库select由系统范围的GCC 4.4包提供的较旧的libc / libstdc ++时,是否设置自己的其他问题?

Solutions Collecting From Web of "链接/运行时不同GCC版本的风险?"

正如Praetorian在下面的评论中指出的那样,devtoolset的使用实际上解决了我最初在这个答案中描述的问题。 我已经纠正了答案。

是否有风险,我的程序会由于4.4和4.7版本的这些库之间的一些不匹配而出现错误?

是。 链接到一个新的libstdc ++。然后试图运行和更旧的是100%不支持。 如果程序中的任何对象或者它使用的任何库都使用GCC 4.7进行编译并链接到libstdc ++,那么从4.7开始,则需要在运行时使用4.7(或更新)的libstdc ++。 它可能甚至不会运行,但如果它确实有可能是由于不兼容导致的沉默的错误。 但是,这不是一个问题,因为你没有链接到GCC 4.7的libstdc ++。所以,见下文。

我可以通过在GCC 4.7版本的libc和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的重点在于它允许你使用一个更新的GCC和更新的libstdc ++,但是不会在新的libstdc ++库上创建任何运行时依赖关系。 编译好的可执行文件只需要系统版本的libstdc ++,这样就可以在RHEL / CentOS上保存,甚至是没有安装devtoolset的系统。 (devtoolset所做的是将所有新的libstdc ++特性打包到一个静态库中,称为libstdc++_nonshared.a这样所有不存在于系统libstdc ++。中的部分就会静态链接,其他所有部分将来自系统libstdc ++ 。所以)。

如果你没有使用devtoolset,那么另外一个选择,而不是静态链接libstdc ++,就是将新的libstdc ++。发布到你的代码中,并确保它是首先被发现的(例如通过链接你的代码来引用新的libstdc ++。 )。 但是devtoolset不是必须的。

或者,如果/当我的代码动态加载的其他库选择由系统范围的GCC 4.4包提供的较旧的libc / libstdc ++时,是否设置自己的其他问题?

使用devtoolset时不会出现这样的问题,因为您总是使用较旧的libstdc ++,所以永远不会有冲突。