Does LD_LIBRARY_PATH really cause inconsistencies?

Question

The blog article "LD_LIBRARY_PATH – or: How to get yourself into trouble!" by the DTU Computing Center states:

3. Inconsistency: This is the most common problem. LD_LIBRARY_PATH forces an application to load a shared library it wasn’t 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.

Is this really true? LD_LIBRARY_PATH allows us to modify the search path for dynamic libraries, but does it really suppress the soname lookup that ensures binary compatibility?

(Because, by my interpretation, the Program Library HOWTO doesn't say any such thing.)

Or is the author unaware of the concept of maintaining a consistent library versioning scheme, and therefore assuming that one is not in use for the library in question?

Answer 1

I think the LD_LIBRARY should only be used for testing and not for a final installation, for it allows to use a specified library before the standard library location are used. But The linux documentation project says this about LD_LIBRARY_PATH and puts it more clear than I can.

3.3.1. LD_LIBRARY_PATH

You can temporarily substitute a different library for this particular execution. In Linux, the environment variable LD_LIBRARY_PATH is a colon-separated set of directories where libraries should be searched for first, before the standard set of directories; this is useful when debugging a new library or using a nonstandard library for special purposes. The environment variable LD_PRELOAD lists shared libraries with functions that override the standard set, just as /etc/ld.so.preload does. These are implemented by the loader /lib/ld-linux.so. I should note that, while LD_LIBRARY_PATH works on many Unix-like systems, it doesn't work on all; for example, this functionality is available on HP-UX but as the environment variable SHLIB_PATH, and on AIX this functionality is through the variable LIBPATH (with the same syntax, a colon-separated list).

LD_LIBRARY_PATH is handy for development and testing, but shouldn't be modified by an installation process for normal use by normal users; see ``Why LD_LIBRARY_PATH is Bad'' at http://www.visi.com/~barr/ldpath.html for an explanation of why. But it's still useful for development or testing, and for working around problems that can't be worked around otherwise. If you don't want to set the LD_LIBRARY_PATH environment variable, on Linux you can even invoke the program loader directly and pass it arguments. For example, the following will use the given PATH instead of the content of the environment variable LD_LIBRARY_PATH, and run the given executable:

/lib/ld-linux.so.2 --library-path PATH EXECUTABLE

Just executing ld-linux.so without arguments will give you more help on using this, but again, don't use this for normal use - these are all intended for debugging.

taken at august 13th 2013 from: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

The link inside the document is old, found a the intended article here: http://xahlee.info/UnixResource_dir/_/ldpath.html

edit

You can override a library to which a program is linked to during building/installing because of the order in which ld.so will lookup a library to load at runtime. A library found at in a location specified inside de environmental variable LD_LIBRARY_PATH will be loaded instead of a library specified the default path ( /lib and the /usr/lib)

from man 8 ld.so

   ld.so loads the shared libraries needed by a program, prepares the pro‐
   gram to run, and then runs it.  Unless  explicitly  specified  via  the
   -static  option to ld during compilation, all Linux programs are incom‐
   plete and require further linking at run time.

   The necessary shared libraries needed by the program are  searched  for
   in the following order

   o      Using      the      environment     variable     LD_LIBRARY_PATH
          (LD_AOUT_LIBRARY_PATH for a.out programs).  Except if  the  exe‐
          cutable is a setuid/setgid binary, in which case it is ignored.

   o      From  the  cache file /etc/ld.so.cache which contains a compiled
          list of candidate libraries previously found  in  the  augmented
          library  path.  Libraries  installed  in  hardware  capabilities
          directories (see below) are prefered to other libraries.

   o      In the default path /lib, and then /usr/lib.