Regenerated.

FAQ

@@ -1078,7 +1078,7 @@ Note that I have at this point no information about any other platform.
 {AJ} This is at first a kernel issue.  The kernel defines limits with
 OPEN_MAX the number of simultaneous open files and with FD_SETSIZE the
 number of used file descriptors.  You need to change these values in your
-kernel and recompile the kernel so that the kernel allows to use more open
+kernel and recompile the kernel so that the kernel allows more open
 files.  You don't necessarily need to recompile the GNU C library since the
 only place where OPEN_MAX and FD_SETSIZE is really needed in the library
 itself is the size of fd_set which is used by select.

INSTALL

@@ -36,8 +36,8 @@ Configuring and compiling GNU Libc
 advise to build it in a separate build directory.  For example, if you
 have unpacked the glibc sources in `/src/gnu/glibc-2.1.0', create a
 directory `/src/gnu/glibc-build' to put the object files in.  This
-allows to remove the whole build directory in case an error occurs
-which is the safest way to get a clean way and should always be done.
+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.
 
    From your object directory, run the shell script `configure' found
 at the top level of the source tree.  In the scenario above, you'd type
@@ -193,6 +193,23 @@ distribution already includes the on-line formatted version of the
 manual, as Info files.  You can regenerate those with `make info', but
 it shouldn't be necessary.
 
+   The library has a number of special-purpose configuration parameters
+which you can find in `Makeconfig'.  These can be overwritten with the
+file `configparms'.  To change them, create a `configparms' in your
+build directory and add values as appropriate for your system.  The
+file is included and parsed by `make' and has to follow the conventions
+for makefiles.
+
+   It is easy to configure the GNU C library for cross-compilation by
+setting a few variables in `configparms'.  Set `CC' to the
+cross-compiler for the target you configured the library for; it is
+important to use this same `CC' value when running `configure', like
+this: `CC=TARGET-gcc configure TARGET'.  Set `BUILD_CC' to the compiler
+to use for for programs run on the build system as part of compiling
+the library.  You may need to set `AR' and `RANLIB' to cross-compiling
+versions of `ar' and `ranlib' if the native tools are not configured to
+work with object files for the target you configured for.
+
 Installing the C Library
 ========================
 
@@ -204,24 +221,37 @@ recommend that you shut the system down to single-user mode first, and
 reboot afterward.  This minimizes the risk of breaking things when the
 library changes out from underneath.
 
+   If you're upgrading from Linux libc5 or some other C library, you
+need to replace the `/usr/include' with a fresh directory before
+installing it.  The new `/usr/include' should contain the Linux
+headers, but nothing else.
+
+   You must first build the library (`make'), optionally check it
+(`make check'), switch the include directories and then install (`make
+install').  The steps must be done in this order.  Not moving the
+directory before install will result in an unusable mixture of header
+files from both libraries, but configuring, building, and checking the
+library requires the ability to compile and run programs against the old
+library.
+
    If you are upgrading from a previous installation of glibc 2.0 or
-2.1, `make install' will do the entire job.  If you're upgrading from
-Linux libc5 or some other C library, you need to rename the old
-`/usr/include' directory before running `make install', or you will end
-up with a mixture of header files from both libraries, and you won't be
-able to compile anything.  You may also need to reconfigure GCC to work
-with the new library.  The easiest way to do that is to figure out the
-compiler switches to make it work again
-(`-Wl,--dynamic-linker=/lib/ld-linux.so.2' should work on Linux
-systems) and use them to recompile gcc.  You can also edit the specs
-file (`/usr/lib/gcc-lib/TARGET/VERSION/specs'), but that is a bit of a
-black art.
+2.1, `make install' will do the entire job.  You do not need to remove
+the old includes - if you want to do so anyway you must then follow the
+order given above.
+
+   You may also need to reconfigure GCC to work with the new library.
+The easiest way to do that is to figure out the compiler switches to
+make it work again (`-Wl,--dynamic-linker=/lib/ld-linux.so.2' should
+work on Linux systems) and use them to recompile gcc.  You can also
+edit the specs file (`/usr/lib/gcc-lib/TARGET/VERSION/specs'), but that
+is a bit of a black art.
 
    You can install glibc somewhere other than where you configured it
 to go by setting the `install_root' variable on the command line for
 `make install'.  The value of this variable is prepended to all the
 paths for installation.  This is useful when setting up a chroot
-environment or preparing a binary distribution.
+environment or preparing a binary distribution.  The directory should be
+specified with an absolute file name.
 
    Glibc 2.1 includes two daemons, `nscd' and `utmpd', which you may or
 may not want to run.  `nscd' caches name service lookups; it can
@@ -273,13 +303,13 @@ build the GNU C library:
      to have bugs which only show up in big projects like GNU `libc'.
      Version 3.76.1 seems OK but some people have reported problems.
 
-   * EGCS 1.1.1, 1.1 or 1.0.3, or GCC 2.8.1, 2.95, 2.95.1
+   * EGCS 1.1.1, 1.1 or 1.0.3, or GCC 2.8.1, 2.95 or newer
 
      The GNU C library can only be compiled with the GNU C compiler
      family.  As of the 2.1 release, EGCS 1.0.3 or higher is required.
      GCC 2.8.1 can also be used (but see the FAQ for reasons why you
      might not want to).  Earlier versions simply are too buggy.  As of
-     this writing, GCC 2.95.1 is the compiler we advise to use.
+     this writing, GCC 2.95.2 is the compiler we advise to use.
 
      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
@@ -327,6 +357,15 @@ build the GNU C library:
      Perl is not required, but it is used if present to test the
      installation.  We may decide to use it elsewhere in the future.
 
+   * GNU `sed' 3.02 or newer
+
+     Sed is used in several places to generate files.  Most scripts
+     work with any version of `sed'.  The known exception is the script
+     `po2test.sed' in the `intl' subdirectory which is used to generate
+     `msgs.h' for the testsuite.  This script works correctly only with
+     GNU `sed' 3.02.  If you like to run the testsuite, you should
+     definitly upgrade `sed'.
+
 
 If you change any of the `configure.in' files you will also need
 
@@ -467,7 +506,7 @@ twice.
 
    If you think you have found some way in which the GNU C library does
 not conform to the ISO and POSIX standards (*note Standards and
-Portability::.), that is definitely a bug.  Report it!
+Portability::), that is definitely a bug.  Report it!
 
    Once you're sure you've found a bug, try to narrow it down to the
 smallest test case that reproduces the problem.  In the case of a C

NOTES

@@ -12,7 +12,7 @@ options.
 
    You should define these macros by using `#define' preprocessor
 directives at the top of your source code files.  These directives
-*must* come before any `#include' of a system header file.  It is best
+_must_ come before any `#include' of a system header file.  It is best
 to make them the very first thing in the file, preceded only by
 comments.  You could also use the `-D' option to GCC, but it's better
 if you make the source files indicate their own meaning in a
@@ -25,10 +25,10 @@ standards require functions with names that smaller ones reserve to the
 user program.  This is not mere pedantry -- it has been a problem in
 practice.  For instance, some non-GNU programs define functions named
 `getline' that have nothing to do with this library's `getline'.  They
-would not be compilable if all features were enabled indescriminantly.
+would not be compilable if all features were enabled indiscriminately.
 
    This should not be used to verify that a program conforms to a
-limited standard.  It is insufficent for this purpose, as it will not
+limited standard.  It is insufficient for this purpose, as it will not
 protect you from including header files outside the standard, or
 relying on semantics undefined within the standard.
 
@@ -125,17 +125,16 @@ relying on semantics undefined within the standard.
      extension (LFS).
 
  - Macro: _LARGEFILE64_SOURCE
-     If you define this macro an additional set of function gets
-     available which enables to use on 32 bit systems to use files of
-     sizes beyond the usual limit of 2GB.  This interface is not
-     available if the system does not support files that large.  On
-     systems where the natural file size limit is greater than 2GB
-     (i.e., on 64 bit systems) the new functions are identical to the
-     replaced functions.
+     If you define this macro an additional set of function is made
+     available which enables 32 bit systems to use files of sizes beyond
+     the usual limit of 2GB.  This interface is not available if the
+     system does not support files that large.  On systems where the
+     natural file size limit is greater than 2GB (i.e., on 64 bit
+     systems) the new functions are identical to the replaced functions.
 
      The new functionality is made available by a new set of types and
-     functions which replace existing.  The names of these new objects
-     contain `64' to indicate the intention, e.g., `off_t' vs.
+     functions which replace the existing ones.  The names of these new
+     objects contain `64' to indicate the intention, e.g., `off_t' vs.
      `off64_t' and `fseeko' vs. `fseeko64'.
 
      This macro was introduced as part of the Large File Support
@@ -143,17 +142,17 @@ relying on semantics undefined within the standard.
      offsets are not generally used (see `_FILE_OFFSET_BITS'.
 
  - Macro: _FILE_OFFSET_BITS
-     This macro lets decide which file system interface shall be used,
+     This macro determines which file system interface shall be used,
      one replacing the other.  While `_LARGEFILE64_SOURCE' makes the
      64 bit interface available as an additional interface
-     `_FILE_OFFSET_BITS' allows to use the 64 bit interface to replace
-     the old interface.
+     `_FILE_OFFSET_BITS' allows the 64 bit interface to replace the old
+     interface.
 
-     If `_FILE_OFFSET_BITS' is undefined or if it is defined to the
-     value `32' nothing changes.  The 32 bit interface is used and
+     If `_FILE_OFFSET_BITS' is undefined, or if it is defined to the
+     value `32', nothing changes.  The 32 bit interface is used and
      types like `off_t' have a size of 32 bits on 32 bit systems.
 
-     If the macro is defined to the value `64' the large file interface
+     If the macro is defined to the value `64', the large file interface
      replaces the old interface.  I.e., the functions are not made
      available under different names as `_LARGEFILE64_SOURCE' does.
      Instead the old function names now reference the new functions,
@@ -167,11 +166,17 @@ relying on semantics undefined within the standard.
      This macro was introduced as part of the Large File Support
      extension (LFS).
 
+ - Macro: _ISOC99_SOURCE
+     Until the revised ISO C standard is widely adopted the new features
+     are not automatically enabled.  The GNU libc nevertheless has a
+     complete implementation of the new standard and to enable the new
+     features the macro `_ISOC99_SOURCE' should be defined.
+
  - Macro: _GNU_SOURCE
-     If you define this macro, everything is included: ISO C, POSIX.1,
-     POSIX.2, BSD, SVID, X/Open, LFS, and GNU extensions.  In the cases
-     where POSIX.1 conflicts with BSD, the POSIX definitions take
-     precedence.
+     If you define this macro, everything is included: ISO C89,
+     ISO C99, POSIX.1, POSIX.2, BSD, SVID, X/Open, LFS, and GNU
+     extensions.  In the cases where POSIX.1 conflicts with BSD, the
+     POSIX definitions take precedence.
 
      If you want to get the full effect of `_GNU_SOURCE' but make the
      BSD definitions take precedence over the POSIX definitions, use
@@ -191,11 +196,10 @@ relying on semantics undefined within the standard.
      If you define one of these macros, reentrant versions of several
      functions get declared.  Some of the functions are specified in
      POSIX.1c but many others are only available on a few other systems
-     or are unique to GNU libc.  The problem is that the
-     standardization of the thread safe C library interface still is
-     behind.
+     or are unique to GNU libc.  The problem is the delay in the
+     standardization of the thread safe C library interface.
 
-     Unlike on some other systems no special version of the C library
+     Unlike on some other systems, no special version of the C library
      must be used for linking.  There is only one version but while
      compiling this it must have been specified to compile as thread
      safe.

README

@@ -57,10 +57,10 @@ for crypt; it is called `glibc-crypt-2.1.90.tar.gz'.  You can just
 unpack the crypt distribution along with the rest of the C library and
 build; you can also build the library without getting crypt.  Users
 outside the USA can get the crypt distribution via anonymous FTP from
-ftp.funet.fi [128.214.248.6] in the directory pub/gnu/funet, or
+ftp.gwdg.de [134.76.11.100] in the directory pub/linux/glibc, or
 another archive site outside the USA.  Archive maintainers are
 encouraged to copy this distribution to their archives outside the
-USA.  Please get it from ftp.funet.fi; transferring this distribution
+USA.  Please get it from ftp.gwdg.de; transferring this distribution
 from ftp.gnu.org (or any other site in the USA) to a site outside the
 USA is in violation of US export laws.