### 2.8 Hardcode library names for Guile ¶

On some systems you would want to hardcode file names of libraries required by Lepton when compiling the code. It is true, for example, on Debian and its derivatives. The issue you may encounter on Debian and several other systems is partitioning of header files and binaries of a library and putting them into different files and, to make them harder for using in Guile, extending file name extensions of library binaries and their symlinks by adding some info at the end. So, for instance, a binary library name may look like `libglib-2.0.so.0.7000.1` and its symlink name like `libglib-2.0.so.0`. Guile, on the other hand, cannot find such libraries because it uses canonical file extensions for looking up for them, which is `.so` on Linux, and thus would look for `libglib-2.0.so` in this example. It could never use all the convoluted and complex algorithms `libtool` and other C compiler tools use, otherwise it would itself turn into autotools along with `gcc` or `cmake`. Symlinks with canonical names are available on Debian in development packages. It’s OK to install them when the user wants to build Lepton from sources as they are also required for compiling C code. However, a mere mortal who installs Debian package of Lepton usually doesn’t want to have them installed so the package should be prepared for it. Or, she would like to clean up her system and remove the development packages. In both cases, hardcoding existing library file names in Scheme code is sufficient for Lepton tools to work correctly, and Lepton supports it by using the environment variable USE_LDCONFIG. It should be set to the absolute filename of `ldconfig`, the utility that may fetch and report names of all libraries installed on the system. When building Lepton, it may be used on the `configure` stage as follows:

    ./configure USE_LDCONFIG=/sbin/ldconfig