'library-path'、'rpath' 和 'rpath-link' 背后的基本原理和预期用途

问：

我注意到很多人，包括我，都不知道链接器搜索路径背后的基本原理和预期用途：“library-path”、“rpath”和“rpath-link”。someody 能向我们解释这一点吗？

上下文

在我阅读了所有内容之后，我倾向于认为“library-path”和“rpath”就足够了。“rpath-link”的基本原理和预期用途对我来说是一个谜。让我解释一下原因。
设置 'library-path' 会将指定的路径传递给链接器，以便在 link（/build） 时在指定路径上查找库。
设置“rpath”将指定的路径存储在构建的可执行文件中，链接器随后在应用程序运行时（即在运行时）查看指定的路径。
因此，如果你的库位于非标准位置，那么你需要指定“library-path”来构建你的可执行文件，并指定“rpath”来运行它。
现在 GNU 链接器文档说：“-rpath 和 -rpath-link 之间的区别在于，-rpath 选项指定的目录包含在可执行文件中并在运行时使用，而 -rpath-link 选项仅在链接时有效。
这就提出了两个问题：
1）如果“rpath-link”中的“r”代表“runtime”，那么“rpath-link”这个名字似乎具有误导性，因为它是在链接时使用的。
2） 我已经在“library-path”中指定了我的库目录的链接时间。我认为'rpath-link'没有用。奇怪的现实：从 http://www.kaizou.org/2015/01/linux-libraries/ 我知道“library-path”不用于辅助依赖项（从一个共享库到另一个共享库的依赖项）。要解决这些次要依赖关系，您需要设置 'rpath' 或 'rpath-link'。那么我的问题是：您不能使用“library-path”来指定次要依赖项，而是不得不使用“rpath-link”的原因是什么？

我是如何偶然发现这个问题的

我有一个名为应用程序的可执行文件，它想使用 liba.so 的功能，所以我将应用程序链接到 liba.so。liba.so 取决于 libb.so。liba.so 和 libb.so 都位于目录 mylibs 中。当我想构建我的可执行文件时，我遇到了以下消息：

/usr/bin/ld: warning: libb.so.80, needed by /.../liba.so, not found (try using -rpath or -rpath-link)

后跟几个未定义的引用错误。
为了正确构建它，我必须将“library-path”和“rpath-link”（或“rpath”）都设置为目录mylibs。令我困惑的是，为什么“library-path”不也用于搜索次要依赖项 libb.so，并且必须设置一个额外的“rpath-link”来搜索这个次要依赖项。

相关问题：-rpath-link 的基本原理