he 'PACKAGE' environment variable.

     The '--with-pic' and '--without-pic' configure flags can be used to
     specify whether or not 'libtool' uses PIC objects.  By default,
     'libtool' uses PIC objects for shared libraries and non-PIC objects
     for static libraries.  The '--with-pic' option also accepts a
     comma-separated list of package names.  Specifying
     '--with-pic=PKGS' is the same as configuring every package in PKGS
     with '--with-pic' and every other package with the default
     configuration.  The package name 'default' is treated the same as
     for '--enable-shared' and '--enable-static'.

     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.ac':

          LT_INIT
          AC_SUBST([LIBTOOL_DEPS])

     and, to 'Makefile.in' or 'Makefile.am':

          LIBTOOL_DEPS = @LIBTOOL_DEPS@
          libtool: $(LIBTOOL_DEPS)
                  $(SHELL) ./config.status libtool

     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'.

     Aside from 'disable-static' and 'disable-shared', there are other
     options that you can pass to 'LT_INIT' to modify its behaviour.
     Here is a full list:

     'dlopen'
          Enable checking for dlopen support.  This option should be
          used if the package makes use of the '-dlopen' and
          '-dlpreopen' libtool flags, otherwise libtool will assume that
          the system does not support dlopening.

     'win32-dll'
          This option 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 option is not used, libtool
          will assume that the package libraries are not dll clean and
          will build only static libraries on win32 hosts.

          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!

     'aix-soname=aix'
     'aix-soname=svr4'
     'aix-soname=both'
          Enable the '--with-aix-soname' to 'configure', which the user
          can pass to override the given default.

          By default (and *always* in releases prior to 2.4.4), Libtool
          always behaves as if 'aix-soname=aix' is given, with no
          'configure' option for the user to override.  Specifically,
          when the '-brtl' linker flag is seen in 'LDFLAGS' at
          build-time, static archives are built from static objects
          only, otherwise, traditional AIX shared library archives of
          shared objects using in-archive versioning are built (with the
          '.a' file extension!).  Similarly, with '-brtl' in 'LDFLAGS',
          libtool shared archives are built from shared objects, without
          any filename-based versioning; and without '-brtl' no shared
          archives are built at all.

          When 'aix-soname=svr4' option is given, or the
          '--with-aix-soname=svr4' 'configure' option is passed, static
          archives are always created from static objects, even without
          '-brtl' in 'LDFLAGS'.  Shared archives are made from shared
          objects, and filename based versioning is enabled.

          When 'aix-soname=both' option is given, or the
          '--with-aix-soname=svr4' 'configure' option is passed, static
          archives are built traditionally (as 'aix-soname=aix'), and
          both kinds of shared archives are built.  The '.la'
          pseudo-archive specifies one or the other depending on whether
          '-brtl' is specified in 'LDFLAGS' when the library is built.

     'disable-fast-install'
          Change the default behaviour for 'LT_INIT' to disable
          optimization for fast installation.  The user may still
          override this default, depending on platform support, by
          specifying '--enable-fast-install' to 'configure'.

     'shared'
          Change the default behaviour for 'LT_INIT' to enable shared
          libraries.  This is the default on all systems where Libtool
          knows how to create shared libraries.  The user may still
          override this default by specifying '--disable-shared' to
          'configure'.

     'disable-shared'
          Change the default behaviour for 'LT_INIT' to disable shared
          libraries.  The user may still override this default by
          specifying '--enable-shared' to 'configure'.

     'static'
          Change the default behaviour for 'LT_INIT' to enable static
          libraries.  This is the default on all systems where shared
          libraries have been disabled for some reason, and on most
          systems where shared libraries have been enabled.  If shared
          libraries are enabled, the user may still override this
          default by specifying '--disable-static' to 'configure'.

     'disable-static'
          Change the default behaviour for 'LT_INIT' to disable static
          libraries.  The user may still override this default by
          specifying '--enable-static' to 'configure'.

     'pic-only'
          Change the default behaviour for 'libtool' to try to use only
          PIC objects.  The user may still override this default by
          specifying '--without-pic' to 'configure'.

     'no-pic'
          Change the default behaviour of 'libtool' to try to use only
          non-PIC objects.  The user may still override this default by
          specifying '--with-pic' to 'configure'.

 -- Macro: LT_LANG (LANGUAGE)
     Enable 'libtool' support for the language given if it has not yet
     already been enabled.  Languages accepted are "C++", "Fortran 77",
     "Java", "Go", and "Windows Resource".

     If Autoconf language support macros such as 'AC_PROG_CXX' are used
     in your 'configure.ac', Libtool language support will automatically
     be enabled.

     Conversely using 'LT_LANG' to enable language support for Libtool
     will automatically enable Autoconf language support as well.

     Both of the following examples are therefore valid ways of adding
     C++ language support to Libtool.

          LT_INIT
          LT_LANG([C++])

          LT_INIT
          AC_PROG_CXX

 -- Macro: AC_LIBTOOL_DLOPEN
     This macro is deprecated, the 'dlopen' option to 'LT_INIT' should
     be used instead.

 -- Macro: AC_LIBTOOL_WIN32_DLL
     This macro is deprecated, the 'win32-dll' option to 'LT_INIT'
     should be used instead.

 -- Macro: AC_DISABLE_FAST_INSTALL
     This macro is deprecated, the 'disable-fast-install' option to
     'LT_INIT' should be used instead.

 -- Macro: AC_DISABLE_SHARED
 -- Macro: AM_DISABLE_SHARED
     Change the default behaviour for 'LT_INIT' to disable shared
     libraries.  The user may still override this default by specifying
     '--enable-shared'.  The option 'disable-shared' to 'LT_INIT' is a
     shorthand for this.  'AM_DISABLE_SHARED' is a deprecated alias for
     'AC_DISABLE_SHARED'.

 -- Macro: AC_ENABLE_SHARED
 -- Macro: AM_ENABLE_SHARED
     Change the default behaviour for 'LT_INIT' to enable shared
     libraries.  This is the default on all systems where Libtool knows
     how to create shared libraries.  The user may still override this
     default by specifying '--disable-shared'.  The option 'shared' to
     'LT_INIT' is a shorthand for this.  'AM_ENABLE_SHARED' is a
     deprecated alias for 'AC_ENABLE_SHARED'.

 -- Macro: AC_DISABLE_STATIC
 -- Macro: AM_DISABLE_STATIC
     Change the default behaviour for 'LT_INIT' to disable static
     libraries.  The user may still override this default by specifying
     '--enable-static'.  The option 'disable-static' to 'LT_INIT' is a
     shorthand for this.  'AM_DISABLE_STATIC' is a deprecated alias for
     'AC_DISABLE_STATIC'.

 -- Macro: AC_ENABLE_STATIC
 -- Macro: AM_ENABLE_STATIC
     Change the default behaviour for 'LT_INIT' to enable static
     libraries.  This is the default on all systems where shared
     libraries have been disabled for some reason, and on most systems
     where shared libraries have been enabled.  If shared libraries are
     enabled, the user may still override this default by specifying
     '--disable-static'.  The option 'static' to 'LT_INIT' is a
     shorthand for this.  'AM_ENABLE_STATIC' is a deprecated alias for
     'AC_ENABLE_STATIC'.

   The tests in 'LT_INIT' also recognize the following environment
variables:

 -- Variable: CC
     The C compiler that will be used by the generated 'libtool'.  If
     this is not set, 'LT_INIT' will look for 'gcc' or 'cc'.

 -- Variable: CFLAGS
     Compiler flags used to generate standard object files.  If this is
     not set, 'LT_INIT' will not use any such flags.  It affects only
     the way 'LT_INIT' runs tests, not the produced 'libtool'.

 -- Variable: CPPFLAGS
     C preprocessor flags.  If this is not set, 'LT_INIT' will not use
     any such flags.  It affects only the way 'LT_INIT' runs tests, not
     the produced 'libtool'.

 -- Variable: LD
     The system linker to use (if the generated 'libtool' requires one).
     If this is not set, 'LT_INIT' 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, 'LT_INIT' will not use any such flags.  It affects only
     the way 'LT_INIT' runs tests, not the produced 'libtool'.

 -- Variable: LIBS
     The libraries to be used by 'LT_INIT' when it links a program.  If
     this is not set, 'LT_INIT' will not use any such flags.  It affects
     only the way 'LT_INIT' 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.  'LT_INIT' 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.

 -- Variable: MANIFEST_TOOL
     Program to use rather than checking for 'mt', the Manifest Tool.
     Only used on Cygwin/MS-Windows at the moment.

 -- Variable: LT_SYS_LIBRARY_PATH
     Libtool has heuristics for the system search path for
     runtime-loaded libraries.  If the guessed default does not match
     the setup of the host system, this variable can be used to modify
     that path list, as follows ('LT_SYS_LIBRARY_PATH' is a
     colon-delimited list like 'PATH'):
        * 'path:' The heuristically determined paths will be appened
          after the trailing colon;
        * ':path' The heuristically determined paths will be prepended
          before the leading colon;
        * 'path::path' The heuristically determined paths will be
          inserted between the double colons;
        * 'path' With no dangling colons, the heuristically determined
          paths will be ignored entirely.

   With 1.3 era libtool, if you wanted to know any details of what
libtool had discovered about your architecture and environment, you had
to run the script with '--config' and grep through the results.  This
idiom was supported up to and including 1.5.x era libtool, where it was
possible to call the generated libtool script from 'configure.ac' as
soon as 'LT_INIT' had completed.  However, one of the features of
libtool 1.4 was that the libtool configuration was migrated out of a
separate 'ltconfig' file, and added to the 'LT_INIT' macro (nee
'AC_PROG_LIBTOOL'), so the results of the configuration tests were
available directly to code in 'configure.ac', rendering the call out to
the generated libtool script obsolete.

   Starting with libtool 2.0, the multipass generation of the libtool
script has been consolidated into a single 'config.status' pass, which
happens after all the code in 'configure.ac' has completed.  The
implication of this is that the libtool script does not exist during
execution of code from 'configure.ac', and so obviously it cannot be
called for '--config' details anymore.  If you are upgrading projects
that used this idiom to libtool 2.0 or newer, you should replace those
calls with direct references to the equivalent Autoconf shell variables
that are set by the configure time tests before being passed to
'config.status' for inclusion in the generated libtool script.

 -- Macro: LT_OUTPUT
     By default, the configured 'libtool' script is generated by the
     call to 'AC_OUTPUT' command, and there is rarely any need to use
     'libtool' from 'configure'.  However, sometimes it is necessary to
     run configure time compile and link tests using 'libtool'.  You can
     add 'LT_OUTPUT' to your 'configure.ac' any time after 'LT_INIT' and
     any 'LT_LANG' calls; that done, 'libtool' will be created by a
     specially generated 'config.lt' file, and available for use in
     later tests.

     Also, when 'LT_OUTPUT' is used, for backwards compatibility with
     Automake regeneration rules, 'config.status' will call 'config.lt'
     to regenerate 'libtool', rather than generating the file itself.

   When you invoke the 'libtoolize' program (*note Invoking
libtoolize::), it will tell you where to find a definition of 'LT_INIT'.
If you use Automake, the 'aclocal' program will automatically add
'LT_INIT' support to your 'configure' script when it sees the invocation
of 'LT_INIT' in 'configure.ac'.

   Because of these changes, and the runtime version compatibility
checks Libtool now executes, we now advise *against* including a copy of
'libtool.m4' (and brethren) in 'acinclude.m4'.  Instead, you should set
your project macro directory with 'AC_CONFIG_MACRO_DIRS'.  When you
'libtoolize' your project, a copy of the relevant macro definitions will
be placed in your 'AC_CONFIG_MACRO_DIRS', where 'aclocal' can reference
them directly from 'aclocal.m4'.

   ---------- Footnotes ----------

   (1) 'LT_INIT' 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).

