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