混合静态库和共享库时的链接器依赖关系答案

【问题标题】：Linker dependencies when mixing static and shared libraries混合静态库和共享库时的链接器依赖关系
【发布时间】：2012-09-18 18:55:40
【问题描述】：

我有以下关于在 Linux 上链接的问题：

假设我有一个使用 Qt 的类 Foo。要构建这个类，我必须使用 qmake 来生成 Makefile。

稍后我想将这个类 Foo 用于 Perl 模块，它是一个共享库。但是，要构建它，我必须使用 Perl 的 MakeMaker 来生成它自己的 Makefile。

我现在的做法是将 Foo 类构建为静态库，在构建 Perl 模块的共享库时，我将它与 Foo 的静态库链接。

问题在于，在构建 Perl 模块的共享库时，我必须将其链接到 Foo 的静态库所链接的所有 Qt 库。

所以问题是：

【问题讨论】：

【解决方案1】：

1) 您不能将静态库链接到共享库。

2) 如果 Foo 本身是 DSO，则您不需要显式链接 Foo 的依赖项

3) 您可以轻松修改 Makefile.PL LIBS 部分以添加额外的链接器依赖项。

4) 无论如何，静态链接 Qt 是一个彻头彻尾的痛苦。除非你有特定的版本依赖和操作系统/平台限制，否则你最好只做整个动态 shebang。提示：即使你确实有 Qt 的“静态”构建，这个“静态”构建也不会包含它可能决定需要作为可加载模块存在的东西。去过那里。

5) 我相信有一个提供 Qt4 绑定的 CPAN 模块（有点新）。我从未使用过它，也不知道它的状态，但它可能值得一试。

但最好的办法是让Foo 成为一个动态库.. 那样每个人都开心。

【讨论】：

【解决方案2】：

1) 这取决于你的目标是什么。

2) 如果是为了尽量减少构建它的麻烦，您可以将 Qt 的静态库作为静态库包含到您的 Foo 库中。重要的是您在 Foo 中引用的符号可以在运行时找到。这样你就不需要在你的 PerlMake 中包含 Qt 库了。

3) 如果它是关于最小化可执行文件大小，您必须使用共享库。然后您应该将所有内容构建为共享库。

静态构建的优点是独立于目标平台上已安装的共享库，但缺点是可执行文件大小膨胀和库不可重用（加载两个相同的可执行文件需要更多内存）。

链接共享的优点是代码更小，但同时必须在目标平台上安装正确的共享库。

【讨论】：

嗯，最初的问题是让那些以不同方式生成 Makefile 的人一起工作。构建 Qt 的静态版本可能会有问题。例如，最新版本的 Qt 不支持 QtWebkit 的静态链接。因此，如果我坚持将所有内容构建为共享库，我将不得不拖所有这些依赖项？
据我了解，您正在静态链接 Foo，因此最简单的方法可能是将所有 Qt-lib 添加（静态链接）到您的 Foo 存档中。不过，这将导致一个庞大的存档文件。