Next: When tests fail, Up: Libtool test suite [Contents][Index]
Here is a list of the current programs in the old test suite, and what they test for:
These programs check to see that the tests/cdemo subdirectory of the libtool distribution can be configured and built correctly.
The tests/cdemo subdirectory contains a demonstration of libtool convenience libraries, a mechanism that allows build-time static libraries to be created, in a way that their components can be later linked into programs or other libraries, even shared ones.
The tests matching cdemo-*make.test and cdemo-*exec.test are executed three times, under three different libtool configurations: cdemo-conf.test configures cdemo/libtool to build both static and shared libraries (the default for platforms that support both), cdemo-static.test builds only static libraries (‘--disable-shared’), and cdemo-shared.test builds only shared libraries (‘--disable-static’).
The test cdemo-undef.test tests the generation of shared libraries with undefined symbols on systems that allow this.
These programs check to see that the tests/demo subdirectory of the libtool distribution can be configured, built, installed, and uninstalled correctly.
The tests/demo subdirectory contains a demonstration of a trivial package that uses libtool. The tests matching demo-*make.test, demo-*exec.test, demo-*inst.test and demo-*unst.test are executed four times, under four different libtool configurations: demo-conf.test configures demo/libtool to build both static and shared libraries, demo-static.test builds only static libraries (--disable-shared), and demo-shared.test builds only shared libraries (--disable-static). demo-nofast.test configures demo/libtool to disable the fast-install mode (--enable-fast-install=no). demo-pic.test configures demo/libtool to prefer building PIC code (--with-pic), demo-nopic.test to prefer non-PIC code (--without-pic).
Many systems cannot link static libraries into shared libraries.
libtool uses a deplibs_check_method
to prevent such cases.
This tests checks whether libtool’s deplibs_check_method
works properly.
On all systems with shared libraries, the location of the library can be encoded in executables that are linked against it see 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.
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.
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.
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).
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 (see 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).
This test checks whether libtool’s --dry-run mode works properly.
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.
This test guarantees that linking directly against a non-libtool static library works properly.
This test makes sure that files ending in .lo are never linked directly into a program file.
Check whether we can actually get help for libtool.
Check that a nonexistent objectlist file is properly detected.
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.
This program checks libtool’s metacharacter quoting.
Checks for some nonportable or dubious or undesired shell constructs in shell scripts.
When other programming languages are used with libtool (see 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.
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.
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.
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:
The test group exercises one of these libtool
language tags.
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.
This test group may require user interaction on some systems. Typically, this means closing a popup window about a DLL load error on Windows.
Denote that the libltdl library is exercised by the test group.
Denote that the libtool
or libtoolize
scripts are
exercised by the test group, respectively.
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.
Next: When tests fail, Up: Libtool test suite [Contents][Index]