我将开始一个新的C ++项目,该项目将依赖于一系列库,包括Boost库的一部分,log4cxx或google日志库 - 并且随着项目的发展,其他的也是如此(我不能但期待)。
它必须在32位和64位系统上运行,很可能是在一个非常多样化的Linux环境中,我不希望所有必需的库都可用,也不需要su权限。
我的问题是,我应该通过动态或静态链接到所有这些库来构建我的应用程序吗?
注意:
(1)我知道静态链接在开发过程中可能会很痛苦(编译时间较长,32位和64位交叉编译,下载依赖链以包含所有库等),但它更容易在测试期间 - 只需移动文件并运行。
(2)另一方面,动态链接接缝在开发阶段更容易 - 编译时间短(不知道如何处理从32位开发环境到64位库的动态链接),没有依赖性的喧嚣链。另一方面,新版本的部署可能很难看 - 特别是在需要新库时(参见上述条件,目标机器上没有su权限,也没有这些库可用)。
(3)我已阅读有关此主题的相关问题,但无法确定哪种方法最适合我的方案。
结论:
答案 0 :(得分:11)
静态链接有一个糟糕的说唱。这些天我们有巨大的硬盘驱动器,而且管道非常胖。许多支持动态链接的旧论据现在都不那么重要了。
另外,有一个很好的理由在Linux上更喜欢静态链接:过多的平台配置使得几乎不可能保证你的可执行文件在没有静态链接的情况下即使只有一小部分可以工作。
我怀疑这不是一个流行的观点。精细。但是我有11年在Linux上部署应用程序的经验,直到像LSB这样的东西真正起飞并真正扩展它的范围,Linux将继续在部署应用程序时变得更加困难。在此之前,如果您必须在各种平台上运行,请静态链接您的应用程序。
答案 1 :(得分:4)
我可能会在(大部分)开发期间使用动态链接,然后在开发的最后阶段和(所有)部署中切换到静态链接。幸运的是,当从库的动态链接切换到静态链接时,几乎不需要额外的测试。
答案 2 :(得分:2)
这是静态链接的另一个投票。我没有注意到外出申请的连接时间明显延长。有问题的应用程序是一个~50K的线路控制台应用程序,有多个库可以为一堆不同寻常的机器编译,主要是具有100-10,000个核心的超级计算机。通过静态链接,您可以确切地知道要使用的库,可以轻松地测试它们的新版本。
通常,这是构建大多数Mac应用程序的方式。这是允许安装简单地将目录复制到系统上的原因。
答案 3 :(得分:1)
最好是将其留给打包器,并在configure / make脚本中提供这两个选项。通常,动态链接具有优先权,因为在必要时,即在发现安全漏洞等时,可以很容易地升级库。
请注意,如果您没有root权限来在系统目录中安装库,则可以编译程序,使其首先查找其他所需的动态库,这可以通过在ELF二进制文件中设置runpath指令来完成。您可以使用链接器ld。
的-rpath选项指定此类目录