Gcc - /Usr/Bin/Ld Error: Cannot Find <Library> in /Usr/Local/Lib Though Ldconfig List It, and Path Added to Ld.So.Conf

gcc - /usr/bin/ld error: cannot find library in /usr/local/lib though ldconfig list it, and path added to ld.so.conf

ld, the linker, does not use external configuration files for that. ldconfig is for the loader, ld.so. Create a makefile if you want to set values for the linker somewhere.

Shared library in /usr/local/lib not found

gcc -print-search-dirs will tell you what path the compiler checks. /usr/local/lib is simply not among them, so your compile time linker (in this case the new gold ld from binutils) doesn't find the library while the dynamic one (ld-linux.so which reads the cache written by ldconfig) does. Presumably the builds you've done previously added -L/usr/local/lib as necessary in their makefiles (usually done by a ./configure script), or you installed binaries.

Shared libraries not found but in ld.so.conf path

The problem ended up being an issue with my compiler-linker toolchain. The specs file gcc was using to compile all the libraries in question was pointing to an older version of ld located in the /tools/ directory. Readjusting the specs file per the instructions here resulted in gcc producing binaries that compiled against the correct linker and called on the correct dynamic library loader that was able to search /lib and /usr/lib and find the libraries. In other words, be very careful when adjusting the gcc specs file!

shared library not found during compilation

At this point I should be able to use the libraries without specifying the library path

Here lies the confusion.

You have built your shared library libbtiGPIO.so (just sticking with that one),
placed it in /usr/local/lib/agony, and updated the ldconfig database accordingly.

The effect of that is when you run a program that has been linked with libbtiGPIO
then the dynamic linker (/lib/x86_64-linux-gnu/ld-2.21.so, or similar) will know where to look
to load that library into the process and you will not need to tell it by setting an LD_LIBRARY_PATH in the environment.

However, you haven't done anything that affects the list of default library
search directories that are hardwired into your build of gcc, that it passes to
the linker (/usr/bin/ld) when you link a program with libbtiGPIO in the first place.

That list of default search directories is what you will find if your do a verbose
build of your program - gcc -v ... - and then pick out the value of LIBRARY_PATH
from the output, e.g.

LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/5/:\
        /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/:\
        /usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/:\
        /lib/x86_64-linux-gnu/:\
        /lib/../lib/:\
        /usr/lib/x86_64-linux-gnu/:\
        /usr/lib/../lib/:\
        /usr/lib/gcc/x86_64-linux-gnu/5/../../../:\
        /lib/:\
        /usr/lib

/usr/local/lib/agony is not one of those and to make it one of those you
would have to build gcc from source yourself. Hence, in order to link your
program with libbtiGPIO you still need to tell ld where to find it with
-L/usr/local/lib/agony -lbtiGPIO.

Shared library not found in /usr/local/lib

Figured it out. While library names have to be prefixed with "lib", that prefix must not be specified when linking. That is, gcc -o prog main.c -llibt is wrong while gcc -o prog main.c -lt works as expected.

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

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.

---

Related Topics