Differences

This shows you the differences between two versions of the page.

--- bash:environment_variables:ld_library_path [2021/02/02 13:17] – peter
+++ bash:environment_variables:ld_library_path [2021/02/02 13:40] (current) – [BASH - Environment Variables - LD_LIBRARY_PATH] peter
@@ Line 1: / Line 1: @@
 ====== BASH - Environment Variables - LD_LIBRARY_PATH ======
+**LD_LIBRARY_PATH** tells the dynamic link loader (ld.so, the program that starts all your applications) where to search for the dynamic shared libraries an application was linked against.
+Multiple directories can be listed, separated by a colon (:), and this list is then searched before the compiled-in search path(s), and the standard locations (typically /lib, /usr/lib, …).
+LD_LIBRARY_PATH can be used for:
+  * testing new versions of a shared library against an already compiled application
+  * re-locating shared libraries, e.g. to preserve old versions
+  * creating a self-contained, relocatable(!) environment for larger applications, such that they do not depend on (changing) system libraries – many software vendors use that approach.
+<WRAP alert>
+**ALERT:**  Problems with using **LD_LIBRARY_PATH** include:
+  * **Security**:   Directories specified in LD_LIBRARY_PATH get searched before(!) the standard locations.
+    * A nasty person could get your application to load a version of a shared library that contains malicious code!
+    * That’s one reason why setuid/setgid executables do neglect that variable!
+  * **Performance**:  The link loader has to search all the directories specified, until it finds the directory where the shared library resides – for ALL shared libraries the application is linked against!
+    * This means a lot of system calls to **open()**, that will fail with **ENOENT (No such file or directory)**!
+    * If the path contains many directories, the number of failed calls will increase linearly, and you can tell that from the start-up time of the application.
+    * If some (or all) of the directories are in an NFS environment, the start-up time of your applications can really get long – and it can slow down the whole system!
+  * **Inconsistency**:  This is the most common problem.
+    * LD_LIBRARY_PATH forces an application to load a shared library it was not linked against, and that is quite likely not compatible with the original version.
+    * This can either be very obvious, i.e. the application crashes, or it can lead to wrong results, if the picked up library not quite does what the original version would have done.
+    * Especially the latter is sometimes hard to debug.
+  * **Non-Fixing of actual issue**.  Very often it is used as a crutch to fix a problem that could have been avoided by other means; but the actual issue is not fixed, as this workaround becomes relied upon.
+    * These settings get dependent on this crutch – and if it is eventually taken away, they start to stumble (i.e. fail to run).
+</WRAP>
+----
+===== Example Usage =====
 When an executable is run that relies on shared libraries not defined in the global search path, an error similar to the following is displayed:
@@ Line 13: / Line 47: @@
 </code>
-----
+-----
 Typically this problem is fixed by running ldd(1) on the executable, locating the missing shared libraries, and adding one or more directories to the LD_LIBRARY_PATH environment variable:
@@ Line 94: / Line 128: @@
 curl: try 'curl --help' or 'curl --manual' for more information
 </code>
+<WRAP info>
+**NOTE:**  Using LD_LIBRARY_PATH for this purpose is a complete hack, and ideally this variable should be avoided.
+</WRAP>