libtool/TODO

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 <peterlin@biofiz.mf.uni-lj.si> -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 <Jean-Daniel.Fekete@emn.fr>
  Thomas Hiller <hiller@tu-harburg.d400.de>

* 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.