1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
|
GNU Libtool
***********
1. In the near future
=====================
1.1. libtool
------------
* Rather than looking up the linker's hardcode characteristics in a
table of shell code, use objdump or equivalent to probe a test program
at configure time.
* Eliminate the warnings from autoconf -Wobsolete.
* Hook the various language dependencies into the autoconf _AC_LANG
framework.
* We could have an option to hardcode paths into libraries, as well as
binaries: `... -Wl,-soname -Wl,/tmp/libtest.so.0 ...'. This is not
possible on all platforms, and is in part obviated by the ability of
linking libtool libraries specified with -lname, but it might still
be desirable.
* Lists of exported symbols should be stored in the pseudo library
so that the size of lt_preloaded_symbols can be reduced.
* Have some option to tell libtool not to include -L flags that point
into a certain tree in the dependence list of an installed library.
For example: -L-$top_builddir would let one link with libtool
libraries in sibling subdirectories within a project, using the -L
notation, without getting builddir pathnames ever mentioned in .la
files that get installed.
* Eric Lemings <elemings@cyberia.lemings.com> writes:
Because of a growing number of config scripts for packages in GNOME 1.2
(e.g. glib-config, xml-config, orbit-config. etc), development of GNOME
2.0 spawned a separate tool called pkg-config that allows all packages
to use one tool rather than several different scripts to query compile
flags, link flags, and other configuration data.
The functionality of pkg-config seems to me to have a lot of overlap
with the goals of libtool. I was wondering if anyone had considered
adding an eighth mode to libtool that just queries the installed
library for the same information that pkg-config provides. Since
most packages that use pkg-config also use libtool, I think this
would be a good way to reduce maintainer and developer dependencies.
1.2. libtldl
------------
* Fix the following bugs in libltdl:
- error reporting of tryall_dlopen():
if the file actually doesn't exist (stat() fails or it wasn't dlpreopened)
-> report `file not found'
if it cannot be loaded (e.g. due to missing dependencies)
-> report dlerror
open question: which error should be reported if all dlloaders fail
or if a specific module type can only be loaded by one of them, how report its dlerror?
Also report dlerror() for dlclose and dlsym if available
- Make sure that the dependency_libs of a dlpreopened module won't be loaded.
2. In the future
================
2.1. Documentation
------------------
* Need to finalize the documentation, and give a specification of
`.la' files so that people can depend on their format. This would be
a good thing to put before the maintainance notes.
2.2. test suite
---------------
* Rewrite the whole thing in Autotest. This will enable us to remove
all the tests/*demo noise, and duplication; and thus speed up bootstrap
and make writing new tests a whole lot more pleasant.
* We should include tests with convenience libraries and reloadable
objects in the testsuite.
* Write a test case for linkage with gnu ld scripts (per 2004-08-25 patch
from Paolo Bonzini).
2.3. libtool
------------
* If not cross-compiling, have the static flag test run the resulting
binary to make sure everything works.
* Another form of convenience library 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. We could also explicitly support `empty'
convenience libraries, that behave as macros that expand to a set of
-Rs, -Ls and -ls switches.
* Filenames containing shell meta-characters are not properly handled
by libtool. Compiling a file named "a;b.c", for example, fails.
* We could introduce a mechanism to allow for soname rewriting, to
ease multi-libc support. Installers could specify a prefix, suffix or
sed command to modify the soname, and libtool would create the
corresponding link. This would allow for rebuilding a library with
the same version number, but depending on different versions of libc,
for example. In the future, we might even have an option to encode
the sonames of all dependencies of a library into its soname.
2.4. libtool autoconf macros
----------------------------
* The definitions for AC_LTDL_SHLIBEXT, AC_LTDL_SHLIBPATH and
AC_LTDL_SYSSEARCHPATH should not rely on the _LT_AC_LTCONFIG_HACK
macro. This involves moving the code which sets the variables
library_names_spec, shlibpath_var and sys_lib_dlsearch_path_spec from
into a separate macro, and AC_REQUIRING the newly extracted macro in the
respective ltdl.m4 macros.
2.5. libltdl
------------
* Try to find a work-around for -[all-]static and libltdl on platforms
that will fail to find dlopening functions in this case. Maybe
creating an alternate libltdl that provides only for dlpreopening, or
creating an additional static library to provide dummy implementations
of the functions that can't be linked statically. This could hardly
be made completely transparent, though.
* 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.
2.6. win32 support
------------------
* Arrange that EXEEXT suffixes are stripped from wrapper script names
only when needed, and that a timestamp file or a wrapper program is
created with the EXEEXT suffix, so that `make' doesn't build it every
time.
* 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.
* jeffdb@goodnet.com writes:
all you need to do for mutually dependent .dll's is to create an implib from
a .def file so it appears that we might need to detect and handle mutual
dependencies specially on win32 =(O|
3. Wish List
============
* Maybe implement full support for other orthogonal library types
(libhello_g, libhello_p, 64 vs 32-bit ABI's, etc). Make these types
configurable.
* Perhaps the iuse of libltdl could be made cleaner by allowing
registration of hook functions to call at various points. This would
hopefully free the user from having to maintain a parallel module
list with user data. This would likely involve being able to carry
additional per user module data in the lt_dlmodule structure -- perhaps
in the form of an associative array keyed by user name?
--
Copyright (C) 2004 Free Software Foundation, Inc.
The canonical source of this file is maintained with the
GNU Libtool package. Report bugs to bug-libtool@gnu.org.
GNU Libtool is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
As a special exception to the GNU General Public License,
if you distribute this file as part of a program or library that
is built using GNU libtool, you may include it under the same
distribution terms that you use for the rest of that program.
GNU Libtool is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Libtool; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA
Local Variables:
mode: text
fill-column: 72
End:
|
