Firstly environment variables were developed for UNIX but now Windows and Linux also have these variables. When some process is created it inherits a copy of its parent’s run-time environment, with the exception of explicit changes made by the parent when the child is created by default. A name/value pair makes up an environment variable, and any number of them can be generated and referenced at any time. Commonly upper case letters are used when naming environment variables. This helps to differentiate environment variables from other types of names in programming code in general.In Unix Operating System, environment variables are case sensitive, but not on DOS, OS/2, or Windows.
LD_LIBRARY is also an environment variable of UNIX/Linux Operating System; in this article we will discuss this environment variable in detail.
Usage of LD_LIBRARY_PATH variable
In UNIX/Linux System LD_LIBRARY_PATH to tell dynamic link loader, a small program that begins all your applications, to determine where to look for dynamic shared libraries that an application was linked with. A colon (:) separates a list of directories, and this list is checked even before built-in search path/paths and conventional locations like (/lib, /usr/lib..).
Some other uses of LD_LIBRARY_PATH are:
- Comparing new versions of a shared library to an application that has previously been compiled.
- Relocation of shared libraries, for example, to keep previous versions alive.
- It is also used to create a self-sufficient system, relocatable environment for bigger applications so that they are independent of changing system libraries.
Problem with LD_LIBRARY_PATH
It is very useful until you try to use it to solve your problems. This line seems strange but this is what really happens when you try to apply it in a user/system environment, the scenario gets worse and all environmental variables start depending on it and it crashes down as it can’t handle all tasks!
Some problems faced by using LD_LIBRARY_PATH are:
Security: LD_LIBRARY_PATH directories are checked first, before their actual location. This approach could be used by a malicious individual to force your application to run a malicious version of a shared library. One of the reasons why setuid/setgid executables ignore that variable is because of this.
Performance: Link loader needs to look in all provided directories till it finds shared libraries (linked with application). Consequently will cause several system calls to open and cause them to crash with ENOENT”no such file or directory”. If the specified path has many directories then it will take a long time and you can check this from the startup time of your application. As a result this will cause the whole system to slow down.
Inconsistency: The most prevalent issue caused by the use of LD_LIBRARY_PATH is inconsistency. LD_LIBRARY_PATH compels a programme to load a shared library against which it was not linked, which is very certainly incompatible with the original version. This can be highly evident, such as when the application crashes, or it can result in incorrect results if the picked up library does not exactly match the original version’s functionality. This will be tough to debug the latter, especially.
Solution
The best solution is the less you use it, the less trouble you will face. Infact try to avoid the usage of LD_LIBRARY_PATH:
How to avoid LD_LIBRARY_PATH:
Provide correct location of shared library: When you compile your application, you need to provide exact location of shared libraries and specify the path in the ‘-rpath’ linker option to inform the linker to include them to your executable’s runpath or you can use LD_RUN_PATH variable to specify multiple paths
Tool to fix problem:To fix/change the runpath of a binary executable, there are programmes available, such as chrpath under Linux. The problem in this way is that the executable space that carries this information (i.e. the path string) cannot be expanded, i.e. you can only rewrite an existing path.
Do not put LD_LIBRARY_PATH IN USER PROFILE: By putting LD_LIBRARY_PATH in user profile you will create problems for yourself so avoid this.
Do not put LD_LIBRARY_PATH IN System PROFILE: Some ISVs provide software that automatically inserts global LD LIBRARY PATH settings into system profiles during installation, or even prompt the user to do so. Simply say no! Try to handle the problem in another way, for example by writing a wrapper script, or tell the vendor to rectify it.
LD_LIBRARY_PATH is useful if used for three uses which are mentioned in the usage portion but try to use it as little as possible to protect yourself from getting into trouble.
Conclusion
LD_LIBRARY_PATH is an environmental variable used in Linux/UNIX Systems. It is used to tell dynamic link loaders where to look for shared libraries for specific applications. It is useful until you don’t mess with it. It’s better to avoid the use of LD_LIBRARY_PATH and use alternatives. In this Article the use of the LD_LIBRARY_PATH environmental variable is discussed and then the problem with the use of it is discussed and then its solution. After reading this article you will get to know the pros and cons of the LD_LIBRARY_PATH variable.
