我注意到包括我在内的很多人都没有准确地知道链接器搜索路径背后的基本原理和用途：＆＃39; library-path＆＃39; rpath＆＃39;，和＆＃39; rpath-link＆＃39;。有人可以向我们解释一下吗？
在我读完之后，我倾向于想到“图书馆之路”。和＆＃39; rpath＆＃39;应该够了。 “rpath-link＆＃39;的基本原理和预期用途对我来说是一个谜。让我解释一下原因。
设置＆＃39; rpath＆＃39;将指定的路径存储在构建的可执行文件中，链接器随后在运行应用程序时查看指定的路径，即在运行时。
因此，如果您的图书馆位于非标准位置，那么您需要指定“图书馆路径”。构建你的可执行文件和＆＃39; rpath＆＃39;运行它。
现在，GNU链接器文档说：＆＃34; -rpath和-rpath-link之间的区别在于-rpath选项指定的目录包含在可执行文件中并在运行时使用，而-rpath-link选项仅在链接时间。＆＃34;
这提出了两个问题：
1）如果＆＃39; r＆＃39;在＆＃39; rpath-link＆＃39;代表＆＃39;运行时＆＃39;，然后是名称＆＃39; rpath-link＆＃39;似乎有误导性，因为它在链接时使用
2）我已经在＆＃39; library-path＆＃39;中为链接时间指定了我的库目录。我认为没有用于＆＃39; rpath-link＆＃39;。奇怪的现实：来自http://www.kaizou.org/2015/01/linux-libraries/我知道＆＃39;图书馆路径＆＃39;不用于辅助依赖项（从一个共享库到另一个共享库的依赖项）。要解决这些辅助依赖关系，您需要设置＆＃39; rpath＆＃39;或者＆＃39; rpath-link＆＃39;。我的问题是：你可能不会使用图书馆路径＆＃39;要还指定辅助依赖关系，而是有义务使用＆＃39; rpath-link＆＃39;？
我有一个名为app的可执行文件想要使用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)
后面有几个未定义的参考错误 要正确构建它，我必须设置两个库路径＆＃39;和＆＃39; rpath-link＆＃39; （或＆＃39; rpath＆＃39;）到目录mylibs。令我困惑的是为什么＆＃39;图书馆路径＆＃39;也不用于搜索辅助依赖项libb.so以及另一个“rpath-link”链接。必须设置为搜索此次要依赖项。
相关问题： Rationale of -rpath-link