0

这是便便。

我们正在两个不同的 Linux 部署上编译 mysql++ 3rd 方库：Red Hat 5.8 和 SuSE Sles10。

编译逻辑在两个系统上完全相同。但是，fileRed Hat 系统上的命令表明生成的库是“ Linux/i386 核心文件”，而在 SuSE 上它正确显示为“ ELF 32-bit LSB shared object ”

>  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”，因此它没有包含在提供列表中。

我知道我可以为这个库手动添加提供子句，但我更愿意找到根本原因并简单地正确检测到库。这是为了让file命令正确地将其归类为 ELF。

10/02/2013 12:14 JRR 编辑

一时兴起，我发现如果我使用 gcc 而不是 g++ 链接，它会获得 ELF 32 文件类型。

4

0 回答 0