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. * Explain why we have the `-lm' in: libhello_la_LDFLAGS = -version-info 3:12:1 -lm * Explain why we don't allow `-o SOMEFILE' with compile mode. * Alexandre Oliva suggests that we hardcode paths into libraries, as well as binaries: `... -Wl,-soname -Wl,/tmp/libtest.so.0 ...'. * Primoz Peterlin -Aicrit: > A very first impression after compiling the new recode on HP-UX 9.05 > (with gcc and various other gnuities). I encountered the following > problem [...] > ../libtool: /./ltmain.sh: not found This is a bug in HP-UX sed. The correct solution is to obtain a sed update from your HP-UX vendor, or to install GNU sed. The sed distributed with HP-UX is so horribly broken that it is impossible to change libtool so that it works by using it. * From Kenneth Albanowski: At the very least, this message should be tailored for the OS and libraries -- if Linux's ld requires explicit -rpath arguments (instead of treating all -L paths as -rpaths) then this message should mention it, as well as the full options. Something like this would seem ideal: Libraries have been installed to /usr/lib, /usr/local/lib, /foo/bar and /foo/baz. To link against libraries in /foo/bar and /foo/baz, users may have to: - Use the -L/foo/bar and -L/foo/baz linker flags, and - Add /foo/bar:/foo/baz to their LD_LIBRARY_PATH environment variable during execution, or - Add /foo/bar:/foo/baz to their LD_RUN_PATH environment variable during linking, or - Use the -rpath /foo/bar and -rpath /foo/baz linker flags, or - Have the system administrator add /foo/bar and /foo/bz to /etc/ld.so.conf [See the ld.so(8) manual page and any operating system documentation about shared libraries for more information.] * Franc,ois Pinard about debugging: ``Another thing I'm curious to experiment is how will `gdb' perform with shared libraries. There are a few notes in the manual about generating a "more easy to debug" version of the program. I tried the recipe, but it broke somewhere in Automake generated dependency code, so I got to remove it for now. However, the manual does not explain what the debugging difficulty is, and so, I wonder what problems I will meet.'' * Document the change from `-allow-undefined' to `-no-undefined'. * Document what to tell users about adding their libraries to their `ldconfig' directories at bootup. Libtool doesn't do this automatically, because it can't. * Some packages, such as GIMP, choose to put a note about `--disable-shared' in their README: ---------------------------------------------------------------------- The GIMP uses GNU libtool in order to build shared libraries on a variety of systems. While this is very nice for making usable binaries, it can be a pain when trying to debug a program. For that reason, compilation of shared libraries can be turned off by specifying the "--disable-shared" option to "configure". ---------------------------------------------------------------------- Simply invoke configure in the top-level directory. Besides the usual GNU configure options, there are the following SANE specific options: --disable-shared Don't use shared libraries. Useful for debugging or when there is a problem building shared libraries. ---------------------------------------------------------------------- Perhaps a similar note could be added to ABOUT-NLS. I'll add a suggestion to the libtool documentation, so that other maintainers add this kind of note to their package documentation. The biggest motivation, mentioned by Franc,ois Pinard, is to turn off double-compilation. 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: ********************** * Implement full support for other orthogonal library types (libhello_g, libhello_p). Make these types configurable. Some thinking will have to be done about the defaults, and what libhello (standard type) should be. Maybe we should just add an autoconf macro and get creative with library_transform_name, or something. These changes should be partially driven by the needs of packaging tools, such as RPM and dpkg. * 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.