我在我的ELF文件上运行了arm-linux-gnueabihf-ldd（一个来自Cygwin - 不要问 - 还有一个来自Ubuntu），尽管已经通过包括 - 删除了Ubuntu上的警告 - rpath-link，我假设它是一个静态的动态依赖，考虑到我读到它的难以捉摸的manpage的模糊性，dll仍然显示ld-linux.so.3作为未解决的5个之一，但链接器从未抱怨过其他四个！在这种情况下，路径是通过apt-get安装的本地副本。
这浪费时间导致主人抱怨＆＃34;未找到＆＃34; （意思是，正如我后来发现的那样，ELF文件已找到，但未命名的库并非如此）。事实上，主机机器中的大部分都在/ lib中，其余部分在/ usr / lib中，这让我觉得-rpath和/或-rpath-link应该告诉它在主机上寻找解决方案的位置，好像主机不够智能，无法知道它在哪里保存库。
我没有找到任何东西＆＃34;更高级别＆＃34; （比如，更不透明）比简单的arm-linux-gnueabihf-ld选项（或者，扩展名为arm-linux-gnueabihf-g ++选项），它们在使用时足够清晰，并且不会导致如下消息：
arm-linux-gnueabihf-g++: error: unrecognized command line option ‘-rpath’
arm-linux-gnueabihf-g++: error: unrecognized command line option ‘-rpath’
当我知道该死的时候，它已经认识到了＃34; -rpath＆＃34;在不同的环境中，它抱怨它无法在构建机器上找到对主机无用的路径！
答案 0 :(得分：0)
您是否尝试过man ld？
完整文档位于binutils manual，您可以使用info ld阅读。
-rpath-link，我假设它是动态依赖静态
不，它告诉链接器在哪里可以找到间接共享库依赖项，因此它可以检查它们以确保没有未解析的引用。
。事实上主机在/ lib中有大部分，而/ usr / lib中的其余部分让我认为-rpath和/或-rpath-link应该告诉它在主机上寻找解决方案的位置< / p>
没有
-rpath添加了可执行文件的路径，因此在运行时，动态加载程序将在该路径运行时中查找共享库依赖项。这是指定共享库路径的一种方法，长期使用ldconfig，LD_LIBRARY_PATH等等（详见ld.so(8)）。
-rpath-link告诉链接器在链接时查找共享库依赖项的位置，但不影响在运行时如何找到依赖项。
您无法将-rpath传递给g++，因为它是链接器的一个选项，g++无法理解它。使用-Wl,-rpath告诉g++将其传递给链接器。