c++ - gcc 链接共享库有效，但同一共享库的 dlopen 失败

Question

我有一个如下所示的项目:

executable
    \---> bsp.so
           |---> bsp_protobuf.a
           \---> protobuf.a

首先构建两个静态库(两个 protobuf 库)，它们静态链接到 bsp.so 共享库。最后bsp.so被链接成可执行文件。

当我使用 gcc 链接可执行文件并链接 bsp.so 时在命令行上它链接正常。

但是，如果我不链接 bsp.so 那么它也可以正常构建 - 这是设计使然 - 因为我想使用 dlopen()确定我是否需要这个库(我有指向对象的指针，但没有实例化的指针等......)。

我遇到的问题是当我使用 dlopen() 时(在代码中)由于 undefined symbol ，它无法打开库。有问题的符号位于静态库中。

我真正难以理解的是为什么它在命令行上工作但在我使用 dlopen() 时不起作用和运行时。

我还有 3-4 个可以成功使用的其他共享库 dlopen() on - 所以我知道我使用 dlopen() 的一般过程很好。

我正在使用dlerror()获取 undefined symbol 错误消息。

我查看了以下链接:

how-to-force-symbols-from-a-static-library-to-be-included-in-a-shared-library-bu

how-to-apply-fvisibility-option-to-symbols-in-static-libraries

我绑了-Wl,--whole-archive想法，但这似乎牵涉太多，构建失败并出现太多警告 - 可能更多与 google protobuf 相关，而且我不确定这是否是我想要的 final方法。

我检查了我的共享库是否是使用 -fPIC 构建的，我不确定静态库是否是用 -fPIC 构建的或者如果需要的话？

我也看过这里:

libtool_9.html

其中讨论了如何与 dlopen() 链接但这是使用 libtools - 我们的所有目标都没有这个，所以我不想使用 libtools。

我真的不确定以哪种方式取得进展 - 感觉这应该是某个地方的简单修复 - 但正如我所说，我无法理解为什么一种方法有效而另一种方法无效......

更新

所以，在 Sam 发表评论后，我开始寻找正确的地方。事实证明，bsp.so 的 makefile 仅静态链接这两个库之一。该共享库有一个单独的测试器，它链接两个库(因此测试器可以工作)，我没有理由怀疑该库已损坏...好吧，我学到了很多有关 dlopen 和链接等的知识...:o

Answer 1

当您将可执行文件与共享库链接时，可执行文件中未解析的符号引用必须由共享库解析，否则链接将失败。

链接共享库时，不需要共享库本身的所有未解析符号都必须由它链接的任何其他共享库解析；因此，当您将共享库链接在一起时，可能会遇到共享库本身无法解析的符号。

将可执行文件与共享库链接成功，因为可执行文件中所有未解析的符号都由共享库解析；但由于共享库本身未解析的符号引用，可执行文件将无法加载。或者，dlopen()共享库会产生相同的错误。

dlopen 手册页还描述了几个可用于控制此行为的可选标志。