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