动态加载的 PIC 共享库具有来自 NPIC 依赖项的运行时未解析符号答案

【问题标题】：Dynamically loaded PIC shared library has runtime unresolved symbols from NPIC dependency动态加载的 PIC 共享库具有来自 NPIC 依赖项的运行时未解析符号
【发布时间】：2016-08-22 16:33:26
【问题描述】：

这是我的情况

我有一个共享库 (PIC) foo.so。它使用来自 bar.a 的符号。 bar.a 是 NPIC。所以不能添加到 foo.so 的链接行。

foo.so 是从 main.C 动态加载的它可以正常加载，但在运行时使用 bar.a 中的符号时，它会以未解析的符号退出。

我被建议的2个解决方案 1. 编译bar.a PIC并添加到foo.so的链接行 2.在main.C链接行使用“-Wl,--whole-archive bar.a -rdynamic”

1 是不可能的，因为 bar.a 是第三方库。 2 是不可能的，因为我们不希望我们的符号被导出。

是否有任何其他成语/解决方案来解决这个问题？

【问题讨论】：

我说的对吗：你并没有真正链接到 foo.so，你只是通过 dlopen 等使用它？

标签： c++ gcc

【解决方案1】：

“1 不可能，因为 bar.a 是第三方”。

这对我来说听起来不对。可以链接任何静态库。那是要使用的成语。也看看this answer和this one

【讨论】：

不同意。想象一下，您只是无法访问提供 -fPIC 选项的资源。
康斯坦丁说的。我们无权访问使用 -fPIC 构建的源代码
@KonstantinVladimirov: PIC 或没有 PIC 真的是 loader 问题，而不是链接器问题。还是我弄错了？
@xtofl 仍然有一些可能性（例如 foo.so 上的显式 dlopen），它可能会被加载得非常混乱。混合 PIC 和非 PIC 是危险的。

【解决方案2】：

有一个古老的好成语。我称它为"libgcc.so idiom"，因为当您从 libgcc.a 创建 libgcc_s.so 时，它经常用于正常的 libgcc 构建中

带上你 bar.a 并用这条线制作 bar.so：

gcc -shared -o bar.so -Wl,--whole-archive bar.a -Wl,--no-whole-archive

您可能还需要提供-nostdlib 之类的内容。

现在将 foo.so 与这个新的 bar.so 链接起来

现在加载 foo.so 时，所有依赖项都将由动态链接器解析。

【讨论】：

制作bar.so时是否需要-fPIC选项？
AFAIC 编号。此选项仅与代码生成有关，但此处不会发生代码生成