Linux gcc：减少 libc 所需的版本
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/12075403/
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
gcc: Reduce libc required version
提问by MonoThreaded
I am trying to run a newly compiled binary on some oldish 32bits RedHat distribution.
The binary is compiled C (not++) on a CentOS 32bits VM running libc v2.12.
RedHat complains about libc version:
我正在尝试在一些旧的 32 位 RedHat 发行版上运行一个新编译的二进制文件。
该二进制文件在运行 libc v2.12 的 CentOS 32 位 VM 上编译为 C（非 ++）。
RedHat 抱怨 libc 版本：
error while loading shared libraries: requires glibc 2.5 or later dynamic linker由于我的程序相当简单，它很可能没有使用 libc 中的任何新东西。
Is there a way to reduce libc version requirement有没有办法减少libc版本要求
采纳答案by MonoThreaded
Ok then, trying to find some balance between elegance and brute force, I downloaded a VM matching the target kernelversion, hence fixing library issues.
The whole thing (download + yum install gcc) took less than 30 minutes.
References: Virtual machines, Kernel Version Mapping Table
好的，为了在优雅和暴力之间找到平衡，我下载了一个与目标内核版本匹配的虚拟机，从而修复了库问题。
整个过程（下载 + yum install gcc）用时不到 30 分钟。
参考资料：虚拟机、内核版本映射表
回答by Michael Burr
An untested possible solution
未经测试的可能解决方案
What is "error while loading shared libraries: requires glibc 2.5 or later dynamic linker"?
The cause of this error is the dynamic binary (or one of its dependent shared libraries) you want to run only has .gnu.hash section, but the ld.so on the target machine is too old to recognize .gnu.hash; it only recognizes the old-school .hash section.
This usually happens when the dynamic binary in question is built using newer version of GCC. The solution is to recompile the code with either -static compiler command-line option (to create a static binary), or the following option:
-Wl,--hash-style=bothThis tells the link editor ld to create both .gnu.hash and .hash sections.
According to ld documentation here, the old-school .hash section is the default, but the compiler can override it. For example, the GCC (which is version 4.1.2) on RHEL (Red Hat Enterprise Linux) Server release 5.5 has this line:
$ gcc -dumpspecs .... *link: %{!static:--eh-frame-hdr} %{!m32:-m elf_x86_64} %{m32:-m elf_i386} --hash-style=gnu %{shared:-shared} .... ^^^^^^^^^^^^^^^^ ...For more information, see here.
什么是“加载共享库时出错：需要 glibc 2.5 或更高版本的动态链接器”？
此错误的原因是您要运行的动态二进制文件（或其依赖共享库之一）只有 .gnu.hash 部分，但目标机器上的 ld.so 太旧而无法识别 .gnu.hash；它只识别老式的 .hash 部分。
当有问题的动态二进制文件是使用较新版本的 GCC 构建时，通常会发生这种情况。解决方案是使用 -static 编译器命令行选项（以创建静态二进制文件）或以下选项重新编译代码：
-Wl,--hash-style=both这告诉链接编辑器 ld 创建 .gnu.hash 和 .hash 部分。
根据ld 文档here，老式 .hash 部分是默认的，但编译器可以覆盖它。例如，RHEL (Red Hat Enterprise Linux) Server 5.5 版上的 GCC（版本 4.1.2）有以下行：
$ gcc -dumpspecs .... *link: %{!static:--eh-frame-hdr} %{!m32:-m elf_x86_64} %{m32:-m elf_i386} --hash-style=gnu %{shared:-shared} .... ^^^^^^^^^^^^^^^^ ...有关更多信息，请参阅此处。
回答by phsym
I already had the same problem, trying to compile a little tool (I wrote) for an old machine for which I had not compiler. I compiled it on an up to date machine, and the binary required at least GLIBC 2.14 in order to run.
我已经遇到了同样的问题，试图为我没有编译器的旧机器编译一个小工具（我写的）。我在最新的机器上编译它，二进制文件至少需要 GLIBC 2.14 才能运行。
By making a dump of the binary (with xxd), I found this :
通过转储二进制文件（使用 xxd），我发现了这一点：
....
5f64 736f 5f68 616e 646c 6500 6d65 6d63 _dso_handle.memc
7079 4040 474c 4942 435f 322e 3134 005f py@@GLIBC_2.14._
....
So I replaced the memcpy calls in my code by a call to an home-made memcpy, and the dependency with the glibc 2.14 magically disappeared.
于是我用一个自制的memcpy调用替换了我代码中的memcpy调用，与glibc 2.14的依赖神奇地消失了。
I'm sorry I can't really explain why it worked, or I can't explain why it didn't work before the modification.
对不起，我无法真正解释它为什么起作用，或者我无法解释为什么它在修改前不起作用。
Hope it helped !
希望有帮助！
