Next: , Up: Libtool test suite


14.1.1 Description of test suite

Here is a list of the current programs in the old test suite, and what they test for:

cdemo-conf.test
cdemo-make.test
cdemo-exec.test
cdemo-static.test
cdemo-static-make.test
cdemo-static-exec.test
cdemo-shared.test
cdemo-shared-make.test
cdemo-shared-exec.test
cdemo-undef.test
cdemo-undef-make.test
cdemo-undef-exec.test
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.

demo-conf.test
demo-make.test
demo-exec.test
demo-inst.test
demo-unst.test
demo-static.test
demo-static-make.test
demo-static-exec.test
demo-static-inst.test
demo-static-unst.test
demo-shared.test
demo-shared-make.test
demo-shared-exec.test
demo-shared-inst.test
demo-shared-unst.test
demo-nofast.test
demo-nofast-make.test
demo-nofast-exec.test
demo-nofast-inst.test
demo-nofast-unst.test
demo-pic.test
demo-pic-make.test
demo-pic-exec.test
demo-nopic.test
demo-nopic-make.test
demo-nopic-exec.test
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).

demo-deplibs.test
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.
demo-hardcode.test
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 the conditions under which 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 (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).

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