dlopen与标准动态链接的用例有哪些？

Question

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

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

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

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

但是，除了边缘的例子之外，它似乎没有推动使用dlopen超过标准加载：

1. 在内存占用优化方面，当共享库已经被另一个程序使用时，条件加载并不是很有趣：加载已经使用过的库不会增加内存占用。
2. 避免编译器监控是不安全的，也是编写错误的好方法......我们也错过了潜在的编译器优化。

那么，是否有其他用途dlopen优先于标准动态链接/加载？

Answer 1

  

那么，还有其他用途，其中dlopen优先于标准动态链接/加载吗？

使用dlopen的典型用例是

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

  

避免编译器监控是不安全的，也是编写bug的好方法......   我们也错过了潜在的编译器优化。

这是真的但你可以通过在延迟加载的共享库周围提供一个小的包装器库来实现两全其美。在Windows上，这是通过标准工具（google for＆＃34; DLL导入库＆＃34;）完成的，在Linux上你可以手动完成或使用Implib.so。

Answer 2

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

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

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