看起来你最喜欢的方式已经有了。做好你的调查我们来看看我是否能帮助我们清除为什么。

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中的错误？