我注意到很多人，包括我在内，并不准确了解链接器搜索路径背后的基本原理和预期用途：“library-path”、“rpath”和“rpath-link”。有人可以向我们解释一下吗？
语境
经过我所有的阅读，我倾向于认为'library-path'和'rpath'就足够了。'rpath-link' 的基本原理和预期用途对我来说是个谜。让我解释一下为什么。设置 'library-path' 将指定的路径传递给链接器，以在链接（/构建）时
在指定路径中查找库。
设置“rpath”将指定的路径存储在构建的可执行文件中，链接器随后会在应用程序运行时（即运行时）查看指定的路径。
因此，如果您的库位于非标准位置，那么您需要指定“library-path”来构建可执行文件并指定“rpath”来运行它。
现在 GNU 链接器文档说：“-rpath 和 -rpath-link 之间的区别在于 -rpath 选项指定的目录包含在可执行文件中并在运行时使用，而 -rpath-link 选项仅在链接时有效。 "
这提出了两个问题：
1) 如果 'rpath-link' 中的 'r' 代表 'runtime'，那么名称 'rpath-link' 似乎具有误导性，因为它是在链接时使用的。
2) 我已经在“库路径”中为链接时间指定了我的库目录。我认为“rpath-link”没有用。奇怪的现实：来自http://www.kaizou.org/2015/01/linux-libraries/我知道“库路径”不用于辅助依赖项（从一个共享库到另一个共享库的依赖项）。要解决这些次要依赖项，您需要设置“rpath”或“rpath-link”。那么我的问题是：您可能不使用“library-path”来指定辅助依赖项而是必须使用“rpath-link”的原因是什么？
我是如何偶然发现这个问题的
我有一个名为 app 的可执行文件，它想要使用 liba.so 中的功能，所以我将 app 链接到 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。我很困惑为什么“库路径”也不能用于搜索二级依赖项 libb.so，并且必须设置一个额外的“rpath-link”来搜索这个二级依赖项。
相关问题： -rpath-link 的基本原理