如何在未安装发行版32位libc的64位Linux发行版上运行32位程序

我有一个为32位Linux编译的可执行文件，在两台64位Linux机器上测试：

• 其中一台已通过发行版包安装了32位glibc及依赖，程序能正常运行，strace输出片段如下：

execve("/path/to/myprog", ["/path/to/my"...], 0x7ffe85ce9790 /* 123 vars */) = 0
strace: [ Process PID=48362 runs in 32 bit mode. ]
brk(NULL) = 0x9940000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=198385, ...}) = 0
mmap2(NULL, 198385, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf775d000
close(3) = 0
openat(AT_FDCWD, "/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3

• 另一台未安装32位glibc的机器上，程序执行初期就失败，strace输出：

execve("/path/to/myprog", ["/path/to/my"..., "2"], 0x7fff02cec1b8 /* 97 vars */) = -1 ENOENT (No such file or directory)
strace: exec: No such file or directory

我尝试手动编译安装32位glibc并添加到LD_LIBRARY_PATH，但没有效果——问题似乎出在系统开始搜索libc.so.6之前。请问该怎么解决才能让这个32位程序正常运行？

问题根源解释 #

你碰到的这个ENOENT报错其实挺误导人的——根本不是你的程序找不到，而是64位系统没法定位到32位程序必需的动态链接器。当你运行一个动态链接的32位程序时，内核会自动尝试调用对应的32位动态链接器（通常是/lib/ld-linux.so.2），如果这个链接器不存在，就会返回看起来像是程序找不到的错误。

解决方案 #

1. 手动指定32位动态链接器启动程序 #

如果你已经手动编译安装了32位glibc，先找到它的动态链接器路径（比如你编译的32位glibc目录下的ld-linux.so.2），然后用它来启动你的程序：

/path/to/32bit-glibc/lib/ld-linux.so.2 --library-path /path/to/32bit-glibc/lib /path/to/myprog

这里的--library-path用来指定32位glibc的库目录，确保程序能找到对应的32位libc.so.6等依赖文件。

2. 用发行版包管理器安装官方32位兼容环境 #

手动编译glibc很容易踩坑（比如版本不兼容、缺少其他32位系统依赖），更稳妥的方式是用系统自带的包管理器安装官方的32位兼容组件：

• 如果你用的是Debian/Ubuntu系列发行版：

  sudo dpkg --add-architecture i386
  sudo apt update
  sudo apt install libc6:i386 libncurses5:i386 libstdc++6:i386
  

• 如果你用的是RHEL/CentOS系列发行版：

  sudo yum install glibc.i686 libstdc++.i686
  

安装完成后，系统会自动处理动态链接器和相关依赖，你直接运行32位程序就能正常工作了。

3. 考虑编译静态链接版本（可选） #

如果你的程序源代码可控，可以考虑把它编译成静态链接版本：

gcc -m32 -static -o myprog myprog.c

静态链接的程序会把所有依赖的库都打包到可执行文件里，不需要系统提供32位glibc就能运行，不过代价是程序体积会变大一些。

内容的提问来源于stack exchange，提问作者einpoklum