我对 Linux 上的链接有以下疑问：
假设我有一个使用 Qt 的类 Foo。要构建这个类，我必须使用 qmake 来生成 Makefile。
稍后我想将这个类 Foo 用于 Perl 模块，它是一个共享库。但是，要构建它，我必须使用 Perl 的 MakeMaker 来生成它自己的 Makefile。
我现在这样做的方式是将类 Foo 构建为静态库，并且在构建 Perl 模块的共享库时，我将它与 Foo 的静态库链接。
问题是在构建 Perl 模块的共享库时，我必须将它与 Foo 的静态库所链接的所有 Qt 库链接。
所以问题是：
这种方法还有意义吗？！
是否可以在构建 Perl 模块的共享库时以不必指定所有依赖项的方式构建 Foo 的静态库？（因为将所有这些依赖项添加到模块的 Makefile 有点困难）
如果 Foo 的库是共享的，而不是静态的，会有什么不同吗？
1）您不能将静态库链接到共享库。
2) 如果它本身是 DSO，则不需要显式链接Foo's 依赖项Foo
3) 您可以轻松修改 Makefile.PLLIBS部分以添加额外的链接器依赖项。
4）无论如何，Qt 静态链接是一个彻头彻尾的痛苦。除非你有特定的版本依赖和操作系统/平台限制，否则你最好只做整个动态 shebang。提示：即使你有 Qt 的“静态”构建，这个“静态”构建也不会包含它可能决定需要作为可加载模块存在的东西。到过那里。
5）我相信有一个提供Qt4绑定的CPAN模块（有点新）。我从未使用过它，也不知道它的状态，但它可能值得一试。
但是你最好的选择是制作Foo一个动态库......然后每个人都很开心。
1）这取决于你的目标是什么。
2）如果是为了尽量减少构建它的麻烦，您可以将 Qt 的静态库作为静态库包含到您的 Foo 库中。重要的是您在 Foo 中引用的符号可以在运行时找到。这样你就不需要在你的 PerlMake 中包含 Qt 库了。
3）如果它是关于最小化可执行文件大小，你必须去共享库。然后您应该将所有内容构建为共享库。
静态构建具有独立于目标平台上安装的共享库的优点，同时具有可执行文件大小膨胀和库不可重用性的缺点（加载两个相同的可执行文件需要更多内存）。
链接共享的优点是代码更小，但同时必须在目标平台上安装正确的共享库。