This is libtool.info, produced by makeinfo version 4.0 from
libtool.texi.

INFO-DIR-SECTION GNU programming tools
START-INFO-DIR-ENTRY
* Libtool: (libtool).           Generic shared library support script.
END-INFO-DIR-ENTRY

INFO-DIR-SECTION Individual utilities
START-INFO-DIR-ENTRY
* libtoolize: (libtool)Invoking libtoolize.     Adding libtool support.
END-INFO-DIR-ENTRY

   This file documents GNU Libtool 1.4.2

   Copyright (C) 1996-2000 Free Software Foundation, Inc.

   Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1 or
any later version published by the Free Software Foundation; with the
no Invariant Sections, with no Front-Cover Texts, and with no
Back-Cover Texts.  A copy of the license is included in the section
entitled "GNU Free Documentation License".


File: libtool.info,  Node: Information sources,  Next: Porting inter-library dependencies,  Up: New ports

Information sources
-------------------

   Once it is clear that a new port is necessary, you'll generally need
the following information:

canonical system name
     You need the output of `config.guess' for this system, so that you
     can make changes to the libtool configuration process without
     affecting other systems.

man pages for `ld' and `cc'
     These generally describe what flags are used to generate PIC, to
     create shared libraries, and to link against only static
     libraries.  You may need to follow some cross references to find
     the information that is required.

man pages for `ld.so', `rtld', or equivalent
     These are a valuable resource for understanding how shared
     libraries are loaded on the system.

man page for `ldconfig', or equivalent
     This page usually describes how to install shared libraries.

output from `ls -l /lib /usr/lib'
     This shows the naming convention for shared libraries on the
     system, including which names should be symbolic links.

any additional documentation
     Some systems have special documentation on how to build and install
     shared libraries.

   If you know how to program the Bourne shell, then you can complete
the port yourself; otherwise, you'll have to find somebody with the
relevant skills who will do the work.  People on the libtool mailing
list are usually willing to volunteer to help you with new ports, so
you can send the information to them.

   To do the port yourself, you'll definitely need to modify the
`libtool.m4' macros in order to make platform-specific changes to the
configuration process.  You should search that file for the `PORTME'
keyword, which will give you some hints on what you'll need to change.
In general, all that is involved is modifying the appropriate
configuration variables (*note libtool script contents::).

   Your best bet is to find an already-supported system that is similar
to yours, and make your changes based on that.  In some cases, however,
your system will differ significantly from every other supported system,
and it may be necessary to add new configuration variables, and modify
the `ltmain.in' script accordingly.  Be sure to write to the mailing
list before you make changes to `ltmain.in', since they may have advice
on the most effective way of accomplishing what you want.


File: libtool.info,  Node: Porting inter-library dependencies,  Prev: Information sources,  Up: New ports

Porting inter-library dependencies support
------------------------------------------

   Since version 1.2c, libtool has re-introduced the ability to do
inter-library dependency on some platforms, thanks to a patch by Toshio
Kuratomi <badger@prtr-13.ucsc.edu>.  Here's a shortened version of the
message that contained his patch:

   The basic architecture is this: in `libtool.m4', the person who
writes libtool makes sure `$deplibs' is included in `$archive_cmds'
somewhere and also sets the variable `$deplibs_check_method', and maybe
`$file_magic_cmd' when `deplibs_check_method' is file_magic.

   `deplibs_check_method' can be one of five things:
`file_magic [REGEX]'
     looks in the library link path for libraries that have the right
     libname.  Then it runs `$file_magic_cmd' on the library and checks
     for a match against REGEX using `egrep'.  When
     FILE_MAGIC_TEST_FILE is set by `libtool.m4', it is used as an
     argument to `$file_magic_cmd' in order to verify whether the
     regular expression matches its output, and warn the user otherwise.

`test_compile'
     just checks whether it is possible to link a program out of a list
     of libraries, and checks which of those are listed in the output of
     `ldd'.  It is currently unused, and will probably be dropped in the
     future.

`pass_all'
     will pass everything without any checking.  This may work on
     platforms in which code is position-independent by default and
     inter-library dependencies are properly supported by the dynamic
     linker, for example, on DEC OSF/1 3 and 4.

`none'
     It causes deplibs to be reassigned deplibs="".  That way
     `archive_cmds' can contain deplibs on all platforms, but not have
     deplibs used unless needed.

`unknown'
     is the default for all systems unless overridden in `libtool.m4'.
     It is the same as `none', but it documents that we really don't
     know what the correct value should be, and we welcome patches that
     improve it.

   Then in `ltmain.in' we have the real workhorse: a little
initialization and postprocessing (to setup/release variables for use
with eval echo libname_spec etc.) and a case statement that decides
which method is being used.  This is the real code... I wish I could
condense it a little more, but I don't think I can without function
calls.  I've mostly optimized it (moved things out of loops, etc) but
there is probably some fat left.  I thought I should stop while I was
ahead, work on whatever bugs you discover, etc before thinking about
more than obvious optimizations.


File: libtool.info,  Node: Tested platforms,  Next: Platform quirks,  Prev: New ports,  Up: Maintaining

Tested platforms
================

   This table describes when libtool was last known to be tested on
platforms where it claims to support shared libraries:

     -------------------------------------------------------
     canonical host name          compiler  libtool results
       (tools versions)                     release
     -------------------------------------------------------
     alpha-dec-osf5.1		cc	 1.3e	  ok (1.910)
     alpha-dec-osf4.0f               gcc      1.3e     ok (1.910)
     alpha-dec-osf4.0f               cc       1.3e     ok (1.910)
     alpha-dec-osf3.2                gcc      0.8      ok
     alpha-dec-osf3.2                cc       0.8      ok
     alpha-dec-osf2.1                gcc      1.2f     NS
     alpha*-unknown-linux-gnu        gcc      1.3b     ok
       (egcs-1.1.2, GNU ld 2.9.1.0.23)
     hppa2.0w-hp-hpux11.00           cc       1.2f     ok
     hppa2.0-hp-hpux10.20            cc       1.3.2    ok
     hppa1.1-hp-hpux10.20            gcc      1.2f     ok
     hppa1.1-hp-hpux10.20            cc       1.3c     ok (1.821)
     hppa1.1-hp-hpux10.10            gcc      1.2f     ok
     hppa1.1-hp-hpux10.10            cc       1.2f     ok
     hppa1.1-hp-hpux9.07             gcc      1.2f     ok
     hppa1.1-hp-hpux9.07             cc       1.2f     ok
     hppa1.1-hp-hpux9.05             gcc      1.2f     ok
     hppa1.1-hp-hpux9.05             cc       1.2f     ok
     hppa1.1-hp-hpux9.01             gcc      1.2f     ok
     hppa1.1-hp-hpux9.01             cc       1.2f     ok
     i*86-*-beos                     gcc      1.2f     ok
     i*86-*-bsdi4.0.1                gcc      1.3c     ok
       (gcc-2.7.2.1)
     i*86-*-bsdi4.0                  gcc      1.2f     ok
     i*86-*-bsdi3.1                  gcc      1.2e     NS
     i*86-*-bsdi3.0                  gcc      1.2e     NS
     i*86-*-bsdi2.1                  gcc      1.2e     NS
     i*86-pc-cygwin                  gcc      1.3b     NS
       (egcs-1.1 stock b20.1 compiler)
     i*86-*-dguxR4.20MU01            gcc      1.2      ok
     i*86-*-freebsd4.3		gcc      1.3e     ok (1.912)
     i*86-*-freebsdelf4.0            gcc      1.3c     ok
       (egcs-1.1.2)
     i*86-*-freebsdelf3.2            gcc      1.3c     ok
       (gcc-2.7.2.1)
     i*86-*-freebsdelf3.1            gcc      1.3c     ok
       (gcc-2.7.2.1)
     i*86-*-freebsdelf3.0            gcc      1.3c     ok
     i*86-*-freebsd3.0               gcc      1.2e     ok
     i*86-*-freebsd2.2.8             gcc      1.3c     ok
       (gcc-2.7.2.1)
     i*86-*-freebsd2.2.6             gcc      1.3b     ok
       (egcs-1.1 & gcc-2.7.2.1, native ld)
     i*86-*-freebsd2.1.5             gcc      0.5      ok
     i*86-*-netbsd1.5                gcc      1.3e     ok (1.901)
       (egcs-1.1.2)
     i*86-*-netbsd1.4                gcc      1.3c     ok
       (egcs-1.1.1)
     i*86-*-netbsd1.4.3A             gcc      1.3e     ok (1.901)
     i*86-*-netbsd1.3.3              gcc      1.3c     ok
       (gcc-2.7.2.2+myc2)
     i*86-*-netbsd1.3.2              gcc      1.2e     ok
     i*86-*-netbsd1.3I               gcc      1.2e     ok
       (egcs 1.1?)
     i*86-*-netbsd1.2                gcc      0.9g     ok
     i*86-*-linux-gnu		gcc	 1.3e	  ok (1.901)
       (Red Hat 7.0, gcc "2.96")
     i*86-*-linux-gnu		gcc	 1.4.2	  ok
       (SuSE 7.0, gcc 2.95.2)
     i*86-*-linux-gnulibc1           gcc      1.2f     ok
     i*86-*-openbsd2.5               gcc      1.3c     ok
       (gcc-2.8.1)
     i*86-*-openbsd2.4               gcc      1.3c     ok
       (gcc-2.8.1)
     i*86-*-solaris2.7               gcc      1.3b     ok
       (egcs-1.1.2, native ld)
     i*86-*-solaris2.6               gcc      1.2f     ok
     i*86-*-solaris2.5.1             gcc      1.2f     ok
     i*86-ncr-sysv4.3.03             gcc      1.2f     ok
     i*86-ncr-sysv4.3.03             cc       1.2e     ok
       (cc -Hnocopyr)
     i*86-pc-sco3.2v5.0.5		cc	 1.3c	  ok
     i*86-pc-sco3.2v5.0.5		gcc	 1.3c	  ok
       (gcc 95q4c)
     i*86-pc-sco3.2v5.0.5		gcc	 1.3c	  ok
       (egcs-1.1.2)
     i*86-sco-sysv5uw7.1.1		gcc	 1.3e	  ok (1.901)
       (gcc-2.95.2, SCO linker)
     i*86-UnixWare7.1.0-sysv5	cc	 1.3c	  ok
     i*86-UnixWare7.1.0-sysv5	gcc	 1.3c	  ok
       (egcs-1.1.1)
     m68k-next-nextstep3             gcc      1.2f     NS
     m68k-sun-sunos4.1.1             gcc      1.2f     NS
       (gcc-2.5.7)
     m88k-dg-dguxR4.12TMU01          gcc      1.2      ok
     m88k-motorola-sysv4             gcc      1.3      ok
       (egcs-1.1.2)
     mips-sgi-irix6.5                gcc      1.2f     ok
       (gcc-2.8.1)
     mips-sgi-irix6.4                gcc      1.2f     ok
     mips-sgi-irix6.3                gcc      1.3b     ok
       (egcs-1.1.2, native ld)
     mips-sgi-irix6.3                cc       1.3b     ok
       (cc 7.0)
     mips-sgi-irix6.2                gcc      1.2f     ok
     mips-sgi-irix6.2                cc       0.9      ok
     mips-sgi-irix5.3                gcc      1.2f     ok
       (egcs-1.1.1)
     mips-sgi-irix5.3                gcc      1.2f     NS
       (gcc-2.6.3)
     mips-sgi-irix5.3                cc       0.8      ok
     mips-sgi-irix5.2                gcc      1.3b     ok
       (egcs-1.1.2, native ld)
     mips-sgi-irix5.2                cc       1.3b     ok
       (cc 3.18)
     mips-sni-sysv4			cc       1.3.5    ok
       (Siemens C-compiler)
     mips-sni-sysv4			gcc      1.3.5    ok
       (gcc-2.7.2.3, GNU assembler 2.8.1, native ld)
     mipsel-unknown-openbsd2.1       gcc      1.0      ok
     powerpc-ibm-aix4.3.1.0          gcc      1.2f     ok
       (egcs-1.1.1)
     powerpc-ibm-aix4.2.1.0          gcc      1.2f     ok
       (egcs-1.1.1)
     powerpc-ibm-aix4.1.5.0          gcc      1.2f     ok
       (egcs-1.1.1)
     powerpc-ibm-aix4.1.5.0          gcc      1.2f     NS
       (gcc-2.8.1)
     powerpc-ibm-aix4.1.4.0          gcc      1.0      ok
     powerpc-ibm-aix4.1.4.0          xlc      1.0i     ok
     rs6000-ibm-aix4.1.5.0           gcc      1.2f     ok
       (gcc-2.7.2)
     rs6000-ibm-aix4.1.4.0           gcc      1.2f     ok
       (gcc-2.7.2)
     rs6000-ibm-aix3.2.5             gcc      1.0i     ok
     rs6000-ibm-aix3.2.5             xlc      1.0i     ok
     sparc-sun-solaris2.8		gcc	 1.4.2	  ok
       (gcc-2.95.2 & native ld)
     sparc-sun-solaris2.8		gcc	 1.4.2	  ok
       (gcc-3.0.1 & GNU ld 2.11.2)
     sparc-sun-solaris2.7            gcc      1.3e     ok (1.913)
       (gcc-2.95.3 & native ld)
     sparc-sun-solaris2.6            gcc      1.3e     ok (1.913)
       (gcc-2.95.3 & native ld)
     sparc-sun-solaris2.5.1          gcc      1.4.2    ok
       (gcc-2.95.1 & GNU ld 2.9.1)
     sparc-sun-solaris2.5            gcc      1.3b     ok
       (egcs-1.1.2, GNU ld 2.9.1 & native ld)
     sparc-sun-solaris2.5            cc       1.3b     ok
       (SC 3.0.1)
     sparc-sun-solaris2.4            gcc      1.0a     ok
     sparc-sun-solaris2.4            cc       1.0a     ok
     sparc-sun-solaris2.3            gcc      1.2f     ok
     sparc-sun-sunos4.1.4            gcc      1.2f     ok
     sparc-sun-sunos4.1.4            cc       1.0f     ok
     sparc-sun-sunos4.1.3_U1         gcc      1.2f     ok
     sparc-sun-sunos4.1.3C           gcc      1.2f     ok
     sparc-sun-sunos4.1.3            gcc      1.3b     ok
       (egcs-1.1.2, GNU ld 2.9.1 & native ld)
     sparc-sun-sunos4.1.3            cc       1.3b     ok
     sparc-unknown-bsdi4.0           gcc      1.2c     ok
     sparc-unknown-linux-gnulibc1    gcc      1.2f     ok
     sparc-unknown-linux-gnu         gcc      1.3b     ok
       (egcs-1.1.2, GNU ld 2.9.1.0.23)
     sparc64-unknown-linux-gnu       gcc      1.2f     ok
     
     Notes:
     - "ok" means "all tests passed".
     - "NS" means "Not Shared", but OK for static libraries

   Note: The vendor-distributed HP-UX `sed'(1) programs are horribly
broken, and cannot handle libtool's requirements, so users may report
unusual problems.  There is no workaround except to install a working
`sed' (such as GNU `sed') on these systems.

   Note: The vendor-distributed NCR MP-RAS `cc' programs emits
copyright on standard error that confuse tests on size of
`conftest.err'.  The workaround is to specify `CC' when run `configure'
with `CC='cc -Hnocopyr''.


File: libtool.info,  Node: Platform quirks,  Next: libtool script contents,  Prev: Tested platforms,  Up: Maintaining

Platform quirks
===============

   This section is dedicated to the sanity of the libtool maintainers.
It describes the programs that libtool uses, how they vary from system
to system, and how to test for them.

   Because libtool is a shell script, it can be difficult to understand
just by reading it from top to bottom.  This section helps show why
libtool does things a certain way.  Combined with the scripts
themselves, you should have a better sense of how to improve libtool, or
write your own.

* Menu:

* References::                  Finding more information.
* Compilers::                   Creating object files from source files.
* Reloadable objects::          Binding object files together.
* Multiple dependencies::	Removing duplicate dependant libraries.
* Archivers::                   Programs that create static archives.


File: libtool.info,  Node: References,  Next: Compilers,  Up: Platform quirks

References
----------

   The following is a list of valuable documentation references:

   * SGI's IRIX Manual Pages, which can be found at
     <http://techpubs.sgi.com/cgi-bin/infosrch.cgi?cmd=browse&db=man>.

   * Sun's free service area
     (<http://www.sun.com/service/online/free.html>) and documentation
     server (<http://docs.sun.com/>).

   * Compaq's Tru64 UNIX online documentation is at
     (<http://tru64unix.compaq.com/faqs/publications/pub_page/doc_list.html>)
     with C++ documentation at
     (<http://tru64unix.compaq.com/cplus/docs/index.htm>).

   * Hewlett-Packard has online documentation at
     (<http://docs.hp.com/index.html>).

   * IBM has online documentation at
     (<http://www.rs6000.ibm.com/resource/aix_resource/Pubs/>).


File: libtool.info,  Node: Compilers,  Next: Reloadable objects,  Prev: References,  Up: Platform quirks

Compilers
---------

   The only compiler characteristics that affect libtool are the flags
needed (if any) to generate PIC objects.  In general, if a C compiler
supports certain PIC flags, then any derivative compilers support the
same flags.  Until there are some noteworthy exceptions to this rule,
this section will document only C compilers.

   The following C compilers have standard command line options,
regardless of the platform:

`gcc'
     This is the GNU C compiler, which is also the system compiler for
     many free operating systems (FreeBSD, GNU/Hurd, GNU/Linux, Lites,
     NetBSD, and OpenBSD, to name a few).

     The `-fpic' or `-fPIC' flags can be used to generate
     position-independent code.  `-fPIC' is guaranteed to generate
     working code, but the code is slower on m68k, m88k, and Sparc
     chips.  However, using `-fpic' on those chips imposes arbitrary
     size limits on the shared libraries.

   The rest of this subsection lists compilers by the operating system
that they are bundled with:

`aix3*'
`aix4*'
     AIX compilers have no PIC flags, since AIX has been ported only to
     PowerPC and RS/6000 chips. (1)

`hpux10*'
     Use `+Z' to generate PIC.

`osf3*'
     Digital/UNIX 3.x does not have PIC flags, at least not on the
     PowerPC platform.

`solaris2*'
     Use `-KPIC' to generate PIC.

`sunos4*'
     Use `-PIC' to generate PIC.

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

   (1) All code compiled for the PowerPC and RS/6000 chips
(`powerpc-*-*', `powerpcle-*-*', and `rs6000-*-*') is
position-independent, regardless of the operating system or compiler
suite.  So, "regular objects" can be used to build shared libraries on
these systems and no special PIC compiler flags are required.


File: libtool.info,  Node: Reloadable objects,  Next: Multiple dependencies,  Prev: Compilers,  Up: Platform quirks

Reloadable objects
------------------

   On all known systems, a reloadable object can be created by running
`ld -r -o OUTPUT.o INPUT1.o INPUT2.o'.  This reloadable object may be
treated as exactly equivalent to other objects.


File: libtool.info,  Node: Multiple dependencies,  Next: Archivers,  Prev: Reloadable objects,  Up: Platform quirks

Multiple dependencies
---------------------

   On most modern platforms the order that dependent libraries are
listed has no effect on object generation.  In theory, there are
platforms which require libraries which provide missing symbols to
other libraries to listed after those libraries whose symbols they
provide.

   Particularly, if a pair of static archives each resolve some of the
other's symbols, it might be necessary to list one of those archives
both before and after the other one.  Libtool does not currently cope
with this situation well, since dupicate libraries are removed from thr
link line.

   If you find yourself developing on a host that requires you to list
libraries multiple times in order for it to generate correctly linked
objects, you can defeat libtool's removal algorithm like this:

     $ libtool ... -lfoo -lbar -Wl,-lfoo


File: libtool.info,  Node: Archivers,  Prev: Multiple dependencies,  Up: Platform quirks

Archivers
---------

   On all known systems, building a static library can be accomplished
by running `ar cru libNAME.a OBJ1.o OBJ2.o ...', where the `.a' file is
the output library, and each `.o' file is an object file.

   On all known systems, if there is a program named `ranlib', then it
must be used to "bless" the created library before linking against it,
with the `ranlib libNAME.a' command.  Some systems, like Irix, use the
`ar ts' command, instead.


File: libtool.info,  Node: libtool script contents,  Next: Cheap tricks,  Prev: Platform quirks,  Up: Maintaining

`libtool' script contents
=========================

   Since version 1.4, the `libtool' script is generated by `configure'
(*note Configuring::).  In earlier versions, `configure' achieved this
by calling a helper script called `ltconfig'.  From libtool version 0.7
to 1.0, this script simply set shell variables, then sourced the
libtool backend, `ltmain.sh'.  `ltconfig' from libtool version 1.1
through 1.3 inlined the contents of `ltmain.sh' into the generated
`libtool', which improved performance on many systems.  The tests that
`ltconfig' used to perform are now kept in `libtool.m4' where thay can
be written using Autoconf.  This has the runtime performance benefits
of inlined `ltmain.sh', _and_ improves the build time a little while
considerably easing the amount of raw shell code that used to need
maintaining.

   The convention used for naming variables which hold shell commands
for delayed evaluation, is to use the suffix `_cmd' where a single line
of valid shell script is needed, and the suffix `_cmds' where multiple
lines of shell script *may* be delayed for later evaluation.  By
convention, `_cmds' variables delimit the evaluation units with the `~'
character where necessary.

   Here is a listing of each of the configuration variables, and how
they are used within `ltmain.sh' (*note Configuring::):

 - Variable: AR
     The name of the system library archiver.

 - Variable: CC
     The name of the C compiler used to configure libtool.

 - Variable: LD
     The name of the linker that libtool should use internally for
     reloadable linking and possibly shared libraries.

 - Variable: NM
     The name of a BSD-compatible `nm' program, which produces listings
     of global symbols in one the following formats:

          ADDRESS C GLOBAL-VARIABLE-NAME
          ADDRESS D GLOBAL-VARIABLE-NAME
          ADDRESS T GLOBAL-FUNCTION-NAME

 - Variable: RANLIB
     Set to the name of the ranlib program, if any.

 - Variable: allow_undefined_flag
     The flag that is used by `archive_cmds' in order to declare that
     there will be unresolved symbols in the resulting shared library.
     Empty, if no such flag is required.  Set to `unsupported' if there
     is no way to generate a shared library with references to symbols
     that aren't defined in that library.

 - Variable: always_export_symbols
     Whether libtool should automatically generate a list of exported
     symbols using EXPORT_SYMBOLS_CMDS before linking an archive.  Set
     to `yes' or `no'.  Default is `no'.

 - Variable: archive_cmds
 - Variable: archive_expsym_cmds
 - Variable: old_archive_cmds
     Commands used to create shared libraries, shared libraries with
     `-export-symbols' and static libraries, respectively.

 - Variable: old_archive_from_new_cmds
     If the shared library depends on a static library,
     `old_archive_from_new_cmds' contains the commands used to create
     that static library.  If this variable is not empty,
     `old_archive_cmds' is not used.

 - Variable: old_archive_from_expsyms_cmds
     If a static library must be created from the export symbol list in
     order to correctly link with a shared library,
     `old_archive_from_expsyms_cmds' contains the commands needed to
     create that static library.  When these commands are executed, the
     variable SONAME contains the name of the shared library in
     question, and the $OBJDIR/$NEWLIB contains the path of the static
     library these commands should build.  After executing these
     commands, libtool will proceed to link against $OBJDIR/$NEWLIB
     instead of SONAME.

 - Variable: build_libtool_libs
     Whether libtool should build shared libraries on this system.  Set
     to `yes' or `no'.

 - Variable: build_old_libs
     Whether libtool should build static libraries on this system.  Set
     to `yes' or `no'.

 - Variable: compiler_c_o
     Whether the compiler supports the `-c' and `-o' options
     simultaneously. Set to `yes' or `no'.

 - Variable: compiler_o_lo
     Whether the compiler supports compiling directly to a ".lo" file,
     i.e whether object files do not have to have the suffix ".o".  Set
     to `yes' or `no'.

 - Variable: dlopen_support
     Whether `dlopen' is supported on the platform.  Set to `yes' or
     `no'.

 - Variable: dlopen_self
     Whether it is possible to `dlopen' the executable itself.  Set to
     `yes' or `no'.

 - Variable: dlopen_self_static
     Whether it is possible to `dlopen' the executable itself, when it
     is linked statically (`-all-static').  Set to `yes' or `no'.

 - Variable: echo
     An `echo' program which does not interpret backslashes as an
     escape character.

 - Variable: exclude_expsyms
     List of symbols that should not be listed in the preloaded symbols.

 - Variable: export_dynamic_flag_spec
     Compiler link flag that allows a dlopened shared library to
     reference symbols that are defined in the program.

 - Variable: export_symbols_cmds
     Commands to extract exported symbols from LIBOBJS to the file
     EXPORT_SYMBOLS.

 - Variable: extract_expsyms_cmds
     Commands to extract the exported symbols list from a shared
     library.  These commands are executed if there is no file
     $OBJDIR/$SONAME-DEF, and should write the names of the exported
     symbols to that file, for the use of
     `old_archive_from_expsyms_cmds'.

 - Variable: fast_install
     Determines whether libtool will privilege the installer or the
     developer.  The assumption is that installers will seldom run
     programs in the build tree, and the developer will seldom install.
     This is only meaningful on platforms in which
     SHLIBPATH_OVERRIDES_RUNPATH is not `yes', so FAST_INSTALL will be
     set to `needless' in this case.  If FAST_INSTALL set to `yes',
     libtool will create programs that search for installed libraries,
     and, if a program is run in the build tree, a new copy will be
     linked on-demand to use the yet-to-be-installed libraries.  If set
     to `no', libtool will create programs that use the
     yet-to-be-installed libraries, and will link a new copy of the
     program at install time.  The default value is `yes' or
     `needless', depending on platform and configuration flags, and it
     can be turned from `yes' to `no' with the configure flag
     `--disable-fast-install'.

 - Variable: finish_cmds
     Commands to tell the dynamic linker how to find shared libraries
     in a specific directory.

 - Variable: finish_eval
     Same as FINISH_CMDS, except the commands are not displayed.

 - Variable: fix_srcfile_path
     Expression to fix the shell variable $srcfile for the compiler.

 - Variable: global_symbol_pipe
     A pipeline that takes the output of NM, and produces a listing of
     raw symbols followed by their C names.  For example:

          $ eval "$NM progname | $global_symbol_pipe"
          D SYMBOL1 C-SYMBOL1
          T SYMBOL2 C-SYMBOL2
          C SYMBOL3 C-SYMBOL3
          ...
          $

     The first column contains the symbol type (used to tell data from
     code on some platforms), but its meaning is system dependent.

 - Variable: global_symbol_to_cdecl
     A pipeline that translates the output of GLOBAL_SYMBOL_PIPE into
     proper C declarations.  On platforms whose linkers differentiate
     code from data, such as HP/UX, data symbols will be declared as
     such, and code symbols will be declared as functions.  On
     platforms that don't care, everything is assumed to be data.

 - Variable: hardcode_action
     Either `immediate' or `relink', depending on whether shared
     library paths can be hardcoded into executables before they are
     installed, or if they need to be relinked.

 - Variable: hardcode_direct
     Set to `yes' or `no', depending on whether the linker hardcodes
     directories if a library is directly specified on the command line
     (such as `DIR/libNAME.a') when HARDCODE_LIBDIR_FLAG_SPEC is
     specified.

 - Variable: hardcode_into_libs
     Whether the platform supports hardcoding of run-paths into
     libraries.  If enabled, linking of programs will be much simpler
     but libraries will need to be relinked during installation.   Set
     to `yes' or `no'.

 - Variable: hardcode_libdir_flag_spec
     Flag to hardcode a LIBDIR variable into a binary, so that the
     dynamic linker searches LIBDIR for shared libraries at runtime.
     If it is empty, libtool will try to use some other hardcoding
     mechanism.

 - Variable: hardcode_libdir_separator
     If the compiler only accepts a single HARDCODE_LIBDIR_FLAG, then
     this variable contains the string that should separate multiple
     arguments to that flag.

 - Variable: hardcode_minus_L
     Set to `yes' or `no', depending on whether the linker hardcodes
     directories specified by `-L' flags into the resulting executable
     when HARDCODE_LIBDIR_FLAG_SPEC is specified.

 - Variable: hardcode_shlibpath_var
     Set to `yes' or `no', depending on whether the linker hardcodes
     directories by writing the contents of `$shlibpath_var' into the
     resulting executable when HARDCODE_LIBDIR_FLAG_SPEC is specified.
     Set to `unsupported' if directories specified by `$shlibpath_var'
     are searched at run time, but not at link time.

 - Variable: host
 - Variable: host_alias
     For information purposes, set to the specified and canonical names
     of the system that libtool was configured for.

 - Variable: include_expsyms
     List of symbols that must always be exported when using
     EXPORT_SYMBOLS.

 - Variable: libext
     The standard old archive suffix (normally "a").

 - Variable: libname_spec
     The format of a library name prefix.  On all Unix systems, static
     libraries are called `libNAME.a', but on some systems (such as
     OS/2 or MS-DOS), the library is just called `NAME.a'.

 - Variable: library_names_spec
     A list of shared library names.  The first is the name of the file,
     the rest are symbolic links to the file.  The name in the list is
     the file name that the linker finds when given `-lNAME'.

 - Variable: link_all_deplibs
     Whether libtool must link a program against all its dependency
     libraries.  Set to `yes' or `no'.  Default is `unknown', which is
     a synonym for `yes'.

 - Variable: link_static_flag
     Linker flag (passed through the C compiler) used to prevent dynamic
     linking.

 - Variable: need_lib_prefix
     Whether libtool should automatically prefix module names with
     'lib'.  Set to `yes' or `no'.  By default, it is `unknown', which
     means the same as `yes', but documents that we are not really sure
     about it.  `yes' means that it is possible both to `dlopen' and to
     link against a library without 'lib' prefix, i.e. it requires
     HARDCODE_DIRECT to be `yes'.

 - Variable: need_version
     Whether versioning is required for libraries, i.e. whether the
     dynamic linker requires a version suffix for all libraries.  Set
     to `yes' or `no'.  By default, it is `unknown', which means the
     same as `yes', but documents that we are not really sure about it.

 - Variable: need_locks
     Whether files must be locked to prevent conflicts when compiling
     simultaneously. Set to `yes' or `no'.

 - Variable: no_builtin_flag
     Compiler flag to disable builtin functions that conflict with
     declaring external global symbols as `char'.

 - Variable: no_undefined_flag
     The flag that is used by `archive_cmds' in order to declare that
     there will be no unresolved symbols in the resulting shared
     library.  Empty, if no such flag is required.

 - Variable: objdir
     The name of the directory that contains temporary libtool files.

 - Variable: objext
     The standard object file suffix (normally "o").

 - Variable: pic_flag
     Any additional compiler flags for building library object files.

 - Variable: postinstall_cmds
 - Variable: old_postinstall_cmds
     Commands run after installing a shared or static library,
     respectively.

 - Variable: postuninstall_cmds
 - Variable: old_postuninstall_cmds
     Commands run after uninstalling a shared or static library,
     respectively.

 - Variable: reload_cmds
 - Variable: reload_flag
     Commands to create a reloadable object.

 - Variable: runpath_var
     The environment variable that tells the linker which directories to
     hardcode in the resulting executable.

 - Variable: shlibpath_overrides_runpath
     Indicates whether it is possible to override the hard-coded library
     search path of a program with an environment variable.  If this is
     set to no, libtool may have to create two copies of a program in
     the build tree, one to be installed and one to be run in the build
     tree only.  When each of these copies is created depends on the
     value of `fast_install'.  The default value is `unknown', which is
     equivalent to `no'.

 - Variable: shlibpath_var
     The environment variable that tells the dynamic linker where to
     find shared libraries.

 - Variable: soname_spec
     The name coded into shared libraries, if different from the real
     name of the file.

 - Variable: striplib
 - Variable: old_striplib
     Command to strip a shared (`striplib') or static (`old_striplib')
     library, respectively.  If these variables are empty, the strip
     flag in the install mode will be ignored for libraries (*note
     Install mode::).

 - Variable: sys_lib_dlsearch_path_spec
     Expression to get the run-time system library search path.
     Directories that appear in this list are never hard-coded into
     executables.

 - Variable: sys_lib_search_path_spec
     Expression to get the compile-time system library search path.
     This variable is used by libtool when it has to test whether a
     certain library is shared or static.  The directories listed in
     SHLIBPATH_VAR are automatically appended to this list, every time
     libtool runs (i.e., not at configuration time), because some
     linkers use this variable to extend the library search path.
     Linker switches such as `-L' also augment the search path.

 - Variable: thread_safe_flag_spec
     Linker flag (passed through the C compiler) used to generate
     thread-safe libraries.

 - Variable: version_type
     The library version numbering type.  One of `libtool',
     `freebsd-aout', `freebsd-elf', `irix', `linux', `osf', `sunos',
     `windows', or `none'.

 - Variable: whole_archive_flag_spec
     Compiler flag to generate shared objects from convenience archives.

 - Variable: wl
     The C compiler flag that allows libtool to pass a flag directly to
     the linker.  Used as: `${wl}SOME-FLAG'.

   Variables ending in `_cmds' or `_eval' contain a `~'-separated list
of commands that are `eval'ed one after another.  If any of the
commands return a nonzero exit status, libtool generally exits with an
error message.

   Variables ending in `_spec' are `eval'ed before being used by
libtool.


File: libtool.info,  Node: Cheap tricks,  Prev: libtool script contents,  Up: Maintaining

Cheap tricks
============

   Here are a few tricks that you can use in order to make
maintainership easier:

   * When people report bugs, ask them to use the `--config',
     `--debug', or `--features' flags, if you think they will help you.
     These flags are there to help you get information directly, rather
     than having to trust second-hand observation.

   * Rather than reconfiguring libtool every time I make a change to
     `ltmain.in', I keep a permanent `libtool' script in my PATH, which
     sources `ltmain.in' directly.

     The following steps describe how to create such a script, where
     `/home/src/libtool' is the directory containing the libtool source
     tree, `/home/src/libtool/libtool' is a libtool script that has been
     configured for your platform, and `~/bin' is a directory in your
     PATH:

          trick$ cd ~/bin
          trick$ sed '/^# ltmain\.sh/q' /home/src/libtool/libtool > libtool
          trick$ echo '. /home/src/libtool/ltmain.in' >> libtool
          trick$ chmod +x libtool
          trick$ libtool --version
          ltmain.sh (GNU @PACKAGE@) @VERSION@@TIMESTAMP@
          trick$

   The output of the final `libtool --version' command shows that the
`ltmain.in' script is being used directly.  Now, modify `~/bin/libtool'
or `/home/src/libtool/ltmain.in' directly in order to test new changes
without having to rerun `configure'.

