src/parsec/disk-image/parsec/parsec-benchmark/pkgs/tools/libtool/src/TODO - public/gem5-resources - Git at Google

 GNU Libtool
 ***********

 1. In the near future
 =====================

 1.1. libtool
 ------------

 * Rather than looking up the linker's hardcode characteristics in a
   table of shell code, use objdump or equivalent to probe a test program
   at configure time.

 * Eliminate the warnings from autoconf -Wobsolete.

 * Hook the various language dependencies into the autoconf _AC_LANG
   framework.

 * Work out what to do when the dynamic linker loads needed dependencies.

 * We could have an option to hardcode paths into libraries, as well as
   binaries: `... -Wl,-soname -Wl,/tmp/libtest.so.0 ...'.  This is not
   possible on all platforms, and is in part obviated by the ability of
   linking libtool libraries specified with -lname, but it might still
   be desirable.

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

 * Have some option to tell libtool not to include -L flags that point
   into a certain tree in the dependence list of an installed library.
   For example: -L-$top_builddir would let one link with libtool
   libraries in sibling subdirectories within a project, using the -L
   notation, without getting builddir pathnames ever mentioned in .la
   files that get installed.

 * Eric Lemings <elemings@cyberia.lemings.com> writes:
   Because of a growing number of config scripts for packages in GNOME 1.2
   (e.g. glib-config, xml-config, orbit-config. etc), development of GNOME
   2.0 spawned a separate tool called pkg-config that allows all packages
   to use one tool rather than several different scripts to query compile
   flags, link flags, and other configuration data.

   The functionality of pkg-config seems to me to have a lot of overlap
   with the goals of libtool.  I was wondering if anyone had considered
   adding an eighth mode to libtool that just queries the installed
   library for the same information that pkg-config provides.  Since
   most packages that use pkg-config also use libtool, I think this
   would be a good way to reduce maintainer and developer dependencies.

 * Have libtoolize install `install-sh' if a newer version is available,
   and/or Automake is not used.

 * Allow to specify linking some dependent libraries statically and some
   dynamically, where possible.

 * Improve support for C++ with templates.

 * Audit file listing in libtool.m4.

 * Fix deplibs_check_method=pass_all (which is wrong!) on linux.

 * Fix -dlopen "self" on AIX.  Reported by Gary Kumfert <kumfert@llnl.gov>.

 * Fix denial of service if using installed `libtool' on a different mount point
   together with a compiler which does not understand `-c -o'.
   Reported by Marcin Siennicki.

 * Look at better -no-undefined support, maybe along the idea of
   [support #103719] for CC.


 1.2. libltdl
 ------------

 * Change libltdl interface: add separate functions for function
   pointers.  This will allow porting to systems where function pointers
   are incompatible with data pointer C-wise.

 * Fix the following bugs in libltdl:
  - error reporting of tryall_dlopen():
    if the file actually doesn't exist (stat() fails or it wasn't dlpreopened)
    -> report `file not found'
    if it cannot be loaded (e.g. due to missing dependencies)
    -> report dlerror
     open question: which error should be reported if all dlloaders fail
     or if a specific module type can only be loaded by one of them, how report its dlerror?
    Also report dlerror() for dlclose and dlsym if available
  - Make sure that the dependency_libs of a dlpreopened module won't be loaded.

  - Fix mdemo failures on mingw.

  - Fix the last memleak.  Reported by Jeff Squyres <jsquyres@lam-mpi.org>.

  - Fix LTDL_CONVENIENCE.  Reported by Bob Friesenhahn
    and Patrick Welche <prlw1@newn.cam.ac.uk>.


 1.3. libtoolize
 ---------------

 * Rewrite the func_copy_* functions so that instead of forking 2 tar
   processes per copied file, a list of files to copy is built and all
   files copied with a single pair of tar processes.

 * Write test case that adds libtool macros to aclocal.m4.


 2. In the future
 ================

 2.1. Documentation
 ------------------

 * Need to finalize the documentation, and give a specification of
   `.la' files so that people can depend on their format.  This would be
   a good thing to put before the maintainance notes.

 * Document the installed `libtool' and its limitations clearly (maybe implement
   --disable-script-install as well).  Or, even better, remove its limitations.

 * Platform notes redo.

 2.2. test suite
 ---------------

 * Rewrite the whole thing in Autotest.  This will enable us to remove
   all the tests/*demo noise, and duplication; and thus speed up bootstrap
   and make writing new tests a whole lot more pleasant.

 * We should include tests with reloadable objects in the testsuite.

 * Write a test case for linkage with gnu ld scripts (per 2004-08-25 patch
   from Paolo Bonzini).

 * Test everything:
     - cross compile
     - dirs with ~
     - multiple input files

 2.3. libtool
 ------------

 * Fix cross-compiling.

 * Fix threads.

 * Support multilibbing.

 * If not cross-compiling, have the static flag test run the resulting
   binary to make sure everything works.

 * Another form of convenience library 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.  We could also explicitly support `empty'
   convenience libraries, that behave as macros that expand to a set of
   -Rs, -Ls and -ls switches.

 * Audit use of object names so we can allow `$' not only within
   source file names.  Necessary especially for java.

 * We could introduce a mechanism to allow for soname rewriting, to
   ease multi-libc support.  Installers could specify a prefix, suffix or
   sed command to modify the soname, and libtool would create the
   corresponding link.  This would allow for rebuilding a library with
   the same version number, but depending on different versions of libc,
   for example.  In the future, we might even have an option to encode
   the sonames of all dependencies of a library into its soname.

 * Look again at a binary C libtool, or byte-compiled libtool to improve
   speed.

 * Generate some "platform specific" shell functions with config.status,
   for example, there is no need to have the C source code for the
   wrapper script on non-windows platforms, this will make the generated
   libtool script smaller and easier to follow, maybe a little faster
   too?

 * Audit the GCJ tag section in libtool.m4.

 * Add caching mechanism.  Look at `libtool-cache' from Robert Ögren.


 2.4. libtool autoconf macros
 ----------------------------

 * Sort out the macro mess in libtool.m4.  We've started this already
   by refactoring chunks into separate files, but I never did completely
   untangle the mess of macros imported from ltconfig.

 * The definitions for LT_SYS_MODULE_EXT, LT_SYS_MODULE_PATH and
   LT_SYS_DLSEARCH_PATH  should not rely on the _LT_SYS_DYNAMIC_LINKER
   macro.  This involves moving the code which sets the variables
   library_names_spec, shlibpath_var and sys_lib_dlsearch_path_spec from
   into a separate macro, and AC_REQUIRING the newly extracted macro in the
   respective ltdl.m4 macros.

 2.5. libtool automake integration
 ---------------------------------

 * Unify locks between libtool and compile.

 * Fix relinking.

 2.6. libltdl
 ------------

 * Finish the rewrite of the core libltdl.  The loaders are fine, and
   the outlying code is now good.  Ralf is starting to pick away at a lot
   of the remaining nasties already, but the code for finding .la/.so files
   and reading/loading them could use a lot more improvement.

 * I think we could factor out a little path management support module
   from existing libltdl.  This would be useful for M4 at least -- keeping
   track of FOO_PATH environment contents, searching for files in paths
   etc.

 * Try to find a work-around for -[all-]static and libltdl on platforms
   that will fail to find dlopening functions in this case.  Maybe
   creating an alternate libltdl that provides only for dlpreopening, or
   creating an additional static library to provide dummy implementations
   of the functions that can't be linked statically.  This could hardly
   be made completely transparent, though.

 * In conjunction with above, fix the failures on *BSD when linked to
   static libc.  Reported by Guilhem Lavaux <guilhem@kaffe.org>.

 * Add i18n strings to libltdl, ensuring that package developers can
   ignore any i18n when they libtoolize.

 2.7. win32 support
 ------------------

 * Arrange that EXEEXT suffixes are stripped from wrapper script names
   only when needed, and that a timestamp file or a wrapper program is
   created with the EXEEXT suffix, so that `make' doesn't build it every
   time.

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

 * jeffdb@goodnet.com writes:
   all you need to do for mutually dependent .dll's is to create an implib from
   a .def file so it appears that we might need to detect and handle mutual
   dependencies specially on win32 =(O|


 3. Wish List
 ============

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

 * Perhaps the use of libltdl could be made cleaner by allowing
   registration of hook functions to call at various points.  This would
   hopefully free the user from having to maintain a parallel module
   list with user data.  This would likely involve being able to carry
   additional per user module data in the lt_dlmodule structure -- perhaps
   in the form of an associative array keyed by user name?

 * Figure out how to make pkg-config aware of the information libtool
   knows about libraries and their dependencies, and send a patch.

 * Generate a libtool.m4 from a bunch of individual files, one per
   platform, to make the job of a "platform maintainer" easier and make
   it easier to add new platforms.

 --
   Copyright (C) 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
   Written by Gary V. Vaughan, 2004

   This file is part of GNU Libtool.

 GNU Libtool is free software; you can redistribute it and/or
 modify it under the terms of the GNU General Public License as
 published by the Free Software Foundation; either version 2 of
 the License, or (at your option) any later version.

 GNU Libtool is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.

 You should have received a copy of the GNU General Public License
 along with GNU Libtool; see the file COPYING.  If not, a copy
 can be downloaded from  http://www.gnu.org/licenses/gpl.html,
 or obtained by writing to the Free Software Foundation, Inc.,
 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

 Local Variables:
 mode: text
 fill-column: 72
 End:
	GNU Libtool
	***********

	1. In the near future
	=====================

	1.1. libtool
	------------

	* Rather than looking up the linker's hardcode characteristics in a
	table of shell code, use objdump or equivalent to probe a test program
	at configure time.

	* Eliminate the warnings from autoconf -Wobsolete.

	* Hook the various language dependencies into the autoconf _AC_LANG
	framework.

	* Work out what to do when the dynamic linker loads needed dependencies.

	* We could have an option to hardcode paths into libraries, as well as
	binaries: `... -Wl,-soname -Wl,/tmp/libtest.so.0 ...'. This is not
	possible on all platforms, and is in part obviated by the ability of
	linking libtool libraries specified with -lname, but it might still
	be desirable.

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

	* Have some option to tell libtool not to include -L flags that point
	into a certain tree in the dependence list of an installed library.
	For example: -L-$top_builddir would let one link with libtool
	libraries in sibling subdirectories within a project, using the -L
	notation, without getting builddir pathnames ever mentioned in .la
	files that get installed.

	* Eric Lemings <elemings@cyberia.lemings.com> writes:
	Because of a growing number of config scripts for packages in GNOME 1.2
	(e.g. glib-config, xml-config, orbit-config. etc), development of GNOME
	2.0 spawned a separate tool called pkg-config that allows all packages
	to use one tool rather than several different scripts to query compile
	flags, link flags, and other configuration data.

	The functionality of pkg-config seems to me to have a lot of overlap
	with the goals of libtool. I was wondering if anyone had considered
	adding an eighth mode to libtool that just queries the installed
	library for the same information that pkg-config provides. Since
	most packages that use pkg-config also use libtool, I think this
	would be a good way to reduce maintainer and developer dependencies.

	* Have libtoolize install `install-sh' if a newer version is available,
	and/or Automake is not used.

	* Allow to specify linking some dependent libraries statically and some
	dynamically, where possible.

	* Improve support for C++ with templates.

	* Audit file listing in libtool.m4.

	* Fix deplibs_check_method=pass_all (which is wrong!) on linux.

	* Fix -dlopen "self" on AIX. Reported by Gary Kumfert <kumfert@llnl.gov>.

	* Fix denial of service if using installed `libtool' on a different mount point
	together with a compiler which does not understand `-c -o'.
	Reported by Marcin Siennicki.

	* Look at better -no-undefined support, maybe along the idea of
	[support #103719] for CC.


	1.2. libltdl
	------------

	* Change libltdl interface: add separate functions for function
	pointers. This will allow porting to systems where function pointers
	are incompatible with data pointer C-wise.

	* Fix the following bugs in libltdl:
	- error reporting of tryall_dlopen():
	if the file actually doesn't exist (stat() fails or it wasn't dlpreopened)
	-> report `file not found'
	if it cannot be loaded (e.g. due to missing dependencies)
	-> report dlerror
	open question: which error should be reported if all dlloaders fail
	or if a specific module type can only be loaded by one of them, how report its dlerror?
	Also report dlerror() for dlclose and dlsym if available
	- Make sure that the dependency_libs of a dlpreopened module won't be loaded.

	- Fix mdemo failures on mingw.

	- Fix the last memleak. Reported by Jeff Squyres <jsquyres@lam-mpi.org>.

	- Fix LTDL_CONVENIENCE. Reported by Bob Friesenhahn
	and Patrick Welche <prlw1@newn.cam.ac.uk>.


	1.3. libtoolize
	---------------

	* Rewrite the func_copy_* functions so that instead of forking 2 tar
	processes per copied file, a list of files to copy is built and all
	files copied with a single pair of tar processes.

	* Write test case that adds libtool macros to aclocal.m4.


	2. In the future
	================

	2.1. Documentation
	------------------

	* Need to finalize the documentation, and give a specification of
	`.la' files so that people can depend on their format. This would be
	a good thing to put before the maintainance notes.

	* Document the installed `libtool' and its limitations clearly (maybe implement
	--disable-script-install as well). Or, even better, remove its limitations.

	* Platform notes redo.

	2.2. test suite
	---------------

	* Rewrite the whole thing in Autotest. This will enable us to remove
	all the tests/*demo noise, and duplication; and thus speed up bootstrap
	and make writing new tests a whole lot more pleasant.

	* We should include tests with reloadable objects in the testsuite.

	* Write a test case for linkage with gnu ld scripts (per 2004-08-25 patch
	from Paolo Bonzini).

	* Test everything:
	- cross compile
	- dirs with ~
	- multiple input files

	2.3. libtool
	------------

	* Fix cross-compiling.

	* Fix threads.

	* Support multilibbing.

	* If not cross-compiling, have the static flag test run the resulting
	binary to make sure everything works.

	* Another form of convenience library 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. We could also explicitly support `empty'
	convenience libraries, that behave as macros that expand to a set of
	-Rs, -Ls and -ls switches.

	* Audit use of object names so we can allow `$' not only within
	source file names. Necessary especially for java.

	* We could introduce a mechanism to allow for soname rewriting, to
	ease multi-libc support. Installers could specify a prefix, suffix or
	sed command to modify the soname, and libtool would create the
	corresponding link. This would allow for rebuilding a library with
	the same version number, but depending on different versions of libc,
	for example. In the future, we might even have an option to encode
	the sonames of all dependencies of a library into its soname.

	* Look again at a binary C libtool, or byte-compiled libtool to improve
	speed.

	* Generate some "platform specific" shell functions with config.status,
	for example, there is no need to have the C source code for the
	wrapper script on non-windows platforms, this will make the generated
	libtool script smaller and easier to follow, maybe a little faster
	too?

	* Audit the GCJ tag section in libtool.m4.

	* Add caching mechanism. Look at `libtool-cache' from Robert Ögren.


	2.4. libtool autoconf macros
	----------------------------

	* Sort out the macro mess in libtool.m4. We've started this already
	by refactoring chunks into separate files, but I never did completely
	untangle the mess of macros imported from ltconfig.

	* The definitions for LT_SYS_MODULE_EXT, LT_SYS_MODULE_PATH and
	LT_SYS_DLSEARCH_PATH should not rely on the _LT_SYS_DYNAMIC_LINKER
	macro. This involves moving the code which sets the variables
	library_names_spec, shlibpath_var and sys_lib_dlsearch_path_spec from
	into a separate macro, and AC_REQUIRING the newly extracted macro in the
	respective ltdl.m4 macros.

	2.5. libtool automake integration
	---------------------------------

	* Unify locks between libtool and compile.

	* Fix relinking.

	2.6. libltdl
	------------

	* Finish the rewrite of the core libltdl. The loaders are fine, and
	the outlying code is now good. Ralf is starting to pick away at a lot
	of the remaining nasties already, but the code for finding .la/.so files
	and reading/loading them could use a lot more improvement.

	* I think we could factor out a little path management support module
	from existing libltdl. This would be useful for M4 at least -- keeping
	track of FOO_PATH environment contents, searching for files in paths
	etc.

	* Try to find a work-around for -[all-]static and libltdl on platforms
	that will fail to find dlopening functions in this case. Maybe
	creating an alternate libltdl that provides only for dlpreopening, or
	creating an additional static library to provide dummy implementations
	of the functions that can't be linked statically. This could hardly
	be made completely transparent, though.

	* In conjunction with above, fix the failures on *BSD when linked to
	static libc. Reported by Guilhem Lavaux <guilhem@kaffe.org>.

	* Add i18n strings to libltdl, ensuring that package developers can
	ignore any i18n when they libtoolize.

	2.7. win32 support
	------------------

	* Arrange that EXEEXT suffixes are stripped from wrapper script names
	only when needed, and that a timestamp file or a wrapper program is
	created with the EXEEXT suffix, so that `make' doesn't build it every
	time.

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

	* jeffdb@goodnet.com writes:
	all you need to do for mutually dependent .dll's is to create an implib from
	a .def file so it appears that we might need to detect and handle mutual
	dependencies specially on win32 =(O\|


	3. Wish List
	============

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

	* Perhaps the use of libltdl could be made cleaner by allowing
	registration of hook functions to call at various points. This would
	hopefully free the user from having to maintain a parallel module
	list with user data. This would likely involve being able to carry
	additional per user module data in the lt_dlmodule structure -- perhaps
	in the form of an associative array keyed by user name?

	* Figure out how to make pkg-config aware of the information libtool
	knows about libraries and their dependencies, and send a patch.

	* Generate a libtool.m4 from a bunch of individual files, one per
	platform, to make the job of a "platform maintainer" easier and make
	it easier to add new platforms.

	--
	Copyright (C) 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
	Written by Gary V. Vaughan, 2004

	This file is part of GNU Libtool.

	GNU Libtool is free software; you can redistribute it and/or
	modify it under the terms of the GNU General Public License as
	published by the Free Software Foundation; either version 2 of
	the License, or (at your option) any later version.

	GNU Libtool is distributed in the hope that it will be useful,
	but WITHOUT ANY WARRANTY; without even the implied warranty of
	MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
	GNU General Public License for more details.

	You should have received a copy of the GNU General Public License
	along with GNU Libtool; see the file COPYING. If not, a copy
	can be downloaded from http://www.gnu.org/licenses/gpl.html,
	or obtained by writing to the Free Software Foundation, Inc.,
	51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

	Local Variables:
	mode: text
	fill-column: 72
	End: