Slibtool

Slibtool is Article description::a surrogate libtool implementation, written in C. It aims at being a replacement for GNU libtool. Unlike GNU libtool it is under active development.

Emerge
Install slibtool:

Usage
In order to make portage prefer slibtool over GNU libtool, add the following lines:

Symlinks
Several different modes of operation can be used by using the corresponding installed symlink, by default either rlibtool or rdlibtool should be used.


 * slibtool: Builds both with shared and static.
 * slibtool-shared: Builds only shared.
 * slibtool-static: Builds only static.
 * dlibtool: Builds both with shared and static and extra debug output.
 * dlibtool-shared: Builds only shared with extra debug output.
 * dlibtool-static: Builds only static with extra debug output.
 * clibtool: Builds both with shared and static and installs the libtool archive files (.la).
 * clibtool-shared: Builds only shared and installs the .la files.
 * clibtool-static: Builds only static and installs the .la files.
 * rlibtool: Automatically determines whether to build shared or static with the build's configure process.
 * rdlibtool: Like rlibtool with extra debug output.
 * rclibtool: Like rlibtool and installs the .la files.
 * rdclibtool: Like rlibtool with extra debug output and installs the .la files.

Undefined references
Using slibtool often exposes undefined references in projects that GNU libtool hides. The can happen because GNU libtool will silently ignore -no-undefined, although even in other cases slibtool will expose undefined references that were previously hidden often with common linker flags or when doing a static build.

Unknown arguments
Using slibtool will expose typos, bogus arguments and other similar mistakes in build systems, GNU libtool often will silently ignore many unknown arguments it receives.

ld cannot find linker flag
When using slibtool ld(1) can fail when its unable to find a linker flag such as -lfoo which represents an internal dependency. This often happens when the build either fails to create the library with libtool meaning the libtool archive file (.la) is entirely missing or that the .la file exists and just needs to be added to the corresponding LDADD or LIBADD variable in the build.

In the event the library cannot be created with libtool as a workaround the build can link directly with the static library (.a) or less preferably pass the linker path directly to ld(1) with -Wl,-Lpath/to/foo which will prevent slibtool from transforming the linker path to -Lpath/to/foo/.libs.

flow error: unexpected condition or other
When using rlibtool slibtool will try to automatically determine if the build should be shared or static based on the corresponding configure arguments. However some builds that use $(LIBTOOL) do not necessarily use use autotools or any kind of configure system and rlibtool is not able to determine what to build. In these cases slibtool-shared, slibtool-static or slibtool should be used instead which build shared, static and both respectively.

No libtool archive (.la) files installed
By default slibtool does not install the libtool archive (.la) files, build systems, ebuilds, programs and other tools should not expect them to exist on the user's system or in the DESTDIR during the installation process. Occasionally some programs hard code the dependencies on .la files in their code and they can still be installed by slibtool in those cases by using rclibtool, rdclibtool or one of the clibtool symlinks.

path not found: ../.libs/.libs
The libtool implementation creates the .libs directories during compilation for its own internal use. The build system and downstream projects should not use this directory directly rather than indirectly through the use of $(LIBTOOL). Since GNU libtool is far more permissive it often lets projects getting away with using either, but slibtool expects the paths without .libs.

External resources

 * - [tracker] Packages failing to build with sys-devel/slibtool (Gentoo Bugzilla)
 * Slibtool issue tracker