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

Question

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

Solution 1

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.

Solution 2

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.

Solution 3

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!

Solution 4

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.

View more solutions

Comments

[dimba]

I have no root permission in the server the compilation is done. The server is only for compilation and the binary won't be executed on it. 1st question is why at link time I need take care of runtime environment and 2nd one is how get rid of the warning.

[Nikos C.]

@dimba You don't have to take care of it. It's just a warning informing you that the binary won't run on the current machine. As for how to disable the warning without using an rpath during linking, I don't know. (Using an rpath is usually not a good idea, unless you bundle libraries with your executable.) If you don't have root permission, then LD_LIBRARY_PATH is your only option.

[Julien Ruffin]

Many thanks, that solved the issue neatly! It is worth mentioning that /etc/ld.so.conf should be created in the toolchain's target sysroot, not the host one.

[user1011113]

Hi! Can you be more specific about what's the "toolchain's target sysroot"? In my application the toolchain is NOT inside the sysroot, they are in separate paths: * /path-to/sysroot * /path-to/toolchain There's already a proper etc.ld.so.conf under /path-to/sysroot/etc, but I still get link issues. Where exactly inside /path-to/toolchain do I need to put the etc.ld.so.conf file?