mirror of
git://git.savannah.gnu.org/libtool.git
synced 2025-02-17 15:10:02 +08:00
* TODO: Reformat. Removed some items that have been implemented.
This commit is contained in:
Gary V. Vaughan
parent
0158428875
commit
c1a20b7881
@ -1,3 +1,7 @@
|
||||
2004-08-29 Gary V. Vaughan <gary@gnu.org>
|
||||
|
||||
* TODO: Reformat. Removed some items that have been implemented.
|
||||
|
||||
2004-08-29 Gary V. Vaughan <gary@gnu.org>
|
||||
|
||||
Add a new `-weak' flag to tell libtool when not to propogate
|
||||
|
||||
268
TODO
268
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 <elemings@cyberia.lemings.com> 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
|
||||
------------
|
||||
|
||||
In the 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.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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 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 bug-libtool@gnu.org.
|
||||
|
||||
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:
|
||||
|
||||
Loading…
Reference in New Issue
Block a user