Go to the first, previous, next, last section, table of contents.
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.
Go to the first, previous, next, last section, table of contents.