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 |
rwild |
1.19 |
* Do not use the number of macro arguments `$#' in public macros; |
245 |
|
|
AU_ALIAS may change it. |
246 |
|
|
|
247 |
rwild |
1.13 |
|
248 |
|
|
9. Abstraction layers in libltdl |
249 |
gary |
1.6 |
================================ |
250 |
|
|
|
251 |
|
|
* The libltdl API uses a layered approach to differentiate internal and |
252 |
|
|
external interfaces, among other things. To keep the abstraction |
253 |
|
|
consistent, files in a given layer may only use APIs from files in the |
254 |
|
|
lower layers. The exception to this is lt__glibc.h which serves a |
255 |
|
|
dual purpose, as explained later. |
256 |
|
|
|
257 |
|
|
* At the bottom of the stack we have the system abstraction layer, |
258 |
|
|
which tries to smooth over the cracks where there are differences |
259 |
|
|
between host systems and compilers. config.h is generated at |
260 |
|
|
configure time and is not installed; lt_system.h is an installed |
261 |
|
|
file and cannot use macros from config.h: |
262 |
|
|
|
263 |
|
|
lt_system.h ../config.h |
264 |
|
|
|
265 |
|
|
* Next up is the libc abstraction layer, which provides a uniform api |
266 |
|
|
to various system libc interfaces that differ between hosts supported |
267 |
|
|
by libtool. Typically, the files that implement this layer begin: |
268 |
|
|
|
269 |
|
|
#if defined(HAVE_CONFIG_H) |
270 |
|
|
# include HAVE_CONFIG_H |
271 |
|
|
#endif |
272 |
|
|
#include "lt_system.h" |
273 |
|
|
|
274 |
|
|
Or if they are installed headers that must work outside the libtool |
275 |
|
|
source tree, simply: |
276 |
|
|
|
277 |
|
|
#include <libltdl/lt_system.h> |
278 |
|
|
|
279 |
|
|
This layer's interface is defined by files that are usually named with |
280 |
|
|
a leading `lt__': |
281 |
|
|
|
282 |
|
|
,------------. ,-----------. ,------. ,-------. |
283 |
|
|
|lt__dirent.h| |lt__alloc.h| |argz.h| |slist.h| |
284 |
|
|
+------------+ +-----------+ +------+ +-------+ |
285 |
|
|
|lt__dirent.c| |lt__alloc.c| |argz.c| |slist.c| |
286 |
|
|
`------------' `-----------' `------' `-------' |
287 |
|
|
|
288 |
|
|
The exceptions here are argz.h and slist.h which are used |
289 |
|
|
independently of libltdl in other projects. |
290 |
|
|
|
291 |
|
|
* There is also a sub-layer that can be used either by the headers that |
292 |
|
|
implement it, in which case its function is to avoid namespace clashes |
293 |
|
|
when linked with the GNU C library; Or it can be included by code that |
294 |
|
|
wants to program against a glibc like interface, where it also serves |
295 |
|
|
the function of pulling in all the glibc-like functionality used by |
296 |
|
|
libltdl from a single: |
297 |
|
|
|
298 |
|
|
#include <libltdl/lt__glibc.h> |
299 |
|
|
|
300 |
|
|
It consists of the single file: |
301 |
|
|
|
302 |
|
|
lt__glibc.h |
303 |
|
|
|
304 |
|
|
* The next layer are the subsystems of the exported libltdl API, which |
305 |
|
|
are defined by files that are named with a leading `lt_' (no double |
306 |
|
|
underscore!): |
307 |
|
|
|
308 |
|
|
,----------. ,-------------. |
309 |
|
|
|lt_error.h| |lt_dlloader.h| |
310 |
|
|
+----------+ +-------------+ |
311 |
|
|
|lt_error.c| |lt_dlloader.c| |
312 |
|
|
`----------' `-------------' |
313 |
|
|
|
314 |
|
|
|
315 |
|
|
* The top layer of the stack is the libltdl API proper, which includes |
316 |
|
|
the subsystems automatically: |
317 |
|
|
|
318 |
|
|
,------. |
319 |
|
|
|ltdl.h| |
320 |
|
|
+------+ |
321 |
|
|
|ltdl.c| |
322 |
|
|
`------' |
323 |
|
|
|
324 |
|
|
* And finally, there is an additional internal only layer (as evidenced |
325 |
|
|
by the `lt__' prefix to the filename!) that defines additional |
326 |
|
|
internal interfaces that are not exported to libltdl clients, but are |
327 |
|
|
shared between internal files: |
328 |
|
|
|
329 |
|
|
lt__private.h |
330 |
|
|
|
331 |
|
|
|
332 |
rwild |
1.13 |
10. Release Procedure |
333 |
gary |
1.1 |
==================== |
334 |
|
|
|
335 |
|
|
* If you are a libtool maintainer, but have not yet registered your |
336 |
|
|
gpg public key and (preferred) email address with the FSF, send an |
337 |
|
|
email, preferably GPG-signed, to <ftp-upload@gnu.org> that includes |
338 |
|
|
the following: |
339 |
|
|
|
340 |
|
|
(a) name of package(s) that you are the maintainer for, and your |
341 |
|
|
preferred email address. |
342 |
|
|
|
343 |
|
|
(b) an ASCII armored copy of your GnuPG key, as an attachment. |
344 |
|
|
("gpg --export -a YOUR_KEY_ID > mykey.asc" should give you |
345 |
|
|
this.) |
346 |
|
|
|
347 |
|
|
When you have received acknowledgement of your message, the proper GPG |
348 |
|
|
keys will be registered on ftp-upload.gnu.org and only then will you be |
349 |
|
|
authorized to upload files to the FSF ftp machines. |
350 |
|
|
|
351 |
rwild |
1.18 |
* If you do not have access to the mailing list administrative interface, |
352 |
|
|
approach the list owners for the password. Be sure to check the lists |
353 |
|
|
(esp. bug-libtool) for outstanding bug reports also in the list of |
354 |
|
|
pending moderation requests. |
355 |
|
|
|
356 |
gary |
1.2 |
* Make sure you have wget installed. |
357 |
|
|
|
358 |
gary |
1.1 |
* Make sure you have a copy of xdelta installed, and a copy of the previous |
359 |
|
|
release tarball in the build directory. |
360 |
|
|
|
361 |
rwild |
1.16 |
* Make sure your locale is sane, e.g. by exporting LC_ALL=C. |
362 |
|
|
|
363 |
|
|
* Double check that serial number updates in public m4 files weren't forgotten |
364 |
|
|
since last release (they should be updated in CVS along with commits that |
365 |
|
|
require it so that users can work with CVS snapshots). |
366 |
|
|
|
367 |
|
|
* Double check that libltdl version number updates weren't forgotten since last |
368 |
|
|
release (they should be updated in CVS along with commits that require it so |
369 |
|
|
that users can work with CVS snapshots). |
370 |
|
|
|
371 |
gary |
1.1 |
* Update the version number in configure.ac. |
372 |
|
|
See http://www.gnu.org/software/libtool/contribute.html for details of |
373 |
|
|
the numbering scheme. |
374 |
|
|
|
375 |
|
|
* Update NEWS, ChangeLog. |
376 |
|
|
|
377 |
|
|
* Run ./bootstrap. |
378 |
|
|
|
379 |
|
|
* Have some tea. If you are running on less than 3.6GHz CPU, order |
380 |
|
|
a pizza too ;-) |
381 |
|
|
|
382 |
gary |
1.2 |
* Run ./configure (or create a build directory first and run configure |
383 |
|
|
from there, if you want to keep the build tree separate). |
384 |
gary |
1.1 |
|
385 |
gary |
1.2 |
* Run `make -fMakefile.maint fetch' (or `make -f../Makefile.maint fetch' |
386 |
|
|
if you are running from a VPATH build directory, where `../' is the |
387 |
|
|
relative path to the directory with `configure' in it), which will |
388 |
|
|
fetch new versions of the files that are maintained outside of |
389 |
|
|
libtool. |
390 |
|
|
|
391 |
rwild |
1.17 |
* Run `make distcheck' and `make distcheck |
392 |
|
|
DISTCHECK_CONFIGURE_FLAGS=--disable-ltdl-install'. If there are any |
393 |
|
|
problems, fix them and start again. |
394 |
gary |
1.2 |
|
395 |
|
|
* Run ./commit from the source tree. |
396 |
|
|
|
397 |
|
|
* Run `make -fMakefile.maint cvs-dist' (or `make -f../Makefile.maint |
398 |
|
|
cvs-dist' if you are running from a VPATH build directory, where `../' |
399 |
|
|
is the relative path to the directory with `configure' in it), which |
400 |
|
|
will build a release tarball (with `make distcheck'), tag the tree |
401 |
|
|
with release-$(VERSION) and generate the gpg signature files. |
402 |
|
|
|
403 |
|
|
* Run 'make -f[../]Makefile.maint deltas' (pass |
404 |
rwild |
1.16 |
LASTRELEASE=maj.min[.mic[alpha]] if needed) to create both diff and |
405 |
gary |
1.2 |
xdelta files between the previous release tarball and the new with |
406 |
|
|
detached gpg signature files and clear signed directive files. |
407 |
gary |
1.1 |
|
408 |
|
|
* Upload release tarball, diff file and xdelta file, plus their associated |
409 |
|
|
detached gpg signature files and clear signed directive files to |
410 |
|
|
ftp-upload.gnu.org. If the upload is destined for ftp.gnu.org, then the |
411 |
|
|
files should be placed in the /incoming/ftp directory. If the upload is |
412 |
|
|
an alpha release destined for alpha.gnu.org, then the files should be |
413 |
|
|
placed in the /incoming/alpha directory. |
414 |
|
|
|
415 |
|
|
* Send announcement to libtool@gnu.org and autotools-announce@gnu.org, |
416 |
|
|
if not an alpha send to info-gnu@gnu.org as well. |
417 |
|
|
|
418 |
|
|
* Update version number in configure.ac to next alpha number. |
419 |
|
|
See http://www.gnu.org/software/libtool/contribute.html for details of |
420 |
|
|
the numbering scheme. |
421 |
|
|
|
422 |
|
|
* Update NEWS, ChangeLog. |
423 |
|
|
|
424 |
|
|
* Run ./commit. |
425 |
|
|
|
426 |
|
|
* Update the webpages, libtool.html will need to indicate the latest |
427 |
|
|
release number and the news page should get a HTMLified copy of your |
428 |
|
|
release announcement. |
429 |
|
|
|
430 |
|
|
* If not an alpha, replace manual.html with the new one |
431 |
gary |
1.2 |
(generate with `make -f[../]Makefile.maint web-manual'). |
432 |
gary |
1.1 |
|
433 |
|
|
|
434 |
|
|
|
435 |
rwild |
1.13 |
11. Alpha release note template |
436 |
gary |
1.10 |
=============================== |
437 |
gary |
1.1 |
|
438 |
|
|
To: libtool@gnu.org, autotools-announce@gnu.org |
439 |
|
|
Subject: GNU Libtool @VERSION@ released (alpha release). |
440 |
|
|
|
441 |
|
|
The Libtool Team is pleased to announce alpha release @VERSION@ of GNU |
442 |
|
|
Libtool. |
443 |
|
|
|
444 |
|
|
GNU Libtool hides the complexity of using shared libraries behind a |
445 |
|
|
consistent, portable interface. GNU Libtool ships with GNU libltdl, |
446 |
|
|
which hides the complexity of loading dynamic runtime libraries |
447 |
|
|
(modules) behind a consistent, portable interface. |
448 |
|
|
|
449 |
|
|
Here are the compressed sources: |
450 |
|
|
|
451 |
|
|
ftp://alpha.gnu.org/gnu/libtool/libtool-@VERSION@.tar.gz |
452 |
|
|
ftp://alpha.gnu.org/gnu/libtool/libtool-@VERSION@.tar.bz2 |
453 |
|
|
|
454 |
|
|
Here are the xdeltas and diffs against libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@: |
455 |
|
|
|
456 |
|
|
ftp://alpha.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz |
457 |
|
|
ftp://alpha.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta |
458 |
|
|
|
459 |
|
|
Here are the gpg detached signatures: |
460 |
|
|
|
461 |
|
|
ftp://alpha.gnu.org/gnu/libtool/libtool-@VERSION@.tar.gz.sig |
462 |
|
|
ftp://alpha.gnu.org/gnu/libtool/libtool-@VERSION@.tar.bz2.sig |
463 |
|
|
ftp://alpha.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz.sig |
464 |
|
|
ftp://alpha.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta.sig |
465 |
|
|
|
466 |
gary |
1.4 |
You should download the signature named after any tarball you download, |
467 |
|
|
and then verify its integrity with, for example: |
468 |
|
|
|
469 |
gary |
1.8 |
gpg --verify libtool-@VERSION.tar.gz.sig |
470 |
gary |
1.4 |
|
471 |
gary |
1.1 |
Here are the MD5 and SHA1 checksums: |
472 |
|
|
|
473 |
|
|
@MD5SUM@ libtool-@VERSION@.tar.gz |
474 |
|
|
@MD5SUM@ libtool-@VERSION@.tar.bz2 |
475 |
|
|
@MD5SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz |
476 |
|
|
@MD5SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta |
477 |
|
|
@SHA1SUM@ libtool-@VERSION@.tar.gz |
478 |
|
|
@SHA1SUM@ libtool-@VERSION@.tar.bz2 |
479 |
|
|
@SHA1SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz |
480 |
|
|
@SHA1SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta |
481 |
|
|
|
482 |
|
|
This release has @SUMMARY_OF_IMPROVEMENTS_SINCE_LAST_RELEASE_ON_THIS_BRANCH@. |
483 |
|
|
|
484 |
|
|
This release was bootstrapped with @BOOTSTRAP_TOOLS_WITH_VERSIONS@, |
485 |
|
|
but is useable with @COMPATIBLE_AUTOTOOL_VERSIONS@ in your own |
486 |
|
|
projects. |
487 |
|
|
|
488 |
|
|
Alternatively, you can fetch the unbootstrapped sourcecode from |
489 |
|
|
anonymous cvs by using the following commands: |
490 |
|
|
|
491 |
|
|
$ export CVS_RSH=ssh |
492 |
|
|
$ cvs -z3 -d :ext:anoncvs@savannah.gnu.org:/cvsroot/libtool \ |
493 |
|
|
co -r @CVS_RELEASE_TAG@ libtool |
494 |
|
|
|
495 |
|
|
You will then need to have recent (possibly as yet unreleased) versions |
496 |
|
|
of Automake and Autoconf installed to bootstrap the checked out |
497 |
|
|
sources yourself. |
498 |
|
|
|
499 |
|
|
New in @VERSION@: @RELEASE_DATE@ |
500 |
|
|
|
501 |
|
|
@EXCERPT_FROM_NEWS_FILE@ |
502 |
|
|
|
503 |
|
|
Please report bugs to <bug-libtool@gnu.org>, along with the verbose |
504 |
|
|
output of any failed test groups, and the output from `./libtool --help.' |
505 |
|
|
|
506 |
|
|
|
507 |
|
|
|
508 |
rwild |
1.13 |
12. Full release note template |
509 |
gary |
1.10 |
============================== |
510 |
gary |
1.1 |
|
511 |
|
|
To: info-gnu@gnu.org |
512 |
|
|
Cc: libtool@gnu.org, autotools-announce@gnu.org |
513 |
|
|
Subject: GNU Libtool @VERSION@ released. |
514 |
|
|
|
515 |
|
|
The Libtool Team is pleased to announce the release of GNU Libtool |
516 |
|
|
@VERSION@. |
517 |
|
|
|
518 |
|
|
GNU Libtool hides the complexity of using shared libraries behind a |
519 |
|
|
consistent, portable interface. GNU Libtool ships with GNU libltdl, |
520 |
rwild |
1.16 |
which hides the complexity of loading dynamic runtime libraries |
521 |
gary |
1.1 |
(modules) behind a consistent, portable interface. |
522 |
|
|
|
523 |
|
|
This release has @SUMMARY_OF_IMPROVEMENTS_SINCE_LAST_RELEASE_ON_THIS_BRANCH@. |
524 |
|
|
|
525 |
|
|
New in @VERSION@: @RELEASE_DATE@ |
526 |
|
|
|
527 |
|
|
@EXCERPT_FROM_NEWS_FILE@ |
528 |
|
|
|
529 |
|
|
libtool-@VERSION@ is available now from ftp.gnu.org, along with |
530 |
|
|
diffs and xdeltas against libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@ |
531 |
|
|
that are also available from ftp.gnu.org. Please |
532 |
|
|
use a mirror to reduce stress on the main gnu machine: |
533 |
|
|
|
534 |
|
|
http://www.gnu.org/order/ftp.html |
535 |
|
|
|
536 |
|
|
Here are the compressed sources: |
537 |
|
|
|
538 |
|
|
ftp://ftp.gnu.org/gnu/libtool/libtool-@VERSION@.tar.gz |
539 |
|
|
ftp://ftp.gnu.org/gnu/libtool/libtool-@VERSION@.tar.bz2 |
540 |
|
|
|
541 |
|
|
Here are the xdeltas and diffs against libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@: |
542 |
|
|
|
543 |
|
|
ftp://ftp.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz |
544 |
|
|
ftp://ftp.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta |
545 |
|
|
|
546 |
|
|
Here are the gpg detached signatures: |
547 |
|
|
|
548 |
|
|
ftp://ftp.gnu.org/gnu/libtool/libtool-@VERSION@.tar.gz.sig |
549 |
|
|
ftp://ftp.gnu.org/gnu/libtool/libtool-@VERSION@.tar.bz2.sig |
550 |
|
|
ftp://ftp.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz.sig |
551 |
|
|
ftp://ftp.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta.sig |
552 |
|
|
|
553 |
gary |
1.4 |
You should download the signature named after any tarball you download, |
554 |
|
|
and then verify its integrity with, for example: |
555 |
|
|
|
556 |
gary |
1.8 |
gpg --verify libtool-@VERSION.tar.gz.sig |
557 |
gary |
1.4 |
|
558 |
gary |
1.1 |
Here are the MD5 and SHA1 checksums: |
559 |
|
|
|
560 |
|
|
@MD5SUM@ libtool-@VERSION@.tar.gz |
561 |
|
|
@MD5SUM@ libtool-@VERSION@.tar.bz2 |
562 |
|
|
@MD5SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz |
563 |
|
|
@MD5SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta |
564 |
|
|
@SHA1SUM@ libtool-@VERSION@.tar.gz |
565 |
|
|
@SHA1SUM@ libtool-@VERSION@.tar.bz2 |
566 |
|
|
@SHA1SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz |
567 |
|
|
@SHA1SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta |
568 |
|
|
|
569 |
|
|
This release was bootstrapped with @BOOTSTRAP_TOOLS_WITH_VERSIONS@, |
570 |
|
|
but is useable with @COMPATIBLE_AUTOTOOL_VERSIONS@ in your own |
571 |
|
|
projects. |
572 |
|
|
|
573 |
|
|
Alternatively, you can fetch the unbootstrapped sourcecode from |
574 |
|
|
anonymous cvs by using the following commands (just hit return when |
575 |
|
|
you are prompted for the password): |
576 |
|
|
|
577 |
|
|
$ export CVS_RSH=ssh |
578 |
|
|
$ cvs -z3 -d :ext:anoncvs@savannah.gnu.org:/cvsroot/libtool \ |
579 |
|
|
co -r @CVS_RELEASE_TAG@ libtool |
580 |
|
|
|
581 |
|
|
You will then need to have the latest release versions of Automake |
582 |
|
|
(@AUTOMAKE_VERSION@) and Autoconf (@AUTOCONF_VERSION@) installed to |
583 |
|
|
bootstrap the checked out sources yourself. |
584 |
|
|
|
585 |
|
|
Please report bugs to <bug-libtool@gnu.org>, along with the verbose |
586 |
|
|
output of any failed test groups, and the output from `./libtool --help.' |
587 |
|
|
|
588 |
|
|
|
589 |
|
|
-- |
590 |
gary |
1.10 |
Copyright (C) 2004, 2005 Free Software Foundation, Inc. |
591 |
gary |
1.1 |
|
592 |
|
|
The canonical source of this file is maintained with the |
593 |
|
|
GNU Libtool package. Report bugs to bug-libtool@gnu.org. |
594 |
|
|
|
595 |
|
|
GNU Libtool is free software; you can redistribute it and/or |
596 |
|
|
modify it under the terms of the GNU General Public License as |
597 |
|
|
published by the Free Software Foundation; either version 2 |
598 |
|
|
of the License, or (at your option) any later version. |
599 |
|
|
|
600 |
|
|
As a special exception to the GNU General Public License, |
601 |
|
|
if you distribute this file as part of a program or library that |
602 |
|
|
is built using GNU libtool, you may include it under the same |
603 |
|
|
distribution terms that you use for the rest of that program. |
604 |
|
|
|
605 |
|
|
GNU Libtool is distributed in the hope that it will be useful, |
606 |
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of |
607 |
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU |
608 |
|
|
General Public License for more details. |
609 |
|
|
|
610 |
|
|
You should have received a copy of the GNU General Public License |
611 |
|
|
along with GNU Libtool; if not, write to the Free Software |
612 |
gary |
1.14 |
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA |
613 |
|
|
02110-1301 USA |
614 |
gary |
1.1 |
|
615 |
|
|
|
616 |
|
|
Local Variables: |
617 |
|
|
mode: text |
618 |
|
|
fill-column: 72 |
619 |
|
|
End: |