From: Gary V. Vaughan Date: Sun, 29 Aug 2004 16:08:13 +0000 (+0000) Subject: * TODO: Reformat. Removed some items that have been implemented. X-Git-Tag: release-1-9b~4 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=c1a20b788110f92090dcc38b96e5fae1272bd5f0;p=thirdparty%2Flibtool.git * TODO: Reformat. Removed some items that have been implemented. --- diff --git a/ChangeLog b/ChangeLog index 90ba1412a..971a84341 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,7 @@ +2004-08-29 Gary V. Vaughan + + * TODO: Reformat. Removed some items that have been implemented. + 2004-08-29 Gary V. Vaughan Add a new `-weak' flag to tell libtool when not to propogate diff --git a/TODO b/TODO index e6b119d3c..9647a0032 100644 --- a/TODO +++ b/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 writes: Because of a growing number of config scripts for packages in GNOME 1.2 @@ -46,16 +37,96 @@ files that get installed. 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 +------------------ -In the future: -************** +* 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. + +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 @@ respective ltdl.m4 macros. 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. + 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| +* 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| -* 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. +3. Wish List +============ -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. +* Maybe implement full support for other orthogonal library types + (libhello_g, libhello_p, 64 vs 32-bit ABI's, etc). Make these types + configurable. -* Another form of convenience library is to have undocumented utility -libraries, where only the shared version is installed. +* 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? -* 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. +-- +Copyright (C) 2004 Free Software Foundation, Inc. -* We should include tests with convenience libraries and reloadable -objects in the testsuite. +The canonical source of this file is maintained with the +GNU Libtool package. Report bugs to bug-libtool@gnu.org. -* 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. +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. -* 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. +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. -* 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. +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. -* The current implementation of libltdl in a subdirectory doesn't work -properly with AC_CONFIG_AUX_DIR using projects. +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 -Things to think about: -********************** -* 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 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? +Local Variables: +mode: text +fill-column: 72 +End: