GNU Libtool - GNU Project - Free Software Foundation (FSF)

GNU Libtool - The GNU Portable Library Tool

Copyright © 1996, 1997, 1998, 1999, 2000, 2001 Free Software Foundation, Inc.
Originally by Gordon Matzigkeit, 1996.

Home | News | Documentation | Future Directions | Contributing | Administration

This page tries to explain what we have planned for Libtool's future, both long and short term.
In the Near Future

In the short term, we are working towards Libtool 1.5, which is already a major release thanks to the newly merged support for multiple languages with configuration tags. The following items should be complete before we can release 1.5, though other features may also be included:

Check whether the version of libtool.m4 is compatible with ltmain.sh. Meanwhile, the recommended approach for developers using automake is to insert libtool.m4 in acinclude.m4.
We could have an option to hardcode paths into libraries, as well as binaries: `... -Wl,-soname -Wl,/tmp/libtest.so.0 ...'. This is not possible on all platforms, and is in part obviated by the ability of linking libtool libraries specified with -lname, but it might still be desirable.
Lists of exported symbols should be stored in the pseudo library so that the size of lt_preloaded_symbols can be reduced.
Robert Collins has supplied us with a version of libtool that works with an unreleased binutils to provide ELF like library functionality on cygwin. The libtool parts of this work will be merged in to the repository before 1.5 is released.

Much of the work for Libtool 1.6 is also underway:

A special libtool branch is being built that will start the development of a binary executable version that will maintain a compatible script, too (a la GCC's fixincludes, for any that remember). The binary-branch is available now, but does little more than create a binary wrapper around the same script and re-emit the last multi-language-branch.

In the Future

Godmar Back writes:
libltdl uses such stdio functions as fopen, fgets, feof, fclose, and others. These functions are not async-signal-safe. While this does not make libltdl unusable, it restricts its usefulness and puts an unnecessary burden on the user.
As a remedy, I'd recommend to replace those functions with functions that POSIX says are async-signal-safe, such as open, read, close. This will require you to handle interrupted system calls and implement fgets, but the former isn't hard and there's plenty of implementations out from which you can steal the latter.
I believe relying on async-signal-safe functions to the greatest extent possible would greatly improve libltdl's ability to be embedded in and used by other systems.
Arrange that EXEEXT suffixes are stripped from wrapper script names only when needed, and that a timestamp file or a wrapper program is created with the EXEEXT suffix, so that `make' doesn't build it every time.
If not cross-compiling, have the static flag test run the resulting binary to make sure everything works.
We need some mechanism to allow users to pass flags to the linker and/or to the compiler, when creating libtool archives. We could recognize linker flags such as `-Wl,flag' and `-Xlinker flag' in libtool's command line, and passing them down to the linker, if "$wl" is `-Wl,', or stripping the `-Wl,' part if we're calling `ld' directly. We could also introduce `-Wc,flag' and `-Xcompiler flag' to allow unrecognized flags to be passed to the compiler, after stripping by libtool. This is already implemented in the CVS tree.
Another form of convenience library is to have undocumented utility libraries, where only the shared version is installed.
We could use libtool object convenience libraries that resolve symbols to be included in a libtool archive. This would require some sort of -whole-archive option, as well.
Currently, convenience libraries (.al) are built from .lo objects, except when --disable-shared. When we can build both shared and static libraries, we should probably create a .al out of .lo objects and also a .a out of .o objects. The .al would only be used to create shared libraries, whereas the .a would be used for creating static libraries and programs. We could also explicitly support `empty' convenience libraries, that behave as macros that expand to a set of -Rs, -Ls and -ls switches.
We should include tests with convenience libraries and reloadable objects in the testsuite.
Try to find a work-around for -[all-]static and libltdl on platforms that will fail to find dlopening functions in this case. Maybe creating an alternate libltdl that provides only for dlpreopening, or creating an additional static library to provide dummy implementations of the functions that can't be linked statically. This could hardly be made completely transparent, though.
Need to finalize the documentation, and give a specification of `.la' files so that people can depend on their format. This would be a good thing to put before the maintainance notes.
Filenames containing shell meta-characters are not properly handled by libtool. Compiling a file named "a;b.c", for example, fails.
We could introduce a mechanism to allow for soname rewriting, to ease multi-libc support. Installers could specify a prefix, suffix or sed command to modify the soname, and libtool would create the corresponding link. This would allow for rebuilding a library with the same version number, but depending on different versions of libc, for example. In the future, we might even have an option to encode the sonames of all dependencies of a library into its soname.

Things to Think About

Maybe implement full support for other orthogonal library types (libhello_g, libhello_p, 64 vs 32-bit ABI's, etc). Make these types configurable.

Home | News | Documentation | Future Directions | Contributing | Administration
Return to GNU's home page.
Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.
Please send comments on these web pages to webmasters@www.gnu.org, send other questions to gnu@gnu.org.
This article, Copyright © 1998, 1999, 2000, 2001 Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
$Date: 2005/04/25 18:54:32 $ $Author: rwild $