GNU Info
(libtool.info)AC_PROG_LIBTOOL
The `AC_PROG_LIBTOOL' macro
---------------------------
If you are using GNU Autoconf (or Automake), you should add a call to
`AC_PROG_LIBTOOL' to your `configure.in' file. This macro adds many
new tests to the `configure' script so that the generated libtool
script will understand the characteristics of the host:
- Macro: AC_PROG_LIBTOOL
- Macro: AM_PROG_LIBTOOL
Add support for the `--enable-shared' and `--disable-shared'
`configure' flags.(1) `AM_PROG_LIBTOOL' was the old name for this
macro, and although supported at the moment is deprecated.
By default, this macro turns on shared libraries if they are
available, and also enables static libraries if they don't
conflict with the shared libraries. You can modify these defaults
by calling either the `AC_DISABLE_SHARED' or `AC_DISABLE_STATIC'
macros:
# Turn off shared libraries during beta-testing, since they
# make the build process take too long.
AC_DISABLE_SHARED
AC_PROG_LIBTOOL
The user may specify modified forms of the configure flags
`--enable-shared' and `--enable-static' to choose whether shared
or static libraries are built based on the name of the package.
For example, to have shared `bfd' and `gdb' libraries built, but
not shared `libg++', you can run all three `configure' scripts as
follows:
trick$ ./configure --enable-shared=bfd,gdb
In general, specifying `--enable-shared=PKGS' is the same as
configuring with `--enable-shared' every package named in the
comma-separated PKGS list, and every other package with
`--disable-shared'. The `--enable-static=PKGS' flag behaves
similarly, but it uses `--enable-static' and `--disable-static'.
The same applies to the `--enable-fast-install=PKGS' flag, which
uses `--enable-fast-install' and `--disable-fast-install'.
The package name `default' matches any packages which have not set
their name in the `PACKAGE' environment variable.
This macro also sets the shell variable LIBTOOL_DEPS, that you can
use to automatically update the libtool script if it becomes
out-of-date. In order to do that, add to your `configure.in':
AC_PROG_LIBTOOL
AC_SUBST(LIBTOOL_DEPS)
and, to `Makefile.in' or `Makefile.am':
LIBTOOL_DEPS = @LIBTOOL_DEPS@
libtool: $(LIBTOOL_DEPS)
$(SHELL) ./config.status --recheck
If you are using GNU automake, you can omit the assignment, as
automake will take care of it. You'll obviously have to create
some dependency on `libtool'.
- Macro: AC_LIBTOOL_DLOPEN
Enable checking for dlopen support. This macro should be used if
the package makes use of the `-dlopen' and `-dlpreopen' flags,
otherwise libtool will assume that the system does not support
dlopening. The macro must be called *before* `AC_PROG_LIBTOOL'.
- Macro: AC_LIBTOOL_WIN32_DLL
This macro should be used if the package has been ported to build
clean dlls on win32 platforms. Usually this means that any
library data items are exported with `__declspec(dllexport)' and
imported with `__declspec(dllimport)'. If this macro is not used,
libtool will assume that the package libraries are not dll clean
and will build only static libraries on win32 hosts.
This macro must be called *before* `AC_PROG_LIBTOOL', and
provision must be made to pass `-no-undefined' to `libtool' in
link mode from the package `Makefile'. Naturally, if you pass
`-no-undefined', you must ensure that all the library symbols
*really are* defined at link time!
- Macro: AC_DISABLE_FAST_INSTALL
Change the default behaviour for `AC_PROG_LIBTOOL' to disable
optimization for fast installation. The user may still override
this default, depending on platform support, by specifying
`--enable-fast-install'.
- Macro: AC_DISABLE_SHARED
- Macro: AM_DISABLE_SHARED
Change the default behaviour for `AC_PROG_LIBTOOL' to disable
shared libraries. The user may still override this default by
specifying `--enable-shared'.
- Macro: AC_DISABLE_STATIC
- Macro: AM_DISABLE_STATIC
Change the default behaviour for `AC_PROG_LIBTOOL' to disable
static libraries. The user may still override this default by
specifying `--enable-static'.
The tests in `AC_PROG_LIBTOOL' also recognize the following
environment variables:
- Variable: CC
The C compiler that will be used by the generated `libtool'. If
this is not set, `AC_PROG_LIBTOOL' will look for `gcc' or `cc'.
- Variable: CFLAGS
Compiler flags used to generate standard object files. If this is
not set, `AC_PROG_LIBTOOL' will not use any such flags. It affects
only the way `AC_PROG_LIBTOOL' runs tests, not the produced
`libtool'.
- Variable: CPPFLAGS
C preprocessor flags. If this is not set, `AC_PROG_LIBTOOL' will
not use any such flags. It affects only the way `AC_PROG_LIBTOOL'
runs tests, not the produced `libtool'.
- Variable: LD
The system linker to use (if the generated `libtool' requires one).
If this is not set, `AC_PROG_LIBTOOL' will try to find out what is
the linker used by CC.
- Variable: LDFLAGS
The flags to be used by `libtool' when it links a program. If
this is not set, `AC_PROG_LIBTOOL' will not use any such flags. It
affects only the way `AC_PROG_LIBTOOL' runs tests, not the produced
`libtool'.
- Variable: LIBS
The libraries to be used by `AC_PROG_LIBTOOL' when it links a
program. If this is not set, `AC_PROG_LIBTOOL' will not use any
such flags. It affects only the way `AC_PROG_LIBTOOL' runs tests,
not the produced `libtool'.
- Variable: NM
Program to use rather than checking for `nm'.
- Variable: RANLIB
Program to use rather than checking for `ranlib'.
- Variable: LN_S
A command that creates a link of a program, a soft-link if
possible, a hard-link otherwise. `AC_PROG_LIBTOOL' will check for
a suitable program if this variable is not set.
- Variable: DLLTOOL
Program to use rather than checking for `dlltool'. Only meaningful
for Cygwin/MS-Windows.
- Variable: OBJDUMP
Program to use rather than checking for `objdump'. Only meaningful
for Cygwin/MS-Windows.
- Variable: AS
Program to use rather than checking for `as'. Only used on
Cygwin/MS-Windows at the moment.
When you invoke the `libtoolize' program (Note: Invoking
libtoolize), it will tell you where to find a definition of
`AC_PROG_LIBTOOL'. If you use Automake, the `aclocal' program will
automatically add `AC_PROG_LIBTOOL' support to your `configure' script.
Nevertheless, it is advisable to include a copy of `libtool.m4' in
`acinclude.m4', so that, even if `aclocal.m4' and `configure' are
rebuilt for any reason, the appropriate libtool macros will be used.
The alternative is to hope the user will have a compatible version of
`libtool.m4' installed and accessible for `aclocal'. This may lead to
weird errors when versions don't match.
---------- Footnotes ----------
(1) `AC_PROG_LIBTOOL' requires that you define the `Makefile'
variable `top_builddir' in your `Makefile.in'. Automake does this
automatically, but Autoconf users should set it to the relative path to
the top of your build directory (`../..', for example).
automatically generated by info2www version 1.2.2.9