Okay, you need to have a piece of software find a dynamic library residing in
You have been using
LD_LIBRARY_PATH manually but found out it is a pain in the ass in the long run (in automation scenarios, sudoing, etc…)
What you want to do is embed in the binary file the location where the OS will find the missing libraries.
This is what the RUNPATH facilities are for.
You have two options depending on the task at hand and your willingness to modify the build rules of the product you are using.
Option 1: the environment variable
Launch your build command passing it the custom locations of your libraries:
LD_RUN_PATH=/usr/local/lib make all
This is a colon separated specification, so you can:
LD_RUN_PATH=/usr/local/lib:/var/lib make all
Option 2: the compiler/linker option
If you want a more definitive approach you can explicitly set your custom locations in the build rules of the project you’re compiling. Using the GNU toolset, you can pass the relevant option to the linker (ld) through a compiler option with:
The -R is the option you want to give to
ld. the -Wl, option is the way to tell the compiler to ignore the option but pass it to
Typically in a Makefile, this will end up looking like this:
CFLAGS=-Wl,-R/usr/local/lib -g -O2 -Wall -Wextra -Isrc -pthread -rdynamic -DNDEBUG $(OPTFLAGS) -D_FILE_OFFSET_BITS=64
When you can not recompile
If you can not easily recompile the binary file (as in a packager-managed build), you still can modify its RUNPATH record. This is achieved through chrpath or elfedit but you will overwrite the existing path and the new value will have to be shorter or equal to the original.
Finally, provided you have access to the location pointed to by your binary file, you can also create symbolic links to the actual location of the DLL you need to link to.
For more info
Read about the rpath option on the GNU linker man page
Learn why you want to avoid LD_LIBRARY_PATH