FYI: libtool--devo--1.0--patch-130

[Gary V. Vaughan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Applied to HEAD.
- -- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook
_________________________________________________________
This patch notification generated by tlaapply version 0.5
http://tkd.kicks-ass.net/arch/address@hidden/cvs-utils--tla--1.0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)

iD8DBQFBMf+XFRMICSmD1gYRAh4TAKDATjNSbGoZA+ycwCDgBlzzvAA+YQCeJBt4
P3wXgbdiPVX5zlMYAnx9gOM=
=BOsj
-----END PGP SIGNATURE-----

* looking for address@hidden/libtool--devo--1.0--patch-129 to compare with
* comparing to address@hidden/libtool--devo--1.0--patch-129
M  ChangeLog
M  TODO

* modified files

Index: Changelog
from  Gary V. Vaughan  <address@hidden>
        * TODO: Reformat.  Removed some items that have been implemented.

2004-08-29  Gary V. Vaughan  <address@hidden>

--- orig/TODO
+++ mod/TODO
@@ -1,36 +1,27 @@
-In the near future:
-********************
+GNU Libtool
+***********
 
-* Port the migration of all code from ltconfig into libtool.m4 to the
-multi-language-branch, so that CVS automake can remove its references
-to ltconfig.
+1. In the near future
+=====================
 
-* 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.
+1.1. libtool
+------------
 
 * 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.
+  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.
+  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.
+  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 <address@hidden> writes:
   Because of a growing number of config scripts for packages in GNOME 1.2
@@ -46,16 +37,96 @@
   most packages that use pkg-config also use libtool, I think this
   would be a good way to reduce maintainer and developer dependencies.
 
+1.2. libtldl
+------------
+
+* 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.
+
+
+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.
 
-In the future:
-**************
+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 convenience libraries and reloadable
+  objects in the testsuite.
+
+* Write a test case for linkage with gnu ld scripts (per 2004-08-25 patch
+  from Paolo Bonzini).
+
+2.3. libtool
+------------
+
+* 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.
+
+* Filenames containing shell meta-characters are not properly handled
+  by libtool.  Compiling a file named "a;b.c", for example, fails.
+
+* 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.
+
+2.4. libtool autoconf macros
+----------------------------
 
 * The definitions for AC_LTDL_SHLIBEXT, AC_LTDL_SHLIBPATH and
-AC_LTDL_SYSSEARCHPATH  should not rely on the _LT_AC_LTCONFIG_HACK
-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.
+  AC_LTDL_SYSSEARCHPATH  should not rely on the _LT_AC_LTCONFIG_HACK
+  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. libltdl
+------------
+
+* 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.
 
 * Godmar Back writes:
   libltdl uses such stdio functions as fopen, fgets, feof, fclose, and others.
@@ -73,90 +144,69 @@
   possible would greatly improve libltdl's ability to be embedded in and
   used by other systems.
 
+2.6. 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.
+  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.
-
-* address@hidden 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|
-
-* 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.
-
-* 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.
-
-* We should include tests with convenience libraries and reloadable
-objects in the testsuite.
-
-* 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.
-
-* 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.
-
-* Filenames containing shell meta-characters are not properly handled
-by libtool.  Compiling a file named "a;b.c", for example, fails.
-
-* 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.
+  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.
+
+* address@hidden 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|
 
-* The current implementation of libltdl in a subdirectory doesn't work
-properly with AC_CONFIG_AUX_DIR using projects.
 
-Things to think about:
-**********************
+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.
+  (libhello_g, libhello_p, 64 vs 32-bit ABI's, etc).  Make these types
+  configurable.
 
 * Perhaps the iuse 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?
+  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?
+
+
+-- 
+Copyright (C) 2004 Free Software Foundation, Inc.
+
+The canonical source of this file is maintained with the
+GNU Libtool package.  Report bugs to address@hidden
+
+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.
+
+As a special exception to the GNU General Public License,
+if you distribute this file as part of a program or library that
+is built using GNU libtool, you may include it under the same
+distribution terms that you use for the rest of that program.
+
+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; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+02111-1307  USA
+
+
+Local Variables:
+mode: text
+fill-column: 72
+End: