File: libtool.info,  Node: Introduction,  Next: Libtool paradigm,  Up: Top

1 Introduction
**************

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

   GNU Libtool simplifies your 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 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.

* Menu:

* 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.