ibraries into shared libraries.
     libtool uses a 'deplibs_check_method' to prevent such cases.  This
     tests checks whether libtool's 'deplibs_check_method' works
     properly.

'demo-hardcode.test'
     On all systems with shared libraries, the location of the library
     can be encoded in executables that are linked against it *note
     Linking executables::.  This test checks under what conditions your
     system linker hardcodes the library location, and guarantees that
     they correspond to libtool's own notion of how your linker behaves.

'demo-relink.test'
'depdemo-relink.test'
     These tests check whether variable 'shlibpath_overrides_runpath' is
     properly set.  If the test fails, it will indicate what the
     variable should have been set to.

'demo-noinst-link.test'
     Checks whether libtool will not try to link with a previously
     installed version of a library when it should be linking with a
     just-built one.

'depdemo-conf.test'
'depdemo-make.test'
'depdemo-exec.test'
'depdemo-inst.test'
'depdemo-unst.test'
'depdemo-static.test'
'depdemo-static-make.test'
'depdemo-static-exec.test'
'depdemo-static-inst.test'
'depdemo-static-unst.test'
'depdemo-shared.test'
'depdemo-shared-make.test'
'depdemo-shared-exec.test'
'depdemo-shared-inst.test'
'depdemo-shared-unst.test'
'depdemo-nofast.test'
'depdemo-nofast-make.test'
'depdemo-nofast-exec.test'
'depdemo-nofast-inst.test'
'depdemo-nofast-unst.test'
     These programs check to see that the 'tests/depdemo' subdirectory
     of the libtool distribution can be configured, built, installed,
     and uninstalled correctly.

     The 'tests/depdemo' subdirectory contains a demonstration of
     inter-library dependencies with libtool.  The test programs link
     some interdependent libraries.

     The tests matching 'depdemo-*make.test', 'depdemo-*exec.test',
     'depdemo-*inst.test' and 'depdemo-*unst.test' are executed four
     times, under four different libtool configurations:
     'depdemo-conf.test' configures 'depdemo/libtool' to build both
     static and shared libraries, 'depdemo-static.test' builds only
     static libraries ('--disable-shared'), and 'depdemo-shared.test'
     builds only shared libraries ('--disable-static').
     'depdemo-nofast.test' configures 'depdemo/libtool' to disable the
     fast-install mode ('--enable-fast-install=no').

'mdemo-conf.test'
'mdemo-make.test'
'mdemo-exec.test'
'mdemo-inst.test'
'mdemo-unst.test'
'mdemo-static.test'
'mdemo-static-make.test'
'mdemo-static-exec.test'
'mdemo-static-inst.test'
'mdemo-static-unst.test'
'mdemo-shared.test'
'mdemo-shared-make.test'
'mdemo-shared-exec.test'
'mdemo-shared-inst.test'
'mdemo-shared-unst.test'
     These programs check to see that the 'tests/mdemo' subdirectory of
     the libtool distribution can be configured, built, installed, and
     uninstalled correctly.

     The 'tests/mdemo' subdirectory contains a demonstration of a
     package that uses libtool and the system independent dlopen wrapper
     'libltdl' to load modules.  The library 'libltdl' provides a dlopen
     wrapper for various platforms (POSIX) including support for
     dlpreopened modules (*note Dlpreopening::).

     The tests matching 'mdemo-*make.test', 'mdemo-*exec.test',
     'mdemo-*inst.test' and 'mdemo-*unst.test' are executed three times,
     under three different libtool configurations: 'mdemo-conf.test'
     configures 'mdemo/libtool' to build both static and shared
     libraries, 'mdemo-static.test' builds only static libraries
     ('--disable-shared'), and 'mdemo-shared.test' builds only shared
     libraries ('--disable-static').

'mdemo-dryrun.test'
     This test checks whether libtool's '--dry-run' mode works properly.

'mdemo2-conf.test'
'mdemo2-exec.test'
'mdemo2-make.test'
     These programs check to see that the 'tests/mdemo2' subdirectory of
     the libtool distribution can be configured, built, and executed
     correctly.

     The 'tests/mdemo2' directory contains a demonstration of a package
     that attempts to link with a library (from the 'tests/mdemo'
     directory) that itself does dlopening of libtool modules.

'link.test'
     This test guarantees that linking directly against a non-libtool
     static library works properly.

'link-2.test'
     This test makes sure that files ending in '.lo' are never linked
     directly into a program file.

'nomode.test'
     Check whether we can actually get help for libtool.

'objectlist.test'
     Check that a nonexistent objectlist file is properly detected.

'pdemo-conf.test'
'pdemo-make.test'
'pdemo-exec.test'
'pdemo-inst.test'
     These programs check to see that the 'tests/pdemo' subdirectory of
     the libtool distribution can be configured, built, and executed
     correctly.

     The 'pdemo-conf.test' lowers the 'max_cmd_len' variable in the
     generated libtool script to test the measures to evade command line
     length limitations.

'quote.test'
     This program checks libtool's metacharacter quoting.

'sh.test'
     Checks for some nonportable or dubious or undesired shell
     constructs in shell scripts.

'suffix.test'
     When other programming languages are used with libtool (*note Other
     languages::), the source files may end in suffixes other than '.c'.
     This test validates that libtool can handle suffixes for all the
     file types that it supports, and that it fails when the suffix is
     invalid.

'tagdemo-conf.test'
'tagdemo-make.test'
'tagdemo-exec.test'
'tagdemo-static.test'
'tagdemo-static-make.test'
'tagdemo-static-exec.test'
'tagdemo-shared.test'
'tagdemo-shared-make.test'
'tagdemo-shared-exec.test'
'tagdemo-undef.test'
'tagdemo-undef-make.test'
'tagdemo-undef-exec.test'
     These programs check to see that the 'tests/tagdemo' subdirectory
     of the libtool distribution can be configured, built, and executed
     correctly.

     The 'tests/tagdemo' directory contains a demonstration of a package
     that uses libtool's multi-language support through configuration
     tags.  It generates a library from C++ sources, which is then
     linked to a C++ program.

'f77demo-conf.test'
'f77demo-make.test'
'f77demo-exec.test'
'f77demo-static.test'
'f77demo-static-make.test'
'f77demo-static-exec.test'
'f77demo-shared.test'
'f77demo-shared-make.test'
'f77demo-shared-exec.test'
     These programs check to see that the 'tests/f77demo' subdirectory
     of the libtool distribution can be configured, built, and executed
     correctly.

     The 'tests/f77demo' tests test Fortran 77 support in libtool by
     creating libraries from Fortran 77 sources, and mixed Fortran and C
     sources, and a Fortran 77 program to use the former library, and a
     C program to use the latter library.

'fcdemo-conf.test'
'fcdemo-make.test'
'fcdemo-exec.test'
'fcdemo-static.test'
'fcdemo-static-make.test'
'fcdemo-static-exec.test'
'fcdemo-shared.test'
'fcdemo-shared-make.test'
'fcdemo-shared-exec.test'
     These programs check to see that the 'tests/fcdemo' subdirectory of
     the libtool distribution can be configured, built, and executed
     correctly.

     The 'tests/fcdemo' is similar to the 'tests/f77demo' directory,
     except that Fortran 90 is used in combination with the 'FC'
     interface provided by Autoconf and Automake.

   The new, Autotest-based test suite uses keywords to classify certain
test groups:

'CXX'
'F77'
'FC'
'GCJ'
     The test group exercises one of these 'libtool' language tags.

'autoconf'
'automake'
     These keywords denote that the respective external program is
     needed by the test group.  The tests are typically skipped if the
     program is not installed.  The 'automake' keyword may also denote
     use of the 'aclocal' program.

'interactive'
     This test group may require user interaction on some systems.
     Typically, this means closing a popup window about a DLL load error
     on Windows.

'libltdl'
     Denote that the 'libltdl' library is exercised by the test group.

'libtool'
'libtoolize'
     Denote that the 'libtool' or 'libtoolize' scripts are exercised by
     the test group, respectively.

'recursive'
     Denote that this test group may recursively re-invoke the test
     suite itself, with changed settings and maybe a changed 'libtool'
     script.  You may use the 'INNER_TESTSUITEFLAGS' variable to pass
     additional settings to this recursive invocation.  Typically,
     recursive invocations delimit the set of tests with another
     keyword, for example by passing '-k libtool' right before the
     expansion of the 'INNER_TESTSUITEFLAGS' variable (without an
     intervening space, so you get the chance for further delimitation).

     Test groups with the keyword 'recursive' should not be denoted with
     keywords, in order to avoid infinite recursion.  As a consequence,
     recursive test groups themselves should never require user
     interaction, while the test groups they invoke may do so.

   There is a convenience target 'check-noninteractive' that runs all
tests from both test suites that do not cause user interaction on
Windows.  Conversely, the target 'check-interactive' runs the complement
of tests and might require closing popup windows about DLL load errors
on Windows.