gcc - 与具有依赖关系的动态库链接

Question

考虑以下场景:

• 共享库 libA.so，无依赖项。
• 共享库 libB.so，以 libA.so 作为其依赖项。

我想编译一个与 libB 链接的二进制文件。我应该仅将二进制文件与 libB 链接还是与 libA 链接？

有没有办法只链接直接依赖项，让运行时的依赖项解析未解析的符号？

我担心库 libB 实现将来可能会发生变化，引入其他依赖项(例如 libC、libD、libE)。我会遇到问题吗？

换句话说:

• libA 文件:a.cpp a.h
• libB 文件:b.cpp b.h
• 主程序文件:main.cpp

当然，b.cpp包含a.h，main.cpp包含b.h。

编译命令:

g++ -fPIC a.cpp -c
g++ -shared -o libA.so a.o

g++ -fPIC b.cpp -c -I.
g++ -shared -o libB.so b.o -L. -lA

我应该使用以下哪个选项？

g++ main.cpp -o main -I. -L. -lB

或

g++ main.cpp -o main -I. -L. -lB -lA

我无法使用第一个选项。链接器提示库 libA 中的未解析符号。但这对我来说有点奇怪。

非常感谢。

--更新评论:

当我链接二进制文件时，链接器将尝试解析 main 和 libB 中的所有符号。但是，libB 具有 libA 中 undefined symbol 。这就是链接器提示的原因。

这就是为什么我也需要链接 libA。不过，我找到了一种方法来忽略共享库中未解析的符号。看起来我应该使用以下命令行来执行此操作:

g++ main.cpp -o main -I. -L. -lB -Wl,-unresolved-symbols=ignore-in-shared-libs

看起来仍然可以使用-rpath选项。不过我需要更好地理解它。

有人知道使用-Wl,-unresolved-symbols=ignore-in-shared-libs选项时可能出现的陷阱吗？

--更新评论2:

-rpath 不应用于此目的。强制在给定目录中找到库很有用。 -unresolved-symbol 方法看起来好多了。

再次感谢。

Answer 1

看来您已经完成了大部分工作。你的调查做得很好。让我们看看我是否可以帮助澄清其背后的“原因”。

这是链接器正在执行的操作。当您链接可执行文件(上面的“main”)时，它有一些未解析的符号(函数和其他内容)。它将查找随后的库列表，尝试解决未解析的符号。在此过程中，它发现一些符号是由 libB.so 提供的，因此它指出它们现在已由该库解析。

但是，它还发现其中一些符号使用了可执行文件中尚未解析的其他符号，因此它现在也需要解析这些符号。如果不链接 libA.so，您的应用程序将是不完整的。一旦链接到 libA.so，所有符号都会被解析并且链接完成。

正如您所见，使用 -unresolved-symbols-in-shared-libs 并不能解决问题。它只是推迟它，以便在运行时解析这些符号。这就是 -rpath 的用途:指定运行时要搜索的库。如果无法解析这些符号，您的应用程序将无法启动。

找出库依赖关系并不是一件容易的事情，因为一个符号可能由多个库提供，并且可以通过链接其中任何一个库来满足。

这里还有这个过程的另一个描述:Why does the order in which libraries are linked sometimes cause errors in GCC?