using ldconfig and ld.so.conf versus LD_LIBRARY_PATH

Question

I often build various libraries from source code to play with, such as gmp-6.1.2, mpfr-4.0.1, and gcc-7.x. In doing so, I prefer to use --prefix=/usr/local/gcc-7.2.0 so I know exactly where it is installed and does not mess up existing libraries. And then I all I basically know is what make install tells me at the end, to update or set LD_LIBRARY_PATH and sometimes but not always LD_RUN_PATH.

most of the time I just manually set LD_LIBRARY_PATH as needed later on, or set it globally in something like /etc/bash.bashrc.local and that has worked.

This is what make install says:

Libraries have been installed in:
  /usr/local/mfprtest/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the '-LLIBDIR'
flag during linking and do at least one of the following:
  - add LIBDIR to the 'LD_LIBRARY_PATH' environment variable
    during execution
  - add LIBDIR to the 'LD_RUN_PATH' environment variable
    during linking
  - use the '-Wl,-rpath -Wl,LIBDIR' linker flag
  - have your system administrator add LIBDIR to '/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.

Is there a better way, or a more offical way? of using ldconfig and ld.so.conf than using LD_LIBRARY_PATH and LD_RUN_PATH, and PATH? This is specifically for writing my own code, but could be for other users, where I want to link against various newer versions of a library than what's installed with a given linux version, such as gmp, mpfr, and then using various manually installed versions of gcc such as gcc-5.x or gcc-6.x or gcc-7.x.

basically, once I install /usr/local/gcc-7.3.0 for example, I want myself and any other user who either writes or runs home grown c, c++, or fortran source code on the system to use /usr/local/gcc-7.3.0 and not the system versions in /usr/bin/ and /usr/lib64/

Answer 1

The solution to this is to add your library directories /usr/local/gcc-7.3.0/lib/ to /etc/ld.so.conf (or a file in /etc/ld.so.conf.d/) and run ldconfig or change users' shell profiles to override the systems' LD_LIBRARY_PATH/LD_RUN_PATH and add the individual */lib entries so that the linker can find the shared objects.

Once you start adding libraries, the complexity of maintaining this increases, so bear that in mind.

Another option that you have is to link all files from /usr/local/<library>/{bin,lib,include} into /usr/local/{bin,lib,include}. This greatly simplifies the ld.so.conf or LD_LIBRARY_PATH/LD_RUN_PATH although you will need to live with messy /usr/local/{bin,lib,include}.

The 'official' way to do this is to use the system's package manager and install the distribution's maintained versions of the libraries in the chosen locations (/usr/lib/, /lib, etc).

Answer 2

For the executables (as opposed to libraries), the users will need to have a PATH correctly set in their environment. This can be done either via their own shell startup files or system-wide, for instance via /etc/profile (but note that this file is not guaranteed to be read under all configurations).

Now, for the libraries, such as GMP and MPFR:

1. If you used a run path when building GCC, then nothing else needs to be done to be able to use GCC: the libraries will be found via the run path.
2. Otherwise, or if you want the users to be able to use the libraries directly for other purpose (e.g. with their own software), then using ldconfig (and possibly /etc/ld.so.conf) may be the best solution. But note that if the users want to compile against these libraries, they will also need LIBRARY_PATH and CPATH (or C_INCLUDE_PATH, etc.).

Note: LD_LIBRARY_PATH is still useful for things that are temporary (e.g. testing) and for libraries installed in the user's home directory (there does not seem to be the equivalent to ldconfig for user-side configuration). But it may override the run path, which is a problem in some cases (e.g. for make check to check a library that has just been built and for which an earlier, compatible version is already installed).