Libraries in /Usr/Local/Lib Not Found

Libraries in /usr/local/lib not found

This is a runtime error, not a build error. Setting the -L flag does nothing for the runtime linker. What you need to do is to tell the runtime loader to also look in /usr/local/lib for libraries. You can do that in two ways. The first is to add the path to the LD_LIBRARY_PATH environment variable:

export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/lib"

The second is to update the configuration file of the runtime linker. This can happen either in the /etc/ld.so.conf file, by putting the line:

/usr/local/lib

somewhere in that file, or by creating a new *.conf file in the /etc/ld.so.conf.d/ directory that contains the new path. For example:

/etc/ld.so.conf.d/99local.conf

with just:

/usr/local/lib

in it. This is the recommended way of doing this, as it allows you to keep your custom library paths separate from paths set by the system. (The "99" prefix is there to make sure the file is loaded last compared to other files there, so that it won't preempt system paths that could contain the same libraries.)

After you modify/create the file in /etc, you need to run:

ldconfig

as root for the change to take effect. (This command updates the /etc/ld.so.cache file, which is the actual file used by the runtime linker.)

There's also another way for a binary to find needed libraries at runtime. You can actually hard-code library paths into the executable itself. This is accomplished by setting a so called "rpath". This is a linker option and must be passed from gcc (or g++) to the linker, so the -Wl option has to be used. The linker option is -rpath=PATH. So you would need to add this to your link flags:

-Wl,-rpath=/usr/local/lib

I don't recommend this for your case though. An rpath is useful when you're shipping libraries together with your executable (maybe with an installer), and a relative rpath (using the rpath $ORIGIN feature) or absolute one (for when you install in /opt, for example) is then used to find those bundled libs at runtime.

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.

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.

Linux : error loading libraries from /usr/local/lib

Can anyone suggest what could be wrong?

If setting LD_LIBRARY_PATH solves the problem, it's almost certain that you didn't add /usr/local/lib to /etc/ld.so.conf.d/ correctly.

Which file in /etc/ld.so.conf.d/ did you add to?

Maybe you have a typo, or a trailing space, or something.

Is /usr/local/lib searched for shared libraries?

Make sure your LD_LIBRARY_PATH is set up to include all directories you want to search and then test it again.

You can test this quickly with:

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib ffmpeg

which will set it only for that invocation.

Alternatively, you can edit /etc/ld.so.conf which contains the default directories searched. Some Linux distributions may not include /usr/local/lib in that file.

Note that you may also need to update the cache /etc/ld.so.cache by running ldconfig (as root, or with sudo).

g++ not finding library in /usr/local/lib

Found a potential solution:

export LIBRARY_PATH=/usr/local/lib

Not sure if this is the best solution but it works for now. I can put this locally in my .bashrc.

UPDATE: On macOS if you run xcode-select --install it should fix these issues.

gcc: linked libraries in /usr/local/lib are not found, but /etc/ld/so.conf.d/libc.conf lists it?

You should run ldconfig (as root) after every change of the directories configured via /etc/ld.so.conf or under /etc/ld.so.conf.d/, in particular in your case after every update inside /usr/local/lib (e.g. after every addition or update of some shared libraries there).

ld: library not found for -l:/usr/local/lib/libopencv_xphoto.3.0.0.dylib

tl;dr Yes, the : is the issue.

I've no idea what rosmake is, but the linker will want a -L option, specifying the library path, and a -l option, specifying the library:

-L/usr/local/lib -lopencv_xphoto

You normally only use -l/usr/local/lib/libopencv_xphoto.3.0.0.dylib if you want to disambiguate between .a and .dylib files. If you don't then use both -L and -l.

---

Related Topics