(_int_free): Add inexpensive double free and memory corruption tests.
[kopensolaris-gnu/glibc.git] / INSTALL
diff --git a/INSTALL b/INSTALL
index 1476bd8..e424610 100644 (file)
--- a/INSTALL
+++ b/INSTALL
-Library Maintenance
-*******************
-
-How to Install the GNU C Library
-================================
-
-   Installation of the GNU C library is relatively simple.
-
-   You need the latest version of GNU `make'.  Modifying the GNU C
-Library to work with other `make' programs would be so hard that we
-recommend you port GNU `make' instead.  *Really.*
-
-   To configure the GNU C library for your system, run the shell script
-`configure' with `sh'.  Use an argument which is the conventional GNU
-name for your system configuration--for example, `sparc-sun-sunos4.1',
-for a Sun 4 running Sunos 4.1.  *Note Installation:
-(gcc.info)Installation, for a full description of standard GNU
-configuration names.  If you omit the configuration name, `configure'
-will try to guess one for you by inspecting the system it is running
-on.  It may or may not be able to come up with a guess, and the its
-guess might be wrong.  `configure' will tell you the canonical name of
-the chosen configuration before proceeding.
-
-   The GNU C Library currently supports configurations that match the
-following patterns:
-
-     alpha-dec-osf1
-     i386-ANYTHING-bsd4.3
-     i386-ANYTHING-gnu
-     i386-ANYTHING-isc2.2
-     i386-ANYTHING-isc3.N
-     i386-ANYTHING-sco3.2
-     i386-ANYTHING-sco3.2v4
-     i386-ANYTHING-sysv
-     i386-ANYTHING-sysv4
-     i386-force_cpu386-none
-     i386-sequent-bsd
-     i960-nindy960-none
-     m68k-hp-bsd4.3
-     m68k-mvme135-none
-     m68k-mvme136-none
-     m68k-sony-newsos3
-     m68k-sony-newsos4
-     m68k-sun-sunos4.N
-     mips-dec-ultrix4.N
-     mips-sgi-irix4.N
-     sparc-sun-solaris2.N
-     sparc-sun-sunos4.N
-
-   While no other configurations are supported, there are handy aliases
-for these few.  (These aliases work in other GNU software as well.)
-
-     decstation
-     hp320-bsd4.3 hp300bsd
-     i386-sco
-     i386-sco3.2v4
-     i386-sequent-dynix
-     i386-svr4
-     news
-     sun3-sunos4.N sun3
-     sun4-solaris2.N sun4-sunos5.N
-     sun4-sunos4.N sun4
-
-   Here are some options that you should specify (if appropriate) when
-you run `configure':
-
-`--with-gnu-ld'
-     Use this option if you plan to use GNU `ld' to link programs with
-     the GNU C Library.  (We strongly recommend that you do.)  This
-     option enables use of features that exist only in GNU `ld'; so if
-     you configure for GNU `ld' you must use GNU `ld' *every time* you
-     link with the GNU C Library, and when building it.
-
-`--with-gnu-as'
-     Use this option if you plan to use the GNU assembler, `gas', when
-     building the GNU C Library.  On some systems, the library may not
-     build properly if you do *not* use `gas'.
-
-`--nfp'
-     Use this option if your computer lacks hardware floating point
-     support.
+Appendix A Installing the GNU C Library
+***************************************
+
+Before you do anything else, you should read the file `FAQ' located at
+the top level of the source tree.  This file answers common questions
+and describes problems you may experience with compilation and
+installation.  It is updated more frequently than this manual.
+
+   Features can be added to GNU Libc via "add-on" bundles.  These are
+separate tar files, which you unpack into the top level of the source
+tree.  Then you give `configure' the `--enable-add-ons' option to
+activate them, and they will be compiled into the library.  As of the
+2.2 release, one important component of glibc is distributed as
+"official" add-ons: the linuxthreads add-on.  Unless you are doing an
+unusual installation, you should get this.
+
+   Support for POSIX threads is maintained by someone else, so it's in a
+separate package.  It is only available for GNU/Linux systems, but this
+will change in the future.  Get it from the same place you got the main
+bundle; the file is `glibc-linuxthreads-VERSION.tar.gz'.
+
+   You will need recent versions of several GNU tools: definitely GCC
+and GNU Make, and possibly others.  *Note Tools for Compilation::,
+below.
+
+A.1 Configuring and compiling GNU Libc
+======================================
+
+GNU libc can be compiled in the source directory, but we strongly advise
+building it in a separate build directory.  For example, if you have
+unpacked the glibc sources in `/src/gnu/glibc-2.3', create a directory
+`/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.
+
+   From your object directory, run the shell script `configure' located
+at the top level of the source tree.  In the scenario above, you'd type
+
+     $ ../glibc-2.3/configure ARGS...
+
+   Please note that even if you're building in a separate build
+directory, the compilation needs to modify a few files in the source
+directory, especially some files in the manual subdirectory.
+
+`configure' takes many options, but you can get away with knowing only
+two: `--prefix' and `--enable-add-ons'.  The `--prefix' option tells
+`configure' where you want glibc installed. This defaults to
+`/usr/local'.  The `--enable-add-ons' option tells `configure' to use
+all the add-on bundles it finds in the source directory.  Since
+important functionality is provided in add-ons, you should always
+specify this option.
+
+   It may also be useful to set the CC and CFLAGS variables in the
+environment when running `configure'.  CC selects the C compiler that
+will be used, and CFLAGS sets optimization options for the compiler.
+
+   The following list describes all of the available options for
+`configure':
 
 `--prefix=DIRECTORY'
      Install machine-independent data files in subdirectories of
-     `DIRECTORY'.  (You can also set this in `configparms'; see below.)
+     `DIRECTORY'.  The default is to install in `/usr/local'.
 
 `--exec-prefix=DIRECTORY'
      Install the library and other machine-dependent files in
-     subdirectories of `DIRECTORY'.  (You can also set this in
-     `configparms'; see below.)
-
-   The simplest way to run `configure' is to do it in the directory
-that contains the library sources.  This prepares to build the library
-in that very directory.
-
-   You can prepare to build the library in some other directory by going
-to that other directory to run `configure'.  In order to run configure,
-you will have to specify a directory for it, like this:
-
-     mkdir sun4
-     cd sun4
-     ../configure sparc-sun-sunos4.1
-
-`configure' looks for the sources in whatever directory you specified
-for finding `configure' itself.  It does not matter where in the file
-system the source and build directories are--as long as you specify the
-source directory when you run `configure', you will get the proper
-results.
-
-   This feature lets you keep sources and binaries in different
-directories, and that makes it easy to build the library for several
-different machines from the same set of sources.  Simply create a build
-directory for each target machine, and run `configure' in that
-directory specifying the target machine's configuration name.
-
-   The library has a number of special-purpose configuration parameters.
-These are defined in the file `Makeconfig'; see the comments in that
-file for the details.
-
-   But don't edit the file `Makeconfig' yourself--instead, create a
-file `configparms' in the directory where you are building the library,
-and define in that file the parameters you want to specify.
-`configparms' should *not* be an edited copy of `Makeconfig'; specify
-only the parameters that you want to override.  To see how to set these
-parameters, find the section of `Makeconfig' that says "These are the
-configuration variables." Then for each parameter that you want to
-change, copy the definition from `Makeconfig' to your new `configparms'
-file, and change the value as appropriate for your system.
+     subdirectories of `DIRECTORY'.  The default is to the `--prefix'
+     directory if that option is specified, or `/usr/local' otherwise.
+
+`--with-headers=DIRECTORY'
+     Look for kernel header files in DIRECTORY, not `/usr/include'.
+     Glibc needs information from the kernel's private header files.
+     Glibc will normally look in `/usr/include' for them, but if you
+     specify this option, it will look in DIRECTORY instead.
+
+     This option is primarily of use on a system where the headers in
+     `/usr/include' come from an older version of glibc.  Conflicts can
+     occasionally happen in this case.  Note that Linux libc5 qualifies
+     as an older version of glibc.  You can also use this option if you
+     want to compile glibc with a newer set of kernel headers than the
+     ones found in `/usr/include'.
+
+`--enable-add-ons[=LIST]'
+     Enable add-on packages in your source tree.  If this option is
+     specified with no list, it enables all the add-on packages it
+     finds.  If you do not wish to use some add-on packages that you
+     have present in your source tree, give this option a list of the
+     add-ons that you _do_ want used, like this:
+     `--enable-add-ons=linuxthreads'
+
+`--enable-kernel=VERSION'
+     This option is currently only useful on GNU/Linux systems.  The
+     VERSION parameter should have the form X.Y.Z and describes the
+     smallest version of the Linux kernel the generated library is
+     expected to support.  The higher the VERSION number is, the less
+     compatibility code is added, and the faster the code gets.
+
+`--with-binutils=DIRECTORY'
+     Use the binutils (assembler and linker) in `DIRECTORY', not the
+     ones the C compiler would default to.  You can use this option if
+     the default binutils on your system cannot deal with all the
+     constructs in the GNU C library.  In that case, `configure' will
+     detect the problem and suppress these constructs, so that the
+     library will still be usable, but functionality may be lost--for
+     example, you can't build a shared libc with old binutils.
+
+`--without-fp'
+     Use this option if your computer lacks hardware floating-point
+     support and your operating system does not emulate an FPU.
+
+     these
+
+`--disable-shared'
+     Don't build shared libraries even if it is possible.  Not all
+     systems support shared libraries; you need ELF support and
+     (currently) the GNU linker.
+
+`--disable-profile'
+     Don't build libraries with profiling information.  You may want to
+     use this option if you don't plan to do profiling.
+
+`--enable-omitfp'
+     Use maximum optimization for the normal (static and shared)
+     libraries, and compile separate static libraries with debugging
+     information and no optimization.  We recommend not doing this.
+     The extra optimization doesn't gain you much, it may provoke
+     compiler bugs, and you won't be able to trace bugs through the C
+     library.
+
+`--disable-versioning'
+     Don't compile the shared libraries with symbol version information.
+     Doing this will make the resulting library incompatible with old
+     binaries, so it's not recommended.
+
+`--enable-static-nss'
+     Compile static versions of the NSS (Name Service Switch) libraries.
+     This is not recommended because it defeats the purpose of NSS; a
+     program linked statically with the NSS libraries cannot be
+     dynamically reconfigured to use a different name database.
+
+`--without-tls'
+     By default the C library is built with support for thread-local
+     storage if the used tools support it.  By using `--without-tls'
+     this can be prevented though there generally is no reason since it
+     creates compatibility problems.
+
+`--build=BUILD-SYSTEM'
+`--host=HOST-SYSTEM'
+     These options are for cross-compiling.  If you specify both
+     options and BUILD-SYSTEM is different from HOST-SYSTEM, `configure'
+     will prepare to cross-compile glibc from BUILD-SYSTEM to be used
+     on HOST-SYSTEM.  You'll probably need the `--with-headers' option
+     too, and you may have to override CONFIGURE's selection of the
+     compiler and/or binutils.
+
+     If you only specify `--host', `configure' will prepare for a
+     native compile but use what you specify instead of guessing what
+     your system is. This is most useful to change the CPU submodel.
+     For example, if `configure' guesses your machine as
+     `i586-pc-linux-gnu' but you want to compile a library for 386es,
+     give `--host=i386-pc-linux-gnu' or just `--host=i386-linux' and add
+     the appropriate compiler flags (`-mcpu=i386' will do the trick) to
+     CFLAGS.
+
+     If you specify just `--build', `configure' will get confused.
+
+   To build the library and related programs, type `make'.  This will
+produce a lot of output, some of which may look like errors from `make'
+but isn't.  Look for error messages from `make' containing `***'.
+Those indicate that something is seriously wrong.
+
+   The compilation process can take several hours.  Expect at least two
+hours for the default configuration on i586 for GNU/Linux.  For Hurd,
+times are much longer.  Some complex modules may take a very long time
+to compile, as much as several minutes on slower machines.  Do not
+panic if the compiler appears to hang.
+
+   If you want to run a parallel make, simply pass the `-j' option with
+an appropriate numeric parameter to `make'.  You need a recent GNU
+`make' version, though.
+
+   To build and run test programs which exercise some of the library
+facilities, type `make check'.  If it does not complete successfully,
+do not use the built library, and report a bug after verifying that the
+problem is not already known.  *Note Reporting Bugs::, for instructions
+on reporting bugs.  Note that some of the tests assume they are not
+being run by `root'.  We recommend you compile and test glibc as an
+unprivileged user.
+
+   Before reporting bugs make sure there is no problem with your system.
+The tests (and later installation) use some pre-existing files of the
+system such as `/etc/passwd', `/etc/nsswitch.conf' and others.  These
+files must all contain correct and sensible content.
+
+   To format the `GNU C Library Reference Manual' for printing, type
+`make dvi'.  You need a working TeX installation to do this.  The
+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
+to use 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.
 
-   Some of the machine-dependent code for some machines uses extensions
-in the GNU C compiler, so you may need to compile the library with GCC.
-(In fact, all of the existing complete ports require GCC.)
-
-   The current release of the C library contains some header files that
-the compiler normally provides: `stddef.h', `stdarg.h', and several
-files with names of the form `va-MACHINE.h'.  The versions of these
-files that came with older releases of GCC do not work properly with
-the GNU C library.  The `stddef.h' file in release 2.2 and later of GCC
-is correct.  If you have release 2.2 or later of GCC, use its version
-of `stddef.h' instead of the C library's.  To do this, put the line
-`override stddef.h =' in `configparms'.  The other files are corrected
-in release 2.3 and later of GCC.  `configure' will automatically detect
-whether the installed `stdarg.h' and `va-MACHINE.h' files are
-compatible with the C library, and use its own if not.
-
-   There is a potential problem with the `size_t' type and versions of
-GCC prior to release 2.4.  ANSI C requires that `size_t' always be an
-unsigned type.  For compatibility with existing systems' header files,
-GCC defines `size_t' in `stddef.h' to be whatever type the system's
-`sys/types.h' defines it to be.  Most Unix systems that define `size_t'
-in `sys/types.h', define it to be a signed type.  Some code in the
-library depends on `size_t' being an unsigned type, and will not work
-correctly if it is signed.
-
-   The GNU C library code which expects `size_t' to be unsigned is
-correct.  The definition of `size_t' as a signed type is incorrect.
-Versions 2.4 and later of GCC always define `size_t' as an unsigned
-type, and GCC's `fixincludes' script massages the system's
-`sys/types.h' so as not to conflict with this.
-
-   In the meantime, we work around this problem by telling GCC
-explicitly to use an unsigned type for `size_t' when compiling the GNU C
-library.  `configure' will automatically detect what type GCC uses for
-`size_t' arrange to override it if necessary.
-
-   To build the library, type `make lib'.  This will produce a lot of
-output, some of which looks like errors from `make' (but isn't).  Look
-for error messages from `make' containing `***'.  Those indicate that
-something is really wrong.
-
-   To build and run some test programs which exercise some of the
-library facilities, type `make tests'.  This will produce several files
-with names like `PROGRAM.out'.
+A.2 Installing the C Library
+============================
+
+To install the library and its header files, and the Info files of the
+manual, type `env LANGUAGE=C LC_ALL=C make install'.  This will build
+things, if necessary, before installing them; however, you should still
+compile everything first.  If you are installing glibc as your primary
+C library, we 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.  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 GNU/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.  The directory should be
+specified with an absolute file name.
+
+   Glibc 2.2 includes a daemon called `nscd', which you may or may not
+want to run.  `nscd' caches name service lookups; it can dramatically
+improve performance with NIS+, and may help with DNS as well.
+
+   One auxiliary program, `/usr/libexec/pt_chown', is installed setuid
+`root'.  This program is invoked by the `grantpt' function; it sets the
+permissions on a pseudoterminal so it can be used by the calling
+process.  This means programs like `xterm' and `screen' do not have to
+be setuid to get a pty.  (There may be other reasons why they need
+privileges.)  If you are using a 2.1 or newer Linux kernel with the
+`devptsfs' or `devfs' filesystems providing pty slaves, you don't need
+this program; otherwise you do.  The source for `pt_chown' is in
+`login/programs/pt_chown.c'.
+
+   After installation you might want to configure the timezone and
+locale installation of your system.  The GNU C library comes with a
+locale database which gets configured with `localedef'.  For example, to
+set up a German locale with name `de_DE', simply issue the command
+`localedef -i de_DE -f ISO-8859-1 de_DE'.  To configure all locales
+that are supported by glibc, you can issue from your build directory the
+command `make localedata/install-locales'.
+
+   To configure the locally used timezone, set the `TZ' environment
+variable.  The script `tzselect' helps you to select the right value.
+As an example, for Germany, `tzselect' would tell you to use
+`TZ='Europe/Berlin''.  For a system wide installation (the given paths
+are for an installation with `--prefix=/usr'), link the timezone file
+which is in `/usr/share/zoneinfo' to the file `/etc/localtime'.  For
+Germany, you might execute `ln -s /usr/share/zoneinfo/Europe/Berlin
+/etc/localtime'.
+
+A.3 Recommended Tools for Compilation
+=====================================
+
+We recommend installing the following GNU tools before attempting to
+build the GNU C library:
+
+   * GNU `make' 3.79 or newer
+
+     You need the latest version of GNU `make'.  Modifying the GNU C
+     Library to work with other `make' programs would be so difficult
+     that we recommend you port GNU `make' instead.  *Really.*  We
+     recommend GNU `make' version 3.79.  All earlier versions have
+     severe bugs or lack features.
+
+   * GCC 3.2 or newer
+
+     The GNU C library can only be compiled with the GNU C compiler
+     family.  As of the 2.3 release, GCC 3.2 or higher is required.  As
+     of this writing, GCC 3.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
+     their floating-point support that may be triggered by the math
+     library.
+
+     Check the FAQ for any special compiler issues on particular
+     platforms.
+
+   * GNU `binutils' 2.13 or later
+
+     You must use GNU `binutils' (as and ld) to build the GNU C library.
+     No other assembler or linker has the necessary functionality at the
+     moment.
+
+   * GNU `texinfo' 3.12f
 
-   To format the `GNU C Library Reference Manual' for printing, type
-`make dvi'.  To format the Info version of the manual for on line
-reading with `C-h i' in Emacs or with the `info' program, type
-`make info'.
+     To correctly translate and install the Texinfo documentation you
+     need this version of the `texinfo' package.  Earlier versions do
+     not understand all the tags used in the document, and the
+     installation mechanism for the info files is not present or works
+     differently.
 
-   To install the library and its header files, and the Info files of
-the manual, type `make install', after setting the installation
-directories in `configparms'.  This will build things if necessary,
-before installing them.
+   * GNU `awk' 3.0, or some other POSIX awk
 
-Reporting Bugs
-==============
+     `Awk' is used in several places to generate files.  The scripts
+     should work with any POSIX-compliant `awk' implementation; `gawk'
+     3.0 and `mawk' 1.3 are known to work.
 
-   There are probably bugs in the GNU C library.  There are certainly
-errors and omissions in this manual.  If you report them, they will get
-fixed.  If you don't, no one will ever know about them and they will
-remain unfixed for all eternity, if not longer.
+   * Perl 5
 
-   To report a bug, first you must find it.  Hopefully, this will be the
-hard part.  Once you've found a bug, make sure it's really a bug.  A
-good way to do this is to see if the GNU C library behaves the same way
-some other C library does.  If so, probably you are wrong and the
-libraries are right (but not necessarily).  If not, one of the libraries
-is probably wrong.
+     Perl is not required, but it is used if present to test the
+     installation.  We may decide to use it elsewhere in the future.
 
-   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
-library, you really only need to narrow it down to one library function
-call, if possible.  This should not be too difficult.
+   * GNU `sed' 3.02 or newer
 
-   The final step when you have a simple test case is to report the bug.
-When reporting a bug, send your test case, the results you got, the
-results you expected, what you think the problem might be (if you've
-thought of anything), your system type, and the version of the GNU C
-library which you are using.  Also include the files `config.status'
-and `config.make' which are created by running `configure'; they will
-be in whatever directory was current when you ran `configure'.
+     `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 test suite.  This script works correctly only
+     with GNU `sed' 3.02.  If you like to run the test suite, you
+     should definitely upgrade `sed'.
 
-   If you think you have found some way in which the GNU C library does
-not conform to the ANSI and POSIX standards (*note Standards and
-Portability::.), that is definitely a bug.  Report it!
 
-   Send bug reports to the Internet address `bug-glibc@prep.ai.mit.edu'
-or the UUCP path `mit-eddie!prep.ai.mit.edu!bug-glibc'.  If you have
-other problems with installation or use, please report those as well.
+If you change any of the `configure.in' files you will also need
 
-   If you are not sure how a function should behave, and this manual
-doesn't tell you, that's a bug in the manual.  Report that too!  If the
-function's behavior disagrees with the manual, then either the library
-or the manual has a bug, so report the disagreement.  If you find any
-errors or omissions in this manual, please report them to the Internet
-address `bug-glibc-manual@prep.ai.mit.edu' or the UUCP path
-`mit-eddie!prep.ai.mit.edu!bug-glibc-manual'.
-
-Adding New Functions
-====================
-
-   The process of building the library is driven by the makefiles, which
-make heavy use of special features of GNU `make'.  The makefiles are
-very complex, and you probably don't want to try to understand them.
-But what they do is fairly straightforward, and only requires that you
-define a few variables in the right places.
-
-   The library sources are divided into subdirectories, grouped by
-topic.  The `string' subdirectory has all the string-manipulation
-functions, `stdio' has all the standard I/O functions, etc.
-
-   Each subdirectory contains a simple makefile, called `Makefile',
-which defines a few `make' variables and then includes the global
-makefile `Rules' with a line like:
-
-     include ../Rules
-
-The basic variables that a subdirectory makefile defines are:
-
-`subdir'
-     The name of the subdirectory, for example `stdio'.  This variable
-     *must* be defined.
-
-`headers'
-     The names of the header files in this section of the library, such
-     as `stdio.h'.
-
-`routines'
-`aux'
-     The names of the modules (source files) in this section of the
-     library.  These should be simple names, such as `strlen' (rather
-     than complete file names, such as `strlen.c').  Use `routines' for
-     modules that define functions in the library, and `aux' for
-     auxiliary modules containing things like data definitions.  But the
-     values of `routines' and `aux' are just concatenated, so there
-     really is no practical difference.
-
-`tests'
-     The names of test programs for this section of the library.  These
-     should be simple names, such as `tester' (rather than complete file
-     names, such as `tester.c').  `make tests' will build and run all
-     the test programs.  If a test program needs input, put the test
-     data in a file called `TEST-PROGRAM.input'; it will be given to
-     the test program on its standard input.  If a test program wants
-     to be run with arguments, put the arguments (all on a single line)
-     in a file called `TEST-PROGRAM.args'.
-
-`others'
-     The names of "other" programs associated with this section of the
-     library.  These are programs which are not tests per se, but are
-     other small programs included with the library.  They are built by
-     `make others'.
-
-`install-lib'
-`install-data'
-`install'
-     Files to be installed by `make install'.  Files listed in
-     `install-lib' are installed in the directory specified by `libdir'
-     in `configparms' or `Makeconfig' (*note Installation::.).  Files
-     listed in `install-data' are installed in the directory specified
-     by `datadir' in `configparms' or `Makeconfig'.  Files listed in
-     `install' are installed in the directory specified by `bindir' in
-     `configparms' or `Makeconfig'.
-
-`distribute'
-     Other files from this subdirectory which should be put into a
-     distribution tar file.  You need not list here the makefile itself
-     or the source and header files listed in the other standard
-     variables.  Only define `distribute' if there are files used in an
-     unusual way that should go into the distribution.
-
-`generated'
-     Files which are generated by `Makefile' in this subdirectory.
-     These files will be removed by `make clean', and they will never
-     go into a distribution.
-
-`extra-objs'
-     Extra object files which are built by `Makefile' in this
-     subdirectory.  This should be a list of file names like `foo.o';
-     the files will actually be found in whatever directory object
-     files are being built in.  These files will be removed by
-     `make clean'.  This variable is used for secondary object files
-     needed to build `others' or `tests'.
-
-Porting the GNU C Library
-=========================
-
-   The GNU C library is written to be easily portable to a variety of
-machines and operating systems.  Machine- and operating system-dependent
-functions are well separated to make it easy to add implementations for
-new machines or operating systems.  This section describes the layout of
-the library source tree and explains the mechanisms used to select
-machine-dependent code to use.
-
-   All the machine-dependent and operating system-dependent files in the
-library are in the subdirectory `sysdeps' under the top-level library
-source directory.  This directory contains a hierarchy of
-subdirectories (*note Hierarchy Conventions::.).
-
-   Each subdirectory of `sysdeps' contains source files for a
-particular machine or operating system, or for a class of machine or
-operating system (for example, systems by a particular vendor, or all
-machines that use IEEE 754 floating-point format).  A configuration
-specifies an ordered list of these subdirectories.  Each subdirectory
-implicitly appends its parent directory to the list.  For example,
-specifying the list `unix/bsd/vax' is equivalent to specifying the list
-`unix/bsd/vax unix/bsd unix'.  A subdirectory can also specify that it
-implies other subdirectories which are not directly above it in the
-directory hierarchy.  If the file `Implies' exists in a subdirectory,
-it lists other subdirectories of `sysdeps' which are appended to the
-list, appearing after the subdirectory containing the `Implies' file.
-Lines in an `Implies' file that begin with a `#' character are ignored
-as comments.  For example, `unix/bsd/Implies' contains:
-     # BSD has Internet-related things.
-     unix/inet
-
-and `unix/Implies' contains:
-     posix
-
-So the final list is `unix/bsd/vax unix/bsd unix/inet unix posix'.
-
-   `sysdeps' has two "special" subdirectories, called `generic' and
-`stub'.  These two are always implicitly appended to the list of
-subdirectories (in that order), so you needn't put them in an `Implies'
-file, and you should not create any subdirectories under them.
-`generic' is for things that can be implemented in machine-independent
-C, using only other machine-independent functions in the C library.
-`stub' is for "stub" versions of functions which cannot be implemented
-on a particular machine or operating system.  The stub functions always
-return an error, and set `errno' to `ENOSYS' (Function not
-implemented).  *Note Error Reporting::.
-
-   A source file is known to be system-dependent by its having a
-version in `generic' or `stub'; every system-dependent function should
-have either a generic or stub implementation (there is no point in
-having both).
-
-   If you come across a file that is in one of the main source
-directories (`string', `stdio', etc.), and you want to write a machine-
-or operating system-dependent version of it, move the file into
-`sysdeps/generic' and write your new implementation in the appropriate
-system-specific subdirectory.  Note that if a file is to be
-system-dependent, it *must not* appear in one of the main source
-directories.
-
-   There are a few special files that may exist in each subdirectory of
-`sysdeps':
-
-`Makefile'
-     A makefile for this machine or operating system, or class of
-     machine or operating system.  This file is included by the library
-     makefile `Makerules', which is used by the top-level makefile and
-     the subdirectory makefiles.  It can change the variables set in the
-     including makefile or add new rules.  It can use GNU `make'
-     conditional directives based on the variable `subdir' (see above)
-     to select different sets of variables and rules for different
-     sections of the library.  It can also set the `make' variable
-     `sysdep-routines', to specify extra modules to be included in the
-     library.  You should use `sysdep-routines' rather than adding
-     modules to `routines' because the latter is used in determining
-     what to distribute for each subdirectory of the main source tree.
-
-     Each makefile in a subdirectory in the ordered list of
-     subdirectories to be searched is included in order.  Since several
-     system-dependent makefiles may be included, each should append to
-     `sysdep-routines' rather than simply setting it:
-
-          sysdep-routines := $(sysdep-routines) foo bar
-
-`Subdirs'
-     This file contains the names of new whole subdirectories under the
-     top-level library source tree that should be included for this
-     system.  These subdirectories are treated just like the
-     system-independent subdirectories in the library source tree, such
-     as `stdio' and `math'.
-
-     Use this when there are completely new sets of functions and header
-     files that should go into the library for the system this
-     subdirectory of `sysdeps' implements.  For example,
-     `sysdeps/unix/inet/Subdirs' contains `inet'; the `inet' directory
-     contains various network-oriented operations which only make sense
-     to put in the library on systems that support the Internet.
-
-`Dist'
-     This file contains the names of files (relative to the
-     subdirectory of `sysdeps' in which it appears) which should be
-     included in the distribution.  List any new files used by rules in
-     the `Makefile' in the same directory, or header files used by the
-     source files in that directory.  You don't need to list files that
-     are implementations (either C or assembly source) of routines
-     whose names are given in the machine-independent makefiles in the
-     main source tree.
-
-`configure'
-     This file is a shell script fragment to be run at configuration
-     time.  The top-level `configure' script uses the shell `.' command
-     to read the `configure' file in each system-dependent directory
-     chosen, in order.  The `configure' files are often generated from
-     `configure.in' files using Autoconf.
-
-     A system-dependent `configure' script will usually add things to
-     the shell variables `DEFS' and `config_vars'; see the top-level
-     `configure' script for details.  The script can check for
-     `--with-PACKAGE' options that were passed to the top-level
-     `configure'.  For an option `--with-PACKAGE=VALUE' `configure'
-     sets the shell variable `with_PACKAGE' (with any dashes in PACKAGE
-     converted to underscores) to VALUE; if the option is just
-     `--with-PACKAGE' (no argument), then it sets `with_PACKAGE' to
-     `yes'.
-
-`configure.in'
-     This file is an Autoconf input fragment to be processed into the
-     file `configure' in this subdirectory.  *Note Introduction:
-     (autoconf.info)Introduction, for a description of Autoconf.  You
-     should write either `configure' or `configure.in', but not both.
-     The first line of `configure.in' should invoke the `m4' macro
-     `GLIBC_PROVIDES'.  This macro does several `AC_PROVIDE' calls for
-     Autoconf macros which are used by the top-level `configure'
-     script; without this, those macros might be invoked again
-     unnecessarily by Autoconf.
-
-   That is the general system for how system-dependencies are isolated.
-
-Layout of the `sysdeps' Directory Hierarchy
--------------------------------------------
-
-   A GNU configuration name has three parts: the CPU type, the
-manufacturer's name, and the operating system.  `configure' uses these
-to pick the list of system-dependent directories to look for.  If the
-`--nfp' option is *not* passed to `configure', the directory
-`MACHINE/fpu' is also used.  The operating system often has a "base
-operating system"; for example, if the operating system is `sunos4.1',
-the base operating system is `unix/bsd'.  The algorithm used to pick
-the list of directories is simple: `configure' makes a list of the base
-operating system, manufacturer, CPU type, and operating system, in that
-order.  It then concatenates all these together with slashes in
-between, to produce a directory name; for example, the configuration
-`sparc-sun-sunos4.1' results in `unix/bsd/sun/sparc/sunos4.1'.
-`configure' then tries removing each element of the list in turn, so
-`unix/bsd/sparc' and `sun/sparc' are also tried, among others.  Since
-the precise version number of the operating system is often not
-important, and it would be very inconvenient, for example, to have
-identical `sunos4.1.1' and `sunos4.1.2' directories, `configure' tries
-successively less specific operating system names by removing trailing
-suffixes starting with a period.
-
-   As an example, here is the complete list of directories that would be
-tried for the configuration `sparc-sun-sunos4.1' (without the `--nfp'
-option):
-
-     sparc/fpu
-     unix/bsd/sun/sunos4.1/sparc
-     unix/bsd/sun/sunos4.1
-     unix/bsd/sun/sunos4/sparc
-     unix/bsd/sun/sunos4
-     unix/bsd/sun/sunos/sparc
-     unix/bsd/sun/sunos
-     unix/bsd/sun/sparc
-     unix/bsd/sun
-     unix/bsd/sunos4.1/sparc
-     unix/bsd/sunos4.1
-     unix/bsd/sunos4/sparc
-     unix/bsd/sunos4
-     unix/bsd/sunos/sparc
-     unix/bsd/sunos
-     unix/bsd/sparc
-     unix/bsd
-     unix/sun/sunos4.1/sparc
-     unix/sun/sunos4.1
-     unix/sun/sunos4/sparc
-     unix/sun/sunos4
-     unix/sun/sunos/sparc
-     unix/sun/sunos
-     unix/sun/sparc
-     unix/sun
-     unix/sunos4.1/sparc
-     unix/sunos4.1
-     unix/sunos4/sparc
-     unix/sunos4
-     unix/sunos/sparc
-     unix/sunos
-     unix/sparc
-     unix
-     sun/sunos4.1/sparc
-     sun/sunos4.1
-     sun/sunos4/sparc
-     sun/sunos4
-     sun/sunos/sparc
-     sun/sunos
-     sun/sparc
-     sun
-     sunos4.1/sparc
-     sunos4.1
-     sunos4/sparc
-     sunos4
-     sunos/sparc
-     sunos
-     sparc
-
-   Different machine architectures are conventionally subdirectories at
-the top level of the `sysdeps' directory tree.  For example,
-`sysdeps/sparc' and `sysdeps/m68k'.  These contain files specific to
-those machine architectures, but not specific to any particular
-operating system.  There might be subdirectories for specializations of
-those architectures, such as `sysdeps/m68k/68020'. Code which is
-specific to the floating-point coprocessor used with a particular
-machine should go in `sysdeps/MACHINE/fpu'.
-
-   There are a few directories at the top level of the `sysdeps'
-hierarchy that are not for particular machine architectures.
-
-`generic'
-`stub'
-     As described above (*note Porting::.), these are the two
-     subdirectories that every configuration implicitly uses after all
-     others.
-
-`ieee754'
-     This directory is for code using the IEEE 754 floating-point
-     format, where the C type `float' is IEEE 754 single-precision
-     format, and `double' is IEEE 754 double-precision format.  Usually
-     this directory is referred to in the `Implies' file in a machine
-     architecture-specific directory, such as `m68k/Implies'.
-
-`posix'
-     This directory contains implementations of things in the library in
-     terms of POSIX.1 functions.  This includes some of the POSIX.1
-     functions themselves.  Of course, POSIX.1 cannot be completely
-     implemented in terms of itself, so a configuration using just
-     `posix' cannot be complete.
-
-`unix'
-     This is the directory for Unix-like things.  *Note Porting to
-     Unix::.  `unix' implies `posix'.  There are some special-purpose
-     subdirectories of `unix':
-
-    `unix/common'
-          This directory is for things common to both BSD and System V
-          release 4.  Both `unix/bsd' and `unix/sysv/sysv4' imply
-          `unix/common'.
-
-    `unix/inet'
-          This directory is for `socket' and related functions on Unix
-          systems.  The `inet' top-level subdirectory is enabled by
-          `unix/inet/Subdirs'.  `unix/common' implies `unix/inet'.
-
-`mach'
-     This is the directory for things based on the Mach microkernel
-     from CMU (including the GNU operating system).  Other basic
-     operating systems (VMS, for example) would have their own
-     directories at the top level of the `sysdeps' hierarchy, parallel
-     to `unix' and `mach'.
-
-Porting the GNU C Library to Unix Systems
------------------------------------------
-
-   Most Unix systems are fundamentally very similar.  There are
-variations between different machines, and variations in what
-facilities are provided by the kernel.  But the interface to the
-operating system facilities is, for the most part, pretty uniform and
-simple.
-
-   The code for Unix systems is in the directory `unix', at the top
-level of the `sysdeps' hierarchy.  This directory contains
-subdirectories (and subdirectory trees) for various Unix variants.
-
-   The functions which are system calls in most Unix systems are
-implemented in assembly code in files in `sysdeps/unix'.  These files
-are named with a suffix of `.S'; for example, `__open.S'.  Files ending
-in `.S' are run through the C preprocessor before being fed to the
-assembler.
-
-   These files all use a set of macros that should be defined in
-`sysdep.h'.  The `sysdep.h' file in `sysdeps/unix' partially defines
-them; a `sysdep.h' file in another directory must finish defining them
-for the particular machine and operating system variant.  See
-`sysdeps/unix/sysdep.h' and the machine-specific `sysdep.h'
-implementations to see what these macros are and what they should do.
-
-   The system-specific makefile for the `unix' directory (that is, the
-file `sysdeps/unix/Makefile') gives rules to generate several files
-from the Unix system you are building the library on (which is assumed
-to be the target system you are building the library *for*).  All the
-generated files are put in the directory where the object files are
-kept; they should not affect the source tree itself.  The files
-generated are `ioctls.h', `errnos.h', `sys/param.h', and `errlist.c'
-(for the `stdio' section of the library).
-
-Contributors to the GNU C Library
-=================================
-
-   The GNU C library was written almost entirely by Roland McGrath, who
-now maintains it.  Some parts of the library were contributed or worked
-on by other people.
-
-   * The `getopt' function and related code were written by Richard
-     Stallman, David J. MacKenzie, and Roland McGrath.
-
-   * Most of the math functions are taken from 4.4 BSD; they have been
-     modified only slightly to work with the GNU C library.  The
-     Internet-related code (most of the `inet' subdirectory) and several
-     other miscellaneous functions and header files have been included
-     with little or no modification.
-
-     All code incorporated from 4.4 BSD is under the following
-     copyright:
-
-               Copyright (C) 1991 Regents of the University of California.
-               All rights reserved.
-
-          Redistribution and use in source and binary forms, with or
-          without modification, are permitted provided that the
-          following conditions are met:
-
-            1. Redistributions of source code must retain the above
-               copyright notice, this list of conditions and the
-               following disclaimer.
-
-            2. Redistributions in binary form must reproduce the above
-               copyright notice, this list of conditions and the
-               following disclaimer in the documentation and/or other
-               materials provided with the distribution.
-
-            3. All advertising materials mentioning features or use of
-               this software must display the following acknowledgement:
-                    This product includes software developed by the
-                    University of California, Berkeley and its
-                    contributors.
-
-            4. Neither the name of the University nor the names of its
-               contributors may be used to endorse or promote products
-               derived from this software without specific prior
-               written permission.
-
-          THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS
-          IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-          LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
-          FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT
-          SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
-          INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-          DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
-          SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
-          OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
-          LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-          (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
-          THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
-          OF SUCH DAMAGE.
-
-   * The random number generation functions `random', `srandom',
-     `setstate' and `initstate', which are also the basis for the
-     `rand' and `srand' functions, were written by Earl T. Cohen for
-     the University of California at Berkeley and are copyrighted by the
-     Regents of the University of California.  They have undergone minor
-     changes to fit into the GNU C library and to fit the ANSI C
-     standard, but the functional code is Berkeley's.
-
-   * The merge sort function `qsort' was written by Michael J. Haertel.
-
-   * The quick sort function used as a fallback by `qsort' was written
-     by Douglas C. Schmidt.
-
-   * The memory allocation functions `malloc', `realloc' and `free' and
-     related code were written by Michael J. Haertel.
-
-   * Fast implementations of many of the string functions (`memcpy',
-     `strlen', etc.) were written by Torbjorn Granlund.
-
-   * Some of the support code for Mach is taken from Mach 3.0 by CMU,
-     and is under the following copyright terms:
-
-               Mach Operating System
-               Copyright (C) 1991,1990,1989 Carnegie Mellon University
-               All Rights Reserved.
-
-          Permission to use, copy, modify and distribute this software
-          and its documentation is hereby granted, provided that both
-          the copyright notice and this permission notice appear in all
-          copies of the software, derivative works or modified
-          versions, and any portions thereof, and that both notices
-          appear in supporting documentation.
-
-          CARNEGIE MELLON ALLOWS FREE USE OF THIS SOFTWARE IN ITS "AS
-          IS" CONDITION.  CARNEGIE MELLON DISCLAIMS ANY LIABILITY OF
-          ANY KIND FOR ANY DAMAGES WHATSOEVER RESULTING FROM THE USE OF
-          THIS SOFTWARE.
-
-          Carnegie Mellon requests users of this software to return to
-
-                Software Distribution Coordinator
-                School of Computer Science
-                Carnegie Mellon University
-                Pittsburgh PA 15213-3890
-
-          or `Software.Distribution@CS.CMU.EDU' any improvements or
-          extensions that they make and grant Carnegie Mellon the
-          rights to redistribute these changes.
-
-   * The `tar.h' header file was written by David J. MacKenzie.
-
-   * The port to the MIPS DECStation running Ultrix 4
-     (`mips-dec-ultrix4') was contributed by Brendan Kehoe and Ian
-     Lance Taylor.
-
-   * The DES encryption function `crypt' and related functions were
-     contributed by Michael Glad.
-
-   * The `ftw' function was contributed by Ian Lance Taylor.
-
-   * The code to support SunOS shared libraries was contributed by Tom
-     Quinn.
-
-   * The `mktime' function was contributed by Noel Cragg.
-
-   * The port to the Sequent Symmetry running Dynix version 3
-     (`i386-sequent-bsd') was contributed by Jason Merrill.
-
-   * The timezone support code is derived from the public-domain
-     timezone package by Arthur David Olson.
-
-   * The Internet resolver code is taken directly from BIND 4.9.1,
-     which is under both the Berkeley copyright above and also:
-
-          Portions Copyright (C) 1993 by Digital Equipment Corporation.
-
-          Permission to use, copy, modify, and distribute this software
-          for any purpose with or without fee is hereby granted,
-          provided that the above copyright notice and this permission
-          notice appear in all copies, and that the name of Digital
-          Equipment Corporation not be used in advertising or publicity
-          pertaining to distribution of the document or software
-          without specific, written prior permission.
-
-          THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP.
-          DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
-          INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
-          FITNESS.  IN NO EVENT SHALL DIGITAL EQUIPMENT CORPORATION BE
-          LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
-          DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
-          DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
-          OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION
-          WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
-
-   * The port to the DEC Alpha running OSF/1 (`alpha-dec-osf1') was
-     contributed by Brendan Kehoe, using some code written by Roland
-     McGrath.
+   * GNU `autoconf' 2.53 or higher
 
-   * The floating-point printing function used by `printf' and friends
-     was written by Roland McGrath and Torbjorn Granlund.  The
-     multi-precision integer functions used in that function are taken
-     from GNU MP, which was contributed by Torbjorn Granlund.
+and if you change any of the message translation files you will need
 
-   * The code to support Sun RPC is taken verbatim from Sun's
-     RPCSRC-4.0 distribution, and is covered by this copyright:
+   * GNU `gettext' 0.10.36 or later
 
-               Copyright (C) 1984, Sun Microsystems, Inc.
+You may also need these packages if you upgrade your source tree using
+patches, although we try to avoid this.
 
-          Sun RPC is a product of Sun Microsystems, Inc. and is
-          provided for unrestricted use provided that this legend is
-          included on all tape media and as a part of the software
-          program in whole or part.  Users may copy or modify Sun RPC
-          without charge, but are not authorized to license or
-          distribute it to anyone else except as part of a product or
-          program developed by the user.
+A.4 Supported Configurations
+============================
 
-          SUN RPC IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND
-          INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND
-          FITNESS FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF
-          DEALING, USAGE OR TRADE PRACTICE.
+The GNU C Library currently supports configurations that match the
+following patterns:
 
-          Sun RPC is provided with no support and without any
-          obligation on the part of Sun Microsystems, Inc. to assist in
-          its use, correction, modification or enhancement.
+     alpha*-*-linux
+     arm-*-linux
+     cris-*-linux
+     hppa-*-linux
+     iX86-*-gnu
+     iX86-*-linux
+     ia64-*-linux
+     m68k-*-linux
+     mips*-*-linux
+     powerpc-*-linux
+     s390-*-linux
+     s390x-*-linux
+     sparc-*-linux
+     sparc64-*-linux
+     x86_64-*-linux
+
+   Former releases of this library (version 2.1 and/or 2.0) used to run
+on the following configurations:
+
+     arm-*-linuxaout
+     arm-*-none
+
+   Very early releases (version 1.09.1 and perhaps earlier versions)
+used to run on the following configurations:
 
-          SUN MICROSYSTEMS, INC. SHALL HAVE NO LIABILITY WITH RESPECT
-          TO THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY
-          PATENTS BY SUN RPC OR ANY PART THEREOF.
+     alpha-dec-osf1
+     alpha-*-linuxecoff
+     iX86-*-bsd4.3
+     iX86-*-isc2.2
+     iX86-*-isc3.N
+     iX86-*-sco3.2
+     iX86-*-sco3.2v4
+     iX86-*-sysv
+     iX86-*-sysv4
+     iX86-force_cpu386-none
+     iX86-sequent-bsd
+     i960-nindy960-none
+     m68k-hp-bsd4.3
+     m68k-mvme135-none
+     m68k-mvme136-none
+     m68k-sony-newsos3
+     m68k-sony-newsos4
+     m68k-sun-sunos4.N
+     mips-dec-ultrix4.N
+     mips-sgi-irix4.N
+     sparc-sun-solaris2.N
+     sparc-sun-sunos4.N
 
-          In no event will Sun Microsystems, Inc. be liable for any
-          lost revenue or profits or other special, indirect and
-          consequential damages, even if Sun has been advised of the
-          possibility of such damages.
+   Since no one has volunteered to test and fix these configurations,
+they are not supported at the moment.  They probably don't compile;
+they definitely don't work anymore.  Porting the library is not hard.
+If you are interested in doing a port, please contact the glibc
+maintainers.  Start at `http://www.gnu.org/software/libc/' and read the
+references there on how to go about getting involved and contacting the
+developers.
+
+   Valid cases of `iX86' include `i386', `i486', `i586', and `i686'.
+All of those configurations produce a library that can run on this
+processor and newer processors.  The GCC compiler by default generates
+code that's optimized for the machine it's configured for and will use
+the instructions available on that machine.  For example if your GCC is
+configured for `i686', gcc will optimize for `i686' and might issue
+some `i686' specific instructions.  To generate code for other models,
+you have to configure for that model and give GCC the appropriate
+`-march=' and `-mcpu=' compiler switches via CFLAGS.
+
+A.5 Specific advice for GNU/Linux systems
+=========================================
+
+If you are installing GNU libc on a GNU/Linux system, you need to have
+the header files from a 2.2 or newer kernel around for reference.  For
+some architectures, like ia64, sh and hppa, you need at least headers
+from kernel 2.3.99 (sh and hppa) or 2.4.0 (ia64).  You do not need to
+use that kernel, just have its headers where glibc can access at them.
+The easiest way to do this is to unpack it in a directory such as
+`/usr/src/linux-2.2.1'.  In that directory, run `make config' and
+accept all the defaults.  Then run `make include/linux/version.h'.
+Finally, configure glibc with the option
+`--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 `make
+config' as above; then, rename or delete `/usr/include', create a new
+`/usr/include', and make symbolic links of `/usr/include/linux' and
+`/usr/include/asm' into the 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.
+
+   After installing GNU libc, you may need to remove or rename
+`/usr/include/linux' and `/usr/include/asm', and replace them with
+copies of `include/linux' and `include/asm-$ARCHITECTURE' taken from
+the Linux source package which supplied kernel headers for building the
+library.  ARCHITECTURE will be the machine architecture for which the
+library was built, such as `i386' or `alpha'.  You do not need to do
+this if you did not specify an alternate kernel header source using
+`--with-headers'.  The intent here is that these directories should be
+copies of, *not* symlinks to, the kernel headers used to build the
+library.
+
+   Note that `/usr/include/net' and `/usr/include/scsi' should *not* be
+symlinks into the kernel sources.  GNU libc provides its own versions
+of these files.
+
+   GNU/Linux expects some components of the libc installation to be in
+`/lib' and some in `/usr/lib'.  This is handled automatically if you
+configure glibc with `--prefix=/usr'.  If you set some other prefix or
+allow it to default to `/usr/local', then all the components are
+installed there.
+
+   If you are upgrading from libc5, you need to recompile every shared
+library on your system against the new library for the sake of new code,
+but keep the old libraries around for old binaries to use.  This is
+complicated and difficult.  Consult the Glibc2 HOWTO at
+`http://www.imaxx.net/~thrytis/glibc' for details.
+
+   You cannot use `nscd' with 2.0 kernels, due to bugs in the
+kernel-side thread support.  `nscd' happens to hit these bugs
+particularly hard, but you might have problems with any threaded
+program.
+
+A.6 Reporting Bugs
+==================
+
+There are probably bugs in the GNU C library.  There are certainly
+errors and omissions in this manual.  If you report them, they will get
+fixed.  If you don't, no one will ever know about them and they will
+remain unfixed for all eternity, if not longer.
 
-               Sun Microsystems, Inc.
-               2550 Garcia Avenue
-               Mountain View, California  94043
+   It is a good idea to verify that the problem has not already been
+reported.  Bugs are documented in two places: The file `BUGS' describes
+a number of well known bugs and the bug tracking system has a WWW
+interface at `http://sources.redhat.com/bugzilla/'.  The WWW interface
+gives you access to open and closed reports.  A closed report normally
+includes a patch or a hint on solving the problem.
+
+   To report a bug, first you must find it.  With any luck, this will
+be the hard part.  Once you've found a bug, make sure it's really a
+bug.  A good way to do this is to see if the GNU C library behaves the
+same way some other C library does.  If so, probably you are wrong and
+the libraries are right (but not necessarily).  If not, one of the
+libraries is probably wrong.  It might not be the GNU library.  Many
+historical Unix C libraries permit things that we don't, such as
+closing a file 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!
+
+   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
+library, you really only need to narrow it down to one library function
+call, if possible.  This should not be too difficult.
 
-   * The port to SGI machines running Irix 4 (`mips-sgi-irix4') was
-     contributed by Tom Quinn.
+   The final step when you have a simple test case is to report the bug.
+Do this using the WWW interface to the bug database.
 
-   * The port of the Mach and Hurd code to the MIPS architecture
-     (`mips-ANYTHING-gnu') was contribued by Kazumoto Kojima.
+   If you are not sure how a function should behave, and this manual
+doesn't tell you, that's a bug in the manual.  Report that too!  If the
+function's behavior disagrees with the manual, then either the library
+or the manual has a bug, so report the disagreement.  If you find any
+errors or omissions in this manual, please report them to the bug
+database.  If you refer to specific sections of the manual, please
+include the section names for easier identification.