10 * Rather than looking up the linker's hardcode characteristics in a
11 table of shell code, use objdump or equivalent to probe a test program
14 * Eliminate the warnings from autoconf -Wobsolete.
16 * Hook the various language dependencies into the autoconf _AC_LANG
19 * Work out what to do when the dynamic linker loads needed dependencies.
21 * We could have an option to hardcode paths into libraries, as well as
22 binaries: `... -Wl,-soname -Wl,/tmp/libtest.so.0 ...'. This is not
23 possible on all platforms, and is in part obviated by the ability of
24 linking libtool libraries specified with -lname, but it might still
27 * Lists of exported symbols should be stored in the pseudo library
28 so that the size of lt_preloaded_symbols can be reduced.
30 * Have some option to tell libtool not to include -L flags that point
31 into a certain tree in the dependence list of an installed library.
32 For example: -L-$top_builddir would let one link with libtool
33 libraries in sibling subdirectories within a project, using the -L
34 notation, without getting builddir pathnames ever mentioned in .la
35 files that get installed.
37 * Eric Lemings <elemings@cyberia.lemings.com> writes:
38 Because of a growing number of config scripts for packages in GNOME 1.2
39 (e.g. glib-config, xml-config, orbit-config. etc), development of GNOME
40 2.0 spawned a separate tool called pkg-config that allows all packages
41 to use one tool rather than several different scripts to query compile
42 flags, link flags, and other configuration data.
44 The functionality of pkg-config seems to me to have a lot of overlap
45 with the goals of libtool. I was wondering if anyone had considered
46 adding an eighth mode to libtool that just queries the installed
47 library for the same information that pkg-config provides. Since
48 most packages that use pkg-config also use libtool, I think this
49 would be a good way to reduce maintainer and developer dependencies.
51 * Have libtoolize install `install-sh' if a newer version is available,
52 and/or Automake is not used.
54 * Allow to specify linking some dependent libraries statically and some
55 dynamically, where possible.
57 * Improve support for C++ with templates.
59 * Audit file listing in libtool.m4.
61 * Fix deplibs_check_method=pass_all (which is wrong!) on linux.
63 * Fix -dlopen "self" on AIX. Reported by Gary Kumfert <kumfert@llnl.gov>.
65 * Audit AU_DEFUNs whether they need to be AU_ALIASes.
66 Reported by Akim Demaille <akim.demaille@free.fr>
68 * Fix wrong $ECHO after `config.status --recheck'.
69 Reported by Ralf Menzel <menzel@ls6.cs.uni-dortmund.de> and
70 Jeff Squyres <jsquyres@lam-mpi.org>.
72 * Fix denial of service if using installed `libtool' on a different mount point
73 together with a compiler which does not understand `-c -o'.
74 Reported by Marcin Siennicki.
76 * Fix -no-undefined with Solaris CC,f77. Maybe look at implementing something
77 along the idea of [support #103719] for CC.
78 Reported by Ralf Menzel <menzel@ls6.cs.uni-dortmund.de>,
79 Пухальский Юрий Андреевич <pooh@cryptopro.ru>,
80 Albert Chin <libtool-patches@mlists.thewrittenword.com> and others.
86 * Change libltdl interface: add separate functions for function
87 pointers. This will allow porting to systems where function pointers
88 are incompatible with data pointer C-wise.
90 * Fix the following bugs in libltdl:
91 - error reporting of tryall_dlopen():
92 if the file actually doesn't exist (stat() fails or it wasn't dlpreopened)
93 -> report `file not found'
94 if it cannot be loaded (e.g. due to missing dependencies)
96 open question: which error should be reported if all dlloaders fail
97 or if a specific module type can only be loaded by one of them, how report its dlerror?
98 Also report dlerror() for dlclose and dlsym if available
99 - Make sure that the dependency_libs of a dlpreopened module won't be loaded.
101 - Fix mdemo failures on mingw.
103 - Fix the last memleak. Reported by Jeff Squyres <jsquyres@lam-mpi.org>.
105 - Fix LTDL_CONVENIENCE. Reported by Bob Friesenhahn
106 and Patrick Welche <prlw1@newn.cam.ac.uk>.
112 * Rewrite the func_copy_* functions so that instead of forking 2 tar
113 processes per copied file, a list of files to copy is built and all
114 files copied with a single pair of tar processes.
123 * Need to finalize the documentation, and give a specification of
124 `.la' files so that people can depend on their format. This would be
125 a good thing to put before the maintainance notes.
127 * Document the installed `libtool' and its limitations clearly (maybe implement
128 --disable-script-install as well). Or, even better, remove its limitations.
130 * Platform notes redo.
135 * Rewrite the whole thing in Autotest. This will enable us to remove
136 all the tests/*demo noise, and duplication; and thus speed up bootstrap
137 and make writing new tests a whole lot more pleasant.
139 * We should include tests with convenience libraries and reloadable
140 objects in the testsuite.
142 * Write a test case for linkage with gnu ld scripts (per 2004-08-25 patch
148 - multiple input files
153 * Fix cross-compiling.
157 * Support multilibbing.
159 * If not cross-compiling, have the static flag test run the resulting
160 binary to make sure everything works.
162 * Another form of convenience library is to have undocumented utility
163 libraries, where only the shared version is installed.
165 * We could use libtool object convenience libraries that resolve
166 symbols to be included in a libtool archive. This would require some
167 sort of -whole-archive option, as well.
169 * Currently, convenience libraries (.al) are built from .lo objects,
170 except when --disable-shared. When we can build both shared and
171 static libraries, we should probably create a .al out of .lo objects
172 and also a .a out of .o objects. The .al would only be used to create
173 shared libraries, whereas the .a would be used for creating static
174 libraries and programs. We could also explicitly support `empty'
175 convenience libraries, that behave as macros that expand to a set of
176 -Rs, -Ls and -ls switches.
178 * Audit use of object names so we can allow `$' not only within
179 source file names. Necessary especially for java.
181 * We could introduce a mechanism to allow for soname rewriting, to
182 ease multi-libc support. Installers could specify a prefix, suffix or
183 sed command to modify the soname, and libtool would create the
184 corresponding link. This would allow for rebuilding a library with
185 the same version number, but depending on different versions of libc,
186 for example. In the future, we might even have an option to encode
187 the sonames of all dependencies of a library into its soname.
189 * Look again at a binary C libtool, or byte-compiled libtool to improve
192 * Generate some "platform specific" shell functions with config.status,
193 for example, there is no need to have the C source code for the
194 wrapper script on non-windows platforms, this will make the generated
195 libtool script smaller and easier to follow, maybe a little faster
198 * Look at position-independent executables.
200 * Add support for a FC tag.
202 * Audit the GCJ tag section in libtool.m4.
204 * Add caching mechanism. Look at `libtool-cache' from Robert Ögren.
207 2.4. libtool autoconf macros
208 ----------------------------
210 * Sort out the macro mess in libtool.m4. We've started this already
211 by refactoring chunks into separate files, but I never did completely
212 untangle the mess of macros imported from ltconfig.
214 * The definitions for LT_SYS_MODULE_EXT, LT_SYS_MODULE_PATH and
215 LT_SYS_DLSEARCH_PATH should not rely on the _LT_SYS_DYNAMIC_LINKER
216 macro. This involves moving the code which sets the variables
217 library_names_spec, shlibpath_var and sys_lib_dlsearch_path_spec from
218 into a separate macro, and AC_REQUIRING the newly extracted macro in the
219 respective ltdl.m4 macros.
221 2.5. libtool automake integration
222 ---------------------------------
224 * Unify locks between libtool and compile.
231 * Finish the rewrite of the core libltdl. The loaders are fine, and
232 the outlying code is now good. Ralf is starting to pick away at a lot
233 of the remaining nasties already, but the code for finding .la/.so files
234 and reading/loading them could use a lot more improvement.
236 * I think we could factor out a little path management support module
237 from existing libltdl. This would be useful for M4 at least -- keeping
238 track of FOO_PATH environment contents, searching for files in paths
241 * Try to find a work-around for -[all-]static and libltdl on platforms
242 that will fail to find dlopening functions in this case. Maybe
243 creating an alternate libltdl that provides only for dlpreopening, or
244 creating an additional static library to provide dummy implementations
245 of the functions that can't be linked statically. This could hardly
246 be made completely transparent, though.
248 * In conjunction with above, fix the failures on *BSD when linked to
249 static libc. Reported by Guilhem Lavaux <guilhem@kaffe.org>.
251 * Add i18n strings to libltdl, ensuring that package developers can
252 ignore any i18n when they libtoolize.
257 * Arrange that EXEEXT suffixes are stripped from wrapper script names
258 only when needed, and that a timestamp file or a wrapper program is
259 created with the EXEEXT suffix, so that `make' doesn't build it every
262 * Figure out how to use data items in dlls with win32.
263 The difficult part is compiling each object which will be linked with an
264 import lib differently than if it will be linked with a static lib. This
265 will almost definitely require that automake pass some hints about linkage
266 in to each object compilation line.
268 * jeffdb@goodnet.com writes:
269 all you need to do for mutually dependent .dll's is to create an implib from
270 a .def file so it appears that we might need to detect and handle mutual
271 dependencies specially on win32 =(O|
277 * Maybe implement full support for other orthogonal library types
278 (libhello_g, libhello_p, 64 vs 32-bit ABI's, etc). Make these types
281 * Perhaps the iuse of libltdl could be made cleaner by allowing
282 registration of hook functions to call at various points. This would
283 hopefully free the user from having to maintain a parallel module
284 list with user data. This would likely involve being able to carry
285 additional per user module data in the lt_dlmodule structure -- perhaps
286 in the form of an associative array keyed by user name?
288 * Figure out how to make pkg-config aware of the information libtool
289 knows about libraries and their dependencies, and send a patch.
291 * Generate a libtool.m4 from a bunch of individual files, one per
292 platform, to make the job of a "platform maintainer" easier and make
293 it easier to add new platforms.
296 Copyright (C) 2004, 2005 Free Software Foundation, Inc.
298 The canonical source of this file is maintained with the
299 GNU Libtool package. Report bugs to bug-libtool@gnu.org.
301 GNU Libtool is free software; you can redistribute it and/or
302 modify it under the terms of the GNU General Public License as
303 published by the Free Software Foundation; either version 2
304 of the License, or (at your option) any later version.
306 As a special exception to the GNU General Public License,
307 if you distribute this file as part of a program or library that
308 is built using GNU libtool, you may include it under the same
309 distribution terms that you use for the rest of that program.
311 GNU Libtool is distributed in the hope that it will be useful,
312 but WITHOUT ANY WARRANTY; without even the implied warranty of
313 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
314 General Public License for more details.
316 You should have received a copy of the GNU General Public License
317 along with GNU Libtool; if not, write to the Free Software
318 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA