/[libtool]/libtool/HACKING
ViewVC logotype

Contents of /libtool/HACKING

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.18 - (show annotations) (download)
Mon Aug 8 06:47:42 2005 UTC (18 years, 9 months ago) by rwild
Branch: MAIN
Changes since 1.17: +5 -0 lines
* AUTHORS, HACKING: Updated.

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:

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26