我有联系时以下警告：摆脱 “GCC - 在/ usr/bin中/ LD：警告LIB未找到”
/usr/bin/ld: warning: libxxx.so.6, needed by /a/b/c/libyyy.so, not found (try using -rpath or -rpath-link)
设置环境变量LD_LIBRARY_PATH = path_to_libxxx.so.6沉默警告（添加-Lpath_to_libxxx.so.6不起作用）。
我有一个单独的编译服务器，其中得到的二进制文件只是编译。 二进制文件在其他服务器上执行，并且二进制文件看到libxxx.so.6文件（与ldd executable一起检查）。
是否有其他方法可以在编译时摆脱警告（我有好几次了，这很烦人）？
您需要添加的-L动态库相当于：
-Wl,-rpath-link,/path/to/lib
这将导致链接来寻找非规范的地方共享库，但只用于验证链接的目的是正确的。
如果您希望程序找到在运行时在该位置库，然后有一个类似的选项要做到这一点：
-Wl,-rpath,/path/to/lib
但是，如果你的程序没有这个运行良好，那么你不需要它。
确保运行时链接程序知道所需库的路径。这是通过在/etc/ld.so.conf.d/中添加一个文件来完成的。例如，/etc/ld.so.conf.d/foo具有以下内容：
/usr/local/lib/foo/
如果你有一个很老的Linux版本的，/etc/ld.so.conf.d/可能不支持，在这种情况下，您可能需要将路径直接添加到/etc/ld.so.conf文件中。
完成之后，您需要通过执行“ldconfig”命令更新链接器的数据库。
我在编译完成的服务器中没有root权限。服务器*仅用于编译，二进制文件不会被执行。第一个问题是为什么在*链接*时我需要照顾运行时环境，第二个是如何摆脱警告。 – dimba
@dimba你不需要照顾它。这只是一个警告，通知您二进制文件不会在当前机器上运行。至于如何在链接过程中不使用rpath来禁用警告，我不知道。 （除非将库与可执行文件捆绑在一起，否则使用rpath通常不是一个好主意。）如果您没有root权限，那么LD_LIBRARY_PATH是您唯一的选择。 –
使用命令行选项来消除这些警告的唯一方法就是-L标志，它好奇地不适合你（也许你可以在这里发布更多细节）。由于警告是由ld生成的，因此我们可以尝试使用-Wl,option来禁用链接程序警告，但是从documentation of GNU ld中禁用，但是没有用于（禁用）激活此警告的选项。
因此，这让我们编写一个包装脚本来过滤掉这个警告或编译一个自定义版本ld。
我知道这是旧的，但here's a better fix：
的根本原因：
当LD由GCC调用启动解决 库的依赖问题真正发生。 GCC和LD都知道包含库的sysroot ，但LD可能缺少一个关键的 组件：/etc/ld.so.conf文件。这是一个exampleld.so。的conf文件 从树莓PI系统：
包括/etc/ld.so.conf.d/*.conf
的/etc/ld.so.conf.d目录包含下列文件：
00-vmcs.conf： /选择/ VC/lib中
臂-Linux的gnueabihf.conf：
/LIB /臂-Linux的gnueabihf/usr/lib中/臂-Linux的gnueabihf
libc.conf：
的/ usr /本地/ lib中
通用溶液
该问题可以通过复制LD配置音响容易解决交叉工具链的LD可以找到它们的位置。有不过 一个陷阱：如果你的交叉工具链与MinGW的 建成（大部分是），它可能没有访问水珠（）函数，以便 它不会是能够解析启用通配符包含语句 像* .conf文件。这里的解决方法是只需手动/etc/ld.so.conf.d结合所有conf文件的 内容并将其粘贴到 的/etc/ld.so.conf
*的/ opt/VC/lib目录
/lib目录/ ARM-Linux的gnueabihf
/usr/lib目录/ ARM-Linux的gnueabihf
在/ usr/local/lib目录*
一旦创建了LD。 so.conf文件e正确的文件夹，您的 工具链将能够自动解析所有共享库引用 ，您将不会再看到该错误消息！
请澄清一下您的问题。编译和链接程序时会发生什么，以及当您尝试运行程序时会发生什么情况。 –
@NikosC。澄清在问题 – dimba