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

【问题标题】：making gcc prefer static libs to shared objects when linking?使 gcc 在链接时更喜欢静态库而不是共享对象？
【发布时间】：2011-08-02 00:31:59
【问题描述】：

当使用-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 中，这是一种解决方法，但它不是一个好方法

注意：

【问题讨论】：

【解决方案1】：

只需将.a 文件添加到没有-l 的链接行，就好像它是.o 文件一样。

【讨论】：

【解决方案2】：

您可以指定不带-l 标志的静态库的完整路径来链接这些库。

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

【讨论】：

【解决方案3】：

（几乎页尾）

"如前所述，还可以通过在命令行中指定库的完整路径来直接链接各个库文件。"

【讨论】：