我在ELF文件上运行了arm-linux-gnueabihf-ldd（一个来自Cygwin，请不要问，另一个来自Ubuntu），尽管通过包含-rpath-link在Ubuntu上消除了警告，考虑到我在易读的手册页上的模棱两可，我假设我使动态依赖项静态化，dll仍然显示ld-linux.so.3作为未解决的5个问题之一，但链接程序从未抱怨过其他4个问题！在这种情况下，路径是通过apt-get安装的本地副本。
浪费时间导致主机抱怨“未找到”（正如我后来发现的那样，WAS找到了ELF文件，但未找到未命名的库）。主机在/ lib中拥有大多数这些东西，而在/ usr / lib中则具有其余的事实，这使我认为-rpath和/或-rpath-link应该告诉它在主机上的哪里寻找它们的分辨率，好像主机不够智能，无法知道将库保存在哪里。
除了简单的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’
当我知道该死的时候，它会在不同的上下文中识别“ -rpath”，并且抱怨它无法在构建计算机上找到对主机无用的路径！
最佳答案
您尝试过man ld吗？
完整的文档位于binutils manual中，您可以使用info ld进行阅读。
-rpath-link，我认为这使动态依赖项成为静态
不，它告诉链接器在哪里可以找到间接共享库依赖关系，因此可以检查它们以确保没有未解析的引用。
。主机在/ lib中具有大多数这些，而在/ usr / lib中则具有其余的事实，这使我认为-rpath和/或-rpath-link应该告诉它在主机上的哪里查找其分辨率。
没有。-rpath将路径添加到可执行文件，以便在运行时动态加载程序将在运行时在该路径中查找共享库依赖项。这是指定共享库路径的一种方法，该路径带有ldconfig，LD_LIBRARY_PATH等（有关详细信息，请参见ld.so(8)）。-rpath-link告诉链接器在链接时在哪里查找共享库的依赖关系，但不影响运行时如何查找依赖关系。
您不能将-rpath传递给g++，因为它是链接器的一个选项，而g++无法理解。使用-Wl,-rpath告诉g++将其传递给链接器。
关于c++ - 在哪里可以找到arm-linux-gnueabihf-ld的联机帮助页，更不用说写得很好的联机帮助页了，其中包括-rpath和-rpath-link？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/37487070/