dlmopen能否作为dlopen的直接替代方案？加载共享库遇崩溃求解

1. dlmopen加载单份库能否等价于dlopen两份物理拷贝？ #

可以。dlmopen通过独立链接命名空间实现库的隔离加载，每个命名空间内的库实例拥有独立的全局变量、静态变量和符号表，和复制物理文件后用dlopen加载的效果完全一致，且无需额外的文件拷贝开销，是解决这类全局状态冲突问题的标准方案。

2. 你的dlmopen调用方式存在哪些问题？ #

从代码看，你的调用缺少关键的符号访问逻辑，同时存在编译时绑定的错误：

• 你直接通过&static_function获取静态函数地址，这是编译时绑定，只会指向主程序所在默认命名空间（LM_ID_BASE）的符号，而非dlmopen加载的新命名空间里的函数实例。
• 调用时建议显式指定RTLD_LOCAL（默认行为，但显式声明更清晰），避免新命名空间的符号泄露到全局空间引发冲突。

修正后的调用示例：

inline handle_type open(std::string const& filename) {
    handle_type h = dlmopen(LM_ID_NEWLM, filename.c_str(), RTLD_LAZY | RTLD_LOCAL);
    if (!h) {
        fprintf(stderr, "dlmopen failed: %s\n", dlerror());
        return nullptr;
    }
    return h;
}

3. 直接赋值静态函数地址的根本问题 #

静态函数的符号默认具有链接单元局部性，编译时会被标记为非导出符号（除非显式设置可见性）。当用dlmopen将库加载到独立命名空间后，主程序无法直接通过&static_function访问该命名空间内的静态函数——这个地址是编译时绑定到当前链接单元的符号，和dlmopen加载的实例完全无关，会导致访问无效内存，这就是valgrind报告无效读操作的核心原因。

正确的操作流程：

1. 显式导出库中的静态函数：
   • C代码：给静态函数添加__attribute__((visibility("default")))属性，确保符号能被外部访问。
   • Fortran代码：使用BIND(C)指定符号名，并确保编译器导出该符号。
2. 通过dlsym从dlmopen返回的句柄中获取函数指针：

// 假设static_function的签名为void(*)(void)
using FuncPtr = void(*)();
FuncPtr a = reinterpret_cast<FuncPtr>(dlsym(h, "static_function"));
if (!a) {
    fprintf(stderr, "dlsym failed: %s\n", dlerror());
    // 执行错误处理逻辑
}

内容的提问来源于stack exchange，提问作者Else Ifthen