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 |
+ COPYING.LIB |
43 |
The ones that are important for a release can be udated with, |
44 |
`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 |
|
48 |
* Changes other than bug fixes must be mentioned in NEWS |
49 |
|
50 |
|
51 |
3. Test Suite |
52 |
============= |
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 |
4. Naming |
59 |
========= |
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 |
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 |
* If more than one person collaborated on the change, additional |
89 |
authors can be listed on subsequent lines, thus: |
90 |
|
91 |
yyyy-mm-dd Name of Main Author <email@address>, |
92 |
Name of Contributor <another@email.address> |
93 |
|
94 |
* 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 |
* 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 |
2005-01-08 Ralf Wildenhues <Ralf.Wildenhues@gmx.de> (tiny change), |
159 |
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 |
====================== |
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 |
* Do not use `cd' within back-quotes, use `$(lt__cd)' instead. |
190 |
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 |
7. Editing `.m4sh' Files |
197 |
======================== |
198 |
|
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 |
* 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 |
|
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 |
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 |
================================ |
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 |
10. Release Procedure |
330 |
==================== |
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 |
* 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 |
* Make sure you have wget installed. |
354 |
|
355 |
* Make sure you have a copy of xdelta installed, and a copy of the previous |
356 |
release tarball in the build directory. |
357 |
|
358 |
* 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 |
* 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 |
* Run ./configure (or create a build directory first and run configure |
380 |
from there, if you want to keep the build tree separate). |
381 |
|
382 |
* 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 |
* 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 |
|
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 |
LASTRELEASE=maj.min[.mic[alpha]] if needed) to create both diff and |
402 |
xdelta files between the previous release tarball and the new with |
403 |
detached gpg signature files and clear signed directive files. |
404 |
|
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 |
(generate with `make -f[../]Makefile.maint web-manual'). |
429 |
|
430 |
|
431 |
|
432 |
11. Alpha release note template |
433 |
=============================== |
434 |
|
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 |
You should download the signature named after any tarball you download, |
464 |
and then verify its integrity with, for example: |
465 |
|
466 |
gpg --verify libtool-@VERSION.tar.gz.sig |
467 |
|
468 |
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 |
12. Full release note template |
506 |
============================== |
507 |
|
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 |
which hides the complexity of loading dynamic runtime libraries |
518 |
(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 |
You should download the signature named after any tarball you download, |
551 |
and then verify its integrity with, for example: |
552 |
|
553 |
gpg --verify libtool-@VERSION.tar.gz.sig |
554 |
|
555 |
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 |
Copyright (C) 2004, 2005 Free Software Foundation, Inc. |
588 |
|
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 |
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA |
610 |
02110-1301 USA |
611 |
|
612 |
|
613 |
Local Variables: |
614 |
mode: text |
615 |
fill-column: 72 |
616 |
End: |