dlopen 与标准动态链接的用例是什么？答案

【问题标题】：What are the use cases of dlopen vs standard dynamic linking?dlopen 与标准动态链接的用例是什么？
【发布时间】：2017-07-29 10:30:24
【问题描述】：

根据文档，dlopen 与dlsym 结合使用以加载库，并获取指向符号的指针。

但这已经是动态加载器/链接器所做的。而且，这两种方法都基于ld.so。

使用dlopen时实际上似乎有两个不同之处：

可以有条件地加载该库。
编译器不知道我们正在使用的符号（类型、原型...），因此不会检查潜在的错误。顺便说一句，这是一种实现自省的方法。

但是，除了边缘示例之外，它似乎并没有促使使用dlopen 超过标准加载：

就内存占用优化而言，当共享库已被另一个程序使用时，条件加载并不是很有趣：加载已使用的库不会增加内存占用。
避免编译器监督是不安全的，也是编写错误的好方法...我们还缺少潜在的编译器优化。

那么，与标准动态链接/加载相比，dlopen 是否还有其他用途？

【问题讨论】：

想想插件和类似的东西。
模块化和插件？作为一种使用新功能动态扩展程序的方法。或者作为一种在运行时检测某些功能然后加载正确的库来处理它的方法（游戏或 3d 引擎的典型用例）。
@Someprogrammerdude 这应该是答案。

标签： c shared-libraries dynamic-linking

【解决方案1】：

那么，与标准动态链接/加载相比，dlopen 是否还有其他用途？

使用dlopen 的典型用例是

插件
为当前 CPU 选择最佳实现（英特尔数学库执行此操作）
选择不同供应商的 API 实现（GLEW 和其他 OpenGL 包装器执行此操作）
如果不太可能使用共享库，则延迟加载（这将加速启动，因为库构造函数不会运行 + 运行时链接器要做的工作会稍微少一些）

避免编译器监督是不安全的，也是编写错误的好方法... 我们还缺少潜在的编译器优化。

确实如此，但您可以通过在延迟加载共享库周围提供一个小型包装库来实现两全其美。在 Windows 上，这是通过标准工具完成的（谷歌为“DLL 导入库”），在 Linux 上，您可以手动完成或使用 Implib.so。

【讨论】：

【解决方案2】：

我在 Windows 环境中执行此操作以构建语言切换功能。当我的应用程序启动时，它会检查应该使用哪个 language.dll 的配置设置。从现在开始，所有文本都从动态加载的库中加载，甚至可以在运行时替换。我还包括了一个用于格式化序数（1st、2nd、3rd）的函数，它是特定于语言的。我在可执行文件中包含了我的母语的语言资源，所以我不能最终没有可用的文本。

关键是可执行文件可以在运行时决定应该加载哪个库。在我的情况下，它是一种语言切换，或者正如评论员所说的那样，类似于插件的目录扫描。

缺乏对调用签名的监控绝对是一个缺点。如果你真的想做一些邪恶的事情，比如覆盖原型类型定义，你可以使用标准的 C 类型转换来做到这一点。

【讨论】：