使 gcc 在链接时更喜欢静态库而不是共享对象？
当使用 -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 位共享对象（例如，不包括 为了解决上述限制
，一个可能的解决方案是将生成的共享对象链接到所使用的所有重要库的静态 32 位版本。但是，在安装此类库时，通常会同时安装静态和动态版本，因此 gcc 将始终链接共享对象而不是静态库。
当然，移动/删除/删除有问题的共享对象，并将静态库保留在 /usr/lib32 中，是一种解决方法，但这不是一个好的注意
事项：
- 是的，我确实阅读了如何链接共享对象和库，我并不是想创建一个“完全静态链接的共享对象”
- 是的，我尝试了 -Wl,-static -lfoo -Wl,-Bdynamic, 但没有带来预期的结果
- 是的，我也尝试了
-l:libfoo.a，但这也没有带来预期的结果
When linking against libraries using the -l option (say -lfoo), gcc will prefer a shared object to a static library if both are found (will prefer libfoo.so to libfoo.a). Is there a way to make gcc prefer the static library, if both are found?
The issue I'm trying to solve is the following: I'm creating a plugin for an application (the flight simulator called X-Plane), with the following constraints:
- the plugin is to be in the form of a 32 bit shared object, even when running on a 64 bit system
- the running environment does not provide a convenient way to load shared objects which are not in the 'normal' locations, say
/usr/libor/usr/lib32:- one cannot expect the user to set
LD_PRELOADorLD_LIBRARY_PATHto find shared objects shipped with my plugin - the X-Plane running environment would not add my plugins directory to ``LD_LIBRARY_PATH, before dynamically loading the plugin shared object, which would allow me to ship all my required shared objects alongside my plugin shared object
- one cannot expect the user to set
- one cannot expect 64 bit users to install 32 bit shared objects that are non-trivial (say, are not included in the ia32-libs package on ubuntu)
to solve the above constraints, a possible solution is to link the generated shared object against static, 32 bit versions of all non-trivial libraries used. but, when installing such libraries, usually both static and dynamic versions are installed, and thus gcc will always link against the shared object instead of the static library.
of course, moving / removing / deleting the shared objects in question, and just leaving the static libraries in say /usr/lib32, is a work-around, but it is not a nice one
note:
- yes, I did read up on how to link shared objects & libraries, and I'm not trying to creatae a 'totally statically linked shared object'
- yes, I tried
-Wl,-static -lfoo -Wl,-Bdynamic,but didn't bring the expected results - yes, I tried
-l:libfoo.aas well, but this didn't bring the expected results either
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以指定静态库的完整路径，而无需使用
-l标志来链接它们。You can specify the full path to the static libs without the
-lflag to link with those.只需将
.a文件添加到不带-l的链接行，就像它是.o文件一样。Just add the
.afile to the link line without-las if it were a.ofile.它已过时，但可能有效：http://www.network-theory。 co.uk/docs/gccintro/gccintro_25.html
（几乎页面末尾）
“如前所述，还可以通过指定完整路径直接链接到各个库文件通过命令行访问库。”
It's dated, but may work: http://www.network-theory.co.uk/docs/gccintro/gccintro_25.html
(almost end of the page)
"As noted earlier, it is also possible to link directly with individual library files by specifying the full path to the library on the command line."