|
11.1.1 Extra Configure Options
What follows is a list that describes the more commonly used options
that are automatically added to configure , by virtue of using
`AC_PROG_LIBTOOL' in your `configure.in'. The Libtool Manual
distributed with Libtool releases always contains the most up to date
information about libtool options:
- `--enable-shared'
- `--enable-static'
- More often invoked as `--disable-shared' or equivalently
`--enable-shared=no' these switches determine whether
libtool should build shared and/or static libraries in this
package. If the installer is short of disk space, they might like to
build entirely without static archives. To do this they would use:
|
$ ./configure --disable-static
|
Sometimes it is desirable to configure several related packages with the
same command line. From a scheduled build script or where subpackages
with their own configure scripts are present, for example.
The `--enable-shared' and `--enable-static' switches also
accept a list of package names, causing the option to be applied to
packages whose name is listed, and the opposite to be applied to those
not listed.
By specifying:
|
$ ./configure --enable-static=libsnprintfv,autoopts
|
libtool would pass `--enable-static' to only the packages
named libsnprintfv and autoopts in the current tree. Any
other packages configured would effectively be passed
`--disable-static'. Note that this doesn't necessarily mean that
the packages must honour these options. Enabling static libraries for
a package which consists of only dynamic modules makes no sense, and the
package author would probably have decided to ignore such requests,
See section 11.1.2 Extra Macros for Libtool.
- `--enable-fast-install'
- On some machines,
libtool has to relink executables when they
are installed, See section 10.7 Installing an Executable. Normally, when an end
user builds your package, they will probably type:
|
$ ./configure
$ make
$ make install
|
libtool will build executables suitable for copying into their
respective installation destinations, obviating the need for relinking
them on those hosts which would have required it. Whenever
libtool links an executable which uses shared libraries, it
also creates a wrapper script which ensures that the environment
is correct for loading the correct libraries, See section 10.5 Executing Uninstalled Binaries. On those hosts which require it, the wrapper
script will also relink the executable in the build tree if you attempt
to run it from there before installation.
Sometimes this behaviour is not what you want, particularly if you are
developing the package and not installing between test compilations. By
passing `--disable-fast-install', the default behaviour is
reversed; executables will be built so that they can be run from the
build tree without relinking, but during installation they may be
relinked.
You can pass a list of executables as the argument to
`--enable-fast-install' to determine which set of executables will
not be relinked at installation time (on the hosts that require it). By
specifying:
|
$ ./configure --enable-fast-install=autogen
|
The autogen executable will be linked for fast installation
(without being relinked), and any other executables in the build tree
will be linked for fast execution from their build location. This is
useful if the remaining executables are for testing only, and will never
be installed.
Most machines do not require that executables be relinked in this way,
and in these cases libtool will link each executable once
only, no matter whether `--disable-fast-install' is used.
- `--with-gnu-ld'
This option is used to inform libtool that the C compiler is
using GNU ld as its linker. It is more often used in the opposite
sense when both gcc and GNU ld are installed,
but gcc was built to use the native linker. libtool
will probe the system for GNU ld, and assume that it is used by
gcc if found, unless `--without-gnu-ld' is passed to
configure.
- `--disable-libtool-lock'
In normal operation, libtool will build two objects for every
source file in a package, one PIC(19) and one non-PIC. With
gcc and some other compilers, libtool can specify a
different output location for the PIC object:
|
$ libtool gcc -c shell.c
gcc -c -pic -DPIC shell.c -o .libs/shell.lo
gcc -c foo.c -o shell.o >/dev/null 2>&1
|
When using a compiler that doesn't accept both `-o' and
`-c' in the same command, libtool must compile first
the PIC and then the non-PIC object to the same destination file and
then move the PIC object before compiling the non-PIC object. This
would be a problem for parallel builds, since one file might overwrite
the other. libtool uses a simple shell locking mechanism to
avoid this eventuality.
If you find yourself building in an environment that has such a
compiler, and not using parallel make , then the locking
mechanism can be safely turned off by using
`--disable-libtool-lock' to gain a little extra speed in the
overall compilation.
- `--with-pic'
- In normal operation, Libtool will build shared libraries from PIC
objects and static archives from non-PIC objects, except where one
or the other is not provided by the target host. By specifying
`--with-pic' you are asking
libtool to build static
archives from PIC objects, and similarly by specifying
`--without-pic' you are asking libtool to build shared
libraries from non-PIC objects.
libtool will only honour this flag where it will produce a
working library, otherwise it reverts to the default.
|