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.
Since early 1995, several different GNU developers have recognized the importance of having shared library support for their packages. The primary motivation for such a change is to encourage modularity and reuse of code (both conceptually and physically) in GNU programs.
Such a demand means that the way libraries are built in GNU packages needs to be general, to allow for any library type the package installer might want. The problem is compounded by the absence of a standard procedure for creating shared libraries on different platforms.
The following sections outline the major issues facing shared library support in GNU, and how I propose that shared library support could be standardized with libtool.
The following specifications were used in developing and evaluating this system:
The following issues need to be addressed in any reusable shared library system, specifically libtool:
ldconfig(8).
I have investigated several different implementations of systems that build shared libraries as part of a free software package. At first, I made notes on the features of each of these packages for comparison purposes.
Now it is clear that none of these packages have documented the details of shared library systems that libtool requires. So, other packages have been more or less abandoned as influences.
In all fairness, each of the implementations that I examined do the job that they were intended to do, for a number of different host systems. However, none of these solutions seem to function well as a generalized, reusable component.
Most were too complex for me to use (much less modify) without understanding exactly what the implementation does, and they were generally not documented.
I think the main problem is that different vendors have different views of what libraries are, and none of the packages I examined seemed to be confident enough to settle on a single paradigm that just works.
Ideally, libtool would be a standard that would be implemented as series of extensions and modifications to existing library systems to make them work consistently. However, I don't have the time or power to convince operating system developers to mend their evil ways, and I want to build shared libraries right now, even on buggy, broken, confused operating systems.
For this reason, I have designed libtool as an independent shell script. It isolates the problems and inconsistencies in library building that plague `Makefile' writers by wrapping the compiler suite on different platforms with a consistent, powerful interface.
I hope that libtool will be useful to and used by the GNU community, and that the lessons I've learned in writing it will be taken up and implemented by designers of library systems.
Go to the first, previous, next, last section, table of contents.