Bar*_*art 5 c++ linker linker-errors ld linker-flags
我注意到，包括我在内的许多人都不知道链接程序搜索路径背后的原理和预期用途：“库路径”，“ rpath”和“ rpath-link”。有人可以向我们解释吗？
在阅读完所有内容后，我倾向于认为“ library-path”和“ rpath”就足够了。“ rpath-link”的原理和预期用途对我来说还是一个谜。让我解释一下原因。
设置'library-path'会将指定的路径传递给链接器，以在link（/ build）时在指定的路径中查找库。
设置“ rpath”会将指定的路径存储在生成的可执行文件中，链接器随后会在运行应用程序时（即在运行时）查看指定的路径。
因此，如果您的库位于非标准位置，则需要指定“ library-path”来构建可执行文件，并指定“ rpath”来运行它。
现在，GNU链接器文档说：“ -rpath和-rpath-link之间的区别在于，-rpath选项指定的目录包含在可执行文件中并在运行时使用，而-rpath-link选项仅在链接时有效。 ”
这引起了两个问题：
1）如果“ rpath-link”中的“ r”代表“运行时”，则名称“ rpath-link”似乎具有误导性，因为它是在链接时使用的。
2）我已经在“ library-path”中为链接时间指定了我的库目录。我认为“ rpath-link”没有用。奇怪的现实：来自http://www.kaizou.org/2015/01/linux-libraries/我知道'library-path'不用于辅助依赖性（从一个共享库到另一个共享库的依赖）。要解决这些次级依赖性，您需要设置“ rpath”或“ rpath-link”。那么我的问题是：什么是你不能使用“库路径”的理由也说明二次依赖性，而是有义务使用“rpath的链接”？
我有一个名为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中。这使我感到困惑，为什么不同时使用“ library-path”来搜索二级依赖libb.so，而必须设置一个附加的“ rpath-link”来搜索该二级依赖。
相关问题： -rpath-link的原理