我在我的ELF文件上运行了arm-linux-gnueabihf ldd(一个来自Cygwin，不要问，还有一个来自Ubuntu)，尽管通过包含-rpath链接消除了Ubuntu上的警告，我认为这是一个动态依赖静态的，考虑到我阅读它的难以捉摸的手册页的模糊性，dll仍然显示ld-linux.so.3作为5个未解决的问题之一，但链接者从来没有抱怨过其他四个人！在这种情况下，路径是通过apt-get安装的本地副本。
这种时间浪费导致主机抱怨"找不到"(这意味着，正如我后来发现的，ELF文件找到了，但未命名的库没有找到)。事实上，主机在/lib中有这些库的大部分，而在/usr/lib中有其余的库，这让我认为-rpath和/或-rpath链接应该告诉它在主机上的哪里查找它们的解析，就好像主机不够智能，不知道它在哪里存放库一样。
我不想寻找比简单的arm-linux-gneabihf-ld选项(或者，扩展为arm-linux-gneabiHF-g++选项)更"高级"(即，更不透明)的东西，这些选项在使用中足够清晰，不会引起以下消息：
arm-linux-gnueabihf-g++: error: unrecognized command line option ‘-rpath’
arm-linux-gnueabihf-g++: error: unrecognized command line option ‘-rpath’
当我非常清楚的时候，它在不同的上下文中识别出了"-rpath"，它抱怨在构建机器上找不到对主机无用的路径！
您尝试过man ld吗？
完整的文档在binutils手册中，您可以使用info ld阅读该手册。
-rpath链接，我认为它是一个动态依赖静态
不，它告诉链接器在哪里可以找到间接共享库依赖项，因此它可以检查它们以确保没有未解析的引用。
。主机在/lib中有大部分内容，其余内容在/usr/lib中，这让我认为-rpath和/或-rpath链接应该告诉它在主机上的何处查找它们的分辨率
否。
-rpath为可执行文件添加了一个路径，因此在运行时动态加载程序将在运行时在该路径中查找共享库依赖项。这是指定共享库的路径的一种方法，长有ldconfig、LD_LIBRARY_PATH等(有关详细信息，请参阅ld.so(8))。
-rpath-link告诉链接器在链接时间的何处查找共享库依赖项，但不影响在运行时查找依赖项的方式。
无法将-rpath传递给g++，因为这是链接器的一个选项，而g++不理解它。请使用-Wl,-rpath告诉g++将其传递给链接器。