1. Introduction
The automake command employs libtool, which in turn uses a specific file type and extension. Although extensions are rarely important in Linux, especially when using the command line, file types still exist and are critical. Yet, sometimes extensions hint at the type of file.
In this tutorial, we’ll talk about the function and contents of .la files that libtool works with. First, we discuss the general concept behind libtool. After that, we turn to .la files as a means to facilitate platform-independent library handling.
We tested the code in this tutorial on Debian 12 (Bookworm) with GNU Bash 5.1.4. It should work in most POSIX-compliant environments unless otherwise specified.
2. libtool
Libraries are convenient code capsules, but they can cause issues due to various differences between platforms and operating systems:
To solve many situations that arise from these problems, libtool aims to standardize the process of installing and locating libraries. In particular, the package provides features like documenting and storing library locations, integrating with automated deploying software, as well as basic actions like installing, uninstalling, linking, running, and similar.
For the most part, the functionality of libtool is implemented by means of describing how to locate libraries regardless of the current platform or operating system (OS). Preserving this information between compilation environments reduces the chances that a build should fail.
3. .la Library Files
In essence, since libtool deals with both static and dynamic libraries, it generates wrappers around the original executable as well as the library files themselves. The latter are the .la files in question.
These wrappers aren’t regular binary libraries. libtool is required to read, understand, and interpret them. In fact, .la files are just a textual description of a library that provides support for platform-independent names:
$ cat libx-0.la
# Generated by libtool (GNU libtool) 2.4.7
#
# Please DO NOT delete this file!
# It is necessary for linking the library.
# The name that we can dlopen(3).
dlname='libx-0.so.0'
# Names of this library.
library_names='libx-0.so.0.66610.1 libx-0.so.0 libx-0.so'
[...]
# Version information for libx-0.
current=66610
age=66610
revision=1
# Directory that this library needs to be installed in:
libdir='/usr/local/lib'
Thus, while recognizing and working with a library becomes easier due to this abstraction layer, care should be taken to not try and link an .la file as we would a normal .a (static), .so (dynamic), or similar files.
Also, because of the extra layer, libtool uses .la to distinguish wrappers libraries from the originals:
$ cat Makefile.am
lib_LTLIBRARIES=libx.la
libx_la_SOURCES=x.c
Notably, instead of lib_LIBRARIES and libx_a_SOURCES, for example, this Makefile.am contains an .la equivalent that hints at the use of libtool via the LT prefix: lib_LTLIBRARIES. Furthermore, this directive doesn’t perform the usual linking.
Importantly, .la files are preserved between platforms to provide information about alternative and current library names, dependencies, and versions.
4. Gathering Data and Generating Wrappers
To get the necessary information and generate the abstraction layer, libtool uses several scripts:
- config.guess – guess target system canonical name
- config.sub – validate and expand guessed name
- ltconfig – main configuration
- ltmain.sh – final boilerplate
Initially, the config.* scripts aim to get a basic standardized name for the current system. Based on this name, libtool decides how to generate libraries and wrappers. If this fails, even by guessing a different flavor of UNIX, the shared libraries won’t work.
On the other hand, the ltconfig script runs checks similar to those of autoconf, depending on any command-line parameters to configure. Finally, ltconfig generates a new script with the contents of ltmain.sh as a sort of boilerplate.
To organize this procedure, libtool uses libtoolize:
$ libtoolize --version
libtoolize (GNU libtool) 2.4.7
Written by Gary V. Vaughan <[email protected]>, 2003
Copyright (C) 2022 Free Software Foundation, Inc.
By calling libtoolize in our top-level source directory, we copy or link and set up all four files above into the current directory. While libtoolize works out of the box, we can also configure it with parameters.
5. Summary
In this article, we talked about the libtool and its .la files.
In conclusion, libtool provides a way to make a shared library platform agnostic by using textual descriptions of the relevant metadata.