TODO

   1 In the near future:
   2 ********************
   3
   4 * Port the migration of all code from ltconfig into libtool.m4 to the
   5 multi-language-branch, so that CVS automake can remove its references
   6 to ltconfig.
   7
   8 * Fix the following bugs in libltdl:
   9  - error reporting of tryall_dlopen():
  10    if the file actually doesn't exist (stat() fails or it wasn't dlpreopened)
  11    -> report `file not found'
  12    if it cannot be loaded (e.g. due to missing dependencies)
  13    -> report dlerror
  14     open question: which error should be reported if all dlloaders fail
  15     or if a specific module type can only be loaded by one of them, how report its dlerror?
  16    Also report dlerror() for dlclose and dlsym if available
  17  - Make sure that the dependency_libs of a dlpreopened module won't be loaded.
  18
  19 * We could have an option to hardcode paths into libraries, as well as
  20 binaries: `... -Wl,-soname -Wl,/tmp/libtest.so.0 ...'.  This is not
  21 possible on all platforms, and is in part obviated by the ability of
  22 linking libtool libraries specified with -lname, but it might still
  23 be desirable.
  24
  25 * Lists of exported symbols should be stored in the pseudo library
  26 so that the size of lt_preloaded_symbols can be reduced.
  27
  28 * Have some option to tell libtool not to include -L flags that point
  29 into a certain tree in the dependence list of an installed library.
  30 For example: -L-$top_builddir would let one link with libtool
  31 libraries in sibling subdirectories within a project, using the -L
  32 notation, without getting builddir pathnames ever mentioned in .la
  33 files that get installed.
  34
  35 * Eric Lemings <elemings@cyberia.lemings.com> writes:
  36   Because of a growing number of config scripts for packages in GNOME 1.2
  37   (e.g. glib-config, xml-config, orbit-config. etc), development of GNOME
  38   2.0 spawned a separate tool called pkg-config that allows all packages
  39   to use one tool rather than several different scripts to query compile
  40   flags, link flags, and other configuration data.
  41
  42   The functionality of pkg-config seems to me to have a lot of overlap
  43   with the goals of libtool.  I was wondering if anyone had considered
  44   adding an eighth mode to libtool that just queries the installed
  45   library for the same information that pkg-config provides.  Since
  46   most packages that use pkg-config also use libtool, I think this
  47   would be a good way to reduce maintainer and developer dependencies.
  48
  49
  50 In the future:
  51 **************
  52
  53 * The definitions for AC_LTDL_SHLIBEXT, AC_LTDL_SHLIBPATH and
  54 AC_LTDL_SYSSEARCHPATH  should not rely on the _LT_AC_LTCONFIG_HACK
  55 macro.  This involves moving the code which sets the variables
  56 library_names_spec, shlibpath_var and sys_lib_dlsearch_path_spec from
  57 into a separate macro, and AC_REQUIRING the newly extracted macro in the
  58 respective ltdl.m4 macros.
  59
  60 * Godmar Back writes:
  61   libltdl uses such stdio functions as fopen, fgets, feof, fclose, and others.
  62   These functions are not async-signal-safe. While this does not make
  63   libltdl unusable, it restricts its usefulness and puts an
  64   unnecessary burden on the user.
  65
  66   As a remedy, I'd recommend to replace those functions with functions
  67   that POSIX says are async-signal-safe, such as open, read, close.
  68   This will require you to handle interrupted system calls and implement
  69   fgets, but the former isn't hard and there's plenty of implementations
  70   out from which you can steal the latter.
  71
  72   I believe relying on async-signal-safe functions to the greatest extent
  73   possible would greatly improve libltdl's ability to be embedded in and
  74   used by other systems.
  75
  76 * Arrange that EXEEXT suffixes are stripped from wrapper script names
  77 only when needed, and that a timestamp file or a wrapper program is
  78 created with the EXEEXT suffix, so that `make' doesn't build it every
  79 time.
  80
  81 * Figure out how to use data items in dlls with win32.
  82 The difficult part is compiling each object which will be linked with an
  83 import lib differently than if it will be linked with a static lib.  This will
  84 almost definitely require that automake pass some hints about linkage in to
  85 each object compilation line.
  86
  87 * jeffdb@goodnet.com writes
  88         all you need to do for mutually dependent
  89         .dll's is to create an implib from a .def file
  90 so it appears that we might need to detect and handle mutual dependencies
  91 specially on win32 =(O|
  92
  93 * If not cross-compiling, have the static flag test run the resulting
  94 binary to make sure everything works.
  95
  96 * Implement full multi-language support.  Currently, this is only for
  97 C++, but there are beginnings of this in the manual (Other Languages).
  98 This includes writing libtool not to be so dependent on the compiler
  99 used to configure it.
 100
 101 We especially need this for C++ linking, for which libtool currently
 102 does not handle static constructors properly, even on operating
 103 systems that support them.  ``Don't use static constructors'' is no
 104 longer a satisfactory answer.
 105
 106 * Another form of convenience library is to have undocumented utility
 107 libraries, where only the shared version is installed.
 108
 109 * We could use libtool object convenience libraries that resolve
 110 symbols to be included in a libtool archive.  This would require some
 111 sort of -whole-archive option, as well.
 112
 113 * Currently, convenience libraries (.al) are built from .lo objects,
 114 except when --disable-shared.  When we can build both shared and
 115 static libraries, we should probably create a .al out of .lo objects
 116 and also a .a out of .o objects.  The .al would only be used to create
 117 shared libraries, whereas the .a would be used for creating static
 118 libraries and programs.  We could also explicitly support `empty'
 119 convenience libraries, that behave as macros that expand to a set of
 120 -Rs, -Ls and -ls switches.
 121
 122 * We should include tests with convenience libraries and reloadable
 123 objects in the testsuite.
 124
 125 * Try to find a work-around for -[all-]static and libltdl on platforms
 126 that will fail to find dlopening functions in this case.  Maybe
 127 creating an alternate libltdl that provides only for dlpreopening, or
 128 creating an additional static library to provide dummy implementations
 129 of the functions that can't be linked statically.  This could hardly
 130 be made completely transparent, though.
 131
 132 * Need to finalize the documentation, and give a specification of
 133 `.la' files so that people can depend on their format.  This would be
 134 a good thing to put before the maintainance notes.
 135
 136 * Filenames containing shell meta-characters are not properly handled
 137 by libtool.  Compiling a file named "a;b.c", for example, fails.
 138
 139 * We could introduce a mechanism to allow for soname rewriting, to
 140 ease multi-libc support.  Installers could specify a prefix, suffix or
 141 sed command to modify the soname, and libtool would create the
 142 corresponding link.  This would allow for rebuilding a library with
 143 the same version number, but depending on different versions of libc,
 144 for example.  In the future, we might even have an option to encode
 145 the sonames of all dependencies of a library into its soname.
 146
 147 * The current implementation of libltdl in a subdirectory doesn't work
 148 properly with AC_CONFIG_AUX_DIR using projects.
 149
 150 Things to think about:
 151 **********************
 152
 153 * Maybe implement full support for other orthogonal library types
 154 (libhello_g, libhello_p, 64 vs 32-bit ABI's, etc).  Make these types
 155 configurable.
 156
 157 * Perhaps the iuse of libltdl could be made cleaner by allowing
 158 registration of hook functions to call at various points.  This would
 159 hopefully free the user from having to maintain a parallel module
 160 list with user data.  This would likely involve being able to carry
 161 additional per user module data in the lt_dlmodule structure -- perhaps
 162 in the form of an associative array keyed by user name?