C++ 动态加载的PIC共享库具有NPIC依赖项中的运行时未解析符号

这是我的情况

我有一个共享库（PIC）foo.so。它使用bar.a.中的符号。 酒吧是NPIC。无法将So添加到foo.So的链接行

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

有人向我提出了两种解决办法 1.编译bar.a PIC并将其添加到foo.so的链接行 2.在main.C链接行上使用“-Wl，--whole archive bar.a-rdynamic”

---

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

有没有其他的习惯用法/解决方案可以解决这个问题

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

---

我觉得这不太对。任何静态库都可以链接到。这就是要使用的成语。再看一看

有一个古老的好成语。我称之为

“libgcc.so idiom”

，因为当您从libgcc.a创建libgcc_.so时，它通常用于正常的libgcc构建

带你去bar.a和make bar.用这句话：

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

您可能还需要提供类似于

-nostlib

之类的内容

现在去把foo.so和这个新酒吧联系起来

---

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

不同意。想象一下，你只是无法获得供应源——fPIC选项。康斯坦丁说。我们无法访问用于构建的源代码-fPIC@KonstantinVladimirov：PIC或no PIC实际上是加载程序问题，而不是链接器问题。还是我弄错了？@xtofl仍然有一些可能性（比如foo.so上的显式dlopen）在加载时可能会真的搞砸。混合使用PIC和非PIC是危险的。我说的对吗：你并没有真正链接到foo。所以，你只是通过dlopen等使用它？制作bar时需要-fPIC选项吗？AFAIC否。这个选项只是关于代码生成，但这里没有代码生成