.so 文件的动态加载和对符号的引用答案

【问题标题】：Dynamic loading of .so file and reference to symbols.so 文件的动态加载和对符号的引用
【发布时间】：2020-12-22 14:29:23
【问题描述】：

我正在开发一个使用应用程序驱动程序的 Linux C++ 应用程序。硬件开发商提供 SDK（包括和库）。我想通过 dlopen() 动态使用库，以使应用程序在没有驱动程序的情况下工作（或者，也许，还有另一个驱动程序）。

当我以这种方式使用其中一个库中的方法时：

int (*VCI_OpenCAN)(PVCI_CAN_PARAM) = (int(*)(PVCI_CAN_PARAM))dlsym(_driver_library, "VCI_OpenCAN");

        int open_code = VCI_OpenCAN(&vcparam);

        if ( 0 == open_code) {
            qDebug() << "ERROR: " << open_code;
            exit(1);
        }

它告诉我有未解析的符号 Open_Com。好的，它可能在 VCI_OpenCAN 内部被调用，但 nm 告诉库（例如 lib1.so）中有 U（未定义）符号 Open_Com。我四处搜寻，在 SDK 中捆绑的另一个库 (lib2.so) 中找到了 Open_Com。

所以问题是 - 我如何（并且有可能？）启用两个库的动态加载并让它们看到彼此的符号，或者唯一的解决方案是静态链接？静态链接有效，捆绑示例使用

$(CC) $(CFLAGS) $(LDFLAGS) -o $@ i7565H1H2.o ../lib/libI7565H1H2_64.so.1.0 ../lib/libi7k_64.so.1.0 $(AM_LDFLAGS)```

【问题讨论】：

第一个库应该已经与第二个库链接了。它没有正确构建，显然由您决定与这两个库链接。糟糕的设计。手动 dlopen 也可以使用 RTLD_GLOBAL 标志打开第二个库。
提供的lib1.so 应该明确地依赖于lib2.so（参见readelf -d 输出中的“NEEDS”行）。如果您无法让供应商解决此问题，请先加载 lib2.so，然后再加载 lib1.so。

标签： c++ c linux shared-libraries dynamic-library

【解决方案1】：

手动 dlopen 也可以使用 RTLD_GLOBAL 标志打开第二个库。

_i7k_library = dlopen("/home/kkursor/tmp/libi7k_64.so.1.0", RTLD_GLOBAL | RTLD_NOW);
_driver_library = dlopen(config.value(section + "/driver_library").toString().toLocal8Bit(), RTLD_LAZY);

【讨论】：