6. Libtool Archives

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):


Purportedly this is the name used when calling dlopen(); on ELF systems, this corresponds to the DT_SONAME tag on the shared object.


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”.


The 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.


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.


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.

6.1. Usefulness of Libtool Archives in today's age

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.