这是大便。
我们正在两个不同的Linux deploments上编译mysql ++第三方库：Red Hat 5.8和SuSE Sles10。
两个系统上的编译逻辑完全相同。但是，Red Hat系统上的file命令表明生成的库是“ Linux / i386核心文件”，而在SuSE上它正确显示为“ ELF 32位LSB共享对象“
> cat /etc/issue
Welcome to SUSE Linux Enterprise Server 10 SP1 (i586) - Kernel \r (\l).
> file Obj/libdbums.so
Obj/libdbums.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped
> cat /etc/issue
Red Hat Enterprise Linux Server release 5.8 (Tikanga)
Kernel \r on an \m
> file Obj/libdbums.so
Obj/libdbums.so: Linux/i386 core file, not stripped
链接完成如下：
g++ -m32 -fPIC -shared -Wl,-soname -Wl,libdbums.so.1.0.0 -o Obj/libdbums.so \
<list of Obj/xyz.o files> \
-Wl,-rpath-link \
/usr/server/CommonLib/lib \
-L/usr/server/CommonLib/lib \
-lLogging \
-lboost_date_time \
-lumsxmlapi \
-lmysqlpp
知道为什么会这样吗？在RedHat机器上编译的其他库被正确地发现是“ Elf 32位LSB共享对象”而不是这个库。
哦，.so工作。使用libdbums.so的应用程序使用库中的功能。
你们中的一些人可能会问为什么这很重要，如果它有效，它就会起作用。
我们发现这是一个问题，因为构建RPMS的自动依赖性检测逻辑将过滤掉任何不是“Elf”的.so文件。我们发现我们的SuSE RPMS安装正常，因为RPMS正确地表明他们提供了libdbums.so，但是在RedHat上它失败了，因为文件显示libdbums.so不是“ELF”，所以不包括在提供列表中。 / p>
我知道我可以手动为这个库添加一个提供子句，但我更倾向于找到根本原因并且只是正确检测到库。这是为了让file命令正确地将其归类为ELF。
10/02/2013 12:14 JRR编辑
一时兴起，我发现如果我用gcc而不是g ++链接它会获得ELF 32文件类型。