在链接时让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位共享对象（比如，不包含在ubuntu的ia32-libs包中）。
  

>

来解决上述约束，一个可能的解决方案是将生成的共享对象与所使用的所有非平凡库的静态32位版本链接起来。但是当安装这样的库时，通常会安装静态和动态版本，因此gcc将始终链接到共享对象而不是静态库。

当然，移动/删除/删除有问题的共享对象，而只是将静态库留在 / usr / lib32 中，这是一个解决方法，但它不是一个好的方法

注意：

• 是的，我已经阅读了如何链接共享对象&图书馆，而我并没有试图创造一个'完全静态链接的共享对象'


• 是的，我试过 -Wl，-static -lfoo -Wl， - Bdynamic，但没有带来预期的结果


• 是的，我试过 -l：libfoo.a 也是如此，但这并没有带来预期的结果。
您可以指定 没有 -l 标志的静态库的完整路径与这些链接。

  gcc ... source.c ... /usr/lib32/libmysuperlib.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/lib or /usr/lib32:
  • one cannot expect the user to set LD_PRELOAD or LD_LIBRARY_PATH to 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 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.a as well, but this didn't bring the expected results either
解决方案

You can specify the full path to the static libs without the -l flag to link with those.

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

这篇关于在链接时让gcc更喜欢静态库到共享对象？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！

1403页，肝出来的..