将动态库链接到静态库(也称为预链接动态库)

发布于 2024-11-18 17:20:47 字数 266 浏览 1 评论 0原文

我有一个非常小的库,我想将其转换为静态库(libx.a),但该库依赖于动态库(liby.so)。我希望能够“预链接”我的静态库,以便 libx.a 已经包含对 liby.so 的引用。

这基本上允许我在编译存在 -lx 的程序时不指定选项 -ly 。这使得链接 libx 时的事情变得更简单,特别是当它依赖于许多共享库时。

是否可以 ?如果是,如何(假设 gcc)?

如果可能的话,如果使用 libx 的程序使用 liby 本身,是否会发生某种有趣的重复(我想是变量)?

I have a very small library that I'd like to turn to a static library (libx.a), but this library depends on a dynamic library (liby.so). I would like to be able to "pre-link" my static library, so that libx.a would already contain reference to liby.so.

This would basically allow me not to specify the option -ly when compiling a program where -lx is present. This makes things simpler when linking against libx, especially if it depends on many shared libraries.

Is it possible ? If yes, how (assuming gcc) ?

Still if possible, if the program using libx uses liby itself, will there be some kind of funny duplication (variables I suppose) going on ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

ぺ禁宫浮华殁 2024-11-25 17:20:47

我很困惑您是否真的想将共享库代码包含到静态库存档中,或者您是否只想使其链接静态库自动创建对共享库的引用。

在前一种情况下,我不知道有什么工具可以做到这一点,但这应该是一个可以解决的问题。如果您花一些时间阅读 ELF 规范,那么您可能可以制作一个工具将 .so 文件转换为普通的 .o 文件,然后只需包含 .a 存档中的 o 文件。

对于后一种情况,大多数人使用pkg-config解决这个问题。另一种方法(相当 GNU 特定)是安装 GNU 链接器脚本而不是原始 .a 文件,并让链接器脚本引用静态库和所需的共享库。

I'm confused whether you really want to include the shared library code into the static library archive, or whether you want to just make it so linking the static library automatically creates a reference to the shared library as well.

In the former case, I know of no tools to do it, but it should be a solvable problem. You could probably make a tool to convert a .so file to a normal .o file if you spend some time reading the ELF specs, then just include the .o file in the .a archive.

In the latter case, most people solve this problem with pkg-config. Another approach, which would be rather GNU-specific, would be installing a GNU linker script instead of the raw .a file, and having the linker script reference both your static library and the required shared library.

苄①跕圉湢 2024-11-25 17:20:47

这里的问题是您的动态库是与位置无关的编译的,并且需要动态加载器来在加载时修复内部和外部引用。因此,您无法显式链接动态库。在我正在从事的项目中,我们通常会编译静态和动态版本的库,这是原因之一。

The problem here is that your dynamic library is compiled position-independent and needs a dynamic loader to fix the internal and external references at load time. Thus you cannot explicitly link against a dynamic library. In the project I'm working on we are usually compiling static and dynamic versions of libs and this is one of the reasons.

給妳壹絲溫柔 2024-11-25 17:20:47

这个问题可以通过使用智能构建系统来解决。我建议使用 gyp。它有静态库的选项link_settings

{
  'targets': [
    {
      'target_name': 'x',  # will generate libx.a
      'type': 'static_library',
      'sources': [],
      'link_settings': {
        'libraries': ['-ly'],
      },
    },
    {
      'target_name': 'test',
      'type': 'executable',
      'dependencies': ['x'],
      'sources': [],
    },
  ],
}

The problem can be solved by using an intelligent build system. I can recommend using gyp. It has the option link_settings for static libraries:

{
  'targets': [
    {
      'target_name': 'x',  # will generate libx.a
      'type': 'static_library',
      'sources': [],
      'link_settings': {
        'libraries': ['-ly'],
      },
    },
    {
      'target_name': 'test',
      'type': 'executable',
      'dependencies': ['x'],
      'sources': [],
    },
  ],
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文