gcc:reducelibc所需版本

我正在尝试在一些旧的32位RedHat发行版上运行新编译的二进制文件。
二进制文件是在运行libc v2.12的CentOS 32位虚拟机上用C（而不是++）编译的。

RedHat抱怨libc版本：加载共享库时出错：需要glibc 2.5或更高版本的动态链接器 error while loading shared libraries: requires glibc 2.5 or later dynamic linker 由于我的程序相当简单，它很可能不使用libc中的任何新内容。

---

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

一个未经测试的可能解决方案

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

此错误的原因是动态二进制文件（或其从属文件之一） 要运行的共享库）只有.gnu.hash部分，但 目标机器上的ld.so太旧，无法识别.gnu.hash；只是 识别旧学校。散列部分

这通常发生在所讨论的动态二进制文件构建时 使用更新版本的GCC。解决方案是使用 或-static编译器命令行选项（用于创建静态 二进制），或以下选项：

-Wl,--hash-style=both

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

根据旧学校的说法。散列区 是默认值，但编译器可以重写它。例如，GCC （版本4.1.2）在RHEL（Red Hat Enterprise Linux）服务器上运行 5.5版有以下内容：

$ gcc -dumpspecs
....
*link:
%{!static:--eh-frame-hdr} %{!m32:-m elf_x86_64} %{m32:-m elf_i386} --hash-style=gnu   %{shared:-shared}   ....
                                                                   ^^^^^^^^^^^^^^^^
...

有关详细信息

---

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

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

---

希望有帮助

好吧，为了在优雅和暴力之间找到平衡，我下载了一个与目标内核版本匹配的虚拟机，从而解决了库问题。
整个过程（下载+yum安装gcc）不到30分钟。

---

参考资料：，

这个答案可能有助于更好地捕捉，但重写stdlib看起来有点可怕！是的，我同意，但在这种情况下，代码非常小，在我的代码中只调用了3次memcpy不幸的是-Wl标志没有被我的gcc消化-m32@AknownImous：您得到的错误是什么？

-Wl，

选项的“参数”刚刚传递给链接器-您是使用

gcc

链接，还是直接调用

ld

或其他链接器？另外，请注意，

-Wl，--hash style=both

选项中不能有空格。gcc正在抱怨“无法识别的命令行选项-Wl”。我只使用gcc。@AknownImous：您能复制/粘贴您的gcc命令行和

gcc-v

的输出吗？即使是2001年发布的GCC 2.95.3，也记录了

-Wl

选项，因此我很惊讶您的GCC在这方面遇到了问题。2017年，这也对我起到了作用。我的网络托管公司web服务器似乎是Centos，它愉快地运行着我2006年在Debian上编译的C二进制文件，但拒绝运行现在在Fedora17上重建的C二进制文件。在回答这个问题之后，使用“readelf-a”对新旧版本进行比较。果然在“节头：”和其他地方，新的有“[4].gnu.hash gnu_hash 08048”。。。。而旧的有“[3].hash hash 08048128”…所以我在gcc链接行中添加了标志“-Wl，--hash style=sysv”，一切都很好。