GNU Info

(libtool.info)Introduction

---

Next: Libtool paradigm Prev: Top Up: Top

---

Enter node , (file) or (file)node

Introduction
************

   In the past, if a source code package developer wanted to take
advantage of the power of shared libraries, he needed to write custom
support code for each platform on which his package ran.  He also had
to design a configuration interface so that the package installer could
choose what sort of libraries were built.

   GNU Libtool simplifies the developer's job by encapsulating both the
platform-specific dependencies, and the user interface, in a single
script.  GNU Libtool is designed so that the complete functionality of
each host type is available via a generic interface, but nasty quirks
are hidden from the programmer.

   GNU Libtool's consistent interface is reassuring... users don't need
to read obscure documentation in order to have their favorite source
package build shared libraries.  They just run your package `configure'
script (or equivalent), and libtool does all the dirty work.

   There are several examples throughout this document.  All assume the
same environment: we want to build a library, `libhello', in a generic
way.

   `libhello' could be a shared library, a static library, or both...
whatever is available on the host system, as long as libtool has been
ported to it.

   This chapter explains the original design philosophy of libtool.
Feel free to skip to the next chapter, unless you are interested in
history, or want to write code to extend libtool in a consistent way.

Motivation

Why does GNU need a libtool?

Issues

The problems that need to be addressed.

Other implementations

How other people have solved these issues.

Postmortem

Learning from past difficulties.