20

我正在尝试在一些旧的 32 位 RedHat 发行版上运行新编译的二进制文件。
该二进制文件在运行 libc v2.12 的 CentOS 32 位 VM 上编译为 C（非 ++）。

RedHat 抱怨 libc 版本：

加载共享库时出错：需要 glibc 2.5 或更高版本的动态链接器
由于我的程序相当简单，它很可能没有使用 libc 中的任何新内容。

有没有办法降低 libc 版本要求

4

3 回答 3

24

未经测试的可能解决方案

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

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

这通常发生在使用较新版本的 GCC 构建相关的动态二进制文件时。解决方案是使用 -static 编译器命令行选项（以创建静态二进制文件）或以下选项重新编译代码：

-Wl,--hash-style=both

这告诉链接编辑器 ld 创建 .gnu.hash 和 .hash 部分。

根据此处的 ld 文档，老式 .hash 部分是默认设置，但编译器可以覆盖它。例如，RHEL（Red Hat Enterprise Linux）服务器版本 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}   ....
                                                                   ^^^^^^^^^^^^^^^^
...

有关详细信息，请参阅此处。

于 2012-08-22T14:43:25.427 回答
5

我已经遇到了同样的问题，试图为一台我没有编译过的旧机器编译一个小工具（我写的）。我在最新的机器上编译它，并且二进制文件至少需要 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 的依赖神奇地消失了。

很抱歉，我无法真正解释它为什么起作用，或者我无法解释为什么它在修改之前不起作用。

希望它有所帮助！

于 2012-08-22T14:58:49.127 回答
3

好吧，为了在优雅和蛮力之间找到一些平衡，我下载了一个与目标内核版本匹配的 VM，从而修复了库问题。
整个过程（下载 + yum install gcc）不到 30 分钟。

参考：虚拟机、内核版本映射表

于 2012-08-23T08:50:15.310 回答