gcc:减少libc所需的版本

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编译器命令行选项(创建静态二进制文件)或以下选项重新编译代码:

-Wl,--hash-style=both

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

根据这里的ld文档,old-school .hash部分是默认的,但编译器可以覆盖它.例如,RHEL(红帽企业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}   ....
                                                                   ^^^^^^^^^^^^^^^^
...

有关更多信息,请参阅此处.

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 的依赖神奇地消失了。

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

希望有帮助！