# slibtool

`slibtool` is an independent reimplementation of the commonly used libtool,

written in C. `slibtool` is designed to be a clean, fast, easy-to-use

libtool drop-in replacement, and is accordingly aimed at package authors,

distro developers, and system integrators. `slibtool` maintains compatibility

with libtool in nearly every aspect of the tool's functionality as well as

semantics, leaving out (or turning into no-ops) only a small number of

features that are no longer needed on modern systems.

Being a compiled binary, and although not primarily written for the sake of

performance, building a package with `slibtool` is often faster than with its

script-based counterpart. The resulting performance gain would normally vary

between packages, and is most noticeable in builds that invoke libtool a large

number of times, and which are characterized by the short compilation time of

individual translation units.

## Requirements for building slibtool

- a C toolchain, consisting of...

    - a C compiler such as gcc, clang, or [cparser].

    - The compiler should support -std=c99.

    - The system's libc should support -D_XOPEN_SOURCE=700.

## Usage

With most packages, simply adding `LIBTOOL=slibtool` to the `make` invocation

should suffice. To have `slibtool` operate in debug mode (outputting a colorized

raw argument vector), use `LIBTOOL=dlibtool` instead, or alternatively add

`--debug` to the libtool flags inside of your Makefile.

### Corner cases

Some programs which make heavy use of recursive `make` are known to drop the

`LIBTOOL` value at some point in the process, and as such you may additionally

need to export the environment variable; `export MAKE="make LIBTOOL=slibtool"`.

`slibtool` additionally installs two symlinks that are the equivalent of

`-disable-shared` and `-disable-static`, named `slibtool-static` and

`slibtool-shared`, respectively. These symlinks should be used when building

packages that have the above switches hard-coded into the generated libtool

script; two examples of such packages are `binutils` and `gdb`, which both have

shared library builds disabled by default. A quick way to determine whether this

invocation form is appropriate is to run `./libtool --features` from the build

directory, then check whether the output has either shared or static library

builds disabled.

## Differences from GNU libtool

While `slibtool` aims to be compatible with all common usages of libtool, there

are a few differences at the implementation level that should be noted.

- `-rpath` argument values are passed to the compiler and linker as needed only;

  `-rpath` is often [mis]used by libtool to add redundant paths to a program's

  linker search path. When using slibtool, `-rpath` argument values are only

  forwarded to the compiler and linker when pointing to non-default linker

  directories, and are accordingly filtered out when pointing to default library

  locations (i.e. `/usr/lib`, `/lib`, and so on).

- no-ops

    - `-R`, which adds a path to the generated program's run-time search path;

      this switch is currently not needed, and is accordingly ignored.

    - `-export-symbols`, which exports symbols listed in a given file, and

      `-export-symbols-regex`, which exports symbols matching a regex;

      both are unimplemented because similar functionality has long been

      provided by the compiler or toolchain; `gcc` has supported setting ELF

      visibility since v4.0, for instance, and PE import library support is

      provided by slibtool via the --output-def linker switch and a subsequent

      invocation of dlltool.

    - `-no-install`, which considers the executable wrapper to be optional;

      this switch is not needed on modern systems, and is accordingly ignored.

- No `libltdl`.

  libltdl is nowadays no longer needed; it serves to provide a `dlopen()`

  functionality on systems which do not offer it, i.e. HP-UX and BeOS,

  however since neither HP-UX nor BeOS is currently supported by slibtool,

  there exists no urgent need to provide equivalent functionality.

## Development

Major changes to slibtool should be discussed on [#midipix] prior to pursuing

a considerable effort, and patches should be sent, gpg-signed, to the project

maintainer; before hacking on slibtool, please take a moment of your time and

read the [CONTRIB] document.

Before finalizing your changes, please consider building at least once with

`cparser` as the compiler. cparser is excellent at catching logical errors

and semantic flaws, and at the time of this writing is capable of spotting

some errors that go unnoticed by the other major open source compilers.

For a few examples of such errors, see commits [94d109f], [1142bf2], and

[55c95a8].

## License

`slibtool` is distributed under a permissive [MIT license].

[MIT license]:  http://git.midipix.org/cgit.cgi/slibtool/tree/COPYING.SLIBTOOL

[libltdl]:      https://www.gnu.org/software/libtool/manual/html_node/Using-libltdl.html#Using-libltdl

[dlopen()]:     http://pubs.opengroup.org/onlinepubs/9699919799/functions/dlopen.html

[CONTRIB]:      http://git.midipix.org/cgit.cgi/slibtool/tree/CONTRIB

[libtool]:      https://www.gnu.org/software/libtool/

[#midipix]:     irc://irc.freenode.net/#midipix

[cparser]:      http://pp.ipd.kit.edu/git/cparser/

[94d109f]:      http://git.midipix.org/cgit.cgi/slibtool/commit/?id=94d109fa418c024c214a50d645624e2e2935e6d1

[1142bf2]:      http://git.midipix.org/cgit.cgi/slibtool/commit/?id=1142bf2e13f411cf967c1ed8b4060d7829eb13bb

[55c95a8]:      http://git.midipix.org/cgit.cgi/slibtool/commit/?id=55c95a829928ae9f053678a58a2145276cad9c08