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 GNU/Linux.
63 * Fix -dlopen "self" on AIX. Reported by Gary Kumfert <kumfert@llnl.gov>.
65 * Fix denial of service if using installed 'libtool' on a different mount point
66 together with a compiler that does not understand '-c -o'.
67 Reported by Marcin Siennicki.
69 * Look at better -no-undefined support, maybe along the idea of
70 [support #103719] for CC.
76 * Change libltdl interface: add separate functions for function
77 pointers. This will allow porting to systems where function pointers
78 are incompatible with data pointer C-wise.
80 * Fix the following bugs in libltdl:
81 - error reporting of tryall_dlopen():
82 if the file actually doesn't exist (stat() fails or it wasn't dlpreopened)
83 -> report 'file not found'
84 if it cannot be loaded (e.g. due to missing dependencies)
86 open question: what error should be reported if all dlloaders fail
87 or if a specific module type can only be loaded by one of them, how report its dlerror?
88 Also report dlerror() for dlclose and dlsym if available
89 - Make sure that the dependency_libs of a dlpreopened module won't be loaded.
91 - Fix mdemo failures on mingw.
93 - Fix the last memleak. Reported by Jeff Squyres <jsquyres@lam-mpi.org>.
95 - Fix LTDL_CONVENIENCE. Reported by Bob Friesenhahn
96 and Patrick Welche <prlw1@newn.cam.ac.uk>.
102 * Rewrite the func_copy_* functions so that instead of forking 2 tar
103 processes per copied file, a list of files to copy is built and all
104 files copied with a single pair of tar processes.
106 * Write test case that adds libtool macros to aclocal.m4.
115 * Need to finalize the documentation, and give a specification of
116 '.la' files so that people can depend on their format. This would be
117 a good thing to put before the maintenance notes.
119 * Document the installed 'libtool' and its limitations clearly (maybe implement
120 --disable-script-install as well). Or, even better, remove its limitations.
122 * Platform notes redo.
127 * We should include tests with reloadable objects in the testsuite.
129 * Write a test case for linkage with gnu ld scripts (per 2004-08-25 patch
135 - multiple input files
140 * Fix cross-compiling.
144 * Support multilibbing.
146 * If not cross-compiling, have the static flag test run the resulting
147 binary to make sure everything works.
149 * Another form of convenience library is to have undocumented utility
150 libraries, where only the shared version is installed.
152 * We could use libtool object convenience libraries that resolve
153 symbols to be included in a libtool archive. This would require some
154 sort of -whole-archive option, as well.
156 * Currently, convenience libraries (.al) are built from .lo objects,
157 except when --disable-shared. When we can build both shared and
158 static libraries, we should probably create a .al out of .lo objects
159 and also a .a out of .o objects. The .al would only be used to create
160 shared libraries, whereas the .a would be used for creating static
161 libraries and programs. We could also explicitly support 'empty'
162 convenience libraries, that behave as macros that expand to a set of
163 -Rs, -Ls and -ls switches.
165 * Audit use of object names so we can allow '$' not only within
166 source file names. Necessary especially for java.
168 * We could introduce a mechanism to allow for soname rewriting, to
169 ease multi-libc support. Installers could specify a prefix, suffix or
170 sed command to modify the soname, and libtool would create the
171 corresponding link. This would allow for rebuilding a library with
172 the same version number, but depending on different versions of libc,
173 for example. In the future, we might even have an option to encode
174 the sonames of all dependencies of a library into its soname.
176 * Look again at a binary C libtool, or byte-compiled libtool to improve
179 * Generate some "platform specific" shell functions with config.status,
180 for example, there is no need to have the C source code for the
181 wrapper script on non-windows platforms, this will make the generated
182 libtool script smaller and easier to follow, maybe a little faster
185 * Audit the GCJ tag section in libtool.m4.
187 * Add caching mechanism. Look at 'libtool-cache' from Robert Ă–gren.
190 2.4. libtool autoconf macros
191 ----------------------------
193 * Sort out the macro mess in libtool.m4. We've started this already
194 by refactoring chunks into separate files, but I never did completely
195 untangle the mess of macros imported from ltconfig.
197 * The definitions for LT_SYS_MODULE_EXT, LT_SYS_MODULE_PATH and
198 LT_SYS_DLSEARCH_PATH should not rely on the _LT_SYS_DYNAMIC_LINKER
199 macro. This involves moving the code that sets the variables
200 library_names_spec, shlibpath_var and sys_lib_dlsearch_path_spec from
201 into a separate macro, and AC_REQUIRING the newly extracted macro in the
202 respective ltdl.m4 macros.
204 2.5. libtool automake integration
205 ---------------------------------
207 * Unify locks between libtool and compile.
214 * Finish the rewrite of the core libltdl. The loaders are fine, and
215 the outlying code is now good. Ralf is starting to pick away at a lot
216 of the remaining nasties already, but the code for finding .la/.so files
217 and reading/loading them could use a lot more improvement.
219 * I think we could factor out a little path management support module
220 from existing libltdl. This would be useful for M4 at least -- keeping
221 track of FOO_PATH environment contents, searching for files in paths
224 * Try to find a work-around for -[all-]static and libltdl on platforms
225 that will fail to find dlopening functions in this case. Maybe
226 creating an alternate libltdl that provides only for dlpreopening, or
227 creating an additional static library to provide dummy implementations
228 of the functions that can't be linked statically. This could hardly
229 be made completely transparent, though.
231 * In conjunction with above, fix the failures on *BSD when linked to
232 static libc. Reported by Guilhem Lavaux <guilhem@kaffe.org>.
234 * Add i18n strings to libltdl, ensuring that package developers can
235 ignore any i18n when they libtoolize.
240 * Arrange that EXEEXT suffixes are stripped from wrapper script names
241 only when needed, and that a timestamp file or a wrapper program is
242 created with the EXEEXT suffix, so that 'make' doesn't build it every
245 * Figure out how to use data items in dlls with win32.
246 The difficult part is compiling each object that will be linked with an
247 import lib differently than if it will be linked with a static lib. This
248 will almost definitely require that automake pass some hints about linkage
249 in to each object compilation line.
251 * jeffdb@goodnet.com writes:
252 all you need to do for mutually dependent .dll's is to create an implib from
253 a .def file so it appears that we might need to detect and handle mutual
254 dependencies specially on win32 =(O|
256 * QoI for file name and path conversion functions. Currently, these are
257 implemented as MxN different functions; this has quadratic complexity. If
258 possible, it would be preferred to implement then as M+N functions. However:
259 http://lists.gnu.org/archive/html/libtool-patches/2010-08/msg00224.html
260 The main issue is you don't know what the "native" (e.g. "central")
261 path-type is; e.g. "from-X (to what?)" and "(from what?) to-Y". Right
262 now there are only four "platforms" involved: *nix, mingw, msys, and
263 cygwin. That's actually the break-even point, given the vagaries and
264 optimizations involved in these particular four platforms.
266 We have exactly five basic file name conversion functions (not counting
267 the wrappers that handle paths). For a non-quadratic M+N (from-X|to-Y)
268 solution, we'd need, I think, the same number of conversion functions: brute
269 force suggests nine (four to_*, four from_*, plus the noop), but then many
270 of the from_* and to_* would actually BE noop.
272 I'm assuming here that the "central" path-type is implicitly some sort of
273 unixish -- maybe cyg, maybe msys, maybe unix -- path-type. The issue is
274 that each of the five conversion functions use a different TOOL to perform
275 the conversion, with different syntax. So, trying to combine, e.g.
279 into an all-encompassing "central_unixish_to_mingw" would require additional
280 m4 magic to basically replace the guts depending on whether $build was msys,
281 cygwin, or unix. Worse, you can't really do a set of
282 {msys|cygwin|unix}_to_central_unixish that isn't simply a no-op -- because
283 (A) they already are all unixish, and (B) what tool would you use? How would
284 the later to_mingw function "know" how to convert this new representation to
285 mingw. So, {msys|cygwin|unix}_to_central_unixish would simply be a no-op
286 and central_unixish_to_mingw would still do all the work (with its guts
287 customized based on $build).
289 For more reasonable cross environments (e.g. linux-gnu->some_embedded) I
290 think you could probably work out a general M+N scheme, since most embedded
291 $hosts aren't as strange as the win32 variants -- even VxWorks and INTEGRITY
292 have basic, unix-like file systems (although INTEGRITY does have multiple
293 roots). Aggressive use of the m4 function_replace machinery WOULD be
294 appropriate for /these/ conversion functions. OTOH...(a) you can't run the
295 $host apps on $build anyway, in these embedded situations. At best you'd use
296 $TARGETSHELL and "run" them via a remote connection, and (b) they don't use
299 So...I don't think it makes much difference *right now* in the amount of
300 code required, or the number of functions implemented. At some point in the
301 future we might want to generalize to an M+N scheme. For the existing win32
302 $hosts, all of the functionality would be on "one side" of the 2-step
303 conversion; the "other side" would be noop. But we won't worry about the
304 implicit quadratic complexity of the existing scheme for now.
309 * Maybe implement full support for other orthogonal library types
310 (libhello_g, libhello_p, 64 vs 32-bit ABI's, etc). Make these types
313 * Perhaps the use of libltdl could be made cleaner by allowing
314 registration of hook functions to call at various points. This would
315 hopefully free the user from having to maintain a parallel module
316 list with user data. This would likely involve being able to carry
317 additional per user module data in the lt_dlmodule structure -- perhaps
318 in the form of an associative array keyed by user name?
320 * Figure out how to make pkg-config aware of the information libtool
321 knows about libraries and their dependencies, and send a patch.
323 * Generate a libtool.m4 from a bunch of individual files, one per
324 platform, to make the job of a "platform maintainer" easier and make
325 it easier to add new platforms.
328 Copyright (C) 2004-2005, 2007-2008, 2011-2019, 2021-2024 Free Software
330 Written by Gary V. Vaughan, 2004
332 This file is part of GNU Libtool.
334 Copying and distribution of this file, with or without modification,
335 are permitted in any medium without royalty provided the copyright
336 notice and this notice are preserved. This file is offered as-is,
337 without warranty of any kind.