In the near future: ******************** * Check whether the version of libtool.m4 is compatible with ltconfig/ltmain.sh. Meanwhile, the recommended approach for developers using automake is to insert libtool.m4 in acinclude.m4. * Inter-library dependencies should be fully tracked by libtool and need to work for ltlibraries too. This requires looking up installed libtool libraries for transparent support. Support for this feature is under development, and is expected to be available in libtool 1.4. * 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. 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. * Figure out how to use data items in dlls with win32. The difficult part is compiling each object which will be linked with an import lib differently than if it will be linked with a static lib. This will almost definitely require that automake pass some hints about linkage in to each object compilation line. * Resolve the name clash between import libs and static libs on win32. Probably the best way to do this is to create lib$name-dll.a for the import library, and continue to use lib$name.a for the static lib. libtool --mode=link can then favour -dll.a over .a if there is a choice. No point in doing this until we can export data items (above). * If not cross-compiling, have the static flag test run the resulting binary to make sure everything works. * Implement full multi-language support. Currently, this is only for C++, but there are beginnings of this in the manual (Other Languages). This includes writing libtool not to be so dependent on the compiler used to configure it. We especially need this for C++ linking, for which libtool currently does not handle static constructors properly, even on operating systems that support them. ``Don't use static constructors'' is no longer a satisfactory answer. * 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: ********************** * Talk with RMS about his so-called `automatic package generation tool.' This is probably what Thomas has been murmuring about for the Hurd. We'll need to integrate package-supplied programs such as libtool into that scheme, since it manages some of the preinstall and postinstall commands, but isn't installed itself. Probably, things like libtool should be distributed as part of such a binary package. * Maybe implement full support for other orthogonal library types (libhello_g, libhello_p, 64 vs 32-bit ABI's, etc). Make these types configurable.