在链接/运行时使用不同版本的GCC的风险? [英] Risks of different GCC versions at link / run time?

问题描述

我正在使用Intel的C ++编译器，该编译器在Linux上依赖于GNU提供的libc.so和libstdc ++.so.

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

这是我的问题.要访问某些最新的C ++ 11功能，我需要使用GCC 4.7或更高版本附带的libstdc ++.但是我被困在CentOS 6.4上.

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.

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

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".

我以上述方式将事情设置为使用GCC 4.7，可以使用较新的C ++ 11功能.

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

所以这是我的问题:如果用户在库路径中仅使用GCC 4.4版本的libc.so/libstdc ++.so运行我的程序，是否存在由于4.4之间的某些不匹配而导致我的程序存在错误的风险和这些库的4.7版本?

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?

如果存在潜在问题，我可以通过静态链接GCC 4.7的libc和libstdc ++版本来解决此问题吗?还是在我的代码动态加载的其他库选择了系统级GCC 4.4软件包提供的较旧的libc/libstdc ++时，是否使自己陷入了其他问题?

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?

推荐答案

正如Praetorian在下面的注释中指出的那样，使用devtoolset实际上解决了我最初在此答案中描述的问题.我已经纠正了答案.

由于这些库的4.4和4.7版本之间的某些不匹配，我的程序是否存在错误的风险?

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?

是的. 100％不支持链接到较新的libstdc ++.so，然后再尝试与较旧的libstdc ++.so链接.如果程序或程序中使用的任何库中的任何对象都是通过GCC 4.7 编译并链接到4.7 的libstdc ++.so，则您需要在运行时使用4.7(或更高版本)中的libstdc ++.so.它可能甚至无法运行，但如果这样做，由于不兼容，可能会出现无声的错误.但这对您来说不是问题，因为您没有链接到GCC 4.7的libstdc ++.so，请参见下文.

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.

我可以通过静态链接GCC 4.7的libc和libstdc ++版本来解决此问题吗?

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

1)您只需要为libstdc ++这样做，因为没有诸如"GCC 4.7的libc版本"之类的东西. Glibc是一个与GCC完全独立的项目.当您使用GCC 4.7时，您没有使用其他libc，而是仍在使用CentOS 6.4中的系统libc. (顺便说一句，请注意glibc维护者强烈建议不要静态链接glibc，并且glibc的某些功能在静态链接时将无法使用.)

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)静态链接libstdc ++可以解决此问题，但是您不必这样做，因为这就是

2) Statically linking libstdc++ would work around the problem, but you don't need to, because that's what the Red Hat Developer Toolset (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 libstdc++_nonshared.a 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).

如果您不使用devtoolset，则除了静态链接libstdc ++外，另一个选择是将较新的libstdc ++.so与您的代码一起提供，并确保首先找到它(例如，通过将您的代码与引用较新版本的RPATH链接) libstdc ++.so).但是使用devtoolset并不必要.

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.

或者/当我的代码动态加载的其他库选择了系统级GCC 4.4软件包提供的较旧的libc/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?

使用devtoolset时不会出现此类问题，因为您始终使用较旧的libstdc ++，因此永远不会发生冲突.

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

这篇关于在链接/运行时使用不同版本的GCC的风险?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！