Linux Executable Can't Find Shared Library in Same Folder

Why linux doesn't search for shared libraries in the same folder

Adding . to LD_LIBRARY_PATH is generally not recommended as it introduces security risk and also makes program behavior less predictable for the end user. If you absolutely want to go down this path and want to avoid explicit setting of LD_LIBRARY_PATH, you can

link with -Wl,-rpath -Wl,'$ORIGIN'
not call your app directly but rather through a wrapper shell script which would set proper LD_LIBRARY_PATH and then run the app

Linux executable can't find shared library in same folder

LD_LIBRARY_PATH is a quick ad-hoc hack to specify alternate library loading search paths. A more permanent and cleaner solution is to specify the specific sets of paths in which libraries shall be searched specific for your particular binary. This is called the rpath (Wikipedia article on it: https://en.wikipedia.org/wiki/Rpath). There are a number of "variables" that can be specified in the binary rpath that get substituted. In your case the rpath variable ${ORIGIN} would be the most interesting for you. ${ORIGIN} tells the dynamic linker to look for libraries within the very same directory in which also the binary resides.

The rpath can be set at link time with the -rpath linker option, i.e. when invoked through GCC the option would be -Wl,-rpath='${ORIGIN}', i.e.

gcc -o program_binary -Wl,-rpath='${ORIGIN}' -lSDL2_mixer a.o b.o …

For an existing binary the rpath can be set post-hoc using the chrpath or patchelf tools; it's better to set it at link time proper, though.

Linux: executable cannot find shared library

This is very simple: your library is not in the default system path from them the shared libraries are imported. During the compilation, the compile scripts solved these problems. In runtime, you have the LD_PRELOAD or LD_LIBRARY_PATH environment variables.

For example: an export LD_LIBRARY_PATH=/home/darkside/wunderprog/lib will extend the directoried searched for your libraries with the named directory. If there is your libcasablanca.so, you will get what you want.

Normally I use a /home/<myusername>/lib directory in my useronly accounts and set LD_LIBRARY_PATH from .profile.

Loading a shared library in a same directory with the executable file

I found the solution: add rpath option to CMakelists.txt for the executable, not for the shared library.

Error while loading shared libraries from same folder

The issue was that the new version of dependent library has the RUNPATH defined, but the other project/libraries using this library are using RPATH. When the RUNPATH is defined it ignores any defined RPATH, therefore transitive dependencies do ignore the RPATH. The solution was to remove the RUNPATH from the new library and add RPATH. The RPATH has been deprecated so if anyone facing this can use RUNPATH instead of RPATH they should do so.

The change from RUNPATH to RPATH was done with help of this answer.

Linux Program can't find Shared Library at run-time

Symlinks on libraries work fine, as long as the final target they trace to exists and is accessible.

You have built a dynamically-linked executable, that wishes to be linked against libid3-3.8.so.3 at execution time. This was likely linked during the build phase with something like -L/path/to/libid3/directory -lid3.

You have a few options to make libid3 available, in generally decreasing order of preference (since you didn't mention where the file was, I can only be general):

Create a symlink to libid3* in a directory listed in /etc/ld.so.conf (or /lib or /usr/lib)
Copy libid3* to a directory listed in /etc/ld.so.conf (or /lib or /usr/lib) (defaults)
Add the directory containing libid3* to /etc/ld.so.conf
Set LD_LIBRARY_PATH=/directory/path/to/libid3* before running your id3v2 executable.
Recompile id3v2 statically. (It will work, but don't bother.)

After any of the first 3, rerun ldconfig so the linker cache is updated. (You can then run ldconfig -v to verify it's resolvable.)

Note those aren't steps, they're options. You only need to do 1 of them.

Glad you updated the title. #include directives have nothing to do with linking.

C++ Executable cannot find library at runtime, even though it's in /usr/lib (On Linux)

I can't think of a single reason why I would get this error.

The reason is very simple: the dynamic loader hasn't been told to look in /usr/lib/panda3d for shared libraries, and so doesn't.

You can run your program with:

LD_DEBUG=files,libs ./Test

and observe which directories the loader is searching.

panda3d.conf ... with one line: /usr/local/lib/x86_64-linux-gnu/panda3d

That is the wrong directory (or at least not the one where your libraries are).

One way to fix this is to correct the above path to /usr/lib/panda3d and run sudo ldconfig.

Another way is to add -Wl,-rpath=/usr/lib/panda3d to your link line.