在 Linux 上静态链接库答案

【问题标题】：Statically linking a library on Linux在 Linux 上静态链接库
【发布时间】：2010-12-28 13:34:01
【问题描述】：

我正在尝试为 Firefox 3.6.* 制作 XPCOM 组件。它使用静态编译的 libsqlite3 版本 3.7.4（具有程序独立代码生成 -- -fPIC 编译器选项）。我面临的问题是，一旦 Firefox 加载组件并开始执行，sqlite3_libversion_number() 返回 3007001，而宏 SQLITE_LIBVERSION_NUMBER 定义为 3007004。我很确定我正在链接正确的静态 sqlite3图书馆...但是我该如何仔细检查呢？ ldd 生成的共享对象的输出没有将 libsqlite3.so 列为依赖项（尽管用于创建 XPCOM 组件的 libxul.so 使用 libsqlite3.so）。如何将所有 sqlite3 函数调用解析为不同版本的 SQLite？

PS：是不是因为库是用-fPIC编译的，火狐后来用dlopen加载它们？

【问题讨论】：

标签： c++ linux gcc linker sqlite

【解决方案1】：

我正在查看包含顺序。我也花了一整天或类似的时间想知道为什么 fseek() 失败了，不是直接在 Linux 上而是在 Bada 上，并且使用 Eclipse IDE。问题是具有相同签名的相同函数是由 Bada SDK 中的某个“beta”阶段 .a 文件导出的。而且我不小心首先导入了错误的.a文件。

【讨论】：

是...在链接静态库时，包含顺序非常重要，可以使用以下链接器标志（来自 g++）解决：-Wl,--start-group <all archive files listed here> -Wl,--end-group。这将导致链接器递归检查这些档案中的符号。

【解决方案2】：

在 linux 中，它将执行递归符号解析 - 即如果 libxul 使用 libsqlite3，则 firefox 将通过包含 libxul 中的 libsqlite3 来间接解析符号。

这在 AIX 机器中不是这种情况 - 递归符号解析（基于依赖库）将不会完成。

这可能不是真正的问题 - 但值得检查。

还要检查 sqlite3 是否向后兼容（我想是的），然后您可以将 libxul 和其他库链接到最新版本的 sqlite3。

【讨论】：

是的，SQLite 非常向后兼容，但现在从源代码重建 libxul 并不是一个很好的选择......
如果 libxul 动态链接到 sqlite 则不需要编译 libxul。可以直接放在LD_LIB_PATH中。我不确定为什么必须编译它。