Get rid of "gcc - /usr/bin/ld: warning lib not found"

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).

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).

Is there're other way to get rid of the warning at compilation time (I have it several times and it's very annoying)?

Answers


You need to add the dynamic library equivalent of -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.


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:

/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.

After you've done that, you need to update the linker's database by executing the "ldconfig" command.


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!


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 ld we could try to use -Wl,option to disable a linker warning but from the documentation of GNU ld however there is no option for (de)activating this warnings.

So this leaves us with writing a wrapper script filtering out this warning or compile a custom version of ld.


Need Your Help

HTML5 Video Dimensions

javascript jquery html5-video

I'm trying to get the dimensions of a video of which I'm overlaying onto a page with JavaScript, however it is returning the dimensions of the poster image instead of the actual video as it seems i...

Dynamic, cross-browser script loading

javascript internet-explorer asynchronous cross-browser

I know that IE doesn't have a load event for <script> elements — is there any way to make up for that reliably?