One of the most commonly misunderstood features of libtool,
especially in modern days, is the presence of the *.la files, the so-called
libtool archives. These files are simple textual file descriptors of a
library built with libtool and are consumed only by
libtool and, in some circumstances, libltdl.
The reason for their existence has to be found in the classical UNIX link editors, especially
before the introduction of ELF for executables and shared objects. While this modern format
carries over metadata for the libraries within the file itself, in particular version
information (see Section 4, “Library Versioning”) and dependencies, static archives and even
older shared object formats do not provide that kind of information, so the eponymous
.la is used to augment them.
These are the most important variables to be found in a libtool archive file (a one-liner description is available within the file itself):
dlname
Purportedly this is the name used when calling dlopen(); on ELF
systems, this corresponds to the DT_SONAME tag on the shared object.
library_names
This is a list of equivalent names for the same library; it lists both the unversioned
filename, the DT_SONAME one, and the fully-versioned file. More
detailed information on the topic of versions within libtool
are to be found in Section 4, “Library Versioning”.
old_libraryThe name of the static archive, if any has been built, otherwise an empty string. This allows libtool to know whether static link against the library is possible at all.
inherited_linker_flags
This variable lists selected link editor flags that are needed to ensure the correct ABI
is used with the library, for instance. In most cases, all you'll be seeing in here is
-pthread, as it's probably the only such flag used on modern systems.
dependency_libs
With this list, libtool aim to compensate the lack of
dependency information in static archives; indeed this list provides a similar list to the
one in DT_NEEDED tags for ELF files.
Contrarily to the ELF dependencies, the list does not include version information of any kind, as it's designed to work in turn with static archives, which do not have version information either. Also, these dependencies are used for both static and dynamic link, causing no small headache for developers and distributors alike, as it is well possible that different versions of the same dependency are brought in, due to this list.
While .la files have been introduced with the aim of solving a real
problem, as ELF systems weren't common at the time, their presence on most modern systems is
vestigial at best. The only modern consumer of these files, as has been indicated, is
libtool itself, which already reduces their usefulness, as projects
shy away from it, or even from the whole Autotools stack as a build system.
It might not be obvious, but automake by default will not consult the Libtool Archives at all, when linking an executable. To make use of these files, you have to initialize and use libtool, even when building a project that consists only of executables.
Since initializing libtool in these situations will increase build time and complexity, even most Autotools based projects do not use it.
Historically, KDE 3 used to use a modified libltdl to load its architectural modules, which
relied on the presence of the .la files for all the plugins. Other than
that, even software using libltdl nowadays is not relying on these files, and rather access
directly the generated plugin files (either in ELF or other formats).
Dependency tracking for static linking is, nowadays, mostly supplanted by the use of
pkg-config, as can be read in Section 2.1, “Static linking”. Since most build systems, custom and not, have easy access to the data stored in
.pc files, without the need to use libtool when linking the consumer, the
whole idea of Libtool Archives is, nowadays, considered obsolete.
Indeed, it is not uncommon for distributions to skip packaging of .la
files altogether, at least for those packages whose detection is possible through
pkg-config.