[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
12.1 The libtool test suite Libtool's self-tests. 12.2 Reporting bugs How to report problems with libtool.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
12.1.1 Description of test suite The contents of the test suite. 12.1.2 When tests fail What to do when a test fails.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Here is a list of the current programs in the test suite, and what they test for:
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').
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_check_method
to prevent such cases.
This tests checks whether libtool's deplibs_check_method
works properly.
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'.
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 9.2 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').
--dry-run
mode works properly.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 12.1 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 12.1.2 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).
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |