问题标签 [dynamic-linking]

在某些情况下，是否有任何令人信服的性能理由来选择静态链接而不是动态链接，反之亦然？我听过或读过以下内容，但我对这个主题的了解还不够，无法保证其真实性。

1) 静态链接和动态链接在运行时性能上的差异通常可以忽略不计。

2) (1) 如果使用使用配置文件数据优化程序热路径的分析编译器则不正确，因为通过静态链接，编译器可以同时优化您的代码和库代码。使用动态链接只能优化您的代码。如果大部分时间都花在运行库代码上，这会产生很大的不同。否则，(1) 仍然适用。

我一直在尝试制作一些都依赖于同一个库的应用程序，而动态库是我的第一个想法：所以我开始编写“库”：

然后我编译“库”

然后我快速编写了一个使用库的文件：

然后我尝试用

但它不会编译并出现以下错误：

我想我错过了一些非常明显的东西，请帮助我:)

我的应用程序是否可以监视一个文件夹，如果我们在其中复制一个 DLL（库），应用程序会选择它并链接它？

以前我在 C++ 中做过类似的事情，但是可以在 .NET 中动态链接库吗？

谢谢

我在 64 位 CentOS 5.4 上将应用程序与 mysqlclient 库链接，并出现链接错误（找不到 -lmysqlclient）。该库位于 /usr/lib64/mysql/ 中：

该目录似乎已为 Linux 链接器正确注册：

我可以在这台机器上链接应用程序的唯一方法是指定库文件的完整路径，这在我的情况下是不可接受的。什么可能导致这里的问题？

谢谢。

如何在 C 语言中实现后期绑定？

我将开始一个新的 C++ 项目，该项目将依赖于一系列库，包括 Boost 库、log4cxx 或 google 日志库的一部分——并且随着项目的发展，其他项目也会发展（我还不能预料到） .

它必须在 32 位和 64 位系统上运行，很可能在一个非常多样化的 Linux 环境中，我不希望拥有所有必需的库或 su 权限。

我的问题是，我应该通过动态或静态链接到所有这些库来构建我的应用程序吗？

笔记：

(1) 我知道静态链接在开发过程中可能会很痛苦（更长的编译时间、32 位和 64 位的交叉编译、向下依赖链以包含所有库等），但在测试期间要容易得多 -只需移动文件并运行。

(2) 另一方面，动态链接接缝在开发阶段更容易 - 编译时间短，（真的不知道如何处理从我的 32 位开发环境到 64 位库的动态链接），没有依赖链的喧嚣。另一方面，新版本的部署可能很难看——尤其是在需要新库时（请参阅上面的条件，即在目标机器上没有 su 权限，也没有这些库可用）。

(3) 我已经阅读了有关该主题的相关问题，但无法真正弄清楚哪种方法最适合我的情况。

结论：

1. 谢谢大家的意见！
2. 我可能会使用静态链接，因为：
• 更容易部署
• 在 perf 期间可预测的性能和更一致的结果。测试（看这篇论文：http://www.inf.usi.ch/faculty/hauswirth/publications/CU-CS-1042-08.pdf）
• 正如所指出的，静态与动态编译的大小和持续时间似乎并没有那么大的差异
• 更容易和更快的测试周期
• 我可以保留所有开发人员。在我的开发中循环。机器

为了查看正在运行的程序包含哪些内存映射区域，我编写了一个简单的 C 程序来从 /proc/self/maps 读取数据：

程序的输出如下所示（已标记）：

从执行位和可写位我们可以推断，前两行分别与程序的代码段和数据段相关联。

但是让我感到困惑的是 libc.so，有一些从 libc.so 映射的区域。其中一个甚至只有私有位，无法写入、读取或执行。另一个有趣的事情是 ld.so 只有三个段。与 libc.so 的段相比，缺少只有私有位的段。

所以我想知道这四个部分实际上是做什么的？我正在使用带有内核 2.6.28、gcc 3.4.6 和 binutils 2.19 的 Ubuntu SMP。

我正在开发一个使用 GStreamer 库的应用程序。为了简化部署，我想在本地包中收集所有 GStreamer 库。为此，我编写了一个执行以下操作的小脚本：

• 递归遍历依赖项（使用otool -L）
• 将所有依赖项复制到本地目录
• 使所有依赖路径相对于@executable_path（使用install_name_tool）

（如果您有兴趣，可以查看Ruby 脚本。）

但是，我现在在gst_init调用中看到运行时错误：

仅当我使用本地化库时才会出现这些错误。

在使用 install_name_tool 时是否存在某些“常见陷阱”？有谁知道我做错了什么？如果您需要了解某些细节，请随时询问。

更新
我改变了一些事情：

• 对于依赖库，我现在只更改 dylib 路径而不是 id（仅使用install_name_tool -change而不是install_name_tool -id）。
• 对于主库，我设置了相对于可执行路径 ( @executable_name/components/Video.dylib) 的 id 值。

这两个变化使它工作。但是，我还不清楚它为什么起作用。我在理解“id”属性的含义时遇到了一些麻烦。它似乎是路径名形式的标识符。为什么为依赖库更改它会导致运行时错误？我将尝试通过进一步的实验找到这些问题的答案......

我有一个主机应用程序，并且我编写了一个插件。我将我的插件编译成一个共享对象（比如 foo.so），宿主应用程序将通过 dlopen 加载它。在这种情况下，我的主机应用程序是来自 llvm 的 opt 工具（尽管我认为这对这个问题并不重要）。

我想在启用分析的情况下编译我的插件（即g++ -pg, gprof）。但是，当我这样做时，永远不会创建配置文件输出文件 gmon.out。也许 gprof 期望有人调用一个设置例程，或者类似的东西。

由于各种原因，我想避免使用 -pg 重新编译主机应用程序。我很好奇是否可以在不分析主机应用程序 opt 的情况下分析共享对象 foo.so。

我还研究了其他分析工具；HP 的 qprof 应该能够处理这种情况，但它无法解析共享对象中的函数名称（它以非常幼稚的方式回退到 addr2line）。

谢谢，尼克

我已经为代码生成器编写了一个接口，可以让我生成共享对象。虽然我不想实现对节头表的支持，因为这是 ELF 文件格式的主要复杂性所在。

GNU ld 使用节头来链接共享对象。这意味着当我尝试将 gcc 链接放在没有节标题的共享对象上时，它将失败，因为 ld 找不到符号，即使它们存在于库中。

是否存在一些技巧可以用来欺骗编译器以使链接成功，即使它找不到某些符号？

以下是有关问题的一些说明：