链接动态库与依赖关系 [英] Linking with dynamic library with dependencies
问题描述
考虑以下情况：
- 共享库libA.so，没有依赖关系。
- 共享库libB.so，以libA.so为依赖。
我想编译一个与libB链接的二进制文件。
我应该将二进制文件仅与libB或libA链接吗？
I want to compile a binary file that links with the libB. Should I link the binary with libB only or with libA either?
是否有任何方法仅链接到直接依赖关系，让解决的未解决的符号从运行时的依赖关系来看？
Is there any way to link only with the direct dependencies, letting the resolution of unresolved symbols from the dependencies for runtime?
我担心库libB实现可能会在将来发生变化，引入其他依赖关系（libC，libD，libE） ）。我有问题吗？
I'm worried about the fact that the library libB implementation may change in the future, introducing other dependencies (libC, libD, libE for instance). Am I going to have problems with that?
换句话说：
- libA文件：a.cpp啊
- libB文件：b.cpp bh
- 主程序文件：main.cpp
当然，b.cpp包括啊和main.cpp包括bh
Of course, b.cpp includes a.h and main.cpp includes b.h.
编译命令： p>
Compilation commands:
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中的未解析符号抱怨。但是对我来说听起来有点奇怪。
I couldn't use the first option. The linker complains about the unresolved symbols from the library libA. But it sound a little strange to me.
非常感谢。
- 更新的评论：
当链接二进制文件时，链接器将尝试从main和libB中解析所有符号。但是，libB具有来自libA的未定义符号。这就是为什么链接器会抱怨的。
When I link the binary, the linker will try to resolve all symbols from the main and the libB. However, libB has undefined symbols from the libA. That's why the linker complains about that.
这就是为什么我需要链接到libA的原因。
但是我发现了一种从共享库忽略未解析符号的方法。
看起来我应该使用以下命令行来做到这一点：
That's why I need to link with the libA too. However I found a way to ignore unresolved symbols from shared libraries. Looks like I should use the following command line to do that:
g++ main.cpp -o main -I. -L. -lB -Wl,-unresolved-symbols=ignore-in-shared-libs
看起来像仍然可以使用 -rpath 选项。
然而，我需要理解一点。
Looks like it is still possible to use the -rpath option.
However I need to understand it a little better.
使用 -Wl，-unresolved-符号= ignore-in-shared-libs 选项？
- 更新的评论2：
-rpath 不应用于此目的。强制在给定目录中找到库是有用的。
-rpath should not be used for this purpose. It is useful to force a library to be found in a given directory. The -unresolved-symbol approach looks much better.
再次感谢
推荐答案
看起来你最喜欢的方式已经有了。做好你的调查我们来看看我是否能帮助我们清除为什么。
It looks like you are most of the way there already. Well done with your investigation. Let's see if I can help clear up the 'why' behind it.
这是链接器在做什么。当你链接你的可执行文件（'main'）时，它有一些未被解决的符号（函数和其他东西）。它将向下看下面的库列表，试图解决未解析的符号。一路上，它发现一些符号由libB.so提供，所以它注意到它们现在被这个库解析。
Here's what the linker is doing. When you link your executable ('main' above) it has some symbols (functions and other things) that are unresolved. It will look down the list of libraries that follow, trying to resolve unresolved symbols. Along the way, it finds that some of the symbols are provided by libB.so, so it notes that they are now resolved by this library.
然而，它也发现其中一些符号使用您的可执行文件中尚未解析的其他符号，因此现在还需要解决这些。没有链接到libA.so，您的应用程序将不完整。一旦链接到libA.so，所有符号都被解析，链接完成。
However, it also discovers that some of those symbols use other symbols that are not yet resolved in your executable, so it now needs to resolve those as well. Without linking against libA.so, your application would be incomplete. Once it links against libA.so, all symbols are resolved and linking is complete.
如你所见，使用 -unresolved-symbols- in-shared-libs ，不能解决问题。它只是拖延它，以便这些符号在运行时解决。这就是 -rpath 用于：在运行时指定要搜索的库。如果这些符号无法解决，那么您的应用程序将无法启动。
As you saw, the use of -unresolved-symbols-in-shared-libs, doesn't fix the problem. It just defers it so that those symbols are resolved at run time. That's what -rpath is for: to specify the libraries to be searched at run time. If those symbols can't be resolved then, your app will fail to start.
找出库依赖项并不容易，因为符号可以由更多的而不是一个图书馆，并且通过与任何一个图书馆的联系来获得满足。
It's not an easy thing to figure out library dependencies because a symbol could be provided by more than one library and be satisfied by linking against any one of them.
这里有另一个描述：为什么库链接的顺序有时会导致GCC中的错误？
这篇关于链接动态库与依赖关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
