This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Clean up glibc version numbers in manual
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: libc-alpha at sourceware dot org
- Date: Sun, 19 Feb 2012 23:21:47 +0000 (UTC)
- Subject: Clean up glibc version numbers in manual
The install.texi file (and so the generated INSTALL file) mentions
specific, very old glibc version numbers in the following places:
* In an example directory name, glibc-2.4 (and glibc-libidn-2.4).
* Stating that glibc 2.2 includes nscd.
* Stating that certain compiler versions are required to build glibc
2.4.
Nowhere else does the manual try to document what particular old
versions of glibc do; it can be taken as trying to document the
particular glibc version it comes with, instead.
There is a version number (and UPDATED date) in libc.texinfo. That
version number is out of date (and it's not really meaningful to say
somehow that the last "significant" change was for an old version on
an old date; just making this the current version seems more
practical). That VERSION setting can't be used in install.texi
because install.texi is also built on its own to make the INSTALL file
(and makeinfo's -D option only supports -Dvariable, not
-Dvariable=value, so you can't get the version from the makefile when
building INSTALL without further complication).
So I propose this patch to clean up the version numbers. In
install.texi, all specific numbers are removed; the example
directories now use @var{version}. In libc.texinfo, the current
version number and date are used. I've added a section "Major Release
Process" to <http://sourceware.org/glibc/wiki/Release> listing the
steps I know of that should happen at various times each release cycle
on master, and it includes updating these values in libc.texinfo both
before tagging and when a new cycle starts - that is, at the same time
as version.h is updated. As long as this checklist is followed, we
can hopefully keep this version number in sync with version.h.
(While the makefiles could generate a file with the version number in
it for both the main manual and INSTALL, that would add a "regenerate
INSTALL" step if you keep any version numbers in INSTALL. If you
don't keep them there, I still doubt it's worth the complexity in
order to avoid changing libc.texinfo at release time.)
2012-02-19 Joseph Myers <joseph@codesourcery.com>
* manual/install.texi: Do not mention specific glibc version
numbers.
* manual/libc.texinfo (VERSION, UPDATED): Update.
diff --git a/manual/install.texi b/manual/install.texi
index 61ff23c..8bfd5f1 100644
--- a/manual/install.texi
+++ b/manual/install.texi
@@ -35,7 +35,7 @@ GNU Make, and possibly others. @xref{Tools for Compilation}, below.
GNU libc cannot be compiled in the source directory. You must build
it in a separate build directory. For example, if you have unpacked
-the glibc sources in @file{/src/gnu/glibc-2.4}, create a directory
+the glibc sources in @file{/src/gnu/glibc-@var{version}}, create a directory
@file{/src/gnu/glibc-build} to put the object files in. This allows
removing the whole build directory in case an error occurs, which is
the safest way to get a fresh start and should always be done.
@@ -44,7 +44,7 @@ From your object directory, run the shell script @file{configure} located
at the top level of the source tree. In the scenario above, you'd type
@smallexample
-$ ../glibc-2.4/configure @var{args@dots{}}
+$ ../glibc-@var{version}/configure @var{args@dots{}}
@end smallexample
Please note that even though you're building in a separate build
@@ -98,7 +98,7 @@ spaces or commas (if you use spaces, remember to quote them from the
shell). Each add-on in @var{list} can be an absolute directory name
or can be a directory name relative to the main source directory, or
relative to the build directory (that is, the current working directory).
-For example, @samp{--enable-add-ons=nptl,../glibc-libidn-2.4}.
+For example, @samp{--enable-add-ons=nptl,../glibc-libidn-@var{version}}.
@item --enable-kernel=@var{version}
This option is currently only useful on GNU/Linux systems. The
@@ -262,7 +262,7 @@ paths for installation. This is useful when setting up a chroot
environment or preparing a binary distribution. The directory should be
specified with an absolute file name.
-Glibc 2.2 includes a daemon called @code{nscd}, which you
+Glibc includes a daemon called @code{nscd}, which you
may or may not want to run. @code{nscd} caches name service lookups; it
can dramatically improve performance with NIS+, and may help with DNS as
well.
@@ -315,11 +315,11 @@ bugs or lack features.
@item
GCC 3.4 or newer, GCC 4.1 recommended
-For the 2.4 release or later, GCC 3.4 or higher is required; as of this
+GCC 3.4 or higher is required; as of this
writing, GCC 4.4 is the compiler we advise to use for current versions.
On certain machines including @code{powerpc64}, compilers prior to GCC
-4.0 have bugs that prevent them compiling the C library code in the
-2.4 release. On other machines, GCC 4.1 is required to build the C
+4.0 have bugs that prevent them compiling the C library code. On other
+machines, GCC 4.1 is required to build the C
library with support for the correct @code{long double} type format;
these include @code{powerpc} (32 bit), @code{s390} and @code{s390x}. For
other architectures special compiler-provided headers are needed
diff --git a/manual/libc.texinfo b/manual/libc.texinfo
index dfbfac3..68b12d8 100644
--- a/manual/libc.texinfo
+++ b/manual/libc.texinfo
@@ -19,8 +19,8 @@
@c sold 0.06/1.09, print run out 21may96
@set EDITION 0.13
-@set VERSION 2.14
-@set UPDATED 2011-07-19
+@set VERSION 2.15.90
+@set UPDATED 2012-02-19
@set ISBN 1-882114-55-8
@copying
--
Joseph S. Myers
joseph@codesourcery.com