编译器libstdc ++版本与系统版本 [英] Compiler libstdc++ version vs. system version
问题描述
我试图理解g ++如何选择链接的libstdc ++的版本，以及库的系统版本不同时的含义。
我使用的是gcc / g ++ 4.1.2，它根据 ABI指南
a> doc，其中包含libstdc ++。so.6.0.8，确实如此： -rwxr-xr-x 1 root root 4397810 2007年5月18日/opt/gcc4.1.2/lib/libstdc++.so.6.0.8
根据根据我对ABI向前兼容性的理解，我可以使用g ++ 4.1.2构建，并期望代码能够在系统上运行，而系统的libstdc ++版本高于6.0.8，而不是早期版本，因为那样会有一个旧版本的ABI。
在同一台机器上，在/ usr / lib中有一个旧版本的libstdc ++：
-rwxr-xr-x 1 root root 804288 Jul 22 2005 /usr/lib/libstdc++.so.6.0.3
如果我在这台机器上使用g ++ 4.1.2编译代码，然后使用ldd，我在/ usr / lib中引用了libstdc ++的版本，它是6.0.3：
＃ldd test
。
libstdc ++。so.6 => /usr/lib/libstdc++.so.6（0x005b6000）
。
这是预期的，因为首先检查/ usr / lib。
我的问题是：这里发生了什么？针对libstdc ++的版本，所以这是该版本（6.0.8）的一部分？如果是这样，在运行时，如果可执行文件具有较旧的ABI，那么可执行文件如何在/ usr / lib中使用旧版本？运气？
或者g ++ 4.1.2在链接时拿起libstdc ++（6.0.3）的/ usr / lib版本并使用它，因为它解析了库路径采用与可执行文件在运行时相同的方式？ g ++能做到这一点，即使libstdc ++不是它的自己的版本？ g ++ 4.1.2（6.0.8）中的libstdc ++版本的目的是什么？它在这个过程中是否被使用过？
任何见解都会被赞赏。
目录搜索列表。你可以这样看：
gcc -print-search-dirs
然而，列表通常会优先选择特定于编译器版本的库，如果有的话。
链接时间选择可能与运行时选择不同。
如果链接器命令包含 -rpath 选项（一些工具链供应商可能包含一个非标准的供应商），那么动态链接器将使用它在运行时找到合适的库。否则，系统将使用其默认库。
如果两个库不匹配，那么可能会发生不好的事情。 C库（通常是glibc）一直很小心地保持兼容性。 C ++库并不总是有这种奢侈品。近些年来这样更安全，但许多人仍然推荐不是混合和匹配。
I'm trying to understand how g++ selects which version of libstdc++ it links against and what it means when the "system" version of the library is different.
I'm using gcc/g++ 4.1.2, which according to the ABI Guidelines doc, includes libstdc++.so.6.0.8, and sure enough:
-rwxr-xr-x 1 root root 4397810 May 18 2007 /opt/gcc4.1.2/lib/libstdc++.so.6.0.8
Based on my understanding of the ABI forward-compatibility, I can build with g++ 4.1.2 and expect the code to run on a system with a later version of libstdc++ than 6.0.8, but not on one with an earlier version, because that will have an older version of the ABI.
On the same machine there is an older version of libstdc++ in /usr/lib:
-rwxr-xr-x 1 root root 804288 Jul 22 2005 /usr/lib/libstdc++.so.6.0.3
If I compile code using g++ 4.1.2 on this machine, then ldd it, I see the version of libstdc++ in /usr/lib referenced, which is 6.0.3:
# ldd test
.
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x005b6000)
.
This is expected, as /usr/lib is checked first. And the application runs fine.
My question is: what's happened here?
Has g++ 4.1.2 linked against the version of libstdc++.so that is part of that release (6.0.8)? If so, how come the executable can use the older version in /usr/lib at runtime, when that has an older ABI? Luck?
Or has g++ 4.1.2 picked up the /usr/lib version of libstdc++ (6.0.3) at link time and used that, because it resolves library paths in the same way as executables do at runtime? Can g++ do that, even if the libstdc++ is not its "own" version? What is the purpose of the libstdc++ version in g++4.1.2 (6.0.8)? Has it been used at all in this process?
Any insights appreciated.
GCC selects all libraries according to a directory search list. You can see it like this:
gcc -print-search-dirs
The list usually prefers libraries specific to the compiler version, if there is one.
However, the link-time choice may not be the same as the run-time choice.
If the linker command includes an -rpath option (some toolchain vendors may include a non-standard one) then the dynamic linker will use that to find the right libraries at run-time. Otherwise the system will use its default library.
If the two libraries are not well matches then bad things may happen. The C library (usually glibc) has always been careful to maintain compatibility. The C++ library has not always had this luxury. It's been safer in recent years but many people still recommend not mixing and matching.
这篇关于编译器libstdc ++版本与系统版本的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
