当使用-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，但这也没有带来预期的结果
您可以指定不带-l标志的静态库的完整路径来链接这些库。
gcc ... source.c ... /usr/lib32/libmysuperlib.a ...
把没有-l的.a文件添加到链接行，就像它是.o文件一样
这是过时的，但可能有效:http://www.network-theory.co.uk/docs/gccintro/gccintro_25.html
(几乎页尾)
"如前所述，还可以通过在命令行中指定库的完整路径来直接链接各个库文件。"