For next public release: ************************ * Get rid of the sections that try to change behaviour for GNU ld. We really should make our shared library support just depend on the compiler type. * Alexandre Oliva suggests that we hardcode paths into libraries, as well as binaries: `... -Wl,-soname -Wl,/tmp/libtest.so.0 ...'. * Implement full support for other orthogonal library types (libhello_g, libhello_p, 64 vs 32-bit ABI's, etc). Make these types configurable. In the future: ************** * Inter-library dependencies should be automatically tracked by libtool. Reminded by Alexandre Oliva. This also would require looking up installed libtool libraries for transparent support. * 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. People who need it: Jean Daniel Fekete Thomas Hiller * Writing libtool as a shell script means that proper variable quoting is a real problem. Be careful when `eval'ing a string that the arguments are properly quoted. Note that arguments with embedded whitespace probably will cause problems (because of IFS). I don't have good ideas on to fix the problems with whitespace, other than subverting IFS entirely, perhaps always using an `eval "set $quoted_args"' sequence. * Another form of convenience library, suggested by Alexandre Oliva, 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. * Somehow we need to make sure that static libraries never appear in $deplibs. This, will probably require that libtool discover exactly which files would be linked from which directories when somebody says `-lsomething'. This adds a lot of complexity, but I see no other way around it. * Need to finalize the documentation, and give a specification of `.la' files so that people can depend on their format. This also needs to be done so that DLD uses a public interface to libtool archives. This would be a good thing to put before the maintainance notes. 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. * Add support for windoze DLL's, and maybe other jumptable libs. Check out Lesstif and Tcl configuration again (maybe they would be interested in libtool by now?). The Cygnus win32 project may also be of value, though it still seems pretty rudimentary right now.