Question

我正在尝试在一些旧的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中的任何新东西
有没有办法降低libc版本要求

Answer 1

未经测试的可能解决方案

什么是“加载共享库时出错：需要glibc 2.5或更高版本的动态链接器”？

此错误的原因是动态二进制文件（或其依赖项之一）   你要运行的共享库只有.gnu.hash部分，但是   目标机器上的ld.so太旧了，无法识别.gnu.hash;它只是   认识到老派.hash部分。

这通常在构建有问题的动态二进制文件时发生   使用更新版本的GCC。解决方案是使用重新编译代码   -static compiler命令行选项（用于创建静态   二进制），或以下选项：
-Wl,--hash-style=both
这告诉链接编辑器ld创建.gnu.hash和.hash   部分。

根据ld documentation here，老派.hash部分   是默认值，但编译器可以覆盖它。例如，海湾合作委员会   （RHEL（Red Hat Enterprise Linux）服务器上的（版本4.1.2）   版本5.5有这一行：
$ gcc -dumpspecs
....
*link:
%{!static:--eh-frame-hdr} %{!m32:-m elf_x86_64} %{m32:-m elf_i386} --hash-style=gnu   %{shared:-shared}   ....
                                                                   ^^^^^^^^^^^^^^^^
...
有关详细信息，请see here。

Answer 2

我已经遇到了同样的问题，试图为我没有编译器的旧机器编译一个小工具（我写的）。我在最新的机器上编译它，并且二进制文件至少需要GLIBC 2.14才能运行。

通过转储二进制文件（使用xxd），我发现了这个：

....
5f64 736f 5f68 616e 646c 6500 6d65 6d63  _dso_handle.memc
7079 4040 474c 4942 435f 322e 3134 005f  py@@GLIBC_2.14._
....

所以我通过调用自制的memcpy替换了代码中的memcpy调用，并且glibc 2.14的依赖性神奇地消失了。

对不起，我无法解释为什么会有效，或者我无法解释为什么在修改之前它不起作用。

希望它有所帮助！

Answer 3

好的，试着在优雅和蛮力之间找到一些平衡，我下载了一个匹配目标内核版本的 VM，因此修复了库问题。
整个事情（下载+ yum install gcc）花了不到30分钟
参考文献：Virtual machines，Kernel Version Mapping Table

gcc：减少libc所需的版本

3 个答案: