linux - 使 gcc 在链接时更喜欢静态库而不是共享对象？

Question

当使用 -l 选项(例如 -lfoo)链接库时，gcc 将更喜欢共享对象而不是静态库，如果两者都找到(将更喜欢 libfoo.so 到 libfoo.a)。如果两者都找到，有没有办法让 gcc 更喜欢静态库？

我要解决的问题如下:我正在为一个应用程序(名为 X-Plane 的飞行模拟器)创建一个插件，具有以下限制:

• 插件将采用 32 位共享对象的形式，即使在 64 位系统上运行也是如此
• 运行环境没有提供一种方便的方式来加载不在“正常”位置的共享对象，比如 /usr/lib 或 /usr/lib32 :
  • 不能指望用户设置 LD_PRELOAD 或 LD_LIBRARY_PATH 来查找我的插件附带的共享对象
  • 在动态加载插件共享对象之前，X-Plane 运行环境不会将我的插件目录添加到 ``LD_LIBRARY_PATH，这将允许我将所有需要的共享对象与我的插件共享对象一起发送
• 不能期望 64 位用户安装重要的 32 位共享对象(例如，不包含在 ubuntu 上的 ia32-libs 包中)

要解决上述限制，一个可能的解决方案是将生成的共享对象链接到所有使用的非平凡库的静态 32 位版本。但是，在安装此类库时，通常会同时安装静态和动态版本，因此 gcc 将始终链接到共享对象而不是静态库。

当然，移动/删除/删除有问题的共享对象，并且只将静态库留在 /usr/lib32 中，是一种变通方法，但这不是一个好方法

注意:

• 是的，我确实阅读了有关如何链接共享对象和库的内容，我并没有尝试创建“完全静态链接的共享对象”
• 是的，我尝试了 -Wl,-static -lfoo -Wl,-Bdynamic, 但没有带来预期的结果
• 是的，我也尝试了 -l:libfoo.a，但这也没有带来预期的结果

Answer 1

您可以指定静态库的完整路径，而无需使用 -l 标志来与它们链接。

gcc ... source.c ... /usr/lib32/libmysuperlib.a ...