mirror/libtool
2
0
Fork 0
mirror of git://git.savannah.gnu.org/libtool.git synced 2024-11-21 01:40:57 +08:00
Code Issues Packages Projects Releases Wiki Activity
57c342937d
libtool/HACKING
Paolo Bonzini 9c9cde2c95 Do not use $ECHO within eval-ed ..., as %s\\n becomes %s\n. 
* HACKING: Document func_echo_all.
* libltdl/m4/libtool.m4: Use it within backticks that appear in
eval-ed variables.  Reported by Akim Demaille.
2008-11-28 15:53:46 +01:00

929 lines
34 KiB
Plaintext
Raw Blame History

GNU Libtool
***********
1. Introduction
===============
This file attempts to describe the processes we use to maintain libtool,
and is not part of a release distribution.
2. Maintenance Notes
====================
* If you incorporate a change from somebody on the net:
If it is a large change, you must make sure they have signed the
appropriate paperwork, and be sure to add their name and email
address to THANKS
* If a change fixes a test, mention the test in the ChangeLog entry.
* If somebody reports a new bug, mention his name in the ChangeLog entry
and in the test case you write.
* The correct response to most actual bugs is to write a new test case
which demonstrates the bug. Then fix the bug, re-run the test suite,
and check everything in.
* Some files in the libtool package are not owned by libtool. These
files should never be edited here. These files are:
COPYING
INSTALL
config/
+ config.guess
+ config.sub
+ depcomp
+ install-sh
+ mdate-sh
+ missing
+ texinfo.tex
doc/
+ fdl.texi
libltdl/
+ COPYING.LIB
The ones that are important for a release can be udated with,
`make -fMakefile.maint fetch' (or `make -f../Makefile.maint fetch'
if you are running from a VPATH build directory, where `../' is the
relative path to the directory with `configure' in it).
* Changes other than bug fixes must be mentioned in NEWS
3. Test Suite
=============
* When writing tests, make sure the link invocation (first argument to
AT_CHECK) is on a single line so that `testsuite -x' displays the
whole thing. You can use m4_do or `[... ]dnl' to wrap long lines.
* Use
make -k check
liberally, on as many platforms as you can. Use as many compilers and
linkers you can. To run old and new testsuites separately, use
make check TESTSUITEFLAGS=-V
make check-local
* The new Autotest testsuite uses keywords to denote test features:
autoconf needs Autoconf
automake needs Automake
libltdl exercises the `libltdl' library
libtool exercises the `libtool' script
libtoolize exercises the `libtoolize' script
recursive runs the suite recursively, with a modified
`libtool' script and with `-k libtool'
CXX F77 FC GCJ exercises a language other than C
4. Naming
=========
* We've adopted the convention that exported Autoconf macros should be
named with a leading `LT_' and be documented in the libtool manual.
Internal macros begin with `_LT_' if they are visible to aclocal, or
potentially part of an AC_DEFUN/AC_REQUIRE path, or else `_lt_' if
they are very low level. This convention was only introduced just
before libtool-2.0, so there may still be exceptions in the existing
code. But all new code should use it.
* All shell variables used internally by libtool's Autoconf macros
should be named with the a leading `lt_' (not that they cannot clash
with the `_lt_' macro namespace).
5. Editing 'ChangeLog'
======================
* When in doubt, check that emacs can syntax-color properly in
change-log-mode. And preferably use emacs 'C-x 4 a'
(add-change-log-entry-other-window) to open ChangeLog with an
appropriate new template.
* If this change is by a different author, or on a different date to the
last entry start a new entry at the top of the file with the format
(note two spaces between each field):
yyyy-mm-dd Name of Author <email@address>
* If more than one person collaborated on the change, additional
authors can be listed on subsequent lines, thus:
yyyy-mm-dd Name of Main Author <email@address>,
Name of Contributor <another@email.address>
* Where a change author did not supply a copyright assignment, but the
changes they submitted were sufficiently trivial to commit in any case
(see the GCS for guidelines on this), then flag this against their
name in the header, thus:
yyyy-mm-dd Name of Author <email@address> (tiny change)
* In ChangeLog.2004 and earlier, 'Name of Author' was sometimes the name
of the author of the ChangeLog when the person who made the change
being documented didn't supply one. In that case separated from
the previous field by a blank line and indented by 1 tab (note, only
1 space between fields here) you will see:
From Author of Actual Change <email@address>:
As of now, don't do that anymore, since the GNU Coding Standards say
that the author of the change must be credited in the main entry
header for legal purposes.
* Preferably the next part should be a description of the overall
purpose of the change, separated from the header by a blank line,
indented by 1 tab, and filled at column 72. The last character of the
description should be a period. Ideally, this description fits on one
line, or begins with a one-line summary.
* Changes to each file come next. Each new file starts on a new line,
indented by 1 tab and starting with an asterisk and a space. Multiple
files can be listed here relative to $top_srcdir, and comma separated.
Names of functions (or sections as appropriate) to which the change
applies should be named inside parentheses and comma separated. If
this goes beyond column 72, then parens should be closed and re-opened
on the next line:
* file, another/file, test/testcases/foo.test (func_foo)
(func_bar, func_baz): Description of changes.
* If the change does not apply to particular functions (or sections),
the section list can be omitted:
* file, another/file, test/testcases/foo.test: General changes.
* If the changes are particular to certain architectures, they should be
listed after the functions in square brackets:
* file, another/file (func_foo) [linux, solaris]: Description of
changes.
* Subsequent changes in other files that are related to the same overall
enhancement or bugfix should be listed concurrently, without blank
lines. Always start a fresh line for a new file:
* file, another/file (func_foo) [linux, solaris]: Description of
changes.
* doc/foo.texi (Invoking Foo): Document.
* NEWS: Updated.
* If the change is in response to a problem reported by someone other
than the author, then credit them at the end of the description with:
Reported by Reporter Name <email@address>.
* See the GNU Coding Standards document for more details on ChangeLog
formatting.
2005-01-08 Ralf Wildenhues <Ralf.Wildenhues@gmx.de> (tiny change),
Peter O'Gorman <peter@pogma.com>
This is the overall description of the purpose of this change
and any useful background for a model ChangeLog entry.
* HACKING: Updated copyright. This isn't attached to a
particular section of the file, so it comes first.
(Editing 'ChangeLog'): New section. This applies to the same
file, but since it applies to a particular section it starts on
a new line.
(Introduction, Maintenance Notes, Test Suite, Naming)
(Editing '.am' Files): If I had changed all these sections in
the same way, I can list them like this, being careful to close
and reopen the parentheses when starting a new line. The colon
only comes after the last section before this description.
* NEWS: Updated.
Reported by Bob Friesenhahn <bfriesen@simple.dallas.tx.us>.
6. Using git
============
* Preferably, let the git commit message mirror the ChangeLog entry,
without the leading TABs. Use --author for the (first, main) author
of patches from others, sign patches you have reviewed. If the
ChangeLog entry is longer than a line, use a one line summary, then an
empty line, then the rest of the log entry; this makes for nice output
of `git log'.
* You may find it useful to install the git-merge-changelog merge driver:
<http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c>
* Do not ever rewind the public master branch nor any public release
branch on savannah, neither any release tags once they have been
published. Other branches and tags may have different rules.
* Avoid merge commits on the master branch of the public git repository.
For unpublished changes in your development tree, it's easiest to
rebase against the current master before applying them, this preserves
a linear history.
7. Editing `.am' Files
======================
* Always use $(...) and not ${...}
* Use `:', not `true'. Use `exit 1', not `false'.
* Use `##' comments liberally. Comment anything even remotely unusual.
* Never use basename or dirname. Instead use sed.
* Do not use `cd' within back-quotes, use `$(lt__cd)' instead.
Otherwise the directory name may be printed, depending on CDPATH.
* In general, if a loop is required, it should be silent. Then the body
of the loop itself should print each "important" command it runs.
* Use 4 extra spaces to indent continued dependencies.
* One needs to remember that for our whole logic for the different
libltdl modes to function correctly, the thing we need to ensure
*before the client runs libtoolize*, is that the subpackage case is
correct (because all files may be symlinked there). All others can
and will be fixed in the `libtoolize --ltdl --(non)recursive' stage.
8. Editing `.m4sh' Files
========================
* Use shell functions, but be careful not to assume local scope for
variable names. Don't use `return', instead echo the result of a
function and call it from within backquotes.
* Function names should be prefixed `func_', the function header should
look like this:
# func_foo [ OPTIONS ]
# Description of what func_foo does and returns.
func_foo ()
{
$opt_debug
# contents of func_foo ...
}
The `$opt_debug' is used to enable shell tracing (Korn shells reset
this on function entry).
* For functions that are called frequently, if you need to return a
value, don't cause unneccessary forking of the shell using echo as
described above; instead set the return value in a variable named
after the called function with a suffix of `_result'. For example
the function `func_quote_for_eval' stores its return value in the
variable `$func_quote_for_eval_result'.
* Although sh-indentation is set to 2 (by the `Local Variables:' block
at the end of .m4sh files), the left margin of the body of shell
functions should begin indented by 4 spaces.
* Where there are large blocks of shell code with no m4 or m4sh
expansions, put the entire block in an M4SH_VERBATIM call. This
saves both on copy-and-paste errors, and needing to remember to
internally double the m4 quoting characters:
M4SH_VERBATIM([[
my_sed_long_opt='1s/^\(--[^=]*\)=.*/\1/;q'
...
]])
9. Editing `.m4' Files
======================
* Be careful with both `echo' and `$ECHO'. As the latter may be one of
print -r --
printf %s\n
func_fallback_echo
it may not have more than one argument and its value may not be
eval'ed. However, the argument may start with a `-' and contain
backslashes. As a rule of thumb, use
echo .. for literal (constant) strings without leading
hyphen and no backslashes within,
$ECHO ".." otherwise.
func_echo_all when multiple arguments are present, or when
placed in an eval'ed variable.
* The Autoconf manual says that giving an empty parameter is equivalent
to not giving it at all. (In particular, the Autoconf manual doesn't
explain that "FOO()" is calling macro FOO with one empty parameter.)
To prevent misunderstanding, we should use m4_ifval to check whether
a parameter is empty, and not $# to check for the number of parameters.
* Any time we add a macro to an older version, lt~obsolete.m4 needs to
be updated in all newer versions.
10. Abstraction layers in libltdl
=================================
* The libltdl API uses a layered approach to differentiate internal and
external interfaces, among other things. To keep the abstraction
consistent, files in a given layer may only use APIs from files in the
lower layers. The ASCII art boxes below represent this stack, from
top to bottom...
* But first, outside of the stack, there is a convenience header that
defines the internal interfaces (as evidenced by the `lt__' prefix to
the filename!) shared between implementation files in the stack, that
are however not exported to libltdl clients:
,-------------.
|lt__private.h|
`-------------'
* The top layer of the stack is the libltdl API proper, which includes
the relevant subsystems automatically. Clients of libltdl need only
invoke:
#include <ltdl.h>
,------.
|ltdl.h|
+------+
|ltdl.c|
`------'
* The next layer is comprised of the subsystems of the exported libltdl
API, which are implemented by files that are named with a leading `lt_'
(single underscore!):
,------------v---------------.
| lt_error.h | lt_dlloader.h |
+------------+---------------+
| lt_error.c | lt_dlloader.c |
`------------^---------------'
* The next file is used both by the headers that implement it (in which
case its function is to avoid namespace clashes when linking with the
GNU C library proper) and is included by code that wants to program
against a glibc-like interface, in which case it serves to pull in all
the glibc-like functionality used by libltdl with a simple:
#include <libltdl/lt__glibc.h>
It consists of a single file:
,-----------.
|lt__glibc.h|
`-----------'
* Next to last is the libc abstraction layer, which provides a uniform
API to various system libc interfaces that differ between hosts
supported by libtool. Typically, the files that implement this layer
begin:
#if defined(LT_CONFIG_H)
# include LT_CONFIG_H
#else
# include <config.h>
#endif
#include "lt_system.h"
Or if they are installed headers that must work outside the libtool
source tree, simply:
#include <libltdl/lt_system.h>
This layer's interface is defined by files that are usually named with
a leading `lt__':
,--------------v-------------v------------v--------v---------.
| lt__dirent.h | lt__alloc.h | lt__strl.h | argz.h | slist.h |
+--------------+-------------+------------+--------+---------+
| lt__dirent.c | lt__alloc.c | lt__strl.c | argz.c | slist.c |
`--------------^-------------^------------^--------^---------'
(argz.h and slist.h are used independently of libltdl in other projects)
* At the bottom of the stack we have the system abstraction layer,
which tries to smooth over the cracks where there are differences
between host systems and compilers. config.h is generated at
configure time and is not installed; lt_system.h is an installed
file and cannot use macros from config.h:
,-----------.
|../config.h|
`-----------'
,-----------.
|lt_system.h|
`-----------'
* Tacked on the side of this stack, attached via the lt_dlloader.h
definitions are the various implementation modules for run-time module
loading: preopen.c, dlopen.c etc.
11. Licensing Rules
===================
GNU Libtool uses 3 different licenses for various of the files distributed
herein, with 7 variations on license text. It is important that you use
the correct license text in each new file added. Here are the texts
along with some notes on when each is appropriate. Appropriate commenting
(shell, C etc) and decoration (m4sh etc) assumed throughout.
11.1. Notice preservation
Autoconf macros and files used to generate them need this license:
Copyright (C) <year list> Free Software Foundation, Inc.
Written by <author>, <year>
This file is free software; the Free Software Foundation gives
unlimited permission to copy and/or distribute it, with or without
modifications, as long as this notice is preserved.
11.2. GPL
Everything else in the distribution has the following license text
unless there is good reason to use one of the other license texts
below:
Copyright (C) <year list> Free Software Foundation, Inc.
Written by <author>, <year>
This file is part of GNU Libtool.
GNU Libtool is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of
the License, or (at your option) any later version.
GNU Libtool is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Libtool; see the file COPYING. If not, a copy
can be downloaded from http://www.gnu.org/licenses/gpl.html,
or obtained by writing to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
11.3. GPL with Libtool exception clause
At the moment only `libltdl/README' needs the exception clause to
allow projects that distribute a copy of the libltdl sources to also
redistribute the README:
Copyright (C) <year list> Free Software Foundation, Inc.
Written by <author>, <year>
This file is part of GNU Libtool.
GNU Libtool is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of
the License, or (at your option) any later version.
As a special exception to the GNU General Public License,
if you distribute this file as part of a program or library that
is built using GNU Libtool, you may include this file under the
same distribution terms that you use for the rest of that program.
GNU Libtool is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Libtool; see the file COPYING. If not, a copy
can be downloaded from http://www.gnu.org/licenses/gpl.html,
or obtained by writing to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
11.4. GPL with Cvs-utils exception clause
GNU Libtool imports some m4sh infrastructure from the GNU Cvs-utils
project, namely `getopt.m4sh' and `general.m4sh'. Those files use
the GPL with their own exception clause as follows:
Copyright (C) <year list> Free Software Foundation, Inc.
Written by <author>, <year>
This file is part of GNU Cvs-utils.
GNU Cvs-utils is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of
the License, or (at you option) any later version.
As a special exception to the GNU General Public License, if you
distribute this file as part of a program or library that contains
a configuration script generated by Autoconf, you may include this
file under the same distribution terms that you use for the rest
of that program.
GNU Cvs-utils is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNES FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Libtool; see the file COPYING. If not, a copy
can be downloaded from http://www.gnu.org/licenses/gpl.html,
or obtained by writing to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
11.5. GPL with self extracting version
Some of the sources built atop Cvs-utils' m4sh framework use
getopt.m4sh:func_version() to extract their --version output from
the copyright block. Those files also need the --version copyright
text paragraph as follows:
<program name> (GNU @PACKAGE@) <version number>
Written by <author> <email address>.
This file is part of <parent package name>.
Copyright (C) <year list> Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
<program name> is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
<program name> is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with <program name>; see the file COPYING. If not, a copy
can be downloaded from http://www.gnu.org/licenses/gpl.html,
or obtained by writing to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
11.6. GPL with self extracting version and Libtool exception clause
Although the libtool script is generated from `ltmain.m4sh' according
to the rules in the preceding subsection, it also needs the Libtool
exception clause so that it can be redistributed by other projects
that use libtool:
<program name> (GNU @PACKAGE@@TIMESTAMP@) <version number>
Written by <author> <email address>.
This file is part of GNU Libtool.
Copyright (C) <year list> Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
<program name> is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
As a special exception to the GNU General Public License,
if you distribute this file as part of a program or library that
is built using GNU Libtool, you may include this file under the
same distribution terms that you use for the rest of that program.
<program name> is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with <program name>; see the file COPYING. If not, a copy
can be downloaded from http://www.gnu.org/licenses/gpl.html,
or obtained by writing to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
11.7. LGPL with Libtool exception clause
Finally, not only is Libltdl is LGPLed, but it is routinely
redistributed inside projects that use it, so its sources need to use
the following license text citing the LGPL along with Libtool's special
exception clause:
Copyright (C) <year list> Free Software Foundation, Inc.
Written by <author>, <year>
NOTE: The canonical source of this file is maintained with the
GNU Libtool package. Report bugs to bug-libtool@gnu.org.
GNU Libltdl is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.
As a special exception to the GNU Lesser General Public License,
if you distribute this file as part of a program or library that
is built using GNU Libtool, you may include this file under the
same distribution terms that you use for the rest of that program.
GNU Libltdl is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with GNU Libltdl; see the file COPYING.LIB. If not, a
copy can be downloaded from http://www.gnu.org/licenses/lgpl.html,
or obtained by writing to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
12. Release Procedure
=====================
* If you are a libtool maintainer, but have not yet registered your
gpg public key and (preferred) email address with the FSF, send an
email, preferably GPG-signed, to <ftp-upload@gnu.org> that includes
the following:
(a) name of package(s) that you are the maintainer for, and your
preferred email address.
(b) an ASCII armored copy of your GnuPG key, as an attachment.
("gpg --export -a YOUR_KEY_ID > mykey.asc" should give you
this.)
When you have received acknowledgement of your message, the proper GPG
keys will be registered on ftp-upload.gnu.org and only then will you be
authorized to upload files to the FSF ftp machines.
* If you do not have access to the mailing list administrative interface,
approach the list owners for the password. Be sure to check the lists
(esp. bug-libtool) for outstanding bug reports also in the list of
pending moderation requests.
* Make sure you have wget and lzma installed.
* Make sure your locale is sane, e.g. by exporting LC_ALL=C.
* Double check that serial number updates in public m4 files weren't forgotten
since last release (they should be updated in git along with commits that
require it so that users can work with git snapshots).
* Update the LTDL_VERSION_INFO in libltdl/Makefile.inc for changes since
the last release.
* Update the version number in configure.ac and libltdl/configure.ac.
See http://www.gnu.org/software/libtool/contribute.html for details of
the numbering scheme.
* Update NEWS, ChangeLog.
* Run ./bootstrap.
* Run ./configure (or create a build directory first and run configure
from there, if you want to keep the build tree separate).
* Run `make -fMakefile.maint fetch' (or `make -f../Makefile.maint fetch'
if you are running from a VPATH build directory, where `../' is the
relative path to the directory with `configure' in it), which will
fetch new versions of the files that are maintained outside of
libtool.
* Run `make distcheck'
and `make distcheck DISTCHECK_CONFIGURE_FLAGS=--disable-ltdl-install'
and `make distcheck DISTCHECK_CONFIGURE_FLAGS=--program-prefix=g'
and `make distcheck CC=g++'
If there are any problems, fix them and start again.
* Run `./commit -p' from the source tree.
* Run `make -fMakefile.maint git-dist' (or `make -f../Makefile.maint
git-dist' if you are running from a VPATH build directory, where `../'
is the relative path to the directory with `configure' in it), which
will build a release tarball (with `make distcheck'), tag the tree
with release-$(VERSION) and generate the gpg signature files.
* Run 'make -f[../]Makefile.maint diffs' (pass
LASTRELEASE=maj.min[.mic[alpha]] if needed) to create diff files
between the previous release tarball and the new with detached gpg
signature files and clear signed directive files.
* Upload release tarballs and diff files, plus their associated
detached gpg signature files and clear signed directive files to
ftp-upload.gnu.org. If the upload is destined for ftp.gnu.org, then the
files should be placed in the /incoming/ftp directory. If the upload is
an alpha release destined for alpha.gnu.org, then the files should be
placed in the /incoming/alpha directory.
* Update version number in configure.ac and libltdl/configure.ac to next
alpha number. See http://www.gnu.org/software/libtool/contribute.html
for details of the numbering scheme.
* Update NEWS, ChangeLog.
* Run `./commit -p --tags', to push the new changes and tags to origin.
* Update the webpages, libtool.html will need to indicate the latest
release number.
* If not an alpha, upload new manual pages with cvs to:
<yourusername>@cvs.savannah.gnu.org:/webcvs/libtool
(generate with `make -f[../]Makefile.maint web-manual').
* Send announcement to libtool@gnu.org and autotools-announce@gnu.org,
if not an alpha send to info-gnu@gnu.org as well.
* Post a copy of the release announcement to savannah news:
https://savannah.gnu.org/news/submit.php?group=libtool
which will automatically propogate to http://planet.gnu.org.
13. Alpha release note template
===============================
To: libtool@gnu.org, autotools-announce@gnu.org
Subject: GNU Libtool @VERSION@ released (alpha release).
The Libtool Team is pleased to announce alpha release @VERSION@ of GNU
Libtool.
GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl,
which hides the complexity of loading dynamic runtime libraries
(modules) behind a consistent, portable interface.
Here are the compressed sources:
ftp://alpha.gnu.org/gnu/libtool/libtool-@VERSION@.tar.gz
ftp://alpha.gnu.org/gnu/libtool/libtool-@VERSION@.tar.bz2
Here are the xdeltas and diffs against libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@:
ftp://alpha.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz
ftp://alpha.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta
Here are the gpg detached signatures:
ftp://alpha.gnu.org/gnu/libtool/libtool-@VERSION@.tar.gz.sig
ftp://alpha.gnu.org/gnu/libtool/libtool-@VERSION@.tar.bz2.sig
ftp://alpha.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz.sig
ftp://alpha.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta.sig
You should download the signature named after any tarball you download,
and then verify its integrity with, for example:
gpg --verify libtool-@VERSION@.tar.gz.sig
Here are the MD5 and SHA1 checksums:
@MD5SUM@ libtool-@VERSION@.tar.gz
@MD5SUM@ libtool-@VERSION@.tar.bz2
@MD5SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz
@MD5SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta
@SHA1SUM@ libtool-@VERSION@.tar.gz
@SHA1SUM@ libtool-@VERSION@.tar.bz2
@SHA1SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz
@SHA1SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta
This release has @SUMMARY_OF_IMPROVEMENTS_SINCE_LAST_RELEASE_ON_THIS_BRANCH@.
This release was bootstrapped with @BOOTSTRAP_TOOLS_WITH_VERSIONS@,
but is useable with @COMPATIBLE_AUTOTOOL_VERSIONS@ in your own
projects.
Alternatively, you can fetch the unbootstrapped source code with
git by using the following command:
$ git clone git://git.savannah.gnu.org/libtool.git
$ cd libtool
$ git checkout @GIT_RELEASE_TAG@
You will then need to have recent (possibly as yet unreleased) versions
of Automake and Autoconf installed to bootstrap the checked out
sources yourself.
New in @VERSION@: @RELEASE_DATE@
@EXCERPT_FROM_NEWS_FILE@
Please report bugs to <bug-libtool@gnu.org>, along with the verbose
output of any failed test groups, and the output from `./libtool --config.'
The README file explains how to capture the verbose test output.
14. Full release note template
==============================
To: info-gnu@gnu.org
Cc: libtool@gnu.org, autotools-announce@gnu.org
Subject: GNU Libtool @VERSION@ released.
The Libtool Team is pleased to announce the release of GNU Libtool
@VERSION@.
GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl,
which hides the complexity of loading dynamic runtime libraries
(modules) behind a consistent, portable interface.
This release has @SUMMARY_OF_IMPROVEMENTS_SINCE_LAST_RELEASE_ON_THIS_BRANCH@.
New in @VERSION@: @RELEASE_DATE@
@EXCERPT_FROM_NEWS_FILE@
libtool-@VERSION@ is available now from ftp.gnu.org, along with
diffs and xdeltas against libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@
that are also available from ftp.gnu.org. Please
use a mirror to reduce stress on the main gnu machine:
http://www.gnu.org/order/ftp.html
Here are the compressed sources:
ftp://ftp.gnu.org/gnu/libtool/libtool-@VERSION@.tar.gz
ftp://ftp.gnu.org/gnu/libtool/libtool-@VERSION@.tar.bz2
Here are the xdeltas and diffs against libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@:
ftp://ftp.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz
ftp://ftp.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta
Here are the gpg detached signatures:
ftp://ftp.gnu.org/gnu/libtool/libtool-@VERSION@.tar.gz.sig
ftp://ftp.gnu.org/gnu/libtool/libtool-@VERSION@.tar.bz2.sig
ftp://ftp.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz.sig
ftp://ftp.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta.sig
You should download the signature named after any tarball you download,
and then verify its integrity with, for example:
gpg --verify libtool-@VERSION@.tar.gz.sig
Here are the MD5 and SHA1 checksums:
@MD5SUM@ libtool-@VERSION@.tar.gz
@MD5SUM@ libtool-@VERSION@.tar.bz2
@MD5SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz
@MD5SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta
@SHA1SUM@ libtool-@VERSION@.tar.gz
@SHA1SUM@ libtool-@VERSION@.tar.bz2
@SHA1SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz
@SHA1SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta
This release was bootstrapped with @BOOTSTRAP_TOOLS_WITH_VERSIONS@,
but is useable with @COMPATIBLE_AUTOTOOL_VERSIONS@ in your own
projects.
Alternatively, you can fetch the unbootstrapped source code with
git by using the following command:
$ git clone git://git.savannah.gnu.org/libtool.git
$ cd libtool
$ git checkout @GIT_RELEASE_TAG@
You will then need to have the latest release versions of Automake
(@AUTOMAKE_VERSION@) and Autoconf (@AUTOCONF_VERSION@) installed to
bootstrap the checked out sources yourself.
Please report bugs to <bug-libtool@gnu.org>, along with the verbose
output of any failed test groups, and the output from `./libtool --config.'
The README file explains how to capture the verbose test output.
--
Copyright (C) 2004, 2005, 2006, 2007, 2008 Free Software Foundation,
Inc.
Written by Gary V. Vaughan, 2004
This file is part of GNU Libtool. Report bugs to bug-libtool@gnu.org.
GNU Libtool is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
GNU Libtool is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Libtool; see the file COPYING. If not, a copyi
can be downloaded from http://www.gnu.org/licenses/gpl.html,
or obtained by writing to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
Local Variables:
mode: text
fill-column: 72
End:
vim:tw=72
Reference in New Issue View Git Blame Copy Permalink