blocks|key|2817427|text|正如普雷托里安在下面的评论中指出的那样，devtoolset的使用实际上解决了我最初在这个答案中描述的问题。我已经更正了答案。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2817428|2817429|由于这些库的4.4和4.7版本之间的一些不匹配，我的程序会有错误的风险吗？|blockquote|2817430|2817431|2817432|是。100%25不支持链接到较新的libstdc%2B%2B.so，然后尝试运行较旧的a。如果你的程序中的任何对象或它使用的任何库都是用GCC+4.7编译的，并链接到4.7版本的libstdc%2B%2B.so，那么你需要在运行时使用4.7+(或更高版本)的libstdc%2B%2B.so。它可能甚至不会运行，但如果它运行了，由于不兼容，可能会有静默的bug。但这对你来说不是问题，因为你没有链接到GCC+4.7的libstdc%2B%2B.so，见下文。|2817433|在GCC+4.7的libc和libstdc%2B%2B版本中，我可以通过静态链接来解决这个问题吗？|2817434|+libstdc%2B%2B？|2817435|2817436|2817437|1)你只需要为libstdc%2B%2B这么做，因为没有"GCC+4.7版的libc“这回事。Glibc是一个与GCC完全不同的项目。当你使用GCC+4.7时，你并没有使用不同的libc，你仍然在使用CentOS+6.4的系统libc。(顺便说一句，glibc维护者强烈反对静态链接glibc，而且glibc的一些特性在静态链接时将不起作用。)|2817438|2)静态链接libstdc%2B%2B可以解决这个问题，但您不需要这样做，因为这就是Red+Hat+Developer+Toolset+(devtoolset)为您做的事情。devtoolset的全部意义在于，它允许您在不创建对较新的libstdc%2B%2B库的任何运行时依赖项的情况下，使用较新的GCC和较新的libstdc%2B%2B。编译后的可执行文件只需要RHEL/CentOS上始终存在的libstdc%2B%2B.so系统版本，即使是没有安装devtoolset的系统也是如此。(+devtoolset所做的是将所有新的libstdc%2B%2B特性打包到一个名为libstdc%2B%2B_nonshared.a的静态库中，以便静态链接到系统libstdc%2B%2B.so中没有的所有部分，而其他所有部分将来自系统libstdc%2B%2B.so)。|CODE|2817439|如果你没有使用devtoolset，那么另一个替代静态链接libstdc%2B%2B的选择就是将较新的libstdc%2B%2B.so与你的代码一起发布，并确保首先找到它(例如，通过将你的代码与引用较新的libstdc%2B%2B.so的RPATH链接起来)。但是使用devtoolset就不需要了。|2817440|如果/当我的代码动态加载的其他库使用系统范围的GCC+4.4包提供的较旧的|2817441|+/+libstdc%2B%2B时，这是否会给我自己带来其他问题？|2817442|2817443|2817444|在使用devtoolset时不会有这样的问题，因为您总是使用较旧的libstdc%2B%2B，因此不会有冲突。|2817445|entityMap|0|LINK|mutability|MUTABLE|url|https://access.redhat.com/documentation/en/red-hat-developer-toolset/^0|0|1R|0|0|0|0|0|0|0|0|0|0|0|7H|L|12|P|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1G|8|@$9|1H|A|1I|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|1J|8|@]|D|@]|E|$]]|$1|G|3|H|5|I|7|1K|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|1L|8|@]|D|@]|E|$]]|$1|K|3|-4|5|6|7|1M|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|1N|8|@]|D|@]|E|$]]|$1|N|3|O|5|6|7|1O|8|@]|D|@]|E|$]]|$1|P|3|Q|5|I|7|1P|8|@]|D|@]|E|$]]|$1|R|3|-4|5|6|7|1Q|8|@]|D|@]|E|$]]|$1|S|3|-4|5|6|7|1R|8|@]|D|@]|E|$]]|$1|T|3|U|5|6|7|1S|8|@]|D|@]|E|$]]|$1|V|3|W|5|6|7|1T|8|@$9|1U|A|1V|B|X]]|D|@$9|1W|A|1X|1|1Y]]|E|$]]|$1|Y|3|Z|5|6|7|1Z|8|@]|D|@]|E|$]]|$1|10|3|11|5|6|7|20|8|@]|D|@]|E|$]]|$1|12|3|13|5|I|7|21|8|@]|D|@]|E|$]]|$1|14|3|-4|5|6|7|22|8|@]|D|@]|E|$]]|$1|15|3|-4|5|6|7|23|8|@]|D|@]|E|$]]|$1|16|3|17|5|6|7|24|8|@]|D|@]|E|$]]|$1|18|3|-4|5|6|7|25|8|@]|D|@]|E|$]]]|19|$1A|$5|1B|1C|1D|E|$1E|1F]]]]

As Praetorian pointed out in the comments below, the use of devtoolset actually solves the problem I originally described in this answer. I've corrected the answer.

<blockquote>
 is there a risk that my program will have bugs due to some mismatch between the 4.4 and 4.7 versions of those libraries?
</blockquote>

Yes. Linking against a newer libstdc++.so and then trying to run against and older one is 100% not supported. If any object in your program or any libraries it uses is compiled with GCC 4.7 and linked to the libstdc++.so from 4.7 then you need to use the libstdc++.so from 4.7 (or newer) at runtime. It probably won't even run, but if it does there may be silent bugs due to incompatibilities. But that's not a problem in your case, because you're not linking to GCC 4.7's libstdc++.so, see below.

<blockquote>
 can I work around it by statically linking in GCC 4.7's versions of libc and libstdc++?
</blockquote>

1) You would only need to do that for libstdc++, because there is no such thing as "GCC 4.7's version of libc". Glibc is a completely separate project from GCC. When you are using GCC 4.7 you're not using a different libc, you're still using the system libc from CentOS 6.4. 
(As an aside, be aware that statically linking glibc is strongly advised against by the glibc maintainers, and some features of glibc will not work when statically linked.)

2) Statically linking libstdc++ would work around the problem, but you don't need to, because that's what the <a href="https://access.redhat.com/documentation/en/red-hat-developer-toolset/" rel="noreferrer">Red Hat Developer Toolset</a> (devtoolset) does for you anyway. The whole point of devtoolset is that it allows you to use a newer GCC and newer libstdc++ but without creating any run-time dependencies on the newer libstdc++ library. The compiled executables only need the system version of libstdc++.so that is always present on RHEL/CentOS, even systems without devtoolset installed. (What devtoolset does is package all the new libstdc++ features in a static library, called <code>libstdc++_nonshared.a</code> so that all the pieces not present in the system libstdc++.so get statically linked in, and everything else will come from the system libstdc++.so).

If you weren't using devtoolset then another option instead of statically linking libstdc++ would be to ship the newer libstdc++.so with your code and ensure it is found first (e.g. by linking your code with an RPATH that refers to the newer libstdc++.so). But with devtoolset that's not necessary.

<blockquote>
 Or is that setting myself up for other problems if/when other libraries that my code dynamically loads pick up the older libc / libstdc++ supplied by the system-wide GCC 4.4 package?
</blockquote>

There will be no such problems when using devtoolset, because you're always using the older libstdc++, and so there is never a conflict.

I'm using Intel's C++ compiler, which on Linux relies on the GNU-supplied libc.so and libstdc++.so.

Here's my problem. To have access to some of the newest C++11 features, I need to use the libstdc++ which ships with GCC 4.7 or higher. But I'm stuck using CentOS 6.4.

On CentOS 6.4, the native version of GCC is 4.4. But using a RedHat thing called "SCL" and a package named "devtoolset-1.1", I'm able to get GCC 4.7 installed under "/opt".

I set things up to be using GCC 4.7 in the manner mentioned above, I can use the newer C++11 features. 

So here's my question: If a user runs my program with only the GCC 4.4 versions of libc.so / libstdc++.so in the library path, is there a risk that my program will have bugs due to some mismatch between the 4.4 and 4.7 versions of those libraries?

If there is a potential problem, can I work around it by statically linking in GCC 4.7's versions of libc and libstdc++? Or is that setting myself up for other problems if/when other libraries that my code dynamically loads pick up the older libc / libstdc++ supplied by the system-wide GCC 4.4 package?

Risks of different GCC versions at link / run time?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我使用的是英特尔的C++编译器，它在Linux上依赖于GNU提供的libc.so和libstdc++.so。这就是我的问题。要使用一些最新的C++11功能，我需要使用与GCC 4.7或更高版本一起提供的libstdc++。但我还是坚持使用CentOS 6.4。在CentOS 6.4上，GCC的原生版本是4.4。但是使用...

不同版本的GCC在链接/运行时的风险？-腾讯云开发者社区-腾讯云

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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