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