mirror of
git://git.savannah.gnu.org/libtool.git
synced 2025-01-30 14:30:15 +08:00
64d9b880c5
* NEWS: inter-library dependencies are now supported * configure.in: add the depdemo subdirectory * depdemo/*: new demo to demonstrate inter-library dependencies * tests/depdemo*: new tests for depdemo * ltconfig.in: added hardcode_into_libs (whether library paths should be hardcoded into the libraries), it currently defaults to 'no' * ltmain.in: new internal 'relink' mode to relink libraries on platforms with hardcode_into_libs=yes, save command line arguments in libtool_args, accept relative -L directories, ignore -lm on BeOS and Cygwin, always ignore -lc, handle -l, -L and .la arguments later, always make the library installation directory (-rpath) absolute, in relink mode don't delete the not-relinked library and exit immediately after relinking, try to find already-installed libtool libraries that were specified using -l, support hardcoding of library paths into libraries too, export shlibpath before linking libraries, and a lot of other big changes that I don't want to describe here... please read the source. * merged Gary's Win32 code from the ILD branch: * NEWS: Win32 DLLs are now supported * TODO: removed .a library namespace clash for win32. It is now resolved. * ltconfig.in (cygwin, library_names_spec): removed $libname.a. Creating a dll with libtool no longer creates an import library. * ltconfig.in (extract_expsyms_cmds): Create $objdir if it does not exist -- i.e. we need to generate import an import library in a directory which has no libs of its own. * doc/libtool.texi (old_archive_from_expsyms_cmds, extract_expsyms_cmds): documented these new variables. * ltconfig.in (extract_expsyms_cmds): New variable. Commands to extract the exported symbol list from a dll. (old_archive_from_expsyms_cmds): New variable. Commands to build an old archive from the extracted expsyms list. * ltmain.in: run the cmds in extract_expsyms_cmds and old_archive_from_expsyms_cmds as necessary. * ltconfig.in (cygwin, old_archive_from_new_cmds): no longer required. * ltconfig.in (cygwin, shlibpath_overrides_runpath): I'm not even sure whether win32 honours the runpath at all when searching for a dll to load! Anyway, when set to yes this prevents a gratuitous warning. * ltmain.in (deplib): The cygwin environment doesn't actually have -lm, and although the linker fakes having one, specifiying it to libtool will break ILD, so we ignore it when generating dependencies.
107 lines
4.3 KiB
Plaintext
107 lines
4.3 KiB
Plaintext
For next public release:
|
|
************************
|
|
|
|
* check whether the version of libtool.m4 is compatible
|
|
with ltconfig/ltmain.sh
|
|
|
|
* Inter-library dependencies should be fully tracked by libtool
|
|
and need to work for ltlibraries too. This requires looking up
|
|
installed libtool libraries for transparent support.
|
|
Thomas Tanner has a patch for this.
|
|
|
|
* Alexandre Oliva suggests that we should have an option to hardcode
|
|
paths into libraries, as well as binaries: `... -Wl,-soname
|
|
-Wl,/tmp/libtest.so.0 ...'. Tim Mooney wants the same thing.
|
|
|
|
* Lists of exported symbols should be stored in the pseudo library
|
|
so that the size of lt_preloaded_symbols can be reduced.
|
|
|
|
* Documentation:
|
|
|
|
- AC_PROG_LIBTOOL, AC_ENABLE/DISABLE_SHARED/STATIC/FAST_INSTALL,
|
|
AC_LIBTOOL_DLOPEN, AC_LIBLTDL_CONVENIENCE/INSTALLABLE are not documented
|
|
|
|
- Purpose and usage of convenience libraries must be better documented
|
|
|
|
- some new internal variables are not documented yet.
|
|
|
|
In the future:
|
|
**************
|
|
|
|
* 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.
|
|
|
|
* Fix */demo on win32.
|
|
This may simply require resolving the item below.
|
|
|
|
* 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.
|
|
|
|
* 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.
|
|
|
|
People who need it:
|
|
Jean Daniel Fekete <Jean-Daniel.Fekete@emn.fr>
|
|
Thomas Hiller <hiller@tu-harburg.d400.de>
|
|
|
|
* Another form of convenience library, suggested by Alexandre Oliva,
|
|
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.
|
|
|
|
* Need to finalize the documentation, and give a specification of
|
|
`.la' files so that people can depend on their format. This also
|
|
needs to be done so that DLD uses a public interface to libtool
|
|
archives. This would be a good thing to put before the maintainance
|
|
notes.
|
|
|
|
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.
|