10.1 Creating libtool
When you install a distribution of Libtool on your development machine,
a host specific libtool program is installed. The examples in
the rest of this chapter use this installed instance of
libtool.
When you start to use Libtool in the build process of your own projects,
you shouldn't require that libtool be installed on the user's
machine, particularly since they may have a different libtool
version to the one used to develop your project. Instead, distribute
some of the files installed by the Libtool distribution along with your
project, and custom build a libtool script on the user's
machine before invoking ./libtool to build any objects. If
you use Autoconf and Automake, these details are taken care of
automatically (see section Using GNU Libtool with configure.in and Makefile.am). Otherwise you should copy the following
files from your own Libtool installation into the source tree of your
own project:
| | $ ls /usr/local/share/libtool
config.guess config.sub libltdl ltconfig ltmain.in
$ cp /usr/local/share/libtool/config.* /usr/local/share/libtool/lt* .
$ ls
config.guess config.sub ltconfig ltmain.in
|
You must then arrange for your project build process to create an
instance of libtool on the user's machine, so that it is
dependent on their target system and not your development machine. The
creation process requires the four files you just added to your project.
Let's create a libtool instance by hand, so that you can see
what is involved:
| | $ ./config.guess
hppa1.1-hp-hpux10.20
$ ./ltconfig --disable-static --with-gcc ./ltmain.sh hppa1.1-hp-hpux10.20
checking host system type... hppa1.1-hp-hpux10.20
checking build system type... hppa1.1-hp-hpux10.20
checking whether ln -s works... yes
checking for ranlib... ranlib
checking for BSD-compatible nm... /usr/bin/nm -p
checking for strip... strip
checking for gcc... gcc
checking whether we are using GNU C... yes
checking for objdir... .libs
checking for object suffix... o
checking for executable suffix... no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo... yes
checking if gcc supports -fno-rtti -fno-exceptions ... no
checking for ld used by GCC... /opt/gcc-lib/hp821/2.7.0/ld
checking if the linker (/opt/gcc-lib/hp821/2.7.0/ld) is GNU ld... no
checking whether the linker (/opt/gcc-lib/hp821/2.7.0/ld) supports \
shared libraries... yes
checking how to hardcode library paths into programs... relink
checking whether stripping libraries is possible... yes
checking for /opt/gcc-lib/hp821/2.7.0/ld option to reload object \
files... -r
checking dynamic linker characteristics... hpux10.20 dld.sl
checking command to parse /usr/bin/nm -p output... ok
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
creating libtool
$ ls
config.guess config.sub ltconfig
config.log libtool ltmain.sh
$ ./libtool --version
ltmain.sh (GNU libtool) 1.3c (1.629 1999/11/02 12:33:04)
|
The examples in this chapter are all performed on a HP-UX system,
but the principles depicted are representative of any of the platforms
to which Libtool has been ported (see section B. PLATFORMS).
Often you don't need to specify any options, and if you omit the
configuration triplet (see section 3.4 Configuration Names),
ltconfig will run config.guess itself. There are
several options you can specify which affect the generated
libtool, See section `Invoking ltconfig' in The Libtool Manual. Unless your project has special
requirements, you can usually use the simplified:
With the current release of Libtool, you must be careful that `$CC'
is set to the same value when you call ltconfig as when you
invoke the libtool it generates, otherwise libtool
will use the compiler specified in `$CC' currently, but with the
semantics probed by ltconfig for the compiler specified in
`$CC' at the time it was executed.
| 
