Linux GLIBCXX 版本
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4133674/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
GLIBCXX versions
提问by peoro
If I compile a C++ program on my machine, and run it on another one (with older software) I get: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found.
如果我在我的机器上编译一个 C++ 程序，然后在另一个（使用旧软件）上运行它，我得到：/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found.
In fact on my system glibc is newer (I got gcc-libs 4.5.1: libstdc++.so.6.0.14) and strings /usr/lib/libstdc++.so.6 | grep GLIBCXXprints from GLIBCXX_3.4to GLIBCXX_3.4.14. On the other system, instead, it only prints up to GLIBCXX_3.4.8(I got libstdc++.so.6.0.8).
事实上，在我的系统上 glibc 是较新的（我得到了 gcc-libs 4.5.1：libstdc++.so.6.0.14）并strings /usr/lib/libstdc++.so.6 | grep GLIBCXX从GLIBCXX_3.4to打印GLIBCXX_3.4.14。相反，在另一个系统上，它只打印到GLIBCXX_3.4.8（我得到了 libstdc++.so.6.0.8）。
So I've got a few questions:
所以我有几个问题：
Why my linker links C++ binaries against libstdc++ version
GLIBCXX_3.4.9instead ofGLIBCXX_3.4.14?If I complied my binary against libstdc++ version
GLIBCXX_3.4I guess it would run almost on everywhere. Would that imply any sort of issues? (eg: would it use older -and thus worse- algorithm implementations?)If instead I staticallylink my program against my libstdc++ I guess it will run everywhere; the binary will be a lot bigger (~1MB) of course, any other pros/cons?
Can I force the linker to link my binary against a given version of libstdc++?
为什么我的链接器将 C++ 二进制文件链接到 libstdc++ 版本
GLIBCXX_3.4.9而不是GLIBCXX_3.4.14？如果我根据 libstdc++ 版本编译我的二进制文件，
GLIBCXX_3.4我想它几乎可以在任何地方运行。这是否意味着任何类型的问题？（例如：它会使用旧的——因此更糟糕的——算法实现吗？）相反，如果我将我的程序静态链接到我的 libstdc++，我猜它会在任何地方运行；二进制文件当然会更大（~1MB），还有其他优点/缺点吗？
我可以强制链接器将我的二进制文件链接到给定版本的 libstdc++ 吗？
采纳答案by ninjalj
Use readelf -aand objdump -xto inspect ELF files in preference to strings.
使用readelf -a和objdump -x优先检查 ELF 文件strings。
Actually, all the GLIBCXX_* versions don't apply to the entire library, but to each symbol (symbol versioning, see DSO-howto). So you can have e.g: std::char_traits<wchar_t>::eq@@GLIBCXX_3.4.5and std::ios_base::Init::~Init()@@GLIBCXX_3.4on the same library file.
实际上，所有 GLIBCXX_* 版本并不适用于整个库，而是适用于每个符号（符号版本控制，请参阅DSO-howto）。所以你可以在同一个库文件中使用 eg:std::char_traits<wchar_t>::eq@@GLIBCXX_3.4.5和std::ios_base::Init::~Init()@@GLIBCXX_3.4。
The fact that your program needs GLIBCXX_3.4.9 probably means that it has been linked against a symbol that has been introduced/has changed semantics on GLIBCXX_3.4.9.
您的程序需要 GLIBCXX_3.4.9 的事实可能意味着它已与在 GLIBCXX_3.4.9 上引入/已更改语义的符号链接。
回答by B?ови?
- That the the library version that is installed on your system. You could manually build the glibc version 3.4.14 and link to it
- That depends. Maybe the later version fixed some issues. The users of your program would have to link against the version that your program requires
- The memory usage is higher
- Yes, pass proper parameter to the linker. If you need specific version of the library, then it is best to download it, and build it manually, and link to it.
- 您系统上安装的库版本。您可以手动构建 glibc 版本 3.4.14 并链接到它
- 那要看。也许后来的版本修复了一些问题。您程序的用户必须链接到您的程序所需的版本
- 内存占用比较高
- 是的，将正确的参数传递给链接器。如果您需要特定版本的库，那么最好下载它，手动构建它，并链接到它。
EDIT
编辑
I just remembered that statically linked libraries increase the memory usage.
我只记得静态链接的库会增加内存使用量。
回答by Lewis Chan
In my opinion, if your binaries don't use the new features of newer GLIBCXX version, then they won't be linked with that version. So your binaries was linked with GLBCXX 3.4.9, there must be at least one symbol exported from it, and there're no any symbols exported from version newer than 3.4.9.
在我看来，如果您的二进制文件不使用较新 GLIBCXX 版本的新功能，那么它们将不会与该版本链接。所以你的二进制文件与 GLBCXX 3.4.9 链接，必须至少有一个从中导出的符号，并且没有任何符号从高于 3.4.9 的版本中导出。
