Linux 摆脱“gcc - /usr/bin/ld: 未找到警告库”
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/13507600/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Get rid of "gcc - /usr/bin/ld: warning lib not found"
提问by dimba
I have the following warning during link:
我在链接期间收到以下警告：
/usr/bin/ld: warning: libxxx.so.6, needed by /a/b/c/libyyy.so, not found (try using -rpath or -rpath-link)
Setting environment variable LD_LIBRARY_PATH=path_to_libxxx.so.6 silence the warning (adding -Lpath_to_libxxx.so.6 doesn't help).
设置环境变量 LD_LIBRARY_PATH=path_to_libxxx.so.6 使警告静音（添加 -Lpath_to_libxxx.so.6 没有帮助）。
I have a separate compilation server, where the resulting binary is only compile.
The binary is executed on other server and there the libxxx.so.6 is seen by the binary (checked with ldd executable).
我有一个单独的编译服务器，只编译生成的二进制文件。二进制文件在其他服务器上执行，并且二进制文件可以看到 libxxx.so.6（用 进行检查ldd executable）。
Is there're other way to get rid of the warning at compilation time (I have it several times and it's very annoying)?
有没有其他方法可以在编译时消除警告（我有几次，这很烦人）？
采纳答案by ams
You need to add the dynamic library equivalent of -L:
您需要添加等效于-L以下内容的动态库：
-Wl,-rpath-link,/path/to/lib
This will cause the linker to look for shared libraries in non-standard places, but only for the purpose of verifying the link is correct.
这将导致链接器在非标准位置查找共享库，但仅用于验证链接是否正确。
If you want the program to find the library at that location at run-time, then there's a similar option to do that:
如果您希望程序在运行时在该位置找到库，那么有一个类似的选项可以做到这一点：
-Wl,-rpath,/path/to/lib
But, if your program runs fine without this then you don't need it.
但是，如果您的程序在没有这个的情况下运行良好，那么您就不需要它了。
回答by Nikos C.
Make sure the paths to the needed libraries are known to the runtime linker. This is done by adding a file in /etc/ld.so.conf.d/ with the needed path. For example, /etc/ld.so.conf.d/foo with the following contents:
确保运行时链接程序知道所需库的路径。这是通过在 /etc/ld.so.conf.d/ 中添加具有所需路径的文件来完成的。例如，/etc/ld.so.conf.d/foo 包含以下内容：
/usr/local/lib/foo/
If you have a very old Linux version, /etc/ld.so.conf.d/ might not be supported, in which case you might have to add the paths directly into the /etc/ld.so.conf file.
如果您使用的是非常旧的 Linux 版本，则可能不支持 /etc/ld.so.conf.d/，在这种情况下，您可能必须将路径直接添加到 /etc/ld.so.conf 文件中。
After you've done that, you need to update the linker's database by executing the "ldconfig" command.
完成后，您需要通过执行“ldconfig”命令来更新链接器的数据库。
回答by Lothar
The only way to silence these warning using command line options would be the -L flag which curiously does not work for you (maybe you can post more details on this). Since the warning is generated by ldwe could try to use -Wl,optionto disable a linker warning but from the documentation of GNU ldhowever there is no option for (de)activating this warnings.
使用命令行选项使这些警告静音的唯一方法是 -L 标志，它奇怪地对您不起作用（也许您可以发布更多详细信息）。由于警告是由ld我们生成的，我们可以尝试使用-Wl,option来禁用链接器警告，但是从GNU ld的文档中，没有用于（取消）激活此警告的选项。
So this leaves us with writing a wrapper script filtering out this warning or compile a custom version of ld.
所以这让我们需要编写一个包装脚本来过滤掉这个警告或编译一个自定义版本的ld.
回答by Wells
I know this is old, but here's a better fix:
我知道这是旧的，但这里有一个更好的解决方法：
The root cause:
The problem actually happens when LD invoked by GCC starts resolving library dependencies. Both GCC and LD are aware of the sysroot containing libraries, however LD may be missing one critical component: the?/etc/ld.so.conf?file. Here's an exampleld.so.conf?file from a Raspberry PI system:
include /etc/ld.so.conf.d/*.conf
The?/etc/ld.so.conf.d?directory contains the following files:
00-vmcs.conf:/opt/vc/lib
arm-linux-gnueabihf.conf:
/lib/arm-linux-gnueabihf /usr/lib/arm-linux-gnueabihf
libc.conf:
/usr/local/lib
The universal solution
?
The problem can be easily solved by copying the LD configuration files to a location where the cross-toolchain's LD can find them. There's one pitfall however: if your cross-toolchain was built with MinGW (most are), it probably did not have access to the?glob()?function so it won't be able to parse a wildcard-enabled include statement like?*.conf. The workaround here is to just manually combine the contents of all .conf files from?/etc/ld.so.conf.d?and paste them into /etc/ld.so.conf
*/opt/vc/lib
/lib/arm-linux-gnueabihf
/usr/lib/arm-linux-gnueabihf
/usr/local/lib*
Once you create the?ld.so.conf file in the correct folder, your toolchain will be able to resolve all shared library references automatically and you won't see that error message again!
根本原因：
当 GCC 调用的 LD 开始解析库依赖项时，问题实际上发生了。GCC 和 LD 都知道包含库的 sysroot，但是 LD 可能缺少一个关键组件：?/etc/ld.so.conf? 文件。这是来自 Raspberry PI 系统的 exampleld.so.conf? 文件：
包括 /etc/ld.so.conf.d/*.conf
?/etc/ld.so.conf.d? 目录包含以下文件：
00-vmcs.conf：/opt/vc/lib
arm-linux-gnueabihf.conf：
/lib/arm-linux-gnueabihf /usr/lib/arm-linux-gnueabihf
libc.conf:
/usr/local/lib
通用解决方案
?
通过将 LD 配置文件复制到跨工具链的 LD 可以找到它们的位置，可以轻松解决该问题。然而，有一个陷阱：如果您的跨工具链是用 MinGW 构建的（大多数是），它可能无法访问?glob()? 函数，因此它将无法解析启用通配符的 include 语句，例如？ *.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 文件后，您的工具链将能够自动解析所有共享库引用，您将不会再看到该错误消息！
