mirror of
git://git.savannah.gnu.org/libtool.git
synced 2024-11-21 01:40:57 +08:00
4ae2e67203
* libltdl/ltdl.h (lt_dlmakeresident, lt_dlisresident): Add prototypes. (LT_DLERROR_CLOSE_RESIDENT_MODULE): New error status. * libltdl/ltdl.c (lt_dlmakeresident, lt_dlisresident): Allow making and testing of resident module status, which prevents a module from being lt_dlclosed. (lt_dlopen): If lt_dlopen()ing self, make the module resident. (lt_dlclose): Return an error if the module is resident.
138 lines
6.2 KiB
Plaintext
138 lines
6.2 KiB
Plaintext
In the near future:
|
|
********************
|
|
|
|
* 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.
|
|
|
|
* Check whether the version of libtool.m4 is compatible with
|
|
ltconfig/ltmain.sh. Meanwhile, the recommended approach for
|
|
developers using automake is to insert libtool.m4 in acinclude.m4.
|
|
|
|
* 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.
|
|
|
|
In the future:
|
|
**************
|
|
|
|
* 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.
|
|
|
|
* 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.
|
|
|
|
* 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 dependant
|
|
.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.
|
|
|
|
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.
|
|
|
|
* 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?
|