我正在尝试在一些旧的 32 位 RedHat 发行版上运行新编译的二进制文件。
该二进制文件在运行 libc v2.12 的 CentOS 32 位 VM 上编译为 C（非 ++）。
RedHat 抱怨 libc 版本：
加载共享库时出错：需要 glibc 2.5 或更高版本的动态链接器由于我的程序相当简单，很可能没有使用 libc 中的任何新内容。
【问题讨论】：
未经测试的可能解决方案
什么是“加载共享库时出错：需要 glibc 2.5 或更高版本的动态链接器”？
此错误的原因是动态二进制文件（或其依赖项之一 共享库）您要运行的只有 .gnu.hash 部分，但是 目标机器上的 ld.so 太旧，无法识别 .gnu.hash；它只是 识别老式的 .hash 部分。
这通常发生在构建相关的动态二进制文件时 使用较新版本的 GCC。解决方案是重新编译代码 任一 -static 编译器命令行选项（用于创建静态 二进制），或以下选项：
-Wl,--hash-style=both这告诉链接编辑器 ld 创建 .gnu.hash 和 .hash 部分。
根据ld documentation here，老式的 .hash 部分 是默认值，但编译器可以覆盖它。例如，海合会 （版本 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} .... ^^^^^^^^^^^^^^^^ ...更多信息，see here。
【讨论】：
-Wl, 选项的 ' 参数只是传递给链接器 - 您是使用 gcc 链接还是直接调用 ld 或其他链接器？另请注意，-Wl,--hash-style=both 选项中不能有空格。
gcc -v 的输出吗？ -Wl 选项甚至在 2001 年发布的 GCC 2.95.3 中也有记录，所以我很惊讶你的 gcc 遇到了麻烦。
我已经遇到了同样的问题，试图为一台我没有编译器的旧机器编译一个小工具（我写的）。我在最新的机器上编译它，并且二进制文件至少需要 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 的依赖神奇地消失了。
很抱歉，我无法真正解释为什么它会起作用，或者我无法解释为什么它在修改之前不起作用。
希望对您有所帮助！
【讨论】：
好吧，为了在优雅和蛮力之间找到平衡，我下载了一个与目标内核匹配的 VM 版本，从而修复了库问题。
整个过程（下载 + yum install gcc）不到 30 分钟。
参考文献：Virtual machines、Kernel Version Mapping Table
【讨论】：