c - 如何规避 dlopen() 缓存？

Question

根据其man page , dlopen() 不会加载同一个库两次:

If the same shared object is loaded again with dlopen(), the same object handle is returned. The dynamic linker maintains reference counts for object handles, so a dynamically loaded shared object is not deallocated until dlclose() has been called on it as many times as dlopen() has succeeded on it. Any initialization returns (see below) are called just once. However, a subsequent dlopen() call that loads the same shared object with RTLD_NOW may force symbol resolution for a shared object earlier loaded with RTLD_LAZY.

(强调我的)。

但是究竟是什么决定了共享对象的身份呢？我试图查看代码，但并没有走得太远。是吗:

• 某种形式的规范化路径名(例如 realpath？)
• inode ？
• 图书馆的内容？

我很确定我可以排除最后一点，因为实际的文件系统副本会产生两个不同的句柄。

解释这个问题背后的动机:我正在处理一些具有静态全局变量的代码。我需要该代码的多个实例以线程安全的方式运行。我目前的方法是将所述代码编译并链接到一个动态库中，然后多次加载该库。通过一些链接器魔法，它似乎创建了全局变量的多个副本并将每个库中的访问解析为它自己的副本。唯一的问题是我的原型(prototype)为 n 次并发使用复制了生成的库 n 次。这不仅有点难看，而且我还怀疑它可能会在不同的平台上崩溃。

那么根据 POSIX 标准，dlopen() 的确切行为是什么？

编辑:因为它出现在评论和答案中，所以不重构代码绝对不是一种选择。这将涉及数月甚至数年的工作，并可能首先牺牲使用该代码的所有好处。 存在一个正在进行的研究项目可能会以更简洁的方式解决这个问题，但这是实际的研究，可能会失败。我现在需要一个解决方案。

edit2: 因为人们似乎仍然不相信用例实际上是有效的。我正在研究一种纯函数式语言，它将嵌入到更大的 C/C++ 应用程序中。因为我需要一个带有垃圾收集器的原型(prototype)、一个经过验证的类型检查器和合理的性能，所以我使用 OCaml 作为中间代码。现在，我正在将一个源模块编译成一个 OCaml 模块，将生成的目标代码(包括启动等)链接到一个共享库中使用 OCaml 运行时 和 dlopen() that 共享库。每个 .so 都有自己的运行时副本，包括几个全局变量(例如指向年轻一代的指针)，也就是说，或者更确切地说，应该完全没问题。该库恰好公开了两个函数:一个初始化程序和一个执行原始模块打算执行的任何操作的导出。没有 OCaml 运行时的符号被导出/共享。当我加载库时，它的内部符号按预期重新定位，我现在唯一的问题是我实际上需要在运行时为作业的每个实例复制 .so 文件。

关于thread-local-storage:这其实是个有趣的想法，因为对runtime的修改确实比较简单。但问题是 OCaml 编译器生成的机器代码，因为它不能为 tls 符号发出加载指令(还？)。

Answer 1

POSIX 表示:

Only a single copy of an object file is brought into the address space, even if dlopen() is invoked multiple times in reference to the file, and even if different pathnames are used to reference the file.

所以答案是“inode”。复制库文件“应该可以”，但硬链接(hard link)不会。除了。由于它们将公开相同的全局符号，因此当发生这种情况时，所有(可移植性)赌注都会被取消。您正处于通过错误修复而不是良好设计演变而来的弱定义行为的中间。

当你在坑里时，不要挖得更深。添加额外的骇人听闻的黑客攻击以使根本损坏的库正常工作的方法只会导致额外的损坏。只需花几个小时修复库以使其不使用全局变量，而不是花几天时间破解动态链接(充其量是不可移植的)。