Go to file
Gary V. Vaughan 97e1a8755a The checks in assign.test are trying to catch case of this ilk:
`foo=bar break', but unfortunately they also choke on `foo=bar;
break' and `foo=bar && break'.  Writing a sophisticated test to
catch just the intended case seems like more trouble than it's
worth, but leaving the test in causes the testsuite to fail on
valid m4sh output:

* tests/assign.test: Removed; chokes on perfectly valid shell
syntax.
* tests/Makefile.am (COMMON_TESTS): Remove assign.test.
* tests/defs.in (scripts): Don't check the m4sh inputs, go back
to checking the generated ltmain.sh script.
2004-09-19 23:21:45 +00:00
config * config/ltmain.in (func_echo): Except for multi-line warnings and 2004-09-17 17:12:17 +00:00
doc Add a new `-weak' flag to tell libtool when not to propogate 2004-08-29 16:05:34 +00:00
libltdl * libltdl/loaders/loadlibrary.c: Compilation fixes (originally 2004-09-15 18:24:00 +00:00
m4 * m4/libtool.m4: remove an extra "]" 2004-09-17 13:54:05 +00:00
mail
tests The checks in assign.test are trying to catch case of this ilk: 2004-09-19 23:21:45 +00:00
.cvsignore * .cvsignore, config/.cvsignore, libltdl/loaders/.cvsignore, 2004-08-31 10:28:07 +00:00
AUTHORS * AUTHORS: Fix typo in my address. 2004-09-03 00:29:52 +00:00
bootstrap * bootstrap: Remember that the ltmain.sh generated by bootstrap 2004-09-03 08:10:21 +00:00
ChangeLog The checks in assign.test are trying to catch case of this ilk: 2004-09-19 23:21:45 +00:00
ChangeLog.1996
ChangeLog.1997
ChangeLog.1998
ChangeLog.1999
ChangeLog.2000
ChangeLog.2001
ChangeLog.2002
ChangeLog.2003 * ChangeLog.2003: New file, containing all the ChangeLog entries 2004-01-06 19:43:09 +00:00
commit * commit (SHELL): Set it explicitly, incase some madman is using 2004-02-18 09:55:53 +00:00
configure.ac My most recent `2004-09-02 Gary V. Vaughan' patch for mkdir_p 2004-09-16 14:57:02 +00:00
HACKING * HACKING: Explain how to verify detached signatures with gpg in 2004-09-03 00:34:48 +00:00
libtoolize.in Missed a couple of MKDIR_P references in ltmain.in in my last 2004-09-17 14:13:04 +00:00
ltmain.c
Makefile.am My most recent `2004-09-02 Gary V. Vaughan' patch for mkdir_p 2004-09-16 14:57:02 +00:00
Makefile.maint * NEWS: Updated. 2004-08-29 21:42:15 +00:00
NEWS My most recent `2004-09-02 Gary V. Vaughan' patch for mkdir_p 2004-09-16 14:57:02 +00:00
PORTING
README To help users submit better bug reports, improve the general 2004-08-28 16:15:23 +00:00
README.alpha * Makefile.am (dist-hook): Only run if README-alpha exists. 2004-08-29 19:52:20 +00:00
THANKS * libltdl/slist.c, libltdl/slist.h: Merge in changes from latest 2004-09-02 12:55:32 +00:00
TODO From Martin Quinson <mquinson@ens-lyon.fr> 2004-09-03 01:54:37 +00:00

GNU Libtool
***********

1. Introduction
===============

This is GNU Libtool, a generic library support script.  Libtool hides
the complexity of using shared libraries behind a consistent, portable
interface.

To use libtool, add the new generic library building commands to your
Makefile, Makefile.in, or Makefile.am.  See the documentation for
details.

Libtool's home page is:

  http://www.gnu.org/software/libtool/libtool.html

See the file NEWS for a description of recent changes to libtool.

See the file INSTALL for instructions on how to build and install
libtool.

See the info node (libtool)Tested Platforms. (or the file
doc/PLATFORMS) for a list of platforms that libtool supports.


2. Reporting Bugs
=================

If you have any suggestions or bug reports, or you wish to port
libtool to a new platform, please send electronic mail to the libtool
mailing list <libtool@gnu.org> or bug reports to <bug-libtool@gnu.org>.
Be sure to send us your information from the end of the help message
given by `./libtool --help'.


3. The Test Suite
=================

Libtool comes with an integrated set of tests to check that your build
is sane.  You can run the entire suite like this:

  make check

The tests run in groups in the various demo subdirectories, so if one
of the tests early in a group FAILs, the rest of the tests in that
group will be SKIPPED.  If you see a FAIL further into a group, even
if a test with the same name PASSes in another test group, you need to
take note of the name of the first test in the group if you want to
rerun the group with FAILures to get verbose output.

To run a test group in isolation (say, you think you have fixed a bug,
but don't want to rerun the entire suit), you can do it like this:

  make check TESTS='cdemo-static.test cdemo-make.test cdemo-exec.test'

Providing that you have a FAIL from the most recent group from a
particular demo directory (like the cdemo-static.test group above), you
can explore the state of the directory to help with debugging.

If you wish to report a test group failure to the libtool list, you
need to send the verbose output of the FAILing group, along with the
information from the end of `$(top_builddir)/libtool --help' to the
bug report mailing list, <bug-libtool@gnu.org>.  From a bourne
compatible shell, you can generate verbose test output like this:

  VERBOSE=1 make check \
  TESTS='cdemo-static.test cdemo-make.test cdemo-exec.test' \
  | tee cdemo-static-group.log


4. Version Numbering
====================

People have complained that they find the version numbering scheme
under which libtool is released confusing... so we've changed it!

It works like this:

	<major-number>.<minor-number>

Releases with a <major-number> less than 1 were not yet feature
complete.  Releases with a <major-number> of 1 used the old numbering
scheme that everyone disliked so much.  Releases with a <major-number>
of 2 us the new scheme described here.  If libtool ever undergoes a
major rewrite or substantial restructuring, the <major-number> will be
incremented again.

If we make a patch release to fix bugs in a stable release, we use a
third number, so:

      <major-number>.<minor-number>.<micro-number>

Version numbers are chosen to make it easy for users to decide two
things:

  Q: How `developed' is this release?
  A: The higher the number, the better!
  Q: How `stable' is this release?
  A: - If the <minor-number> is even, it is a stable release, `2.0'.
     - If the <minor-number> is odd, it is a development version with
       new features compared to the last stable release, `2.1a'.
     - If it has an `odd'[1] letter after the version number,  it is a
       snapshot direct from CVS, `2.1a'.
     - If it has an `even'[1] letter after the version number, it is an
       alpha quality release, `2.1b'.
     - If it has three numbers in the version, it is a patch release,
       fixing bugs from the stable release (with no new features), `2.0.1'.

[1] We always increment the letter in the repository before *and* after
    making a release tarball.  This means that "odd" letters
    (a,c,e,g...) only exist in the repository, and "even" letters are
    used instantaneously for an alpha release.  Since the odd lettered
    version numbers cover many states of the tree, we also qualify them
    by adding the cvs version of the ChangeLog:

    $ libtool --version
    ltmain.sh (GNU libtool 1.1603 2004/09/12 22:02:07) 2.1a

    Copyright (C) 2004  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.

For more details about version numbers, see:

    http://www.gnu.org/software/libtool/contribute.html

-- 
Copyright (C) 2004 Free Software Foundation, Inc.

The canonical source of this file is maintained with the
GNU Libtool package.  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.

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 it 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; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307  USA


Local Variables:
mode: text
fill-column: 72
End: