Update.cvs/libc-971205

1997-12-05 00:01  Ulrich Drepper  <drepper@cygnus.com>

	The kernel expects the arguments in a different order.
	* sysdeps/unix/sysv/linux/i386/s_pread64.S: New file.
	* sysdeps/unix/sysv/linux/i386/s_pwrite64.S: New file.

	* FAQ.in: New file.
	* gen-FAQ.pl: New file.
	* Makefile (FAQ): Add rule to generate from FAQ.in.

	* iconvdata/Makefile: Treat libJIS like the other modules.

	* rt/librt.map: New file.

	* sysdeps/wordsize-32/bits/environments.h: Add test for direct
	inclusion.
	* sysdeps/wordsize-64/bits/environments.h: Likewise.  Correct
	comment.

1997-12-04 22:29  Ulrich Drepper  <drepper@cygnus.com>

	* sysdeps/unix/sysv/linux/rt_sigprocmask.c: Fix prototype.
	* sysdeps/unix/sysv/linux/rt_sigsuspend.c: Likewise.
	* sysdeps/unix/sysv/linux/rt_sigqueueinfo.c: Include <sys/types.h>.
	Patches by Thorsten Kukuk <kukuk@weber.uni-paderborn.de>.

1997-11-27  Andreas Jaeger  <aj@arthur.rhein-neckar.de>

	* string/bits/string2.h: Fix spellings.

	* string/string.h: Fix spellings.

1997-12-04  Andreas Jaeger  <aj@arthur.rhein-neckar.de>

	* sysdeps/unix/sysv/linux/i386/sigaction.c: Rename extern
	declaration to __syscall_rt_sigaction.

	* sysdeps/unix/sysv/linux/sigreturn.c: Remove inclusion of
	non-existant <sigcontext.h>.

1997-12-04  Andreas Jaeger  <aj@arthur.rhein-neckar.de>

	* sysdeps/generic/enbl-secure.c (__libc_init_secure): Correct
	typo.

1997-12-04  Andreas Jaeger  <aj@arthur.rhein-neckar.de>

	* sysdeps/wordsize-64/bits/environments.h: Correct spelling.

	* Makeconfig (shared-thread-library): Correct spelling.

	* sysdeps/unix/sysv/linux/sys/pci.h: Include <linux/pci.h> and not
	<asm/pci.h>.

1997-12-04  Andreas Jaeger  <aj@arthur.rhein-neckar.de>

	* sysdeps/unix/sysv/linux/bits/socket.h: Add AF_* and PF_
	constants from Linux headers. Pointed out by
	csmall@scooter.o.i.net. [PR libc/369]

1997-12-04 10:21  Thorsten Kukuk  <kukuk@vt.uni-paderborn.de>

	* sunrpc/xcrypt.c: Fix lower/upper characters in optimized hexval.

1997-12-04 00:06  Zack Weinberg  <zack@rabi.phys.columbia.edu>

	* configure.in: If --enable-add-ons is given without an
	argument, set the addons list to all subdirs with a configure
	script.

1 files changed, 577 insertions, 590 deletions

diff --git a/FAQ b/FAQ
index 38023476e8..bcca3ec38b 100644
--- a/FAQ
+++ b/FAQ
@@ -1,131 +1,117 @@
-		Frequently Asked Question on GNU C Library
+	    Frequently Asked Questions about the GNU C Library
 
-As every FAQ this one also tries to answer questions the user might have
-when using the package.  Please make sure you read this before sending
-questions or bug reports to the maintainers.
+This document tries to answer questions a user might have when
+installing and using glibc.  Please make sure you read this before
+sending questions or bug reports to the maintainers.
 
-The GNU C Library is very complex.  The building process exploits the
-features available in tools generally available.  But many things can
-only be done using GNU tools.  Also the code is sometimes hard to
-understand because it has to be portable but on the other hand must be
-fast.  But you need not understand the details to use GNU C Library.
-This will only be necessary if you intend to contribute or change it.
+The GNU C library is very complex.  The installation process has not
+been completely automated; there are too many variables. You can do
+substantial damage to your system by installing the library
+incorrectly.  Make sure you understand what you are undertaking before
+you begin.
 
 If you have any questions you think should be answered in this document,
 please let me know.
 
 						  --drepper@cygnus.com
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q1]	``What systems does the GNU C Library run on?''
+~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 
+
+1. Compiling glibc
+
+1.1.	What systems does the GNU C Library run on?
+1.2.	What compiler do I need to build GNU libc?
+1.3.	When I try to compile glibc I get only error messages.
+	What's wrong?
+1.4.	Do I need a special linker or archiver?
+1.5.	Do I need some more things to compile GNU C Library?
+1.6.	When I run `nm -u libc.so' on the produced library I still
+	find unresolved symbols.  Can this be ok?
+1.7.	What are these `add-ons'?
+1.8.	My XXX kernel emulates a floating-point coprocessor for me.
+	Should I enable --with-fp?
+1.9.	When compiling GNU libc I get lots of errors saying functions
+	in glibc are duplicated in libgcc.
+1.10.	What's the problem with configure --enable-omitfp?
+
+2. Installation and configuration issues
+
+2.1.	Can I replace the libc on my Linux system with GNU libc?
+2.2.	How do I configure GNU libc so that the essential libraries
+	like libc.so go into /lib and the other into /usr/lib?
+2.3.	How should I avoid damaging my system when I install GNU libc?
+2.4.	Do I need to use GNU CC to compile programs that will use the
+	GNU C Library?
+2.5.	When linking with the new libc I get unresolved symbols
+	`crypt' and `setkey'.  Why aren't these functions in the
+	libc anymore?
+2.6.	When I use GNU libc on my Linux system by linking against
+	the libc.so which comes with glibc all I get is a core dump.
+2.7.	Looking through the shared libc file I haven't found the
+	functions `stat', `lstat', `fstat', and `mknod' and while
+	linking on my Linux system I get error messages.  How is
+	this supposed to work?
+2.8.	How can I compile gcc 2.7.2.1 from the gcc source code using
+	glibc 2.x?
+2.9.	The `gencat' utility cannot process the catalog sources which
+	were used on my Linux libc5 based system.  Why?
+2.10.	I have set up /etc/nis.conf, and the Linux libc 5 with NYS
+	works great.  But the glibc NIS+ doesn't seem to work.
+2.11.	After installing glibc name resolving doesn't work properly.
+2.12.	I have /usr/include/net and /usr/include/scsi as symlinks
+	into my Linux source tree.  Is that wrong?
+2.13.	Programs like `logname', `top', `uptime' `users', `w' and
+	`who', show incorrect information about the (number of)
+	users on my system.  Why?
+2.14.	After upgrading to glibc 2.1 with symbol versioning I get
+	errors about undefined symbols.  What went wrong?
+2.15.	When I start the program XXX after upgrading the library
+	I get
+	  XXX: Symbol `_sys_errlist' has different size in shared
+	  object, consider re-linking
+	Why?  What should I do?
+
+3. Source and binary incompatibilities, and what to do about them
+
+3.1.	I expect GNU libc to be 100% source code compatible with
+	the old Linux based GNU libc.  Why isn't it like this?
+3.2.	Why does getlogin() always return NULL on my Linux box?
+3.3.	Where are the DST_* constants found in <sys/time.h> on many
+	systems?
+3.4.	The prototypes for `connect', `accept', `getsockopt',
+	`setsockopt', `getsockname', `getpeername', `send',
+	`sendto', and `recvfrom' are different in GNU libc from
+	any other system I saw.  This is a bug, isn't it?
+3.5.	On Linux I've got problems with the declarations in Linux
+	kernel headers.
+3.6.	I don't include any kernel headers myself but the compiler
+	still complains about redeclarations of types in the kernel
+	headers.
+3.7.	Why don't signals interrupt system calls anymore?
+3.8.	I've got errors compiling code that uses certain string
+	functions.  Why?
+
+4. Miscellaneous
+
+4.1.	After I changed configure.in I get `Autoconf version X.Y.
+	or higher is required for this script'.  What can I do?
+4.2.	When I try to compile code which uses IPv6 headers and
+	definitions on my Linux 2.x.y system I am in trouble.
+	Nothing seems to work.
 
-[Q2]	``What compiler do I need to build GNU libc?''
-
-[Q3]	``When starting make I get only error messages.
-	  What's wrong?''
-
-[Q4]	``After I changed configure.in I get `Autoconf version X.Y.
-	  or higher is required for this script'.  What can I do?''
-
-[Q5]	``Do I need a special linker or archiver?''
-
-[Q6]	``Do I need some more things to compile GNU C Library?''
-
-[Q7]	``When I run `nm -u libc.so' on the produced library I still
-	  find unresolved symbols?  Can this be ok?''
-
-[Q8]	``Can I replace the libc on my Linux system with GNU libc?''
-
-[Q9]	``I expect GNU libc to be 100% source code compatible with
-	  the old Linux based GNU libc.  Why isn't it like this?''
-
-[Q10]	``Why does getlogin() always return NULL on my Linux box?''
-
-[Q11]	``Where are the DST_* constants found in <sys/time.h> on many
-	  systems?''
-
-[Q12]	``The `gencat' utility cannot process the input which are
-	  successfully used on my Linux libc based system.  Why?''
-
-[Q13]	``How do I configure GNU libc so that the essential libraries
-	  like libc.so go into /lib and the other into /usr/lib?''
-
-[Q14]	``When linking with the new libc I get unresolved symbols
-	  `crypt' and `setkey'.  Why aren't these functions in the
-	  libc anymore?''
-
-[Q15]	``What are these `add-ons'?''
-
-[Q16]	``When I use GNU libc on my Linux system by linking against
-	  to libc.so which comes with glibc all I get is a core dump.''
-
-[Q17]	``Looking through the shared libc file I haven't found the
-	  functions `stat', `lstat', `fstat', and `mknod' and while
-	  linking on my Linux system I get error messages.  How is
-	  this supposed to work?''
-
-[Q18]	``The prototypes for `connect', `accept', `getsockopt',
-	  `setsockopt', `getsockname', `getpeername', `send',
-	  `sendto', and `recvfrom' are different in GNU libc than
-	  on any other system I saw.  This is a bug, isn't it?''
-
-[Q19]	``My XXX kernel emulates a floating-point coprocessor for me.
-	  Should I enable --with-fp?''
-
-[Q20]	``How can I compile gcc 2.7.2.1 from the gcc source code using
-	  glibc 2.x?
-
-[Q21]    ``On Linux I've got problems with the declarations in Linux
-           kernel headers.''
-
-[Q22]	``When I try to compile code which uses IPv6 header and
-	  definitions on my Linux 2.x.y system I am in trouble.
-	  Nothing seems to work.''
-
-[Q23]	``When compiling GNU libc I get lots of errors saying functions
-	  in glibc are duplicated in libgcc.''
-
-[Q24]	``I have set up /etc/nis.conf, and the Linux libc 5 with NYS
-	  works great.  But the glibc NIS+ doesn't seem to work.''
-
-[Q25]	``After installing glibc name resolving doesn't work properly.''
-
-
-[Q26]	``I have /usr/include/net and /usr/include/scsi as symlinks
-	  into my Linux source tree.  Is that wrong?''
-
-[Q27]	``Programs like `logname', `top', `uptime' `users', `w' and
-	  `who', show incorrect information about the (number of)
-	  users on my system.  Why?''
-
-[Q28]	``After upgrading to a glibc 2.1 with symbol versioning I get
-	  errors about undefined symbols.  What went wrong?''
-
-[Q29]	``I don't include any kernel header myself but still the
-	  compiler complains about type redeclarations of types in the
-	  kernel headers.''
-
-[Q30]	``When I start the program XXX after upgrading the library
-	  I get
-	    XXX: Symbol `_sys_errlist' has different size in shared object, consider re-linking
-	  Why?  What to do?''
-
-[Q31]	``What's the problem with configure --enable-omitfp?''
+
+~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 
 
-[Q32]	``Why don't signals interrupt system calls anymore?''
+1. Compiling glibc
 
-[Q33]	``I've got errors compiling code that uses certain string
-	  functions.  Why?''
-
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q1]	``What systems does the GNU C Library run on?''
+1.1.	What systems does the GNU C Library run on?
 
-[A1] {UD} This is difficult to answer.  The file `README' lists the
-architectures GNU libc is known to run *at some time*.  This does not
-mean that it still can be compiled and run on them in the moment.
+{UD} This is difficult to answer.  The file `README' lists the
+architectures GNU libc was known to run on *at some time*.  This does
+not mean that it still can be compiled and run on them now.
 
-The systems glibc is known to work on in the moment and most probably
-in the future are:
+The systems glibc is known to work on as of this release, and most
+probably in the future, are:
 
 	*-*-gnu			GNU Hurd
 	i[3456]86-*-linux-gnu	Linux-2.0 on Intel
@@ -135,8 +121,10 @@ in the future are:
 	sparc-*-linux-gnu	Linux-2.0 on SPARC
 	sparc64-*-linux-gnu	Linux-2.0 on UltraSPARC
 
-Other Linux platforms are also on the way to be supported but I need
-some success reports first.
+Ports to other Linux platforms are in development, and may in fact
+work already, but no one has sent us success reports for them.
+Currently no ports to other operating systems are underway, although a
+few people have expressed interest.
 
 If you have a system not listed above (or in the `README' file) and
 you are really interested in porting it, contact
@@ -144,389 +132,312 @@ you are really interested in porting it, contact
 	<bug-glibc@prep.ai.mit.edu>
 
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q2]	``What compiler do I need to build GNU libc?''
+1.2.	What compiler do I need to build GNU libc?
 
-[A2] {UD} It is (almost) impossible to compile GNU C Library using a
-different compiler than GNU CC.  A lot of extensions of GNU CC are
-used to increase the portability and speed.
+{UD} You must use GNU CC to compile GNU libc.  A lot of extensions of
+GNU CC are used to increase portability and speed.
 
-But this does not mean you have to use GNU CC for using the GNU C
-Library.  In fact you should be able to use the native C compiler
-because the success only depends on the binutils: the linker and
-archiver.
-
-The GNU CC is found like all other GNU packages on
+GNU CC is found, like all other GNU packages, on
 	ftp://prep.ai.mit.edu/pub/gnu
-or better one of the many mirror sites.
+and the many mirror sites.  prep is always overloaded, so try to find
+a local mirror first.
 
 You always should try to use the latest official release.  Older
-versions might not have all the features GNU libc could use.  It is
-known that on most platforms compilers earlier than 2.7.2.3 fail so
-at least use this version.
+versions may not have all the features GNU libc requires.  On most
+supported platforms, 2.7.2.3 is the earliest version that works at all.
 
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q3]	``When starting `make' I get only errors messages.
-	  What's wrong?''
+1.3.	When I try to compile glibc I get only error messages.
+	What's wrong?
 
-[A3] {UD} You definitely need GNU make to translate GNU libc.  No
+{UD} You definitely need GNU make to translate GNU libc.  No
 other make program has the needed functionality.
 
-Versions before 3.74 have bugs which prevent correct execution so you
-should upgrade to the latest version before starting the compilation.
-
-We recommend version GNU make version 3.75.  Versions 3.76 and
-3.76.1 are known to have bugs which only show up in big projects like
-GNU libc.
+We recommend version GNU make version 3.75.  Versions 3.76 and 3.76.1
+have bugs which appear when building big projects like GNU libc.
+Versions before 3.74 have bugs and/or are missing features.
 
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q4]	``After I changed configure.in I get `Autoconf version X.Y.
-	  or higher is required for this script'.  What can I do?''
+1.4.	Do I need a special linker or archiver?
 
-[A4] {UD} You have to get the specified autoconf version (or a later)
-from your favourite mirror of prep.ai.mit.edu.
-
-
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q5]	``Do I need a special linker or archiver?''
-
-[A5] {UD} If your native versions are not too buggy you can probably
-work with them.  But GNU libc works best with GNU binutils.
+{UD} You may be able to use your system linker, but GNU libc works
+best with GNU binutils.
 
 On systems where the native linker does not support weak symbols you
-will not get a really ISO C compliant C library.  Generally speaking
+will not get a fully ISO C compliant C library.  Generally speaking
 you should use the GNU binutils if they provide at least the same
 functionality as your system's tools.
 
-Always get the newest release of GNU binutils available.
-Older releases are known to have bugs that affect building the GNU C
-Library.
+Always get the newest release of GNU binutils available.  Older
+releases are known to have bugs that prevent a successful compilation.
 
+{ZW} As of release 2.1 a linker supporting symbol versions is
+required.  For Linux, get binutils-2.8.1.0.17 or later.  Other systems
+may have native linker support, but it's moot right now, because glibc
+has not been ported to them.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q6]	``Do I need some more things to compile GNU C Library?''
 
-[A6] {UD} Yes, there are some more :-).
+1.5.	Do I need some more things to compile GNU C Library?
 
-* GNU gettext; the GNU libc is internationalized and partly localized.
-  For bringing the messages for the different languages in the needed
-  form the tools from the GNU gettext package are necessary.  See
-  ftp://prep.ai.mit.edu/pub/gnu or better any mirror site.
+{UD} Yes, there are some more :-).
 
-* lots of diskspace (for i?86-linux this means, e.g., ~170MB; for ppc-linux
-  even ~200MB).
+* GNU gettext.  This package contains the tools needed to construct
+  `message catalog' files containing translated versions of system
+  messages. See ftp://prep.ai.mit.edu/pub/gnu or better any mirror
+  site.  (We distribute compiled message catalogs, but they may not be
+  updated in patches.)
 
-  You should avoid compiling on a NFS mounted device.  This is very
-  slow.
+* Some files depend on special tools.  E.g., files ending in .gperf
+  need a `gperf' program.  The GNU version (part of libg++) is known
+  to work while some vendor versions do not.
 
-* plenty of time (approx 1h for i?86-linux on i586@133 or 2.5h on
-  i486@66 or 4.5h on i486@33), both for shared and static only).
-  Multiply this by 1.5 or 2.0 if you build profiling and/or the highly
-  optimized version as well.  For Hurd systems times are much higher.
+  You should not need these tools unless you change the source files.
 
-  For Atari Falcon (Motorola 68030 @ 16 Mhz, 14 Mb memory) James Troup
-  <J.J.Troup@comp.brad.ac.uk> reports for a full build (shared, static,
-  and profiled) a compile time of 45h34m.
+* When compiling for Linux, the header files of the Linux kernel must
+  be available to the compiler as <linux/*.h> and <asm/*.h>.
 
-  For Atari TT030 (Motorola 68030 @ 32 Mhz, 34 Mb memory) (full build)
-  a compile time of 22h48m.
+* lots of disk space (~170MB for i?86-linux; more for RISC platforms).
 
-  If you have some more measurements let me know.
+* plenty of time.  Compiling just the shared and static libraries for
+  i?86-linux takes approximately 1h on an i586@133, or 2.5h on
+  i486@66, or 4.5h on i486@33.  Multiply this by 1.5 or 2.0 if you
+  build profiling and/or the highly optimized version as well.  For
+  Hurd systems times are much higher.
 
-* When compiling for Linux:
+  You should avoid compiling in a NFS mounted filesystem.  This is
+  very slow.
 
-  + the header files of the Linux kernel must be available in the
-    search path of the CPP as <linux/*.h> and <asm/*.h>.
+  James Troup <J.J.Troup@comp.brad.ac.uk> reports a compile time of
+  45h34m for a full build (shared, static, and profiled) on
+  Atari Falcon (Motorola 68030 @ 16 Mhz, 14 Mb memory) and 22h48m
+  on Atari TT030 (Motorola 68030 @ 32 Mhz, 34 Mb memory)
 
-* Some files depend on special tools.  E.g., files ending in .gperf
-  need a `gperf' program.  The GNU version (part of libg++) is known
-  to work while some vendor versions do not.
+  If you have some more measurements let me know.
 
-  You should not need these tools unless you change the source files.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q7]	``When I run `nm -u libc.so' on the produced library I still
-	  find unresolved symbols?  Can this be ok?''
+1.6.	When I run `nm -u libc.so' on the produced library I still
+	find unresolved symbols.  Can this be ok?
 
-[A7] {UD} Yes, this is ok.  There can be several kinds of unresolved
+{UD} Yes, this is ok.  There can be several kinds of unresolved
 symbols:
 
-* magic symbols automatically generated by the linker.  Names are
-  often like __start_* and __stop_*
+* magic symbols automatically generated by the linker.  These have names
+  like __start_* and __stop_*
 
 * symbols starting with _dl_* come from the dynamic linker
 
 * symbols resolved by using libgcc.a
   (__udivdi3, __umoddi3, or similar)
 
-* weak symbols, which need not be resolved at all
-  (currently fabs among others; this gets resolved if the program
-   is linked against libm, too.)
+* weak symbols, which need not be resolved at all (fabs for example)
 
 Generally, you should make sure you find a real program which produces
 errors while linking before deciding there is a problem.
 
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q8]	``Can I replace the libc on my Linux system with GNU libc?''
-
-[A8] {UD} You cannot replace any existing libc for Linux with GNU
-libc.  There are different versions of C libraries and you can run
-libcs with different major version independently.
-
-For Linux there are today two libc versions:
-	libc-4		old a.out libc
-	libc-5		current ELF libc
-
-GNU libc will have the major number 6 and therefore you can have this
-additionally installed.  For more information consult documentation for
-shared library handling.  The Makefiles of GNU libc will automatically
-generate the needed symbolic links which the linker will use.
+1.7.	What are these `add-ons'?
 
+{UD} To avoid complications with export rules or external source
+code some optional parts of the libc are distributed as separate
+packages (e.g., the crypt package, see question 2.5).
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q9]	``I expect GNU libc to be 100% source code compatible with
-	  the old Linux based GNU libc.  Why isn't it like this?''
+To use these packages as part of GNU libc, just unpack the tarfiles in
+the libc source directory and tell the configuration script about them
+using the --enable-add-ons option.  If you give just --enable-add-ons
+configure tries to find all the add-on packages in your source tree.
+This may not work.  If it doesn't, or if you want to select only a
+subset of the add-ons, give a comma-separated list of the add-ons to
+enable:
 
-[A9] {DMT,UD} Not every extension in Linux libc's history was well
-thought-out.  In fact it had a lot of problems with standards compliance
-and with cleanliness.  With the introduction of a new version number these
-errors now can be corrected.  Here is a list of the known source code
-incompatibilities:
+	configure --enable-add-ons=crypt,linuxthreads
 
-* _GNU_SOURCE: glibc does not automatically define _GNU_SOURCE.  Thus,
-  if a program depends on GNU extensions or some other non-standard
-  functionality, it is necessary to compile it with C compiler option
-  -D_GNU_SOURCE, or better, to put `#define _GNU_SOURCE' at the beginning
-  of your source files, before any C library header files are included.
-  This difference normally manifests itself in the form of missing
-  prototypes and/or data type definitions.  Thus, if you get such errors,
-  the first thing you should do is try defining _GNU_SOURCE and see if
-  that makes the problem go away.
+for example.
 
-  For more information consult the file `NOTES' part of the GNU C
-  library sources.
+Add-ons can add features (including entirely new shared libraries),
+override files, provide support for additional architectures, and
+just about anything else.  The existing makefiles do most of the work;
+only some few stub rules must be written to get everything running.
 
-* reboot(): GNU libc sanitizes the interface of reboot() to be more
-  compatible with the interface used on other OSes.  In particular,
-  reboot() as implemented in glibc takes just one argument.  This argument
-  corresponds to the third argument of the Linux reboot system call.
-  That is, a call of the form reboot(a, b, c) needs to be changed into
-  reboot(c).
-     Beside this the header <sys/reboot.h> defines the needed constants
-  for the argument.  These RB_* constants should be used instead of the
-  cryptic magic numbers.
-
-* swapon(): the interface of this function didn't changed, but the
-  prototype is in a separate header file <sys/swap.h>.  For the additional
-  argument of swapon() you should use the SWAP_* constants from
-  <linux/swap.h>, which get defined when <sys/swap.h> is included.
-
-* errno: If a program uses variable "errno", then it _must_ include header
-  file <errno.h>.  The old libc often (erroneously) declared this variable
-  implicitly as a side-effect of including other libc header files.  glibc
-  is careful to avoid such namespace pollution, which, in turn, means that
-  you really need to include the header files that you depend on.  This
-  difference normally manifests itself in the form of the compiler
-  complaining about the references of the undeclared symbol "errno".
 
-* Linux-specific syscalls: All Linux system calls now have appropriate
-  library wrappers and corresponding declarations in various header files.
-  This is because the syscall() macro that was traditionally used to
-  work around missing syscall wrappers are inherently non-portable and
-  error-prone.  The following tables lists all the new syscall stubs,
-  the header-file declaring their interface and the system call name.
+1.8.	My XXX kernel emulates a floating-point coprocessor for me.
+	Should I enable --with-fp?
 
-       syscall name:	wrapper name:	declaring header file:
-       -------------	-------------	----------------------
-       bdflush		bdflush		<sys/kdaemon.h>
-       syslog		ksyslog_ctl	<sys/klog.h>
+{ZW} An emulated FPU is just as good as a real one, as far as the C
+library is concerned.  You only need to say --without-fp if your
+machine has no way to execute floating-point instructions.
 
-* lpd: Older versions of lpd depend on a routine called _validuser().
-  The library does not provide this function, but instead provides
-  __ivaliduser() which has a slightly different interfaces.  Simply
-  upgrading to a newer lpd should fix this problem (e.g., the 4.4BSD
-  lpd is known to be working).
+People who are interested in squeezing the last drop of performance
+out of their machine may wish to avoid the trap overhead, but this is
+far more trouble than it's worth: you then have to compile
+*everything* this way, including the compiler's internal libraries
+(libgcc.a for GNU C), because the calling conventions change.
 
-* resolver functions/BIND: like on many other systems the functions of
-  the resolver library are not included in the libc itself.  There is
-  a separate library libresolv.  If you