1 |
gary |
1.1 |
GNU Libtool |
2 |
|
|
*********** |
3 |
|
|
|
4 |
|
|
1. Introduction |
5 |
|
|
=============== |
6 |
|
|
|
7 |
|
|
This file attempts to describe the processes we use to maintain libtool, |
8 |
|
|
and is not part of a release distribution. |
9 |
|
|
|
10 |
|
|
2. Maintenance Notes |
11 |
|
|
==================== |
12 |
|
|
|
13 |
|
|
* If you incorporate a change from somebody on the net: |
14 |
|
|
If it is a large change, you must make sure they have signed the |
15 |
|
|
appropriate paperwork, and be sure to add their name and email |
16 |
|
|
address to THANKS |
17 |
|
|
|
18 |
|
|
* If a change fixes a test, mention the test in the ChangeLog entry. |
19 |
|
|
|
20 |
|
|
* If somebody reports a new bug, mention his name in the ChangeLog entry |
21 |
|
|
and in the test case you write. |
22 |
|
|
|
23 |
|
|
* The correct response to most actual bugs is to write a new test case |
24 |
|
|
which demonstrates the bug. Then fix the bug, re-run the test suite, |
25 |
|
|
and check everything in. |
26 |
|
|
|
27 |
|
|
* Some files in the libtool package are not owned by libtool. These |
28 |
|
|
files should never be edited here. These files are: |
29 |
|
|
COPYING |
30 |
|
|
INSTALL |
31 |
|
|
config/ |
32 |
|
|
+ config.guess |
33 |
|
|
+ config.sub |
34 |
|
|
+ depcomp |
35 |
|
|
+ install-sh |
36 |
|
|
+ mdate-sh |
37 |
|
|
+ missing |
38 |
|
|
+ texinfo.tex |
39 |
|
|
doc/ |
40 |
|
|
+ fdl.texi |
41 |
|
|
libltdl/ |
42 |
rwild |
1.9 |
+ COPYING.LIB |
43 |
gary |
1.1 |
The ones that are important for a release can be udated with, |
44 |
gary |
1.2 |
`make -fMakefile.maint fetch' (or `make -f../Makefile.maint fetch' |
45 |
|
|
if you are running from a VPATH build directory, where `../' is the |
46 |
|
|
relative path to the directory with `configure' in it). |
47 |
gary |
1.1 |
|
48 |
|
|
* Changes other than bug fixes must be mentioned in NEWS |
49 |
|
|
|
50 |
|
|
|
51 |
gary |
1.10 |
3. Test Suite |
52 |
gary |
1.1 |
============= |
53 |
|
|
|
54 |
|
|
* Use "make check" liberally, on as many platforms as you can. Use as |
55 |
|
|
many compilers and linkers you can. |
56 |
|
|
|
57 |
|
|
|
58 |
gary |
1.10 |
4. Naming |
59 |
gary |
1.1 |
========= |
60 |
|
|
|
61 |
|
|
* We've adopted the convention that exported Autoconf macros should be |
62 |
|
|
named with a leading `LT_' and be documented in the libtool manual. |
63 |
|
|
Internal macros begin with `_LT_' if they are visible to aclocal, or |
64 |
|
|
potentially part of an AC_DEFUN/AC_REQUIRE path, or else `_lt_' if |
65 |
|
|
they are very low level. This convention was only introduced just |
66 |
|
|
before libtool-2.0, so there may still be exceptions in the existing |
67 |
|
|
code. But all new code should use it. |
68 |
|
|
|
69 |
|
|
* All shell variables used internally by libtool's Autoconf macros |
70 |
|
|
should be named with the a leading `lt_' (not that they cannot clash |
71 |
|
|
with the `_lt_' macro namespace). |
72 |
|
|
|
73 |
|
|
|
74 |
gary |
1.10 |
5. Editing 'ChangeLog' |
75 |
|
|
====================== |
76 |
|
|
|
77 |
|
|
* When in doubt, check that emacs can syntax-color properly in |
78 |
|
|
change-log-mode. And preferably use emacs 'C-x 4 a' |
79 |
|
|
(add-change-log-entry-other-window) to open ChangeLog with an |
80 |
|
|
appropriate new template. |
81 |
|
|
|
82 |
|
|
* If this change is by a different author, or on a different date to the |
83 |
|
|
last entry start a new entry at the top of the file with the format |
84 |
|
|
(note two spaces between each field): |
85 |
|
|
|
86 |
|
|
yyyy-mm-dd Name of Author <email@address> |
87 |
|
|
|
88 |
gary |
1.11 |
* If more than one person collaborated on the change, additional |
89 |
|
|
authors can be listed on subsequent lines, thus: |
90 |
gary |
1.10 |
|
91 |
|
|
yyyy-mm-dd Name of Main Author <email@address>, |
92 |
|
|
Name of Contributor <another@email.address> |
93 |
|
|
|
94 |
gary |
1.11 |
* Where a change author did not supply a copyright assignment, but the |
95 |
|
|
changes they submitted were sufficiently trivial to commit in any case |
96 |
|
|
(see the GCS for guidelines on this), then flag this against their |
97 |
|
|
name in the header, thus: |
98 |
|
|
|
99 |
|
|
yyyy-mm-dd Name of Author <email@address> (tiny change) |
100 |
|
|
|
101 |
|
|
* In ChangeLog.2004 and earlier, 'Name of Author' was sometimes the name |
102 |
|
|
of the author of the ChangeLog when the person who made the change |
103 |
|
|
being documented didn't supply one. In that case separated from |
104 |
|
|
the previous field by a blank line and indented by 1 tab (note, only |
105 |
|
|
1 space between fields here) you will see: |
106 |
|
|
|
107 |
|
|
From Author of Actual Change <email@address>: |
108 |
|
|
|
109 |
|
|
As of now, don't do that anymore, since the GNU Coding Standards say |
110 |
|
|
that the author of the change must be credited in the main entry |
111 |
|
|
header for legal purposes. |
112 |
|
|
|
113 |
gary |
1.10 |
* Preferably the next part should be a description of the overall |
114 |
|
|
purpose of the change, separated from the header by a blank line, |
115 |
|
|
indented by 1 tab, and filled at column 72. The last character of the |
116 |
|
|
description should be a colon, :. |
117 |
|
|
|
118 |
|
|
* Changes to each file come next. Each new file starts on a new line, |
119 |
|
|
indented by 1 tab and starting with an asterisk and a space. Multiple |
120 |
|
|
files can be listed here relative to $top_srcdir, and comma separated. |
121 |
|
|
Names of functions (or sections as appropriate) to which the change |
122 |
|
|
applies should be named inside parentheses and comma separated. If |
123 |
|
|
this goes beyond column 72, then parens should be closed and re-opened |
124 |
|
|
on the next line: |
125 |
|
|
|
126 |
|
|
* file, another/file, test/testcases/foo.test (func_foo) |
127 |
|
|
(func_bar, func_baz): Description of changes. |
128 |
|
|
|
129 |
|
|
* If the change does not apply to particular functions (or sections), |
130 |
|
|
the section list can be omitted: |
131 |
|
|
|
132 |
|
|
* file, another/file, test/testcases/foo.test: General changes. |
133 |
|
|
|
134 |
|
|
* If the changes are particular to certain architectures, they should be |
135 |
|
|
listed after the functions in square brackets: |
136 |
|
|
|
137 |
|
|
* file, another/file (func_foo) [linux, solaris]: Description of |
138 |
|
|
changes. |
139 |
|
|
|
140 |
|
|
* Subsequent changes in other files that are related to the same overall |
141 |
|
|
enhancement or bugfix should be listed concurrently, without blank |
142 |
|
|
lines. Always start a fresh line for a new file: |
143 |
|
|
|
144 |
|
|
* file, another/file (func_foo) [linux, solaris]: Description of |
145 |
|
|
changes. |
146 |
|
|
* doc/foo.texi (Invoking Foo): Document. |
147 |
|
|
* NEWS: Updated. |
148 |
|
|
|
149 |
|
|
* If the change is in response to a problem reported by someone other |
150 |
|
|
than the author, then credit them at the end of the description with: |
151 |
|
|
|
152 |
|
|
Reported by Reporter Name <email@address>. |
153 |
|
|
|
154 |
|
|
* See the GNU Coding Standards document for more details on ChangeLog |
155 |
|
|
formatting. |
156 |
|
|
|
157 |
|
|
|
158 |
gary |
1.11 |
2005-01-08 Ralf Wildenhues <Ralf.Wildenhues@gmx.de> (tiny change), |
159 |
gary |
1.10 |
Peter O'Gorman <peter@pogma.com> |
160 |
|
|
|
161 |
|
|
This is the overall description of the purpose of this change |
162 |
|
|
and any useful background for a model ChangeLog entry: |
163 |
|
|
|
164 |
|
|
* HACKING: Updated copyright. This isn't attached to a |
165 |
|
|
particular section of the file, so it comes first. |
166 |
|
|
(Editing 'ChangeLog'): New section. This applies to the same |
167 |
|
|
file, but since it applies to a particular section it starts on |
168 |
|
|
a new line. |
169 |
|
|
(Introduction, Maintenance Notes, Test Suite, Naming) |
170 |
|
|
(Editing '.am' Files): If I had changed all these sections in |
171 |
|
|
the same way, I can list them like this, being careful to close |
172 |
|
|
and reopen the parentheses when starting a new line. The colon |
173 |
|
|
only comes after the last section before this description. |
174 |
|
|
* NEWS: Updated. |
175 |
|
|
Reported by Bob Friesenhahn <bfriesen@simple.dallas.tx.us>. |
176 |
|
|
|
177 |
|
|
|
178 |
|
|
6. Editing `.am' Files |
179 |
gary |
1.1 |
====================== |
180 |
|
|
|
181 |
|
|
* Always use $(...) and not ${...} |
182 |
|
|
|
183 |
|
|
* Use `:', not `true'. Use `exit 1', not `false'. |
184 |
|
|
|
185 |
|
|
* Use `##' comments liberally. Comment anything even remotely unusual. |
186 |
|
|
|
187 |
|
|
* Never use basename or dirname. Instead use sed. |
188 |
|
|
|
189 |
gary |
1.15 |
* Do not use `cd' within back-quotes, use `$(lt__cd)' instead. |
190 |
gary |
1.1 |
Otherwise the directory name may be printed, depending on CDPATH. |
191 |
|
|
|
192 |
|
|
* In general, if a loop is required, it should be silent. Then the body |
193 |
|
|
of the loop itself should print each "important" command it runs. |
194 |
|
|
|
195 |
|
|
|
196 |
gary |
1.10 |
7. Editing `.m4sh' Files |
197 |
gary |
1.7 |
======================== |
198 |
gary |
1.1 |
|
199 |
|
|
* Use shell functions, but be careful not to assume local scope for |
200 |
|
|
variable names. Don't use `return', instead echo the result of a |
201 |
|
|
function and call it from within backquotes. |
202 |
|
|
|
203 |
rwild |
1.12 |
* Function names should be prefixed `func_', the function header should |
204 |
|
|
look like this: |
205 |
|
|
|
206 |
|
|
# func_foo [ OPTIONS ] |
207 |
|
|
# Description of what func_foo does and returns. |
208 |
|
|
func_foo () |
209 |
|
|
{ |
210 |
|
|
$opt_debug |
211 |
|
|
# contents of func_foo ... |
212 |
|
|
} |
213 |
|
|
|
214 |
|
|
The `$opt_debug' is used to enable shell tracing (Korn shells reset |
215 |
|
|
this on function entry). |
216 |
gary |
1.7 |
|
217 |
|
|
* For functions that are called frequently, if you need to return a |
218 |
|
|
value, don't cause unneccessary forking of the shell using echo as |
219 |
|
|
described above; instead set the return value in a variable named |
220 |
|
|
after the called function with a suffix of `_result'. For example |
221 |
|
|
the function `func_quote_for_eval' stores its return value in the |
222 |
|
|
variable `$func_quote_for_eval_result'. |
223 |
|
|
|
224 |
|
|
* Although sh-indentation is set to 2 (by the `Local Variables:' block |
225 |
|
|
at the end of .m4sh files), the left margin of the body of shell |
226 |
|
|
functions should begin indented by 4 spaces. |
227 |
|
|
|
228 |
|
|
|
229 |
rwild |
1.13 |
8. Editing `.m4' Files |
230 |
|
|
====================== |
231 |
|
|
|
232 |
|
|
* Be careful with both `echo' and `$ECHO'. As the latter may be one of |
233 |
|
|
echo |
234 |
|
|
print -r |
235 |
|
|
printf %s\n |
236 |
|
|
$CONFIG_SHELL $0 --fallback-echo |
237 |
|
|
it may not have more than one argument, its value may not be eval'ed |
238 |
|
|
and the argument may not start with a `-'. As a rule of thumb, use |
239 |
|
|
echo .. for literal (constant) strings without leading |
240 |
|
|
hyphen and no backslashes within, |
241 |
|
|
$ECHO ".." for strings without leading hyphen, |
242 |
|
|
$ECHO "X.." | $Xsed otherwise. |
243 |
|
|
|
244 |
|
|
|
245 |
|
|
9. Abstraction layers in libltdl |
246 |
gary |
1.6 |
================================ |
247 |
|
|
|
248 |
|
|
* The libltdl API uses a layered approach to differentiate internal and |
249 |
|
|
external interfaces, among other things. To keep the abstraction |
250 |
|
|
consistent, files in a given layer may only use APIs from files in the |
251 |
|
|
lower layers. The exception to this is lt__glibc.h which serves a |
252 |
|
|
dual purpose, as explained later. |
253 |
|
|
|
254 |
|
|
* At the bottom of the stack we have the system abstraction layer, |
255 |
|
|
which tries to smooth over the cracks where there are differences |
256 |
|
|
between host systems and compilers. config.h is generated at |
257 |
|
|
configure time and is not installed; lt_system.h is an installed |
258 |
|
|
file and cannot use macros from config.h: |
259 |
|
|
|
260 |
|
|
lt_system.h ../config.h |
261 |
|
|
|
262 |
|
|
* Next up is the libc abstraction layer, which provides a uniform api |
263 |
|
|
to various system libc interfaces that differ between hosts supported |
264 |
|
|
by libtool. Typically, the files that implement this layer begin: |
265 |
|
|
|
266 |
|
|
#if defined(HAVE_CONFIG_H) |
267 |
|
|
# include HAVE_CONFIG_H |
268 |
|
|
#endif |
269 |
|
|
#include "lt_system.h" |
270 |
|
|
|
271 |
|
|
Or if they are installed headers that must work outside the libtool |
272 |
|
|
source tree, simply: |
273 |
|
|
|
274 |
|
|
#include <libltdl/lt_system.h> |
275 |
|
|
|
276 |
|
|
This layer's interface is defined by files that are usually named with |
277 |
|
|
a leading `lt__': |
278 |
|
|
|
279 |
|
|
,------------. ,-----------. ,------. ,-------. |
280 |
|
|
|lt__dirent.h| |lt__alloc.h| |argz.h| |slist.h| |
281 |
|
|
+------------+ +-----------+ +------+ +-------+ |
282 |
|
|
|lt__dirent.c| |lt__alloc.c| |argz.c| |slist.c| |
283 |
|
|
`------------' `-----------' `------' `-------' |
284 |
|
|
|
285 |
|
|
The exceptions here are argz.h and slist.h which are used |
286 |
|
|
independently of libltdl in other projects. |
287 |
|
|
|
288 |
|
|
* There is also a sub-layer that can be used either by the headers that |
289 |
|
|
implement it, in which case its function is to avoid namespace clashes |
290 |
|
|
when linked with the GNU C library; Or it can be included by code that |
291 |
|
|
wants to program against a glibc like interface, where it also serves |
292 |
|
|
the function of pulling in all the glibc-like functionality used by |
293 |
|
|
libltdl from a single: |
294 |
|
|
|
295 |
|
|
#include <libltdl/lt__glibc.h> |
296 |
|
|
|
297 |
|
|
It consists of the single file: |
298 |
|
|
|
299 |
|
|
lt__glibc.h |
300 |
|
|
|
301 |
|
|
* The next layer are the subsystems of the exported libltdl API, which |
302 |
|
|
are defined by files that are named with a leading `lt_' (no double |
303 |
|
|
underscore!): |
304 |
|
|
|
305 |
|
|
,----------. ,-------------. |
306 |
|
|
|lt_error.h| |lt_dlloader.h| |
307 |
|
|
+----------+ +-------------+ |
308 |
|
|
|lt_error.c| |lt_dlloader.c| |
309 |
|
|
`----------' `-------------' |
310 |
|
|
|
311 |
|
|
|
312 |
|
|
* The top layer of the stack is the libltdl API proper, which includes |
313 |
|
|
the subsystems automatically: |
314 |
|
|
|
315 |
|
|
,------. |
316 |
|
|
|ltdl.h| |
317 |
|
|
+------+ |
318 |
|
|
|ltdl.c| |
319 |
|
|
`------' |
320 |
|
|
|
321 |
|
|
* And finally, there is an additional internal only layer (as evidenced |
322 |
|
|
by the `lt__' prefix to the filename!) that defines additional |
323 |
|
|
internal interfaces that are not exported to libltdl clients, but are |
324 |
|
|
shared between internal files: |
325 |
|
|
|
326 |
|
|
lt__private.h |
327 |
|
|
|
328 |
|
|
|
329 |
rwild |
1.13 |
10. Release Procedure |
330 |
gary |
1.1 |
==================== |
331 |
|
|
|
332 |
|
|
* If you are a libtool maintainer, but have not yet registered your |
333 |
|
|
gpg public key and (preferred) email address with the FSF, send an |
334 |
|
|
email, preferably GPG-signed, to <ftp-upload@gnu.org> that includes |
335 |
|
|
the following: |
336 |
|
|
|
337 |
|
|
(a) name of package(s) that you are the maintainer for, and your |
338 |
|
|
preferred email address. |
339 |
|
|
|
340 |
|
|
(b) an ASCII armored copy of your GnuPG key, as an attachment. |
341 |
|
|
("gpg --export -a YOUR_KEY_ID > mykey.asc" should give you |
342 |
|
|
this.) |
343 |
|
|
|
344 |
|
|
When you have received acknowledgement of your message, the proper GPG |
345 |
|
|
keys will be registered on ftp-upload.gnu.org and only then will you be |
346 |
|
|
authorized to upload files to the FSF ftp machines. |
347 |
|
|
|
348 |
rwild |
1.18 |
* If you do not have access to the mailing list administrative interface, |
349 |
|
|
approach the list owners for the password. Be sure to check the lists |
350 |
|
|
(esp. bug-libtool) for outstanding bug reports also in the list of |
351 |
|
|
pending moderation requests. |
352 |
|
|
|
353 |
gary |
1.2 |
* Make sure you have wget installed. |
354 |
|
|
|
355 |
gary |
1.1 |
* Make sure you have a copy of xdelta installed, and a copy of the previous |
356 |
|
|
release tarball in the build directory. |
357 |
|
|
|
358 |
rwild |
1.16 |
* Make sure your locale is sane, e.g. by exporting LC_ALL=C. |
359 |
|
|
|
360 |
|
|
* Double check that serial number updates in public m4 files weren't forgotten |
361 |
|
|
since last release (they should be updated in CVS along with commits that |
362 |
|
|
require it so that users can work with CVS snapshots). |
363 |
|
|
|
364 |
|
|
* Double check that libltdl version number updates weren't forgotten since last |
365 |
|
|
release (they should be updated in CVS along with commits that require it so |
366 |
|
|
that users can work with CVS snapshots). |
367 |
|
|
|
368 |
gary |
1.1 |
* Update the version number in configure.ac. |
369 |
|
|
See http://www.gnu.org/software/libtool/contribute.html for details of |
370 |
|
|
the numbering scheme. |
371 |
|
|
|
372 |
|
|
* Update NEWS, ChangeLog. |
373 |
|
|
|
374 |
|
|
* Run ./bootstrap. |
375 |
|
|
|
376 |
|
|
* Have some tea. If you are running on less than 3.6GHz CPU, order |
377 |
|
|
a pizza too ;-) |
378 |
|
|
|
379 |
gary |
1.2 |
* Run ./configure (or create a build directory first and run configure |
380 |
|
|
from there, if you want to keep the build tree separate). |
381 |
gary |
1.1 |
|
382 |
gary |
1.2 |
* Run `make -fMakefile.maint fetch' (or `make -f../Makefile.maint fetch' |
383 |
|
|
if you are running from a VPATH build directory, where `../' is the |
384 |
|
|
relative path to the directory with `configure' in it), which will |
385 |
|
|
fetch new versions of the files that are maintained outside of |
386 |
|
|
libtool. |
387 |
|
|
|
388 |
rwild |
1.17 |
* Run `make distcheck' and `make distcheck |
389 |
|
|
DISTCHECK_CONFIGURE_FLAGS=--disable-ltdl-install'. If there are any |
390 |
|
|
problems, fix them and start again. |
391 |
gary |
1.2 |
|
392 |
|
|
* Run ./commit from the source tree. |
393 |
|
|
|
394 |
|
|
* Run `make -fMakefile.maint cvs-dist' (or `make -f../Makefile.maint |
395 |
|
|
cvs-dist' if you are running from a VPATH build directory, where `../' |
396 |
|
|
is the relative path to the directory with `configure' in it), which |
397 |
|
|
will build a release tarball (with `make distcheck'), tag the tree |
398 |
|
|
with release-$(VERSION) and generate the gpg signature files. |
399 |
|
|
|
400 |
|
|
* Run 'make -f[../]Makefile.maint deltas' (pass |
401 |
rwild |
1.16 |
LASTRELEASE=maj.min[.mic[alpha]] if needed) to create both diff and |
402 |
gary |
1.2 |
xdelta files between the previous release tarball and the new with |
403 |
|
|
detached gpg signature files and clear signed directive files. |
404 |
gary |
1.1 |
|
405 |
|
|
* Upload release tarball, diff file and xdelta file, plus their associated |
406 |
|
|
detached gpg signature files and clear signed directive files to |
407 |
|
|
ftp-upload.gnu.org. If the upload is destined for ftp.gnu.org, then the |
408 |
|
|
files should be placed in the /incoming/ftp directory. If the upload is |
409 |
|
|
an alpha release destined for alpha.gnu.org, then the files should be |
410 |
|
|
placed in the /incoming/alpha directory. |
411 |
|
|
|
412 |
|
|
* Send announcement to libtool@gnu.org and autotools-announce@gnu.org, |
413 |
|
|
if not an alpha send to info-gnu@gnu.org as well. |
414 |
|
|
|
415 |
|
|
* Update version number in configure.ac to next alpha number. |
416 |
|
|
See http://www.gnu.org/software/libtool/contribute.html for details of |
417 |
|
|
the numbering scheme. |
418 |
|
|
|
419 |
|
|
* Update NEWS, ChangeLog. |
420 |
|
|
|
421 |
|
|
* Run ./commit. |
422 |
|
|
|
423 |
|
|
* Update the webpages, libtool.html will need to indicate the latest |
424 |
|
|
release number and the news page should get a HTMLified copy of your |
425 |
|
|
release announcement. |
426 |
|
|
|
427 |
|
|
* If not an alpha, replace manual.html with the new one |
428 |
gary |
1.2 |
(generate with `make -f[../]Makefile.maint web-manual'). |
429 |
gary |
1.1 |
|
430 |
|
|
|
431 |
|
|
|
432 |
rwild |
1.13 |
11. Alpha release note template |
433 |
gary |
1.10 |
=============================== |
434 |
gary |
1.1 |
|
435 |
|
|
To: libtool@gnu.org, autotools-announce@gnu.org |
436 |
|
|
Subject: GNU Libtool @VERSION@ released (alpha release). |
437 |
|
|
|
438 |
|
|
The Libtool Team is pleased to announce alpha release @VERSION@ of GNU |
439 |
|
|
Libtool. |
440 |
|
|
|
441 |
|
|
GNU Libtool hides the complexity of using shared libraries behind a |
442 |
|
|
consistent, portable interface. GNU Libtool ships with GNU libltdl, |
443 |
|
|
which hides the complexity of loading dynamic runtime libraries |
444 |
|
|
(modules) behind a consistent, portable interface. |
445 |
|
|
|
446 |
|
|
Here are the compressed sources: |
447 |
|
|
|
448 |
|
|
ftp://alpha.gnu.org/gnu/libtool/libtool-@VERSION@.tar.gz |
449 |
|
|
ftp://alpha.gnu.org/gnu/libtool/libtool-@VERSION@.tar.bz2 |
450 |
|
|
|
451 |
|
|
Here are the xdeltas and diffs against libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@: |
452 |
|
|
|
453 |
|
|
ftp://alpha.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz |
454 |
|
|
ftp://alpha.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta |
455 |
|
|
|
456 |
|
|
Here are the gpg detached signatures: |
457 |
|
|
|
458 |
|
|
ftp://alpha.gnu.org/gnu/libtool/libtool-@VERSION@.tar.gz.sig |
459 |
|
|
ftp://alpha.gnu.org/gnu/libtool/libtool-@VERSION@.tar.bz2.sig |
460 |
|
|
ftp://alpha.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz.sig |
461 |
|
|
ftp://alpha.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta.sig |
462 |
|
|
|
463 |
gary |
1.4 |
You should download the signature named after any tarball you download, |
464 |
|
|
and then verify its integrity with, for example: |
465 |
|
|
|
466 |
gary |
1.8 |
gpg --verify libtool-@VERSION.tar.gz.sig |
467 |
gary |
1.4 |
|
468 |
gary |
1.1 |
Here are the MD5 and SHA1 checksums: |
469 |
|
|
|
470 |
|
|
@MD5SUM@ libtool-@VERSION@.tar.gz |
471 |
|
|
@MD5SUM@ libtool-@VERSION@.tar.bz2 |
472 |
|
|
@MD5SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz |
473 |
|
|
@MD5SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta |
474 |
|
|
@SHA1SUM@ libtool-@VERSION@.tar.gz |
475 |
|
|
@SHA1SUM@ libtool-@VERSION@.tar.bz2 |
476 |
|
|
@SHA1SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz |
477 |
|
|
@SHA1SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta |
478 |
|
|
|
479 |
|
|
This release has @SUMMARY_OF_IMPROVEMENTS_SINCE_LAST_RELEASE_ON_THIS_BRANCH@. |
480 |
|
|
|
481 |
|
|
This release was bootstrapped with @BOOTSTRAP_TOOLS_WITH_VERSIONS@, |
482 |
|
|
but is useable with @COMPATIBLE_AUTOTOOL_VERSIONS@ in your own |
483 |
|
|
projects. |
484 |
|
|
|
485 |
|
|
Alternatively, you can fetch the unbootstrapped sourcecode from |
486 |
|
|
anonymous cvs by using the following commands: |
487 |
|
|
|
488 |
|
|
$ export CVS_RSH=ssh |
489 |
|
|
$ cvs -z3 -d :ext:anoncvs@savannah.gnu.org:/cvsroot/libtool \ |
490 |
|
|
co -r @CVS_RELEASE_TAG@ libtool |
491 |
|
|
|
492 |
|
|
You will then need to have recent (possibly as yet unreleased) versions |
493 |
|
|
of Automake and Autoconf installed to bootstrap the checked out |
494 |
|
|
sources yourself. |
495 |
|
|
|
496 |
|
|
New in @VERSION@: @RELEASE_DATE@ |
497 |
|
|
|
498 |
|
|
@EXCERPT_FROM_NEWS_FILE@ |
499 |
|
|
|
500 |
|
|
Please report bugs to <bug-libtool@gnu.org>, along with the verbose |
501 |
|
|
output of any failed test groups, and the output from `./libtool --help.' |
502 |
|
|
|
503 |
|
|
|
504 |
|
|
|
505 |
rwild |
1.13 |
12. Full release note template |
506 |
gary |
1.10 |
============================== |
507 |
gary |
1.1 |
|
508 |
|
|
To: info-gnu@gnu.org |
509 |
|
|
Cc: libtool@gnu.org, autotools-announce@gnu.org |
510 |
|
|
Subject: GNU Libtool @VERSION@ released. |
511 |
|
|
|
512 |
|
|
The Libtool Team is pleased to announce the release of GNU Libtool |
513 |
|
|
@VERSION@. |
514 |
|
|
|
515 |
|
|
GNU Libtool hides the complexity of using shared libraries behind a |
516 |
|
|
consistent, portable interface. GNU Libtool ships with GNU libltdl, |
517 |
rwild |
1.16 |
which hides the complexity of loading dynamic runtime libraries |
518 |
gary |
1.1 |
(modules) behind a consistent, portable interface. |
519 |
|
|
|
520 |
|
|
This release has @SUMMARY_OF_IMPROVEMENTS_SINCE_LAST_RELEASE_ON_THIS_BRANCH@. |
521 |
|
|
|
522 |
|
|
New in @VERSION@: @RELEASE_DATE@ |
523 |
|
|
|
524 |
|
|
@EXCERPT_FROM_NEWS_FILE@ |
525 |
|
|
|
526 |
|
|
libtool-@VERSION@ is available now from ftp.gnu.org, along with |
527 |
|
|
diffs and xdeltas against libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@ |
528 |
|
|
that are also available from ftp.gnu.org. Please |
529 |
|
|
use a mirror to reduce stress on the main gnu machine: |
530 |
|
|
|
531 |
|
|
http://www.gnu.org/order/ftp.html |
532 |
|
|
|
533 |
|
|
Here are the compressed sources: |
534 |
|
|
|
535 |
|
|
ftp://ftp.gnu.org/gnu/libtool/libtool-@VERSION@.tar.gz |
536 |
|
|
ftp://ftp.gnu.org/gnu/libtool/libtool-@VERSION@.tar.bz2 |
537 |
|
|
|
538 |
|
|
Here are the xdeltas and diffs against libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@: |
539 |
|
|
|
540 |
|
|
ftp://ftp.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz |
541 |
|
|
ftp://ftp.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta |
542 |
|
|
|
543 |
|
|
Here are the gpg detached signatures: |
544 |
|
|
|
545 |
|
|
ftp://ftp.gnu.org/gnu/libtool/libtool-@VERSION@.tar.gz.sig |
546 |
|
|
ftp://ftp.gnu.org/gnu/libtool/libtool-@VERSION@.tar.bz2.sig |
547 |
|
|
ftp://ftp.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz.sig |
548 |
|
|
ftp://ftp.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta.sig |
549 |
|
|
|
550 |
gary |
1.4 |
You should download the signature named after any tarball you download, |
551 |
|
|
and then verify its integrity with, for example: |
552 |
|
|
|
553 |
gary |
1.8 |
gpg --verify libtool-@VERSION.tar.gz.sig |
554 |
gary |
1.4 |
|
555 |
gary |
1.1 |
Here are the MD5 and SHA1 checksums: |
556 |
|
|
|
557 |
|
|
@MD5SUM@ libtool-@VERSION@.tar.gz |
558 |
|
|
@MD5SUM@ libtool-@VERSION@.tar.bz2 |
559 |
|
|
@MD5SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz |
560 |
|
|
@MD5SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta |
561 |
|
|
@SHA1SUM@ libtool-@VERSION@.tar.gz |
562 |
|
|
@SHA1SUM@ libtool-@VERSION@.tar.bz2 |
563 |
|
|
@SHA1SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz |
564 |
|
|
@SHA1SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta |
565 |
|
|
|
566 |
|
|
This release was bootstrapped with @BOOTSTRAP_TOOLS_WITH_VERSIONS@, |
567 |
|
|
but is useable with @COMPATIBLE_AUTOTOOL_VERSIONS@ in your own |
568 |
|
|
projects. |
569 |
|
|
|
570 |
|
|
Alternatively, you can fetch the unbootstrapped sourcecode from |
571 |
|
|
anonymous cvs by using the following commands (just hit return when |
572 |
|
|
you are prompted for the password): |
573 |
|
|
|
574 |
|
|
$ export CVS_RSH=ssh |
575 |
|
|
$ cvs -z3 -d :ext:anoncvs@savannah.gnu.org:/cvsroot/libtool \ |
576 |
|
|
co -r @CVS_RELEASE_TAG@ libtool |
577 |
|
|
|
578 |
|
|
You will then need to have the latest release versions of Automake |
579 |
|
|
(@AUTOMAKE_VERSION@) and Autoconf (@AUTOCONF_VERSION@) installed to |
580 |
|
|
bootstrap the checked out sources yourself. |
581 |
|
|
|
582 |
|
|
Please report bugs to <bug-libtool@gnu.org>, along with the verbose |
583 |
|
|
output of any failed test groups, and the output from `./libtool --help.' |
584 |
|
|
|
585 |
|
|
|
586 |
|
|
-- |
587 |
gary |
1.10 |
Copyright (C) 2004, 2005 Free Software Foundation, Inc. |
588 |
gary |
1.1 |
|
589 |
|
|
The canonical source of this file is maintained with the |
590 |
|
|
GNU Libtool package. Report bugs to bug-libtool@gnu.org. |
591 |
|
|
|
592 |
|
|
GNU Libtool is free software; you can redistribute it and/or |
593 |
|
|
modify it under the terms of the GNU General Public License as |
594 |
|
|
published by the Free Software Foundation; either version 2 |
595 |
|
|
of the License, or (at your option) any later version. |
596 |
|
|
|
597 |
|
|
As a special exception to the GNU General Public License, |
598 |
|
|
if you distribute this file as part of a program or library that |
599 |
|
|
is built using GNU libtool, you may include it under the same |
600 |
|
|
distribution terms that you use for the rest of that program. |
601 |
|
|
|
602 |
|
|
GNU Libtool is distributed in the hope that it will be useful, |
603 |
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of |
604 |
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU |
605 |
|
|
General Public License for more details. |
606 |
|
|
|
607 |
|
|
You should have received a copy of the GNU General Public License |
608 |
|
|
along with GNU Libtool; if not, write to the Free Software |
609 |
gary |
1.14 |
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA |
610 |
|
|
02110-1301 USA |
611 |
gary |
1.1 |
|
612 |
|
|
|
613 |
|
|
Local Variables: |
614 |
|
|
mode: text |
615 |
|
|
fill-column: 72 |
616 |
|
|
End: |