( Introduction

Info Catalog ( Top ( Top ( Libtool paradigm
 1 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
    `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.
Info Catalog ( Top ( Top ( Libtool paradigm
automatically generated byinfo2html