libtool/TODO
Thomas Tanner e65f46d3fc * use the same header in all configure.in's and Makefile.am's
* NEWS: improved support for BeOS and Cygwin
* TODO: ILD branch was merged, all internal variables and macros
  are now documented
* demo/Makefile.am: use $(LIBS) instead of -lm
* doc/libtool.texi: documented new variable hardcode_into_libs
  and thread_safe_flag_spec, renamed all AM_ENABLE/DISABLE_* macros
  to AC_*, documented AC_DISABLE_FAST_INSTALL and AC_LIBTOOL_DLOPEN
* libltdl/ltdl.c: added two new error messages (cannot_open_error,
  cannot_close_error), use them where approriate,
  BeOS support (thanks to Xavier Pianet), on BeOS search modules
  additionally in ADDON_PATH
* libtool.m4: rewrote AC_CHECK_LIBM: BeOS and Cygwin don't have
  libm and *-ncr-sysv4.3* requires libmw
* ltconfig.in: don't check for LoadLibrary, hardcode dlopen
  configuration for BeOS and Cygwin
* ltmain.in: fix sourcing of .la files on Solaris
  (patch by Raja R Harinath)
1999-03-20 00:27:33 +00:00

95 lines
3.9 KiB
Plaintext

For next public release:
************************
* check whether the version of libtool.m4 is compatible
with ltconfig/ltmain.sh
* 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.
* Purpose and usage of convenience libraries must be better documented
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.