/[libtool]/libtool/HACKING
ViewVC logotype

Annotation of /libtool/HACKING

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.19 - (hide annotations) (download)
Mon Sep 12 11:21:39 2005 UTC (18 years, 8 months ago) by rwild
Branch: MAIN
Changes since 1.18: +3 -0 lines
* libltdl/m4/ltdl.m4 (LT_WITH_LTDL, LTDL_CONVENIENCE)
(LTDL_INSTALLABLE): Use less quoting for expanded LIBLTDL,
LTDLINCL.  Use m4_default instead of m4_if, to work
around AU_ALIAS bug with empty macro arguments.
(LTDL_INIT): Likewise.
* libltdl/m4/ltoptions.m4 (_LT_WITH_PIC): Likewise.
* TODO, HACKING: Updated.

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:

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