TODO

For next public release:
************************

* Create a new library version_type, `irix'.  Janos Farkas writes:

I just realized I also have mortal access to an SGI system, and found
this in the dso.5 page, this looks more informative :)

   Versioning of Shared Objects.

   QUICK OVERVIEW

   For a shared object to be versioned the following needs to be done:

   * Version strings consist of 3 parts and a dot: The string "sgi",
     a decimal number (the major number), a dot, and a decimal number
     (the minor number).

   * Add the command -set_version sgi1.0 to the command to build
     the shared object (cc -shared, ld -shared, etc.).

   * Whenever you make a COMPATIBLE change update the minor version
     number (the one after the dot), and add the latest version string
     to colon-separated list of version strings, e.g., -set_version
     sgi1.0:sgi1.1:sgi1.3

   * Whenever you make an INCOMPATIBLE change, update the
     major version number.  Pass this as the version list, e.g.,
     -set_version sgi2.0.  Change the filename of the OLD shared object
     by adding a dot followed by the previous major number to the filename
     of the shared object.  DO NOT CHANGE the soname of the object.
     No change to the file contents are necessary or desirable.  Simply
     rename the file.

* Inter-library dependencies should be fully tracked by libtool.
Reminded by Alexandre Oliva.  This requires looking up installed
libtool libraries for transparent support.

* Inter-library dependencies need to work for ltlibraries too.
Thomas Tanner has a patch for this.

* Alexandre Oliva suggests that we hardcode paths into libraries, as
well as binaries:  `... -Wl,-soname -Wl,/tmp/libtest.so.0 ...'.  Tim
Mooney wants the same thing.

* Tom Lane adds that HP-UX's linker, at least (I've also found this on
AIX 4), distinguishes between global function and global variable
references.  This means that we cannot declare every symbol as `extern
char'.  Find a workaround.

* Jeff Garzik <jgarzik@pobox.com> noticed that libtool wrapper scripts do
not always work on Linux.  When running tests in a newly built package, the
script is prone to picking up a similarly sonamed library in /usr/lib in
preference to the newly built library in the distribution.  The scripts *do*
work under Solaris however.

* Documentation:

- libltdl documentation needs to be completed.

In the future:
**************

* Fix */demo on win32.
This may require resolving some of the items below.

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

People who need it:
  Jean Daniel Fekete <Jean-Daniel.Fekete@emn.fr>
  Thomas Hiller <hiller@tu-harburg.d400.de>

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

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

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

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