TODO - libtool - Git at Google

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

 * check whether the version of libtool.m4 is compatible
 with ltconfig/ltmain.sh

 * 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.
 Thomas Tanner has a patch for this.

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

 * Lists of exported symbols should be stored in the pseudo library
 so that the size of lt_preloaded_symbols can be reduced.

 * Documentation:

 - AC_PROG_LIBTOOL, AC_ENABLE/DISABLE_SHARED/STATIC/FAST_INSTALL,
   AC_LIBTOOL_DLOPEN, AC_LIBLTDL_CONVENIENCE/INSTALLABLE are not documented

 - Purpose and usage of convenience libraries must be better documented

 - some new internal variables are not documented yet.

 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.

 * Fix */demo on win32.
 This may simply require resolving the item 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.

 * 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.
	For next public release:
	************************

	* check whether the version of libtool.m4 is compatible
	with ltconfig/ltmain.sh

	* 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.
	Thomas Tanner has a patch for this.

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

	* Lists of exported symbols should be stored in the pseudo library
	so that the size of lt_preloaded_symbols can be reduced.

	* Documentation:

	- AC_PROG_LIBTOOL, AC_ENABLE/DISABLE_SHARED/STATIC/FAST_INSTALL,
	AC_LIBTOOL_DLOPEN, AC_LIBLTDL_CONVENIENCE/INSTALLABLE are not documented

	- Purpose and usage of convenience libraries must be better documented

	- some new internal variables are not documented yet.

	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.

	* Fix */demo on win32.
	This may simply require resolving the item 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.

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