libtool: Usage, Options & Common CI Errors
libtool hides platform differences in building and linking shared libraries.
libtool wraps the compiler/linker so a project builds .so/.dylib/.dll the same way everywhere, producing .la helper files. In CI the friction is libtoolize setup and stale .la files baking wrong absolute paths after a cache move.
What it does
GNU libtool provides a uniform interface for building static and shared libraries across platforms, hiding compiler- and OS-specific flags. It emits .la metadata files and an rpath-aware wrapper so built binaries find libraries before installation.
Common usage
libtoolize --install --copy # set up libtool in a project
autoreconf -fi # runs libtoolize for you
./configure && make # libtool drives the link
libtool --mode=link gcc -o libfoo.la foo.lo -rpath /usr/lib
libtool --mode=install install libfoo.la /usr/libOptions
| Item | What it does |
|---|---|
| libtoolize --install | Add libtool support files to a project |
| --mode=compile|link|install | Select the libtool operation |
| -rpath <dir> | Required to build a shared library |
| .la file | Libtool archive metadata (not a real lib) |
| LT_INIT | configure.ac macro that enables libtool |
Common errors in CI
"Possibly undefined macro: LT_INIT" - libtool is not installed or libtoolize did not run; install libtool and re-run autoreconf -fi. Stale .la files contain absolute paths and dependency_libs; after moving a cached build tree they cause "cannot find -lfoo" or wrong rpaths - distros increasingly delete .la files for this reason. "libtool: link: cannot build a shared library" without -rpath - add -rpath to the link. Pin matching libtool/automake versions.