Go to the first, previous, next, last section, table of contents.
Libtool is under constant development, changing to remain up-to-date
with modern operating systems. If libtool doesn't work the way you
think it should on your platform, you should read this chapter to help
determine what the problem is, and how to resolve it.
Libtool comes with its own set of programs that test its capabilities,
and report obvious bugs in the libtool program. These tests, too, are
constantly evolving, based on past problems with libtool, and known
deficiencies in other operating systems.
As described in the `INSTALL' file, you may run make check
after you have built libtool (possibly before you install it) in order
to make sure that it meets basic functional requirements.
Here is a list of the current programs in the test suite, and what they
test for:
- `cdemo-conf.test'
-
- `cdemo-exec.test'
-
- `cdemo-make.test'
-
- `cdemo-static.test'
-
- `cdemo-shared.test'
-
These programs check to see that the `cdemo' subdirectory of the
libtool distribution can be configured and built correctly.
The `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 `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').
- `demo-conf.test'
-
- `demo-exec.test'
-
- `demo-inst.test'
-
- `demo-make.test'
-
- `demo-unst.test'
-
- `demo-static.test'
-
- `demo-shared.test'
-
- `demo-nofast.test'
-
- `demo-pic.test'
-
- `demo-nopic.test'
-
These programs check to see that the `demo' subdirectory of the
libtool distribution can be configured, built, installed, and
uninstalled correctly.
The `demo' subdirectory contains a demonstration of a trivial
package that uses libtool. The tests `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').
- `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.
- `hardcode.test'
-
On all systems with shared libraries, the location of the library can be
encoded in executables that are linked against it see section 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.
- `build-relink.test'
-
Checks whether variable shlibpath_overrides_runpath is properly
set. If the test fails and VERBOSE is set, it will indicate what
the variable should have been set to.
- `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-exec.test'
-
- `depdemo-inst.test'
-
- `depdemo-make.test'
-
- `depdemo-unst.test'
-
- `depdemo-static.test'
-
- `depdemo-shared.test'
-
- `depdemo-nofast.test'
-
These programs check to see that the `depdemo' subdirectory of the
libtool distribution can be configured, built, installed, and
uninstalled correctly.
The `depdemo' subdirectory contains a demonstration of inter-library
dependencies with libtool. The test programs link some interdependent
libraries.
The tests `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-exec.test'
-
- `mdemo-inst.test'
-
- `mdemo-make.test'
-
- `mdemo-unst.test'
-
- `mdemo-static.test'
-
- `mdemo-shared.test'
-
These programs check to see that the `mdemo' subdirectory of the
libtool distribution can be configured, built, installed, and
uninstalled correctly.
The `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 (Linux, Solaris, HP/UX etc.) including support for
dlpreopened modules (see section Dlpreopening).
The tests `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').
- `dryrun.test'
-
This test checks whether libtool's
--dry-run
mode works properly.
- `assign.test'
-
Checks whether we don't put break or continue on the same
line as an assignment in the libtool script.
- `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.
- `quote.test'
-
This program checks libtool's metacharacter quoting.
- `sh.test'
-
Checks whether a `test' command was forgotten in libtool.
- `suffix.test'
-
When other programming languages are used with libtool (see section Using libtool with 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.
Each of the above tests are designed to produce no output when they are
run via make check. The exit status of each program tells the
`Makefile' whether or not the test succeeded.
If a test fails, it means that there is either a programming error in
libtool, or in the test program itself.
To investigate a particular test, you may run it directly, as you would
a normal program. When the test is invoked in this way, it produces
output which may be useful in determining what the problem is.
Another way to have the test programs produce output is to set the
VERBOSE environment variable to `yes' before running them.
For example, env VERBOSE=yes make check runs all the tests, and
has each of them display debugging information.
If you think you have discovered a bug in libtool, you should think
twice: the libtool maintainer is notorious for passing the buck (or
maybe that should be "passing the bug"). Libtool was invented to fix
known deficiencies in shared library implementations, so, in a way, most
of the bugs in libtool are actually bugs in other operating systems.
However, the libtool maintainer would definitely be happy to add support
for somebody else's buggy operating system. [I wish there was a good
way to do winking smiley-faces in Texinfo.]
Genuine bugs in libtool include problems with shell script portability,
documentation errors, and failures in the test suite (see section The libtool test suite).
First, check the documentation and help screens to make sure that the
behaviour you think is a problem is not already mentioned as a feature.
Then, you should read the Emacs guide to reporting bugs (see section `Reporting Bugs' in The Emacs Manual). Some of the details
listed there are specific to Emacs, but the principle behind them is a
general one.
Finally, send a bug report to the libtool bug reporting address bug-libtool@gnu.org with any appropriate
facts, such as test suite output (see section When tests fail), all
the details needed to reproduce the bug, and a brief description of why
you think the behaviour is a bug. Be sure to include the word
"libtool" in the subject line, as well as the version number you are
using (which can be found by typing libtool --version).
Go to the first, previous, next, last section, table of contents.