如何规避 dlopen() 缓存？
How to circumvent dlopen() caching?
根据其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.
（强调我的）。
但是究竟是什么决定了共享对象的身份呢？我试图查看代码，但并没有走得太远。是吗：
- 某种形式的规范化路径名（例如真实路径？）
- 索引节点 ?
- 图书馆的内容？
我很确定我可以排除最后一点，因为实际的文件系统副本会产生两个不同的句柄。
解释这个问题背后的动机：我正在处理一些具有静态全局变量的代码。我需要该代码的多个实例以线程安全的方式 运行 。我目前的方法是将 link 所述代码编译成动态库并多次加载该库。借助一些 linker 魔法，它似乎创建了全局变量的多个副本，并解析了每个库中对其自身副本的访问。唯一的问题是我的原型为 n 次并发使用复制了生成的库 n 次。这不仅有点难看，而且我还怀疑它可能会在不同的平台上崩溃。
那么 dlopen() 根据 POSIX 标准的确切行为是什么？
编辑： 因为它出现在评论和答案中，所以不重构代码绝对不是一种选择。这将涉及数月甚至数年的工作，并可能首先牺牲使用该代码的所有好处。 存在 一个正在进行的研究项目可能会以更简洁的方式解决这个问题，但这是实际的研究，可能会失败。我现在需要一个解决方案。
edit2: 因为人们似乎仍然不相信用例实际上是有效的。我正在研究一种纯函数式语言，它将嵌入到更大的 C/C++ 应用程序中。因为我需要一个带有垃圾收集器的原型、一个经过验证的类型检查器和合理的性能，所以我使用 OCaml 作为中间代码。现在，我正在将一个源模块编译成一个 OCaml 模块，link 生成的目标代码（包括启动等）到一个共享库 with OCaml 运行time 和 dlopen() that 共享库。每个 .so 都有自己的 运行time 副本，包括几个全局变量（例如指向年轻一代的指针），也就是说，或者更确切地说，应该是完全没问题的。该库恰好公开了两个函数：一个初始化程序和一个执行原始模块打算执行的任何操作的导出。 OCaml 运行time 的符号都不是 exported/shared。当我加载库时，它的内部符号按预期重新定位，我现在唯一的问题是我实际上需要在 运行 时间为作业的每个实例复制 .so 文件。
关于thread-local-storage：这其实是一个有趣的想法，因为对运行time的修改确实比较简单。但问题是 OCaml 编译器生成的机器代码，因为它不能为 tls 符号发出加载指令（还？）。
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"。复制库文件"should work"，但硬链接不会。除了。由于它们将公开相同的全局符号，因此当发生这种情况时，所有（可移植性）赌注都会被取消。您正处于通过错误修复而不是良好设计演变而来的弱定义行为的中间。
身陷囹圄，不要越陷越深。添加额外的骇人听闻的黑客攻击以使根本损坏的库正常工作的方法只会导致额外的损坏。只需花几个小时修复库以使其不使用全局变量，而不是花几天时间破解动态链接（充其量是不可移植的）。
根据其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.
（强调我的）。
但是究竟是什么决定了共享对象的身份呢？我试图查看代码，但并没有走得太远。是吗：
- 某种形式的规范化路径名（例如真实路径？）
- 索引节点 ?
- 图书馆的内容？
我很确定我可以排除最后一点，因为实际的文件系统副本会产生两个不同的句柄。
解释这个问题背后的动机：我正在处理一些具有静态全局变量的代码。我需要该代码的多个实例以线程安全的方式 运行 。我目前的方法是将 link 所述代码编译成动态库并多次加载该库。借助一些 linker 魔法，它似乎创建了全局变量的多个副本，并解析了每个库中对其自身副本的访问。唯一的问题是我的原型为 n 次并发使用复制了生成的库 n 次。这不仅有点难看，而且我还怀疑它可能会在不同的平台上崩溃。
那么 dlopen() 根据 POSIX 标准的确切行为是什么？
编辑： 因为它出现在评论和答案中，所以不重构代码绝对不是一种选择。这将涉及数月甚至数年的工作，并可能首先牺牲使用该代码的所有好处。 存在 一个正在进行的研究项目可能会以更简洁的方式解决这个问题，但这是实际的研究，可能会失败。我现在需要一个解决方案。
edit2: 因为人们似乎仍然不相信用例实际上是有效的。我正在研究一种纯函数式语言，它将嵌入到更大的 C/C++ 应用程序中。因为我需要一个带有垃圾收集器的原型、一个经过验证的类型检查器和合理的性能，所以我使用 OCaml 作为中间代码。现在，我正在将一个源模块编译成一个 OCaml 模块，link 生成的目标代码（包括启动等）到一个共享库 with OCaml 运行time 和 dlopen() that 共享库。每个 .so 都有自己的 运行time 副本，包括几个全局变量（例如指向年轻一代的指针），也就是说，或者更确切地说，应该是完全没问题的。该库恰好公开了两个函数：一个初始化程序和一个执行原始模块打算执行的任何操作的导出。 OCaml 运行time 的符号都不是 exported/shared。当我加载库时，它的内部符号按预期重新定位，我现在唯一的问题是我实际上需要在 运行 时间为作业的每个实例复制 .so 文件。
关于thread-local-storage：这其实是一个有趣的想法，因为对运行time的修改确实比较简单。但问题是 OCaml 编译器生成的机器代码，因为它不能为 tls 符号发出加载指令（还？）。
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"。复制库文件"should work"，但硬链接不会。除了。由于它们将公开相同的全局符号，因此当发生这种情况时，所有（可移植性）赌注都会被取消。您正处于通过错误修复而不是良好设计演变而来的弱定义行为的中间。
身陷囹圄，不要越陷越深。添加额外的骇人听闻的黑客攻击以使根本损坏的库正常工作的方法只会导致额外的损坏。只需花几个小时修复库以使其不使用全局变量，而不是花几天时间破解动态链接（充其量是不可移植的）。