如何定位RHEL上x86_64 RPM触发的“transaction check vs depsolve”错误？

碰到这种x86_64架构的RPM包却依赖32位glibc的情况，大概率是构建过程中某个环节引入了32位相关的配置或依赖，下面是我常用的排查流程：

1. 验证RPM内二进制文件的架构 #

首先确认你打包的二进制文件是不是真的64位的——这是最基础的检查：

# 先把RPM解压提取文件
rpm2cpio your-package.x86_64.rpm | cpio -idmv
# 检查二进制文件的架构
file path/to/extracted/binary

如果输出里显示ELF 64-bit LSB executable，那架构是对的；如果是ELF 32-bit，说明你编译时没指定64位架构，得去检查编译脚本里的CFLAGS、LDFLAGS有没有加-m64，或者configure命令有没有指定--host=x86_64-redhat-linux-gnu。

2. 检查二进制文件的动态依赖 #

如果二进制是64位，但还是依赖32位libc，那得看它实际链接的库：

ldd path/to/extracted/binary

正常情况下，libc.so.6应该指向/lib64/libc.so.6（64位库路径）。如果看到指向/lib/libc.so.6（32位库路径），说明你的二进制在链接时不小心引用了32位的库文件。这时候要查编译时的链接参数，是不是误指定了32位的库目录，或者依赖的第三方库是32位的。

3. 检查RPM的依赖声明 #

有时候问题出在.spec文件的依赖配置上，比如硬编码了32位依赖，或者变量使用错误：

# 查看RPM声明的所有依赖
rpm -qp --requires your-package.x86_64.rpm

如果输出里有libc.so.6()(32bit)或者glibc.i686，那要么是.spec里写了错误的Requires，要么是rpmbuild自动推导依赖时抓错了（这种情况一般是因为二进制里有32位依赖）。

4. 检查构建环境的配置 #

确认你是在64位的RHEL环境下构建的，同时检查构建时的环境变量：

# 查看构建时的CFLAGS/LDFLAGS
echo $CFLAGS $LDFLAGS

如果这些变量里有-m32，那就是强制编译32位了，得去掉这个参数。另外，检查configure或make脚本里有没有硬编码的32位编译选项。

5. 排查第三方依赖库 #

如果你的项目依赖了其他第三方库（比如自己编译的.so或者系统外的库），检查这些库的架构：

file path/to/third-party/libs/*.so

如果其中有32位的库，那链接时就会自动引入32位的libc，把这些第三方库换成64位版本即可。

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