Update.glibc-2.1cvs/glibc-2_1

1999-02-04  Ulrich Drepper  <drepper@cygnus.com>

	* stdlib/strtoll.c: Add alias __strtoq_internal.
	* stdlib/strtoull.c: Add alias __strtouq_internal.

	* wcsmbs/mbrtowc.c: Correct logic testing for converted NUL
	character.  Patch by Owen Taylor <otaylor@redhat.com>.

1 files changed, 29 insertions, 28 deletions

diff --git a/manual/install.texi b/manual/install.texi
index a05114d..bfd1ca6 100644
--- a/manual/install.texi
+++ b/manual/install.texi
@@ -279,11 +279,12 @@ Version 3.76.1 seems OK but some people have reported problems.
 EGCS 1.1.1, 1.1 or 1.0.3
 
 The GNU C library can only be compiled with the GNU C compiler family.
-We recommend EGCS 1.0.3 or higher.  GCC 2.8.1 and older versions of EGCS
-may have problems, particularly on non-Intel architectures.  GCC 2.7.x
-has catastrophic bugs and cannot be used at all.  (You can use GCC 2.7.x
-to compile programs that use GNU libc, but you may have problems,
-particularly with the math functions.)
+As of the 2.1 release, EGCS 1.0.3 or higher is required.  GCC 2.8.1 cannot
+be used due to an incompatible implementation of some internal compiler
+support routines; see the FAQ for details.  GCC 2.7.x is simply too
+buggy.  You can use whatever compiler you like to compile programs that
+use GNU libc, but be aware that both GCC 2.7 and 2.8 have bugs in their
+floating-point support that may be triggered by the math library.
 
 On Alpha machines you need at least EGCS 1.1.1.  Earlier versions don't
 work reliably.
@@ -292,17 +293,17 @@ For PPC you might need some patches even on top of the last EGCS version.
 See the FAQ.
 
 @item
-GNU @code{binutils} 2.9.1, or 2.9.1.0.16
+GNU @code{binutils} 2.9.1, 2.9.1.0.16, or later 2.9.1.0.x release
 
 You must use GNU binutils (as and ld) if you want to build a shared
 library.  Even if you don't, we recommend you use them anyway.  No one
 has tested compilation with non-GNU binutils in a long time.
 
 The quality of binutils releases has varied a bit recently.  The bugs
-are in obscure features, but glibc uses quite a few of those.
-2.9.1 and 2.9.1.0.16 are known to work.  Versions after
-2.8.1.0.23 may or may not work.  Older versions definitely don't.
-2.9.1.0.16 is required on some platforms, like PPC and Arm.
+are in obscure features, but glibc uses quite a few of those.  2.9.1,
+2.9.1.0.16, and later 2.9.1.0.x releases are known to work.  Versions
+after 2.8.1.0.23 may or may not work.  Older versions definitely don't.
+2.9.1.0.16 or higher is required on some platforms, like PPC and Arm.
 
 For PPC you might need some patches even on top of the last binutils
 version.  See the FAQ.
@@ -335,7 +336,7 @@ If you change any of the @file{configure.in} files you will also need
 
 @itemize @bullet
 @item
-GNU @code{autoconf} 2.12
+GNU @code{autoconf} 2.12 or higher
 @end itemize
 
 @noindent
@@ -417,23 +418,23 @@ switches via @var{CFLAGS}.
 @cindex upgrading from libc5
 @cindex kernel header files
 
-If you are installing GNU libc on a Linux system, you need to have the
-header files from a development kernel around for reference.  You do not
-need to use the development kernel, just have its headers where glibc
-can get at them.  The easiest way to do this is to unpack a development
-kernel in a directory such as @file{/usr/src/linux-dev}.  In that
-directory, run @samp{make config} and accept all the defaults.  Then
-configure glibc with the option
-@samp{--with-headers=/usr/src/linux-dev/include}.  Use the latest
-development kernel you can get your hands on.
-
-An alternate tactic is to unpack the development kernel and run
-@samp{make config} as above.  Then rename or delete @file{/usr/include},
-create a new @file{/usr/include}, and make the usual symbolic links of
-@file{/usr/include/linux} and @file{/usr/include/asm} into the
-development kernel sources.  You can then configure glibc with no
-special options.  This tactic is recommended if you are upgrading from
-libc5, since you need to get rid of the old header files anyway.
+If you are installing GNU libc on a Linux system, you need to have
+the header files from a 2.2 kernel around for reference.  You do not
+need to use the 2.2 kernel, just have its headers where glibc can get
+at them.  The easiest way to do this is to unpack it in a directory
+such as @file{/usr/src/linux-2.2.1}.  In that directory, run
+@samp{make config} and accept all the defaults.  Then run @samp{make
+include/linux/version.h}.  Finally, configure glibc with the option
+@samp{--with-headers=/usr/src/linux-2.2.1/include}.  Use the most recent
+kernel you can get your hands on.
+
+An alternate tactic is to unpack the 2.2 kernel and run @samp{make
+config} as above.  Then rename or delete @file{/usr/include}, create
+a new @file{/usr/include}, and make the usual symbolic links of
+@file{/usr/include/linux} and @file{/usr/include/asm} into the 2.2
+kernel sources.  You can then configure glibc with no special options.
+This tactic is recommended if you are upgrading from libc5, since you
+need to get rid of the old header files anyway.
 
 Note that @file{/usr/include/net} and @file{/usr/include/scsi} should
 @strong{not} be symlinks into the kernel sources.  GNU libc provides its