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.

25 files changed, 1807 insertions, 696 deletions

diff --git a/ChangeLog b/ChangeLog
index d26d6448f8..f9a3fce48e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,73 @@
+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.
+
 1997-12-03 23:50  Ulrich Drepper  <drepper@cygnus.com>
 
 	* Makeconfig: Add shared-thread-library variable.
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 find some symbols starting with
-  `res_*' undefined simply add -lresolv to your call of the linker.
 
-* the `signal' function's behaviour corresponds to the BSD semantic and
-  not the SysV semantic as it was in libc-5.  The interface on all GNU
-  systems shall be the same and BSD is the semantic of choice.  To use
-  the SysV behaviour simply use `sysv_signal', or define _XOPEN_SOURCE.
-  See question 32 for details.
+1.9.	When compiling GNU libc I get lots of errors saying functions
+	in glibc are duplicated in libgcc.
 
+{EY} This is *exactly* the same problem that I was having.  The
+problem was due to the fact that configure didn't correctly detect
+that the linker flag --no-whole-archive was supported in my linker.
+In my case it was because I had run ./configure with bogus CFLAGS, and
+the test failed.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q10]	``Why does getlogin() always return NULL on my Linux box?''
+One thing that is particularly annoying about this problem is that
+once this is misdetected, running configure again won't fix it unless
+you first delete config.cache.
 
-[A10] {UD} The GNU C library has a format for the UTMP and WTMP file
-which differs from what your system currently has.  It was extended to
-fulfill the needs of the next years when IPv6 is introduced.  So the
-record size is different, fields might have a different position and
-so reading the files written by functions from the one library cannot
-be read by functions from the other library.  Sorry, but this is what
-a major release is for.  It's better to have a cut now than having no
-means to support the new techniques later.
+{UD} Starting with glibc-2.0.3 there should be a better test to avoid
+some problems of this kind.  The setting of CFLAGS is checked at the
+very beginning and if it is not usable `configure' will bark.
 
-{MK} There is however a (partial) solution for this problem.  Please
-take a look at the file `README.utmpd'.
 
+1.10.	What's the problem with configure --enable-omitfp?
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q11]	``Where are the DST_* constants found in <sys/time.h> on many
-	  systems?''
+{AJ} When --enable-omitfp is set the libraries are built without frame
+pointers. Some compilers produce buggy code for this model and
+therefore we don't advise using it at the moment.
 
-[A11] {UD} These constants come from the old BSD days and are not used
-today anymore (even the Linux based glibc does not implement the handling
-although the constants are defined).
+If you use --enable-omitfp, you're on your own. If you encounter
+problems with a library that was build this way, we advise you to
+rebuild the library without --enable-omitfp.  If the problem vanishes
+consider tracking the problem down and report it as compiler failure.
 
-Instead GNU libc contains the zone database handling and compatibility
-code for POSIX TZ environment variable handling.
+Since a library build with --enable-omitfp is undebuggable on most
+systems, debuggable libraries are also built - you can use it by
+appending "_g" to the library names.
 
+The compilation of these extra libraries and the compiler optimizations
+slow down the build process and need more disk space.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q12]	``The `gencat' utility cannot process the input which are
-	  successfully used on my Linux libc based system.  Why?''
+
+. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
 
-[A12] {UD} Unlike the author of the `gencat' program which is distributed
-with Linux libc I have read the underlying standards before writing the
-code.  It is completely compatible with the specification given in
-X/Open Portability Guide.
+2. Installation and configuration issues
 
-To ease the transition from the Linux version some of the non-standard
-features are also present in the `gencat' program of GNU libc.  This
-mainly includes the use of symbols for the message number and the automatic
-generation of header files which contain the needed #defines to map the
-symbols to integers.
+2.1.	Can I replace the libc on my Linux system with GNU libc?
 
-Here is a simple SED script to convert at least some Linux specific
-catalog files to the XPG4 form:
+{UD} You cannot replace any existing libc for Linux with GNU
+libc.  It is binary incompatible and therefore has a different major
+version.  You can, however, install it alongside your existing libc.
 
------------------------------------------------------------------------
-# Change catalog source in Linux specific format to standard XPG format.
-# Ulrich Drepper <drepper@cygnus.com>, 1996.
-#
-/^\$ #/ {
-  h
-  s/\$ #\([^ ]*\).*/\1/
-  x
-  s/\$ #[^ ]* *\(.*\)/\$ \1/
-}
+For Linux there are three major libc versions:
+	libc-4		a.out libc
+	libc-5		original ELF libc
+	libc-6		GNU libc
 
-/^# / {
-  s/^# \(.*\)/\1/
-  G
-  s/\(.*\)\n\(.*\)/\2 \1/
-}
------------------------------------------------------------------------
+You can have any combination of these three 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.
 
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q13]	``How do I configure GNU libc so that the essential libraries
-	  like libc.so go into /lib and the other into /usr/lib?''
+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?
 
-[A13] {UD,AJ} Like all other GNU packages GNU libc is configured to
-use a base directory and install all files relative to this.  If you
-intend to really use GNU libc on your system this base directory is
-/usr.  I.e., you run
-	configure --prefix=/usr <other_options>
+{UD,AJ} Like all other GNU packages GNU libc is designed to use a base
+directory and install all files relative to this.  The default is
+/usr/local, because this is safe (it will not damage the system if
+installed there).  If you wish to install GNU libc as the primary C
+library on your system, set the base directory to /usr (i.e. run
+configure --prefix=/usr <other_options>).  Note that this can damage
+your system; see question 2.3 for details.
 
 Some systems like Linux have a filesystem standard which makes a
 difference between essential libraries and others.  Essential
 libraries are placed in /lib because this directory is required to be
 located on the same disk partition as /.  The /usr subtree might be
-found on another partition/disk.
+found on another partition/disk. If you configure for Linux with
+--prefix=/usr, then this will be done automatically.
 
-To install the essential libraries which come with GNU libc in /lib
-one must explicitly tell this (except on Linux, see below).  Autoconf
-has no option for this so you have to use the file where all user
-supplied additional information should go in: `configparms' (see the
-`INSTALL' file).  Therefore the `configparms' file should contain:
+To install the essential libraries which come with GNU libc in /lib on
+systems other than Linux one must explicitly request it.  Autoconf has
+no option for this so you have to use a `configparms' file (see the
+`INSTALL' file for details).  It should contain:
 
 slibdir=/lib
 sysconfdir=/etc
 
 The first line specifies the directory for the essential libraries,
-the second line the directory for file which are by tradition placed
-in a directory named /etc.
+the second line the directory for system configuration files.
 
-No rule without an exception: If you configure for Linux with
---prefix=/usr, then slibdir and sysconfdir will automatically be
-defined as stated above.
 
+2.3.	How should I avoid damaging my system when I install GNU libc?
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q14]	``When linking with the new libc I get unresolved symbols
-	  `crypt' and `setkey'.  Why aren't these functions in the
-	  libc anymore?''
+{ZW} If you wish to be cautious, do not configure with --prefix=/usr.
+If you don't specify a prefix, glibc will be installed in /usr/local,
+where it will probably not break anything.  (If you wish to be
+certain, set the prefix to something like /usr/local/glibc2 which is
+not used for anything.)
 
-[A14] {UD} Remember the US restrictions of exporting cryptographic
-programs and source code.  Until this law gets abolished we cannot
-ship the cryptographic function together with the libc.
+The dangers when installing glibc in /usr are twofold:
 
-But of course we provide the code and there is an very easy way to use
-this code.  First get the extra package.  People in the US may get it
-from the same place they got the GNU libc from.  People outside the US
-should get the code from ftp://ftp.ifi.uio.no/pub/gnu, or another
-archive site outside the USA.  The README explains how to install the
-sources.
+* glibc will overwrite the headers in /usr/include.  Other C libraries
+  install a different but overlapping set of headers there, so the
+  effect will probably be that you can't compile anything.  You need to
+  rename /usr/include out of the way first.  (Do not throw it away; you
+  will then lose the ability to compile programs against your old libc.)
 
-If you already have the crypt code on your system the reason for the
-failure is probably that you failed to link with -lcrypt.  The crypto
-functions are in a separate library to make it possible to export GNU
-libc binaries from the US.
+* None of your old libraries, static or shared, can be used with a
+  different C library major version.  For shared libraries this is not a
+  problem, because the filenames are different and the dynamic linker
+  will enforce the restriction.  But static libraries have no version
+  information.  You have to evacuate all the static libraries in
+  /usr/lib to a safe location.
 
+The situation is rather similar to the move from a.out to ELF which
+long-time Linux users will remember.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q15]	``What are these `add-ons'?''
 
-[A15] {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 Q14).
+2.4.	Do I need to use GNU CC to compile programs that will use the
+	GNU C Library?
 
-To ease the use as part of GNU libc the installer just has to unpack
-the package and tell the configuration script about these additional
-subdirectories using the --enable-add-ons option.  When you add the
-crypt add-on you just have to use
+{ZW} In theory, no; the linker does not care, and the headers are
+supposed to check for GNU CC before using its extensions to the C
+language.
 
-	configure --enable-add-ons=crypt,XXX ...
+However, there are currently no ports of glibc to systems where
+another compiler is the default, so no one has tested the headers
+extensively against another compiler.  You may therefore encounter
+difficulties.  If you do, please report them as bugs.
 
-where XXX are possible other add-ons and ... means the rest of the
-normal option list.
+Also, in several places GNU extensions provide large benefits in code
+quality.  For example, the library has hand-optimized, inline assembly
+versions of some string functions.  These can only be used with GCC.
+See question 3.8 for details.
 
-You can use add-ons also to overwrite some files in glibc.  The add-on
-system dependent subdirs are search first.  It is also possible to add
-banner files (use a file named `Banner') or create shared libraries.
 
-Using add-ons has the big advantage that the makefiles of the GNU libc
-can be used.  Only some few stub rules must be written to get
-everything running.  Even handling of architecture dependent
-compilation is provided.  The GNU libc's sysdeps/ directory shows how
-to use this feature.
+2.5.	When linking with the new libc I get unresolved symbols
+	`crypt' and `setkey'.  Why aren't these functions in the
+	libc anymore?
 
+{UD} The US places restrictions on exporting cryptographic programs
+and source code.  Until this law gets abolished we cannot ship the
+cryptographic functions together with glibc.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[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.''
+The functions are available, as an add-on (see question 1.7).  People in the
+US may get it from the same place they got GNU libc from.  People
+outside the US should get the code from ftp://ftp.ifi.uio.no/pub/gnu,
+or another archive site outside the USA.  The README explains how to
+install the sources.
 
-[A16] {UD} It is not enough to simply link against the GNU libc
-library itself.  The GNU C library comes with its own dynamic linker
-which really conforms to the ELF API standard.  This dynamic linker
-must be used.
+If you already have the crypt code on your system the reason for the
+failure is probably that you did not link with -lcrypt.  The crypto
+functions are in a separate library to make it possible to export GNU
+libc binaries from the US.
 
-Normally this is done by the compiler.  The gcc will use
 
-	-dynamic-linker /lib/ld-linux.so.1
+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.
 
-unless the user specifies her/himself a -dynamic-linker argument.  But
-this is not the correct name for the GNU dynamic linker.  The correct
-name is /lib/ld.so.1 which is the name specified in the SVr4 ABi.
+{UD} On Linux, gcc sets the dynamic linker to /lib/ld-linux.so.1
+unless the user specifies a -dynamic-linker argument.  This is the
+name of the libc5 dynamic linker, which does not work with glibc.
+
+For casual use of GNU libc you can just specify
+    -dynamic-linker=/lib/ld-linux.so.2
+
+which is the glibc dynamic linker, on Linux systems.  On other systems
+the name is /lib/ld.so.1.
 
 To change your environment to use GNU libc for compiling you need to
 change the `specs' file of your gcc.  This file is normally found at
@@ -535,20 +446,14 @@ change the `specs' file of your gcc.  This file is normally found at
 
 In this file you have to change a few things:
 
-- change `ld-linux.so.1' to `ld.so.1' (or to ld-linux.so.2, see below)
+- change `ld-linux.so.1' to `ld-linux.so.2'
 
 - remove all expression `%{...:-lgmon}';  there is no libgmon in glibc
 
 - fix a minor bug by changing %{pipe:-} to %|
 
-
-Things are getting a bit more complicated if you have GNU libc
-installed in some other place than /usr, i.e., if you do not want to
-use it instead of the old libc.  In this case the needed startup files
-and libraries are not found in the regular places.  So the specs file
-must tell the compiler and linker exactly what to use.  Here is what
-the gcc-2.7.2 specs file should look like when GNU libc is installed at
-/usr:
+Here is what the gcc-2.7.2 specs file should look like when GNU libc
+is installed at /usr:
 
 -----------------------------------------------------------------------
 *asm:
@@ -579,7 +484,7 @@ the gcc-2.7.2 specs file should look like when GNU libc is installed at
 -lgcc
 
 *startfile:
-%{!shared:      %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} 		       %{!p:%{profile:gcrt1.o%s} 			 %{!profile:crt1.o%s}}}}    crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s}
+%{!shared:      %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} 		     %{!p:%{profile:gcrt1.o%s} 			 %{!profile:crt1.o%s}}}}    crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s}
 
 *switches_need_spaces:
 
@@ -598,27 +503,22 @@ the gcc-2.7.2 specs file should look like when GNU libc is installed at
 
 -----------------------------------------------------------------------
 
-The above is currently correct for ix86/Linux.  Because of
-compatibility issues on this platform the dynamic linker must have
-a different name: ld-linux.so.2.  So you have to replace
-
-	%{!dynamic-linker:-dynamic-linker=/home/gnu/lib/ld-linux.so.2}
-by
-	%{!dynamic-linker:-dynamic-linker=/home/gnu/lib/ld.so.1}
-
-in the above example specs file to make it work for other systems.
+Things get a bit more complicated if you have GNU libc installed in
+some other place than /usr, i.e., if you do not want to use it instead
+of the old libc.  In this case the needed startup files and libraries
+are not found in the regular places.  So the specs file must tell the
+compiler and linker exactly what to use.
 
 Version 2.7.2.3 does and future versions of GCC will automatically
 provide the correct specs.
 
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[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?''
+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?
 
-[A17] {RM} Believe it or not, stat and lstat (and fstat, and mknod)
+{RM} Believe it or not, stat and lstat (and fstat, and mknod)
 are supposed to be undefined references in libc.so.6!  Your problem is
 probably a missing or incorrect /usr/lib/libc.so file; note that this
 is a small text file now, not a symlink to libc.so.6.  It should look
@@ -631,211 +531,276 @@ or in ix86/Linux and alpha/Linux:
 GROUP ( libc.so.6 ld-linux.so.2 libc.a )
 
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q18]	``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?''
+2.8.	How can I compile gcc 2.7.2.1 from the gcc source code using
+	glibc 2.x?
 
-[A18] {UD} No, this is no bug.  This version of the GNU libc already
-follows the Single Unix specifications (and I think the POSIX.1g
-draft which adopted the solution).  The type for parameter describing
-a size is now `socklen_t', a new type.
+{AJ} There's only correct support for glibc 2.0.x in gcc 2.7.2.3
+or later.  You should get at least gcc 2.7.2.3.  All previous versions
+had problems with glibc support.
 
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q19]	``My XXX kernel emulates a floating-point coprocessor for me.
-	  Should I enable --with-fp?''
+2.9.	The `gencat' utility cannot process the catalog sources which
+	were used on my Linux libc5 based system.  Why?
 
-[A19] {UD} As `configure --help' shows the default value is `yes' and
-this should not be changed unless the FPU instructions would be
-invalid.  I.e., an emulated FPU is for the libc as good as a real one.
+{UD} The `gencat' utility provided with glibc complies to the XPG
+standard.  The older Linux version did not obey the standard, so they
+are not compatible.
 
+To ease the transition from the Linux version some of the non-standard
+features are also present in the `gencat' program of GNU libc.  This
+mainly includes the use of symbols for the message number and the automatic
+generation of header files which contain the needed #defines to map the
+symbols to integers.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q20]	``How can I compile gcc 2.7.2.1 from the gcc source code using
-	  glibc 2.x?
+Here is a simple SED script to convert at least some Linux specific
+catalog files to the XPG4 form:
 
-[A20] {AJ} There's only correct support for glibc 2.0.x in gcc 2.7.2.3
-or later.  You should get at least gcc 2.7.2.3.  All previous versions
-had problems with glibc support.
+-----------------------------------------------------------------------
+# Change catalog source in Linux specific format to standard XPG format.
+# Ulrich Drepper <drepper@cygnus.com>, 1996.
+#
+/^\$ #/ {
+  h
+  s/\$ #\([^ ]*\).*/\1/
+  x
+  s/\$ #[^ ]* *\(.*\)/\$ \1/
+}
 
+/^# / {
+  s/^# \(.*\)/\1/
+  G
+  s/\(.*\)\n\(.*\)/\2 \1/
+}
+-----------------------------------------------------------------------
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q21]    ``On Linux I've got problems with the declarations in Linux
-           kernel headers.''
 
-[A21] {UD,AJ} On Linux, the use of kernel headers is reduced to a very
-minimum.  Besides giving Linus the possibility to change the headers
-more freely it has another reason: user level programs now do not
-always use the same types like the kernel does.
+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.
 
-I.e., the libc abstracts the use of types.  E.g., the sigset_t type is
-in the kernel 32 or 64 bits wide.  In glibc it is 1024 bits wide, in
-preparation for future development.  The reasons are obvious: we don't
-want to have a new major release when the Linux kernel gets these
-functionality. Consult the headers for more information about the changes.
+{??} The glibc NIS+ implementation uses a /var/nis/NIS_COLD_START
+file for storing information about the NIS+ server and their public
+keys, because the nis.conf file does not contain all the necessary
+information.  You have to copy a NIS_COLD_START file from a Solaris
+client (the NIS_COLD_START file is byte order independent) or generate
+it with nisinit from the nis-tools package (available at
+http://www-vt.uni-paderborn.de/~kukuk/linux/nisplus.html).
 
-Therefore you shouldn't include Linux kernel header files directly if
-glibc has defined a replacement. Otherwise you might get undefined
-results because of type conflicts.
 
+2.11.	After installing glibc name resolving doesn't work properly.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[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.''
+{AJ} You probably should read the manual section describing
+nsswitch.conf (just type `info libc "NSS Configuration File"').
+The NSS configuration file is usually the culprit.
 
-[A22] {UD} The problem is that the IPv6 development still has not reached
-a point where it is stable.  There are still lots of incompatible changes
-made and the libc headers have to follow.
 
-Currently (as of 970401) according to Philip Blundell <philb@gnu.ai.mit.edu>
-the required kernel version is 2.1.30.
+2.12.	I have /usr/include/net and /usr/include/scsi as symlinks
+	into my Linux source tree.  Is that wrong?
 
+{PB} This was necessary for libc5, but is not correct when using
+glibc.  Including the kernel header files directly in user programs
+usually does not work (see question 3.5).  glibc provides its own <net/*>
+and <scsi/*> header files to replace them, and you may have to remove
+any symlink that you have in place before you install glibc.  However,
+/usr/include/asm and /usr/include/linux should remain as they were.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q23]	``When compiling GNU libc I get lots of errors saying functions
-	  in glibc are duplicated in libgcc.''
 
-[A23] {EY} This is *exactly* the same problem that I was having.  The
-problem was due to the fact that the autoconfigure didn't correctly
-detect that linker flag --no-whole-archive was supported in my linker.
-In my case it was because I had run ./configure with bogus CFLAGS, and
-the test failed.
+2.13.	Programs like `logname', `top', `uptime' `users', `w' and
+	`who', show incorrect information about the (number of)
+	users on my system.  Why?
 
-One thing that is particularly annoying about this problem is that
-once this is misdetected, running configure again won't fix it unless
-you first delete config.cache.
+{MK} See question 3.2.
 
-{UD} Starting with glibc-2.0.3 there should be a better test to avoid
-some problems of this kind.  The setting of CFLAGS is checked at the
-very beginning and if it is not usable `configure' will bark.
 
+2.14.	After upgrading to glibc 2.1 with symbol versioning I get
+	errors about undefined symbols.  What went wrong?
 
+{AJ} The problem is caused either by wrong program code or tools.  In
+the versioned libc a lot of symbols are now local that were global
+symbols in previous versions.  It seems that programs linked against
+older versions often accidentally used libc global variables --
+something that should not happen.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[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.''
+The only way to fix this is to recompile your program. Sorry, that's
+the price you might have to pay once for quite a number of advantages
+with symbol versioning.
 
-[A24] The glibc NIS+ implementation uses a /var/nis/NIS_COLD_START
-file for storing information about the NIS+ server and their public
-keys, because the nis.conf file do not contain all necessary
-information.  You have to copy a NIS_COLD_START file from a Solaris
-client (the NIS_COLD_START file is byte order independend) or generate
-it new with nisinit from the nis-tools (look at
-http://www-vt.uni-paderborn.de/~kukuk/linux/nisplus.html).
 
+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?
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q25]	``After installing glibc name resolving doesn't work properly.''
+{UD} As the message says, relink the binary.  The problem is that
+a few symbols from the library can change in size and there is no way
+to avoid this.  _sys_errlist is a good example.  Occasionally there are
+new error numbers added to the kernel and this must be reflected at user
+level, breaking programs that refer to them directly.
 
-[A25] {AJ} You  probable should read the manual section describing
-``nsswitch.conf'' (just type `info libc "NSS Configuration File"').
-The NSS configuration file is usually the culprit.
+Such symbols should normally not be used at all.  There are mechanisms
+to avoid using them.  In the case of _sys_errlist, there is the
+strerror() function which should _always_ be used instead.  So the
+correct fix is to rewrite that part of the application.
 
+In some situations (especially when testing a new library release) it
+might be possible that a symbol changed size when that should not have
+happened.  So in case of doubt report such a warning message as a
+problem.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q26]	``I have /usr/include/net and /usr/include/scsi as symlinks
-	  into my Linux source tree.  Is that wrong?''
+
+. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
 
-[A26] {PB} This was necessary for libc5, but is not correct when using
-glibc.  Including the kernel header files directly in user programs
-usually does not work (see Q21).  glibc provides its own <net/*> and
-<scsi/*> header files to replace them, and you may have to remove any
-symlink that you have in place before you install glibc.  However,
-/usr/include/asm and /usr/include/linux should remain as they were.
+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?
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q27]	``Programs like `logname', `top', `uptime' `users', `w' and
-	  `who', show incorrect information about the (number of)
-	  users on my system.  Why?''
+{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 can now be corrected.  Here is a list of the known source code
+incompatibilities:
 
-[A27] {MK} See Q10.
+* _GNU_SOURCE: glibc does not make the GNU extensions available
+  automatically.  If a program depends on GNU extensions or some
+  other non-standard functionality, it is necessary to compile it
+  with the 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 more information consult the file `NOTES' in the GNU C library
+  sources.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q28]	``After upgrading to a glibc 2.1 with symbol versioning I get
-	  errors about undefined symbols.  What went wrong?''
+* reboot(): GNU libc sanitizes the interface of reboot() to be more
+  compatible with the interface used on other OSes.  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 change, but the
+  prototype is in a separate header file <sys/swap.h>.  This header
+  file also provides the SWAP_* constants defined by <linux/swap.h>;
+  you should use them for the second argument to swapon().
+
+* errno: If a program uses the variable "errno", then it _must_
+  include <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 references to an undeclared
+  symbol "errno".
 
-[A28] {AJ} In a versioned libc a lot of symbols are now local that
-have been global symbols in previous versions. When defining a extern
-variable both in a user program and extern in the libc the links
-resolves this to only one reference - the one in the library. The
-problem is caused by either wrong program code or tools. In no case
-the global variables from libc should be used by any program. Since
-these reference are now local, you might see a message like:
+* 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 table lists all the new syscall stubs,
+  the header-file declaring their interface and the system call name.
 
-"msgfmt: error in loading shared libraries: : undefined symbol: _nl_domain_bindings"
+       syscall name:	wrapper name:	declaring header file:
+       -------------	-------------	----------------------
+       bdflush		bdflush		<sys/kdaemon.h>
+       syslog		ksyslog_ctl	<sys/klog.h>
 
-The only way to fix this is to recompile your program. Sorry, that's
-the price you might have to pay once for quite a number of advantages
-with symbol versioning.
+* 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 interface.  Simply
+  upgrading to a newer lpd should fix this problem (e.g., the 4.4BSD
+  lpd is known to be working).
 
+* resolver functions/BIND: like on many other systems the functions of
+  the resolver library are not included in libc itself.  There is a
+  separate library libresolv.  If you get undefined symbol errors for
+  symbols starting with `res_*' simply add -lresolv to your linker
+  command line.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q29]	``I don't include any kernel header myself but still the
-	  compiler complains about type redeclarations of types in the
-	  kernel headers.''
+* the `signal' function's behavior corresponds to the BSD semantic and
+  not the SysV semantic as it was in libc-5.  The interface on all GNU
+  systems shall be the same and BSD is the semantic of choice.  To use
+  the SysV behavior simply use `sysv_signal', or define _XOPEN_SOURCE.
+  See question 3.7 for details.
 
-[A29] {UD} The kernel headers before Linux 2.1.61 don't work correctly with
-glibc since they pollute the name space in a not acceptable way.  Compiling
-C programs is possible in most cases but especially C++ programs have (due
-to the change of the name lookups for `struct's) problem.  One prominent
-example is `struct fd_set'.
 
-There might be some more problems left but 2.1.61 fixes some of the known
-ones.  See the BUGS file for other known problems.
+3.2.	Why does getlogin() always return NULL on my Linux box?
+
+{UD} The GNU C library has a format for the UTMP and WTMP file which
+differs from what your system currently has.  It was extended to
+fulfill the needs of the next years when IPv6 is introduced.  The
+record size is different and some fields have different positions.
+The files written by functions from the one library cannot be read by
+functions from the other library.  Sorry, but this is what a major
+release is for.  It's better to have a cut now than having no means to
+support the new techniques later.
 
+{MK} There is however a (partial) solution for this problem.  Please
+take a look at the file `README.utmpd'.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[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?''
 
-[A30] {UD} As the message says, relink the binary.  The problem is that
-very few symbols from the library can change in size and there is no way
-to avoid this.  _sys_errlist is a good example.  Occasionally there are
-new error numbers added to the kernel and this must be reflected at user
-level.
+3.3.	Where are the DST_* constants found in <sys/time.h> on many
+	systems?
 
-But this does not mean all programs are doomed once such a change is
-necessary.  Such symbols should normally not be used at all.  There are
-mechanisms to avoid using them.  In the case of _sys_errlist, there is the
-strerror() function which should _always_ be used instead.  So the correct
-fix is to rewrite that part of the application.
+{UD} These constants come from the old BSD days and are not used
+anymore (libc5 does not actually implement the handling although the
+constants are defined).
 
-In some situations (especially when testing a new library release) it might
-be possible that such a symbol size change slipped in though it must not
-happen.  So in case of doubt report such a warning message as a problem.
+Instead GNU libc contains zone database support and compatibility code
+for POSIX TZ environment variable handling.
 
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q31]	``What's the problem with configure --enable-omitfp?''
+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?
 
-[A31] {AJ} When configuring with --enable-omitfp the libraries are build
-without frame pointers. Some compilers produce in this situation buggy
-code and therefore we don't advise using it at the moment.
+{UD} No, this is no bug.  This version of GNU libc already follows the
+new Single Unix specifications (and I think the POSIX.1g draft which
+adopted the solution).  The type for a parameter describing a size is
+now `socklen_t', a new type.
 
-If you use --enable-omitfp, you're on your own. If you encounter
-problems with a library that was build this way, I'll advise you to
-rebuild the library without --enable-omitfp.  If the problem vanishes
-consider tracking the problem down and report it as compiler failure.
 
-Since a library build with --enable-omitfp is undebuggable, a
-debuggable library is also build - you can recognize it by the suffix
-"_g" to the library names.
+3.5.	On Linux I've got problems with the declarations in Linux
+	kernel headers.
 
-The compilation of this extra libraries and the compiler optimizations
-slow down the build process and need more disk space.
+{UD,AJ} On Linux, the use of kernel headers is reduced to the minimum.
+This gives Linus the ability to change the headers more freely.  Also,
+user programs are now insulated from changes in the size of kernel
+data structures.
 
+For example, the sigset_t type is 32 or 64 bits wide in the kernel.
+In glibc it is 1024 bits wide.  This guarantees that when the kernel
+gets a bigger sigset_t (for POSIX.1e realtime support, say) user
+programs will not have to be recompiled.  Consult the header files for
+more information about the changes.
+
+Therefore you shouldn't include Linux kernel header files directly if
+glibc has defined a replacement. Otherwise you might get undefined
+results because of type conflicts.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q32]	``Why don't signals interrupt system calls anymore?''
 
-[A32] {ZW} By default GNU libc uses the BSD semantics for signal(),
+3.6.	I don't include any kernel headers myself but the compiler
+	still complains about redeclarations of types in the kernel
+	headers.
+
+{UD} The kernel headers before Linux 2.1.61 don't work correctly with
+glibc.  Compiling C programs is possible in most cases but C++
+programs have (due to the change of the name lookups for `struct's)
+problems.  One prominent example is `struct fd_set'.
+
+There might be some problems left but 2.1.61 fixes most of the known
+ones.  See the BUGS file for other known problems.
+
+
+3.7.	Why don't signals interrupt system calls anymore?
+
+{ZW} By default GNU libc uses the BSD semantics for signal(),
 unlike Linux libc 5 which used System V semantics.  This is partially
 for compatibility with other systems and partially because the BSD
 semantics tend to make programming with signals easier.
@@ -851,7 +816,7 @@ There are three differences:
 
 * A BSD signal is blocked during the execution of its handler.  In other
   words, a handler for SIGCHLD (for example) does not need to worry about
-  being interrupted by another SIGCHLD.  It may, however, be interrrupted
+  being interrupted by another SIGCHLD.  It may, however, be interrupted
   by other signals.
 
 There is general consensus that for `casual' programming with signals, the
@@ -872,33 +837,32 @@ and return EINTR (for example, to implement a timeout) you can do this with
 siginterrupt().
 
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q33]	``I've got errors compiling code that uses certain string
-	  functions.  Why?''
+3.8.	I've got errors compiling code that uses certain string
+	functions.  Why?
+
+{AJ} glibc 2.1 has special string functions that are faster
+than the normal library functions. Some of the functions are
+implemented as inline functions and others as macros.
 
-[A33] {AJ} glibc 2.1 has the much asked for optimized string
-functions that are faster than the normal library functions. Some of
-the functions are implemented as inline functions and others as
-macros.
 The optimized string functions are only used when compiling with
-optimizations (-O1 or higher). The behaviour can be changed with two
+optimizations (-O1 or higher). The behavior can be changed with two
 feature macros:
-* __NO_STRING_INLINES: Don't use string optimizations.
-* __USE_STRING_INLINES: Use also assembler inline functions (might
-  increase code use dramatically).
+
+* __NO_STRING_INLINES: Don't do any string optimizations.
+* __USE_STRING_INLINES: Use assembly language inline functions (might
+  increase code size dramatically).
 
 Since some of these string functions are now additionally defined as
-macros, code like "char *strncpy();" doesn't work anymore (and is even
-unneccessary since <string.h> has the necessary declarations). Either
+macros, code like "char *strncpy();" doesn't work anymore (and is
+unnecessary, since <string.h> has the necessary declarations). Either
 change your code or define __NO_STRING_INLINES.
 
-{UD} Another problem in this area is that the gcc still has problems on
+{UD} Another problem in this area is that gcc still has problems on
 machines with very few registers (e.g., ix86).  The inline assembler
-code sometimes requires many/all registers and the register allocator
-cannot handle these situation in all cases.
+code can require almost all the registers and the register allocator
+cannot always handle this situation.
 
-If a function is also defined as a macro in the libc headers one can prevent
-the use of the macro easily.  E.g., instead of
+One can disable the string optimizations selectively.  Instead of writing
 
 	cp = strcpy (foo, "lkj");
 
@@ -906,17 +870,39 @@ one can write
 
 	cp = (strcpy) (foo, "lkj");
 
-Using this method one can avoid using the optimizations for selected
-function calls.
+This disables the optimization for that specific call.
+
+
+. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
+
+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?
+
+{UD} You have to get the specified autoconf version (or a later one)
+from your favorite mirror of prep.ai.mit.edu.
+
 
+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.
+
+{UD} The problem is that IPv6 development still has not reached a
+point where the headers are stable.  There are still lots of
+incompatible changes made and the libc headers have to follow.
+
+Also, make sure you have a suitably recent kernel.  As of the 970401
+snapshot, according to Philip Blundell <philb@gnu.ai.mit.edu>, the
+required kernel version is 2.1.30.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
 
+~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 
+
 Answers were given by:
 {UD} Ulrich Drepper, <drepper@cygnus.com>
 {DMT} David Mosberger-Tang, <davidm@AZStarNet.com>
 {RM} Roland McGrath, <roland@gnu.org>
-{HJL} H.J. Lu, <hjl@gnu.org>
 {AJ} Andreas Jaeger, <aj@arthur.rhein-neckar.de>
 {EY} Eric Youngdale, <eric@andante.jic.com>
 {PB} Phil Blundell, <Philip.Blundell@pobox.com>
@@ -924,5 +910,6 @@ Answers were given by:
 {ZW} Zack Weinberg, <zack@rabi.phys.columbia.edu>
 
 Local Variables:
- mode:text
+ mode:outline
+ outline-regexp:"\\?"
 End:
diff --git a/FAQ.in b/FAQ.in
new file mode 100644
index 0000000000..770bef4133
--- /dev/null
+++ b/FAQ.in
@@ -0,0 +1,787 @@
+	    Frequently Asked Questions about the GNU C Library
+
+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 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
+
+? Compiling glibc
+
+??	What systems does the GNU C Library run on?
+
+{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 as of this release, and most
+probably in the future, are:
+
+	*-*-gnu			GNU Hurd
+	i[3456]86-*-linux-gnu	Linux-2.0 on Intel
+	m68k-*-linux-gnu	Linux-2.0 on Motorola 680x0
+	alpha-*-linux-gnu	Linux-2.0 on DEC Alpha
+	powerpc-*-linux-gnu     Linux and MkLinux on PowerPC systems
+	sparc-*-linux-gnu	Linux-2.0 on SPARC
+	sparc64-*-linux-gnu	Linux-2.0 on UltraSPARC
+
+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
+
+	<bug-glibc@prep.ai.mit.edu>
+
+??	What compiler do I need to build GNU libc?
+
+{UD} You must use GNU CC to compile GNU libc.  A lot of extensions of
+GNU CC are used to increase portability and speed.
+
+GNU CC is found, like all other GNU packages, on
+	ftp://prep.ai.mit.edu/pub/gnu
+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 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.
+
+??	When I try to compile glibc I get only error messages.
+	What's wrong?
+
+{UD} You definitely need GNU make to translate GNU libc.  No
+other make program has the needed functionality.
+
+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.
+
+??	Do I need a special linker or archiver?
+
+{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 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 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.
+
+??	Do I need some more things to compile GNU C Library?
+
+{UD} Yes, there are some more :-).
+
+* 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.)
+
+* 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.
+
+  You should not need these tools unless you change the source files.
+
+* When compiling for Linux, the header files of the Linux kernel must
+  be available to the compiler as <linux/*.h> and <asm/*.h>.
+
+* lots of disk space (~170MB for i?86-linux; more for RISC platforms).
+
+* 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.
+
+  You should avoid compiling in a NFS mounted filesystem.  This is
+  very slow.
+
+  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)
+
+  If you have some more measurements let me know.
+
+??	When I run `nm -u libc.so' on the produced library I still
+	find unresolved symbols.  Can this be ok?
+
+{UD} Yes, this is ok.  There can be several kinds of unresolved
+symbols:
+
+* 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 (fabs for example)
+
+Generally, you should make sure you find a real program which produces
+errors while linking before deciding there is a problem.
+
+??addon	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 ?crypt).
+
+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:
+
+	configure --enable-add-ons=crypt,linuxthreads
+
+for example.
+
+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.
+
+??	My XXX kernel emulates a floating-point coprocessor for me.
+	Should I enable --with-fp?
+
+{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.
+
+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.
+
+??	When compiling GNU libc I get lots of errors saying functions
+	in glibc are duplicated in libgcc.
+
+{EY} This is *exactly* the same problem that I was having.  The
+problem was due to the fact that configure didn't correctly detect
+that the linker flag --no-whole-archive was supported in my linker.
+In my case it was because I had run ./configure with bogus CFLAGS, and
+the test failed.
+
+One thing that is particularly annoying about this problem is that
+once this is misdetected, running configure again won't fix it unless
+you first delete config.cache.
+
+{UD} Starting with glibc-2.0.3 there should be a better test to avoid
+some problems of this kind.  The setting of CFLAGS is checked at the
+very beginning and if it is not usable `configure' will bark.
+
+??	What's the problem with configure --enable-omitfp?
+
+{AJ} When --enable-omitfp is set the libraries are built without frame
+pointers. Some compilers produce buggy code for this model and
+therefore we don't advise using it at the moment.
+
+If you use --enable-omitfp, you're on your own. If you encounter
+problems with a library that was build this way, we advise you to
+rebuild the library without --enable-omitfp.  If the problem vanishes
+consider tracking the problem down and report it as compiler failure.
+
+Since a library build with --enable-omitfp is undebuggable on most
+systems, debuggable libraries are also built - you can use it by
+appending "_g" to the library names.
+
+The compilation of these extra libraries and the compiler optimizations
+slow down the build process and need more disk space.
+
+? Installation and configuration issues
+
+??	Can I replace the libc on my Linux system with GNU libc?
+
+{UD} You cannot replace any existing libc for Linux with GNU
+libc.  It is binary incompatible and therefore has a different major
+version.  You can, however, install it alongside your existing libc.
+
+For Linux there are three major libc versions:
+	libc-4		a.out libc
+	libc-5		original ELF libc
+	libc-6		GNU libc
+
+You can have any combination of these three 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.
+
+??	How do I configure GNU libc so that the essential libraries
+	like libc.so go into /lib and the other into /usr/lib?
+
+{UD,AJ} Like all other GNU packages GNU libc is designed to use a base
+directory and install all files relative to this.  The default is
+/usr/local, because this is safe (it will not damage the system if
+installed there).  If you wish to install GNU libc as the primary C
+library on your system, set the base directory to /usr (i.e. run
+configure --prefix=/usr <other_options>).  Note that this can damage
+your system; see ?safety for details.
+
+Some systems like Linux have a filesystem standard which makes a
+difference between essential libraries and others.  Essential
+libraries are placed in /lib because this directory is required to be
+located on the same disk partition as /.  The /usr subtree might be
+found on another partition/disk. If you configure for Linux with
+--prefix=/usr, then this will be done automatically.
+
+To install the essential libraries which come with GNU libc in /lib on
+systems other than Linux one must explicitly request it.  Autoconf has
+no option for this so you have to use a `configparms' file (see the
+`INSTALL' file for details).  It should contain:
+
+slibdir=/lib
+sysconfdir=/etc
+
+The first line specifies the directory for the essential libraries,
+the second line the directory for system configuration files.
+
+??safety	How should I avoid damaging my system when I install GNU libc?
+
+{ZW} If you wish to be cautious, do not configure with --prefix=/usr.
+If you don't specify a prefix, glibc will be installed in /usr/local,
+where it will probably not break anything.  (If you wish to be
+certain, set the prefix to something like /usr/local/glibc2 which is
+not used for anything.)
+
+The dangers when installing glibc in /usr are twofold:
+
+* glibc will overwrite the headers in /usr/include.  Other C libraries
+  install a different but overlapping set of headers there, so the
+  effect will probably be that you can't compile anything.  You need to
+  rename /usr/include out of the way first.  (Do not throw it away; you
+  will then lose the ability to compile programs against your old libc.)
+
+* None of your old libraries, static or shared, can be used with a
+  different C library major version.  For shared libraries this is not a
+  problem, because the filenames are different and the dynamic linker
+  will enforce the restriction.  But static libraries have no version
+  information.  You have to evacuate all the static libraries in
+  /usr/lib to a safe location.
+
+The situation is rather similar to the move from a.out to ELF which
+long-time Linux users will remember.
+
+??	Do I need to use GNU CC to compile programs that will use the
+	GNU C Library?
+
+{ZW} In theory, no; the linker does not care, and the headers are
+supposed to check for GNU CC before using its extensions to the C
+language.
+
+However, there are currently no ports of glibc to systems where
+another compiler is the default, so no one has tested the headers
+extensively against another compiler.  You may therefore encounter
+difficulties.  If you do, please report them as bugs.
+
+Also, in several places GNU extensions provide large benefits in code
+quality.  For example, the library has hand-optimized, inline assembly
+versions of some string functions.  These can only be used with GCC.
+See ?string for details.
+
+??crypt	When linking with the new libc I get unresolved symbols
+	`crypt' and `setkey'.  Why aren't these functions in the
+	libc anymore?
+
+{UD} The US places restrictions on exporting cryptographic programs
+and source code.  Until this law gets abolished we cannot ship the
+cryptographic functions together with glibc.
+
+The functions are available, as an add-on (see ?addon).  People in the
+US may get it from the same place they got GNU libc from.  People
+outside the US should get the code from ftp://ftp.ifi.uio.no/pub/gnu,
+or another archive site outside the USA.  The README explains how to
+install the sources.
+
+If you already have the crypt code on your system the reason for the
+failure is probably that you did not link with -lcrypt.  The crypto
+functions are in a separate library to make it possible to export GNU
+libc binaries from the US.
+
+??	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.
+
+{UD} On Linux, gcc sets the dynamic linker to /lib/ld-linux.so.1
+unless the user specifies a -dynamic-linker argument.  This is the
+name of the libc5 dynamic linker, which does not work with glibc.
+
+For casual use of GNU libc you can just specify
+    -dynamic-linker=/lib/ld-linux.so.2
+
+which is the glibc dynamic linker, on Linux systems.  On other systems
+the name is /lib/ld.so.1.
+
+To change your environment to use GNU libc for compiling you need to
+change the `specs' file of your gcc.  This file is normally found at
+
+	/usr/lib/gcc-lib/<arch>/<version>/specs
+
+In this file you have to change a few things:
+
+- change `ld-linux.so.1' to `ld-linux.so.2'
+
+- remove all expression `%{...:-lgmon}';  there is no libgmon in glibc
+
+- fix a minor bug by changing %{pipe:-} to %|
+
+Here is what the gcc-2.7.2 specs file should look like when GNU libc
+is installed at /usr:
+
+-----------------------------------------------------------------------
+*asm:
+%{V} %{v:%{!V:-V}} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*}
+
+*asm_final:
+%|
+
+*cpp:
+%{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} %{!m386:-D__i486__} %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
+
+*cc1:
+%{profile:-p}
+
+*cc1plus:
+
+
+*endfile:
+%{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s
+
+*link:
+-m elf_i386 %{shared:-shared}   %{!shared:     %{!ibcs:       %{!static: 	%{rdynamic:-export-dynamic} 	%{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2}} 	%{static:-static}}}
+
+*lib:
+%{!shared: %{pthread:-lpthread} 	%{profile:-lc_p} %{!profile: -lc}}
+
+*libgcc:
+-lgcc
+
+*startfile:
+%{!shared:      %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} 		     %{!p:%{profile:gcrt1.o%s} 			 %{!profile:crt1.o%s}}}}    crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s}
+
+*switches_need_spaces:
+
+
+*signed_char:
+%{funsigned-char:-D__CHAR_UNSIGNED__}
+
+*predefines:
+-D__ELF__ -Dunix -Di386 -Dlinux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386)
+
+*cross_compile:
+0
+
+*multilib:
+. ;
+
+-----------------------------------------------------------------------
+
+Things get a bit more complicated if you have GNU libc installed in
+some other place than /usr, i.e., if you do not want to use it instead
+of the old libc.  In this case the needed startup files and libraries
+are not found in the regular places.  So the specs file must tell the
+compiler and linker exactly what to use.
+
+Version 2.7.2.3 does and future versions of GCC will automatically
+provide the correct specs.
+
+??	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?
+
+{RM} Believe it or not, stat and lstat (and fstat, and mknod)
+are supposed to be undefined references in libc.so.6!  Your problem is
+probably a missing or incorrect /usr/lib/libc.so file; note that this
+is a small text file now, not a symlink to libc.so.6.  It should look
+something like this:
+
+GROUP ( libc.so.6 ld.so.1 libc.a )
+
+or in ix86/Linux and alpha/Linux:
+
+GROUP ( libc.so.6 ld-linux.so.2 libc.a )
+
+??	How can I compile gcc 2.7.2.1 from the gcc source code using
+	glibc 2.x?
+
+{AJ} There's only correct support for glibc 2.0.x in gcc 2.7.2.3
+or later.  You should get at least gcc 2.7.2.3.  All previous versions
+had problems with glibc support.
+
+??	The `gencat' utility cannot process the catalog sources which
+	were used on my Linux libc5 based system.  Why?
+
+{UD} The `gencat' utility provided with glibc complies to the XPG
+standard.  The older Linux version did not obey the standard, so they
+are not compatible.
+
+To ease the transition from the Linux version some of the non-standard
+features are also present in the `gencat' program of GNU libc.  This
+mainly includes the use of symbols for the message number and the automatic
+generation of header files which contain the needed #defines to map the
+symbols to integers.
+
+Here is a simple SED script to convert at least some Linux specific
+catalog files to the XPG4 form:
+
+-----------------------------------------------------------------------
+# Change catalog source in Linux specific format to standard XPG format.
+# Ulrich Drepper <drepper@cygnus.com>, 1996.
+#
+/^\$ #/ {
+  h
+  s/\$ #\([^ ]*\).*/\1/
+  x
+  s/\$ #[^ ]* *\(.*\)/\$ \1/
+}
+
+/^# / {
+  s/^# \(.*\)/\1/
+  G
+  s/\(.*\)\n\(.*\)/\2 \1/
+}
+-----------------------------------------------------------------------
+
+??	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.
+
+{??} The glibc NIS+ implementation uses a /var/nis/NIS_COLD_START
+file for storing information about the NIS+ server and their public
+keys, because the nis.conf file does not contain all the necessary
+information.  You have to copy a NIS_COLD_START file from a Solaris
+client (the NIS_COLD_START file is byte order independent) or generate
+it with nisinit from the nis-tools package (available at
+http://www-vt.uni-paderborn.de/~kukuk/linux/nisplus.html).
+
+??	After installing glibc name resolving doesn't work properly.
+
+{AJ} You probably should read the manual section describing
+nsswitch.conf (just type `info libc "NSS Configuration File"').
+The NSS configuration file is usually the culprit.
+
+??	I have /usr/include/net and /usr/include/scsi as symlinks
+	into my Linux source tree.  Is that wrong?
+
+{PB} This was necessary for libc5, but is not correct when using
+glibc.  Including the kernel header files directly in user programs
+usually does not work (see ?kerhdr).  glibc provides its own <net/*>
+and <scsi/*> header files to replace them, and you may have to remove
+any symlink that you have in place before you install glibc.  However,
+/usr/include/asm and /usr/include/linux should remain as they were.
+
+??	Programs like `logname', `top', `uptime' `users', `w' and
+	`who', show incorrect information about the (number of)
+	users on my system.  Why?
+
+{MK} See ?getlog.
+
+??	After upgrading to glibc 2.1 with symbol versioning I get
+	errors about undefined symbols.  What went wrong?
+
+{AJ} The problem is caused either by wrong program code or tools.  In
+the versioned libc a lot of symbols are now local that were global
+symbols in previous versions.  It seems that programs linked against
+older versions often accidentally used libc global variables --
+something that should not happen.
+
+The only way to fix this is to recompile your program. Sorry, that's
+the price you might have to pay once for quite a number of advantages
+with symbol versioning.
+
+??	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?
+
+{UD} As the message says, relink the binary.  The problem is that
+a few symbols from the library can change in size and there is no way
+to avoid this.  _sys_errlist is a good example.  Occasionally there are
+new error numbers added to the kernel and this must be reflected at user
+level, breaking programs that refer to them directly.
+
+Such symbols should normally not be used at all.  There are mechanisms
+to avoid using them.  In the case of _sys_errlist, there is the
+strerror() function which should _always_ be used instead.  So the
+correct fix is to rewrite that part of the application.
+
+In some situations (especially when testing a new library release) it
+might be possible that a symbol changed size when that should not have
+happened.  So in case of doubt report such a warning message as a
+problem.
+
+? Source and binary incompatibilities, and what to do about them
+
+??	I expect GNU libc to be 100% source code compatible with
+	the old Linux based GNU libc.  Why isn't it like this?
+
+{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 can now be corrected.  Here is a list of the known source code
+incompatibilities:
+
+* _GNU_SOURCE: glibc does not make the GNU extensions available
+  automatically.  If a program depends on GNU extensions or some
+  other non-standard functionality, it is necessary to compile it
+  with the 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 more information consult the file `NOTES' in the GNU C library
+  sources.
+
+* reboot(): GNU libc sanitizes the interface of reboot() to be more
+  compatible with the interface used on other OSes.  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 change, but the
+  prototype is in a separate header file <sys/swap.h>.  This header
+  file also provides the SWAP_* constants defined by <linux/swap.h>;
+  you should use them for the second argument to swapon().
+
+* errno: If a program uses the variable "errno", then it _must_
+  include <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 references to an 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 table lists all the new syscall stubs,
+  the header-file declaring their interface and the system call name.
+
+       syscall name:	wrapper name:	declaring header file:
+       -------------	-------------	----------------------
+       bdflush		bdflush		<sys/kdaemon.h>
+       syslog		ksyslog_ctl	<sys/klog.h>
+
+* 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 interface.  Simply
+  upgrading to a newer lpd should fix this problem (e.g., the 4.4BSD
+  lpd is known to be working).
+
+* resolver functions/BIND: like on many other systems the functions of
+  the resolver library are not included in libc itself.  There is a
+  separate library libresolv.  If you get undefined symbol errors for
+  symbols starting with `res_*' simply add -lresolv to your linker
+  command line.
+
+* the `signal' function's behavior corresponds to the BSD semantic and
+  not the SysV semantic as it was in libc-5.  The interface on all GNU
+  systems shall be the same and BSD is the semantic of choice.  To use
+  the SysV behavior simply use `sysv_signal', or define _XOPEN_SOURCE.
+  See ?signal for details.
+
+??getlog	Why does getlogin() always return NULL on my Linux box?
+
+{UD} The GNU C library has a format for the UTMP and WTMP file which
+differs from what your system currently has.  It was extended to
+fulfill the needs of the next years when IPv6 is introduced.  The
+record size is different and some fields have different positions.
+The files written by functions from the one library cannot be read by
+functions from the other library.  Sorry, but this is what a major
+release is for.  It's better to have a cut now than having no means to
+support the new techniques later.
+
+{MK} There is however a (partial) solution for this problem.  Please
+take a look at the file `README.utmpd'.
+
+??	Where are the DST_* constants found in <sys/time.h> on many
+	systems?
+
+{UD} These constants come from the old BSD days and are not used
+anymore (libc5 does not actually implement the handling although the
+constants are defined).
+
+Instead GNU libc contains zone database support and compatibility code
+for POSIX TZ environment variable handling.
+
+??	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?
+
+{UD} No, this is no bug.  This version of GNU libc already follows the
+new Single Unix specifications (and I think the POSIX.1g draft which
+adopted the solution).  The type for a parameter describing a size is
+now `socklen_t', a new type.
+
+??kerhdr	On Linux I've got problems with the declarations in Linux
+	kernel headers.
+
+{UD,AJ} On Linux, the use of kernel headers is reduced to the minimum.
+This gives Linus the ability to change the headers more freely.  Also,
+user programs are now insulated from changes in the size of kernel
+data structures.
+
+For example, the sigset_t type is 32 or 64 bits wide in the kernel.
+In glibc it is 1024 bits wide.  This guarantees that when the kernel
+gets a bigger sigset_t (for POSIX.1e realtime support, say) user
+programs will not have to be recompiled.  Consult the header files for
+more information about the changes.
+
+Therefore you shouldn't include Linux kernel header files directly if
+glibc has defined a replacement. Otherwise you might get undefined
+results because of type conflicts.
+
+??	I don't include any kernel headers myself but the compiler
+	still complains about redeclarations of types in the kernel
+	headers.
+
+{UD} The kernel headers before Linux 2.1.61 don't work correctly with
+glibc.  Compiling C programs is possible in most cases but C++
+programs have (due to the change of the name lookups for `struct's)
+problems.  One prominent example is `struct fd_set'.
+
+There might be some problems left but 2.1.61 fixes most of the known
+ones.  See the BUGS file for other known problems.
+
+??signal	Why don't signals interrupt system calls anymore?
+
+{ZW} By default GNU libc uses the BSD semantics for signal(),
+unlike Linux libc 5 which used System V semantics.  This is partially
+for compatibility with other systems and partially because the BSD
+semantics tend to make programming with signals easier.
+
+There are three differences:
+
+* BSD-style signals that occur in the middle of a system call do not
+  affect the system call; System V signals cause the system call to
+  fail and set errno to EINTR.
+
+* BSD signal handlers remain installed once triggered.  System V signal
+  handlers work only once, so one must reinstall them each time.
+
+* A BSD signal is blocked during the execution of its handler.  In other
+  words, a handler for SIGCHLD (for example) does not need to worry about
+  being interrupted by another SIGCHLD.  It may, however, be interrupted
+  by other signals.
+
+There is general consensus that for `casual' programming with signals, the
+BSD semantics are preferable.  You don't need to worry about system calls
+returning EINTR, and you don't need to worry about the race conditions
+associated with one-shot signal handlers.
+
+If you are porting an old program that relies on the old semantics, you can
+quickly fix the problem by changing signal() to sysv_signal() throughout.
+Alternatively, define _XOPEN_SOURCE before including <signal.h>.
+
+For new programs, the sigaction() function allows you to specify precisely
+how you want your signals to behave.  All three differences listed above are
+individually switchable on a per-signal basis with this function.
+
+If all you want is for one specific signal to cause system calls to fail
+and return EINTR (for example, to implement a timeout) you can do this with
+siginterrupt().
+
+
+??string	I've got errors compiling code that uses certain string
+	functions.  Why?
+
+{AJ} glibc 2.1 has special string functions that are faster
+than the normal library functions. Some of the functions are
+implemented as inline functions and others as macros.
+
+The optimized string functions are only used when compiling with
+optimizations (-O1 or higher). The behavior can be changed with two
+feature macros:
+
+* __NO_STRING_INLINES: Don't do any string optimizations.
+* __USE_STRING_INLINES: Use assembly language inline functions (might
+  increase code size dramatically).
+
+Since some of these string functions are now additionally defined as
+macros, code like "char *strncpy();" doesn't work anymore (and is
+unnecessary, since <string.h> has the necessary declarations). Either
+change your code or define __NO_STRING_INLINES.
+
+{UD} Another problem in this area is that gcc still has problems on
+machines with very few registers (e.g., ix86).  The inline assembler
+code can require almost all the registers and the register allocator
+cannot always handle this situation.
+
+One can disable the string optimizations selectively.  Instead of writing
+
+	cp = strcpy (foo, "lkj");
+
+one can write
+
+	cp = (strcpy) (foo, "lkj");
+
+This disables the optimization for that specific call.
+
+? Miscellaneous
+
+??	After I changed configure.in I get `Autoconf version X.Y.
+	or higher is required for this script'.  What can I do?
+
+{UD} You have to get the specified autoconf version (or a later one)
+from your favorite mirror of prep.ai.mit.edu.
+
+??	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.
+
+{UD} The problem is that IPv6 development still has not reached a
+point where the headers are stable.  There are still lots of
+incompatible changes made and the libc headers have to follow.
+
+Also, make sure you have a suitably recent kernel.  As of the 970401
+snapshot, according to Philip Blundell <philb@gnu.ai.mit.edu>, the
+required kernel version is 2.1.30.
+
+
+Answers were given by:
+{UD} Ulrich Drepper, <drepper@cygnus.com>
+{DMT} David Mosberger-Tang, <davidm@AZStarNet.com>
+{RM} Roland McGrath, <roland@gnu.org>
+{AJ} Andreas Jaeger, <aj@arthur.rhein-neckar.de>
+{EY} Eric Youngdale, <eric@andante.jic.com>
+{PB} Phil Blundell, <Philip.Blundell@pobox.com>
+{MK} Mark Kettenis, <kettenis@phys.uva.nl>
+{ZW} Zack Weinberg, <zack@rabi.phys.columbia.edu>
+
+Local Variables:
+ mode:outline
+ outline-regexp:"\\?"
+End:
diff --git a/Makeconfig b/Makeconfig
index 4d816a0815..44afe0fe30 100644
--- a/Makeconfig
+++ b/Makeconfig
@@ -688,7 +688,7 @@ ifndef rtld-version-installed-name
 rtld-version-installed-name = ld-$(version).so
 endif
 
-# The librt must contain be linked with the thread library.  It least
+# The librt must be linked with the thread library, at least
 # for now.
 ifneq (,$(findstring linuxthreads,$(add-ons)))
 shared-thread-library = $(common-objpfx)linuxthreads/libpthread.so
diff --git a/Makefile b/Makefile
index 90ba29b76d..2c0785b8d3 100644
--- a/Makefile
+++ b/Makefile
@@ -329,6 +329,8 @@ INSTALL: manual/maint.texi; $(format-me)
 NOTES: manual/creature.texi; $(format-me)
 manual/dir-add.texi manual/dir-add.info: FORCE
 	$(MAKE) $(PARALLELMFLAGS) -C $(@D) $(@F)
+FAQ: gen-FAQ.pl FAQ.in
+	$(PERL) $^ > $@.new && rm -f $@ && mv $@.new $@ && chmod a-w $@
 FORCE:
 
 rpm/%: subdir_distinfo
diff --git a/configure b/configure
index b4e7aec313..b6fd050e16 100755
--- a/configure
+++ b/configure
@@ -692,11 +692,16 @@ fi
 # Check whether --enable-add-ons or --disable-add-ons was given.
 if test "${enable_add_ons+set}" = set; then
   enableval="$enable_add_ons"
-  add_ons=`echo "$enableval" | sed 's/,/ /g'`
+  case "$enableval" in
+    yes) add_ons=`echo $srcdir/*/configure | \
+		  sed -e "s!$srcdir/!!g" -e 's!/configure!!g'`;;
+    *) add_ons=`echo "$enableval" | sed 's/,/ /g'`;;
+   esac
 else
   add_ons=
 fi
 
+
 ac_aux_dir=
 for ac_dir in $srcdir $srcdir/.. $srcdir/../..; do
   if test -f $ac_dir/install-sh; then
@@ -752,7 +757,7 @@ else { echo "configure: error: can not run $ac_config_sub" 1>&2; exit 1; }
 fi
 
 echo $ac_n "checking host system type""... $ac_c" 1>&6
-echo "configure:756: checking host system type" >&5
+echo "configure:761: checking host system type" >&5
 
 host_alias=$host
 case "$host_alias" in
@@ -871,7 +876,7 @@ fi
 # This can take a while to compute.
 sysdep_dir=$srcdir/sysdeps
 echo $ac_n "checking sysdep dirs""... $ac_c" 1>&6
-echo "configure:875: checking sysdep dirs" >&5
+echo "configure:880: checking sysdep dirs" >&5
 # Make sco3.2v4 become sco3.2.4 and sunos4.1.1_U1 become sunos4.1.1.U1.
 os="`echo $os | sed 's/\([0-9A-Z]\)[v_]\([0-9A-Z]\)/\1.\2/g'`"
 
@@ -1072,7 +1077,7 @@ echo "$ac_t""sysdeps/generic" 1>&6
 # SVR4 /usr/ucb/install, which tries to use the nonexistent group "staff"
 # ./install, which can be erroneously created by make from ./install.sh.
 echo $ac_n "checking for a BSD compatible install""... $ac_c" 1>&6
-echo "configure:1076: checking for a BSD compatible install" >&5
+echo "configure:1081: checking for a BSD compatible install" >&5
 if test -z "$INSTALL"; then
 if eval "test \"`echo '$''{'ac_cv_path_install'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -1126,7 +1131,7 @@ if test "$INSTALL" = "${srcdir}/install-sh -c"; then
   INSTALL='\$(..)./install-sh -c'
 fi
 echo $ac_n "checking whether ln -s works""... $ac_c" 1>&6
-echo "configure:1130: checking whether ln -s works" >&5
+echo "configure:1135: checking whether ln -s works" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_LN_S'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1151,7 +1156,7 @@ do
 # Extract the first word of "$ac_prog", so it can be a program name with args.
 set dummy $ac_prog; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1155: checking for $ac_word" >&5
+echo "configure:1160: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_MSGFMT'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1183,7 +1188,7 @@ test -n "$MSGFMT" || MSGFMT=":"
 # Extract the first word of "makeinfo", so it can be a program name with args.
 set dummy makeinfo; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1187: checking for $ac_word" >&5
+echo "configure:1192: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_MAKEINFO'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1223,7 +1228,7 @@ fi
 # Extract the first word of "gcc", so it can be a program name with args.
 set dummy gcc; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1227: checking for $ac_word" >&5
+echo "configure:1232: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_CC'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1252,7 +1257,7 @@ if test -z "$CC"; then
   # Extract the first word of "cc", so it can be a program name with args.
 set dummy cc; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1256: checking for $ac_word" >&5
+echo "configure:1261: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_CC'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1300,7 +1305,7 @@ fi
 fi
 
 echo $ac_n "checking whether the C compiler ($CC $CFLAGS $LDFLAGS) works""... $ac_c" 1>&6
-echo "configure:1304: checking whether the C compiler ($CC $CFLAGS $LDFLAGS) works" >&5
+echo "configure:1309: checking whether the C compiler ($CC $CFLAGS $LDFLAGS) works" >&5
 
 ac_ext=c
 # CFLAGS is not in ac_cpp because -g, -O, etc. are not valid cpp options.
@@ -1310,11 +1315,11 @@ ac_link='${CC-cc} -o conftest $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS
 cross_compiling=$ac_cv_prog_cc_cross
 
 cat > conftest.$ac_ext <<EOF
-#line 1314 "configure"
+#line 1319 "configure"
 #include "confdefs.h"
 main(){return(0);}
 EOF
-if { (eval echo configure:1318: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
+if { (eval echo configure:1323: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
   ac_cv_prog_cc_works=yes
   # If we can't run a trivial program, we are probably using a cross compiler.
   if (./conftest; exit) 2>/dev/null; then
@@ -1337,13 +1342,13 @@ else
  cross_linkable=yes
 fi
 echo $ac_n "checking whether the C compiler ($CC $CFLAGS $LDFLAGS) is a cross-compiler""... $ac_c" 1>&6
-echo "configure:1341: checking whether the C compiler ($CC $CFLAGS $LDFLAGS) is a cross-compiler" >&5
+echo "configure:1346: checking whether the C compiler ($CC $CFLAGS $LDFLAGS) is a cross-compiler" >&5
 echo "$ac_t""$ac_cv_prog_cc_cross" 1>&6
 
 cross_compiling=$ac_cv_prog_cc_cross
 
 echo $ac_n "checking whether we are using GNU C""... $ac_c" 1>&6
-echo "configure:1347: checking whether we are using GNU C" >&5
+echo "configure:1352: checking whether we are using GNU C" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_gcc'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1352,7 +1357,7 @@ else
   yes;
 #endif
 EOF
-if { ac_try='${CC-cc} -E conftest.c'; { (eval echo configure:1356: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } | egrep yes >/dev/null 2>&1; then
+if { ac_try='${CC-cc} -E conftest.c'; { (eval echo configure:1361: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } | egrep yes >/dev/null 2>&1; then
   ac_cv_prog_gcc=yes
 else
   ac_cv_prog_gcc=no
@@ -1369,7 +1374,7 @@ if test $ac_cv_prog_gcc = yes; then
   yes;
 #endif
 EOF
-  if { ac_try='${CC-cc} -E conftest.c'; { (eval echo configure:1373: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } | egrep yes >/dev/null 2>&1; then
+  if { ac_try='${CC-cc} -E conftest.c'; { (eval echo configure:1378: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } | egrep yes >/dev/null 2>&1; then
     if test -z "$CFLAGS"; then
       CFLAGS="-g -O2"
     fi
@@ -1381,7 +1386,7 @@ else
 fi
 
 echo $ac_n "checking build system type""... $ac_c" 1>&6
-echo "configure:1385: checking build system type" >&5
+echo "configure:1390: checking build system type" >&5
 
 build_alias=$build
 case "$build_alias" in
@@ -1404,7 +1409,7 @@ do
 # Extract the first word of "$ac_prog", so it can be a program name with args.
 set dummy $ac_prog; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1408: checking for $ac_word" >&5
+echo "configure:1413: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_BUILD_CC'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1435,7 +1440,7 @@ done
 fi
 
 echo $ac_n "checking how to run the C preprocessor""... $ac_c" 1>&6
-echo "configure:1439: checking how to run the C preprocessor" >&5
+echo "configure:1444: checking how to run the C preprocessor" >&5
 # On Suns, sometimes $CPP names a directory.
 if test -n "$CPP" && test -d "$CPP"; then
   CPP=
@@ -1450,13 +1455,13 @@ else
   # On the NeXT, cc -E runs the code through the compiler's parser,
   # not just through cpp.
   cat > conftest.$ac_ext <<EOF
-#line 1454 "configure"
+#line 1459 "configure"
 #include "confdefs.h"
 #include <assert.h>
 Syntax Error
 EOF
 ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
-{ (eval echo configure:1460: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+{ (eval echo configure:1465: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
 ac_err=`grep -v '^ *+' conftest.out`
 if test -z "$ac_err"; then
   :
@@ -1467,13 +1472,13 @@ else
   rm -rf conftest*
   CPP="${CC-cc} -E -traditional-cpp"
   cat > conftest.$ac_ext <<EOF
-#line 1471 "configure"
+#line 1476 "configure"
 #include "confdefs.h"
 #include <assert.h>
 Syntax Error
 EOF
 ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
-{ (eval echo configure:1477: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+{ (eval echo configure:1482: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
 ac_err=`grep -v '^ *+' conftest.out`
 if test -z "$ac_err"; then
   :
@@ -1506,7 +1511,7 @@ LD=`$CC -print-file-name=ld`
 
 # Determine whether we are using GNU binutils.
 echo $ac_n "checking whether $AS is GNU as""... $ac_c" 1>&6
-echo "configure:1510: checking whether $AS is GNU as" >&5
+echo "configure:1515: checking whether $AS is GNU as" >&5
 if eval "test \"`echo '$''{'libc_cv_prog_as_gnu'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1524,7 +1529,7 @@ rm -f a.out
 gnu_as=$libc_cv_prog_as_gnu
 
 echo $ac_n "checking whether $LD is GNU ld""... $ac_c" 1>&6
-echo "configure:1528: checking whether $LD is GNU ld" >&5
+echo "configure:1533: checking whether $LD is GNU ld" >&5
 if eval "test \"`echo '$''{'libc_cv_prog_ld_gnu'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1548,7 +1553,7 @@ fi
 # Extract the first word of "${ac_tool_prefix}ar", so it can be a program name with args.
 set dummy ${ac_tool_prefix}ar; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1552: checking for $ac_word" >&5
+echo "configure:1557: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_AR'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1579,7 +1584,7 @@ fi
 # Extract the first word of "${ac_tool_prefix}ranlib", so it can be a program name with args.
 set dummy ${ac_tool_prefix}ranlib; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1583: checking for $ac_word" >&5
+echo "configure:1588: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_RANLIB'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1610,7 +1615,7 @@ if test -n "$ac_tool_prefix"; then
   # Extract the first word of "ranlib", so it can be a program name with args.
 set dummy ranlib; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1614: checking for $ac_word" >&5
+echo "configure:1619: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_RANLIB'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1645,7 +1650,7 @@ fi
 # Extract the first word of "bash", so it can be a program name with args.
 set dummy bash; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1649: checking for $ac_word" >&5
+echo "configure:1654: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_path_BASH'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1687,7 +1692,7 @@ if test "$BASH" = no; then
   # Extract the first word of "ksh", so it can be a program name with args.
 set dummy ksh; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1691: checking for $ac_word" >&5
+echo "configure:1696: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_path_KSH'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1733,7 +1738,7 @@ do
 # Extract the first word of "$ac_prog", so it can be a program name with args.
 set dummy $ac_prog; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1737: checking for $ac_word" >&5
+echo "configure:1742: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_path_PERL'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1768,7 +1773,7 @@ test -n "$PERL" || PERL="no"
 
 
 echo $ac_n "checking for signed size_t type""... $ac_c" 1>&6
-echo "configure:1772: checking for signed size_t type" >&5
+echo "configure:1777: checking for signed size_t type" >&5
 if eval "test \"`echo '$''{'libc_cv_signed_size_t'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1792,12 +1797,12 @@ EOF
 fi
 
 echo $ac_n "checking for libc-friendly stddef.h""... $ac_c" 1>&6
-echo "configure:1796: checking for libc-friendly stddef.h" >&5
+echo "configure:1801: checking for libc-friendly stddef.h" >&5
 if eval "test \"`echo '$''{'libc_cv_friendly_stddef'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 1801 "configure"
+#line 1806 "configure"
 #include "confdefs.h"
 #define __need_size_t
 #define __need_wchar_t
@@ -1812,7 +1817,7 @@ size_t size; wchar_t wchar;
 if (&size == NULL || &wchar == NULL) abort ();
 ; return 0; }
 EOF
-if { (eval echo configure:1816: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:1821: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
   rm -rf conftest*
   libc_cv_friendly_stddef=yes
 else
@@ -1831,7 +1836,7 @@ override stddef.h = # The installed <stddef.h> seems to be libc-friendly."
 fi
 
 echo $ac_n "checking whether we need to use -P to assemble .S files""... $ac_c" 1>&6
-echo "configure:1835: checking whether we need to use -P to assemble .S files" >&5
+echo "configure:1840: checking whether we need to use -P to assemble .S files" >&5
 if eval "test \"`echo '$''{'libc_cv_need_minus_P'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1862,7 +1867,7 @@ if test $ac_cv_prog_gcc = yes; then
   # We must check this even if -pipe is not given here, because the user
   # might do `make CFLAGS=-pipe'.
   echo $ac_n "checking for gcc 2.7.x -pipe bug""... $ac_c" 1>&6
-echo "configure:1866: checking for gcc 2.7.x -pipe bug" >&5
+echo "configure:1871: checking for gcc 2.7.x -pipe bug" >&5
 if eval "test \"`echo '$''{'libc_cv_gcc_pipe_bug'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1891,7 +1896,7 @@ else
 fi
 
 echo $ac_n "checking for assembler global-symbol directive""... $ac_c" 1>&6
-echo "configure:1895: checking for assembler global-symbol directive" >&5
+echo "configure:1900: checking for assembler global-symbol directive" >&5
 if eval "test \"`echo '$''{'libc_cv_asm_global_directive'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1921,7 +1926,7 @@ EOF
 fi
 
 echo $ac_n "checking for .set assembler directive""... $ac_c" 1>&6
-echo "configure:1925: checking for .set assembler directive" >&5
+echo "configure:1930: checking for .set assembler directive" >&5
 if eval "test \"`echo '$''{'libc_cv_asm_set_directive'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1955,7 +1960,7 @@ EOF
 fi
 
 echo $ac_n "checking for .symver assembler directive""... $ac_c" 1>&6
-echo "configure:1959: checking for .symver assembler directive" >&5
+echo "configure:1964: checking for .symver assembler directive" >&5
 if eval "test \"`echo '$''{'libc_cv_asm_symver_directive'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1974,7 +1979,7 @@ fi
 
 echo "$ac_t""$libc_cv_asm_symver_directive" 1>&6
 echo $ac_n "checking for ld --version-script""... $ac_c" 1>&6
-echo "configure:1978: checking for ld --version-script" >&5
+echo "configure:1983: checking for ld --version-script" >&5
 if eval "test \"`echo '$''{'libc_cv_ld_version_script_option'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1997,7 +2002,7 @@ EOF
     if { ac_try='${CC-cc} $CFLAGS -shared -o conftest.so conftest.o
 					-nostartfiles -nostdlib
 					-Wl,--version-script,conftest.map
-		       1>&5'; { (eval echo configure:2001: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; };
+		       1>&5'; { (eval echo configure:2006: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; };
     then
       libc_cv_ld_version_script_option=yes
     else
@@ -2035,7 +2040,7 @@ if test $VERSIONING = no; then
 fi
 if test $elf = yes; then
   echo $ac_n "checking for .previous assembler directive""... $ac_c" 1>&6
-echo "configure:2039: checking for .previous assembler directive" >&5
+echo "configure:2044: checking for .previous assembler directive" >&5
 if eval "test \"`echo '$''{'libc_cv_asm_previous_directive'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -2043,7 +2048,7 @@ else
 .section foo_section
 .previous
 EOF
-  if { ac_try='${CC-cc} -c $CFLAGS conftest.s 1>&5'; { (eval echo configure:2047: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then
+  if { ac_try='${CC-cc} -c $CFLAGS conftest.s 1>&5'; { (eval echo configure:2052: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then
     libc_cv_asm_previous_directive=yes
   else
     libc_cv_asm_previous_directive=no
@@ -2059,7 +2064,7 @@ EOF
 
   else
     echo $ac_n "checking for .popsection assembler directive""... $ac_c" 1>&6
-echo "configure:2063: checking for .popsection assembler directive" >&5
+echo "configure:2068: checking for .popsection assembler directive" >&5
 if eval "test \"`echo '$''{'libc_cv_asm_popsection_directive'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -2067,7 +2072,7 @@ else
 .pushsection foo_section
 .popsection
 EOF
-    if { ac_try='${CC-cc} -c $CFLAGS conftest.s 1>&5'; { (eval echo configure:2071: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then
+    if { ac_try='${CC-cc} -c $CFLAGS conftest.s 1>&5'; { (eval echo configure:2076: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then
       libc_cv_asm_popsection_directive=yes
     else
       libc_cv_asm_popsection_directive=no
@@ -2087,12 +2092,12 @@ fi
 
 if test $elf != yes; then
   echo $ac_n "checking for .init and .fini sections""... $ac_c" 1>&6
-echo "configure:2091: checking for .init and .fini sections" >&5
+echo "configure:2096: checking for .init and .fini sections" >&5
 if eval "test \"`echo '$''{'libc_cv_have_initfini'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 2096 "configure"
+#line 2101 "configure"
 #include "confdefs.h"
 
 int main() {
@@ -2101,7 +2106,7 @@ asm (".section .init");
 				    asm (".text");
 ; return 0; }
 EOF
-if { (eval echo configure:2105: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:2110: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
   rm -rf conftest*
   libc_cv_have_initfini=yes
 else
@@ -2129,19 +2134,19 @@ if test $elf = yes; then
 else
   if test $ac_cv_prog_cc_works = yes; then
     echo $ac_n "checking for _ prefix on C symbol names""... $ac_c" 1>&6
-echo "configure:2133: checking for _ prefix on C symbol names" >&5
+echo "configure:2138: checking for _ prefix on C symbol names" >&5
 if eval "test \"`echo '$''{'libc_cv_asm_underscores'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 2138 "configure"
+#line 2143 "configure"
 #include "confdefs.h"
 asm ("_glibc_foobar:");
 int main() {
 glibc_foobar ();
 ; return 0; }
 EOF
-if { (eval echo configure:2145: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
+if { (eval echo configure:2150: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
   rm -rf conftest*
   libc_cv_asm_underscores=yes
 else
@@ -2156,17 +2161,17 @@ fi
 echo "$ac_t""$libc_cv_asm_underscores" 1>&6
   else
     echo $ac_n "checking for _ prefix on C symbol names""... $ac_c" 1>&6
-echo "configure:2160: checking for _ prefix on C symbol names" >&5
+echo "configure:2165: checking for _ prefix on C symbol names" >&5
 if eval "test \"`echo '$''{'libc_cv_asm_underscores'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 2165 "configure"
+#line 2170 "configure"
 #include "confdefs.h"
 void underscore_test(void) {
 return; }
 EOF
-if { (eval echo configure:2170: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:2175: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
   if grep _underscore_test conftest* >/dev/null; then
     rm -f conftest*
     libc_cv_asm_underscores=yes
@@ -2199,7 +2204,7 @@ if test $elf = yes; then
   libc_cv_asm_weakext_directive=no
 else
   echo $ac_n "checking for assembler .weak directive""... $ac_c" 1>&6
-echo "configure:2203: checking for assembler .weak directive" >&5
+echo "configure:2208: checking for assembler .weak directive" >&5
 if eval "test \"`echo '$''{'libc_cv_asm_weak_directive'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -2222,7 +2227,7 @@ echo "$ac_t""$libc_cv_asm_weak_directive" 1>&6
 
 if test $libc_cv_asm_weak_directive = no; then
   echo $ac_n "checking for assembler .weakext directive""... $ac_c" 1>&6
-echo "configure:2226: checking for assembler .weakext directive" >&5
+echo "configure:2231: checking for assembler .weakext directive" >&5
 if eval "test \"`echo '$''{'libc_cv_asm_weakext_directive'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -2259,7 +2264,7 @@ EOF
 fi
 
 echo $ac_n "checking for ld --no-whole-archive""... $ac_c" 1>&6
-echo "configure:2263: checking for ld --no-whole-archive" >&5
+echo "configure:2268: checking for ld --no-whole-archive" >&5
 if eval "test \"`echo '$''{'libc_cv_ld_no_whole_archive'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -2270,7 +2275,7 @@ __throw () {}
 EOF
 if { ac_try='${CC-cc} $CFLAGS
 			    -nostdlib -nostartfiles -Wl,--no-whole-archive
-			    -o conftest conftest.c 1>&5'; { (eval echo configure:2274: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then
+			    -o conftest conftest.c 1>&5'; { (eval echo configure:2279: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then
   libc_cv_ld_no_whole_archive=yes
 else
   libc_cv_ld_no_whole_archive=no
@@ -2281,7 +2286,7 @@ fi
 echo "$ac_t""$libc_cv_ld_no_whole_archive" 1>&6
 
 echo $ac_n "checking for gcc -fno-exceptions""... $ac_c" 1>&6
-echo "configure:2285: checking for gcc -fno-exceptions" >&5
+echo "configure:2290: checking for gcc -fno-exceptions" >&5
 if eval "test \"`echo '$''{'libc_cv_gcc_no_exceptions'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -2292,7 +2297,7 @@ __throw () {}
 EOF
 if { ac_try='${CC-cc} $CFLAGS
 			    -nostdlib -nostartfiles -fno-exceptions
-			    -o conftest conftest.c 1>&5'; { (eval echo configure:2296: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then
+			    -o conftest conftest.c 1>&5'; { (eval echo configure:2301: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then
   libc_cv_gcc_no_exceptions=yes
 else
   libc_cv_gcc_no_exceptions=no
@@ -2303,12 +2308,12 @@ fi
 echo "$ac_t""$libc_cv_gcc_no_exceptions" 1>&6
 
 echo $ac_n "checking for DWARF2 unwind info support""... $ac_c" 1>&6
-echo "configure:2307: checking for DWARF2 unwind info support" >&5
+echo "configure:2312: checking for DWARF2 unwind info support" >&5
 if eval "test \"`echo '$''{'libc_cv_gcc_dwarf2_unwind_info'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.c <<EOF
-#line 2312 "configure"
+#line 2317 "configure"
 static char __EH_FRAME_BEGIN__;
 _start ()
 {
@@ -2329,7 +2334,7 @@ __bzero () {}
 EOF
 if { ac_try='${CC-cc} $CFLAGS
 			    -nostdlib -nostartfiles
-			    -o conftest conftest.c -lgcc >&5'; { (eval echo configure:2333: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then
+			    -o conftest conftest.c -lgcc >&5'; { (eval echo configure:2338: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then
   libc_cv_gcc_dwarf2_unwind_info=yes
 else
   libc_cv_gcc_dwarf2_unwind_info=no
@@ -2387,7 +2392,7 @@ if test "$uname" = "sysdeps/generic"; then
   fi
 
   echo $ac_n "checking OS release for uname""... $ac_c" 1>&6
-echo "configure:2391: checking OS release for uname" >&5
+echo "configure:2396: checking OS release for uname" >&5
 if eval "test \"`echo '$''{'libc_cv_uname_release'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -2409,7 +2414,7 @@ echo "$ac_t""$libc_cv_uname_release" 1>&6
   uname_release="$libc_cv_uname_release"
 
   echo $ac_n "checking OS version for uname""... $ac_c" 1>&6
-echo "configure:2413: checking OS version for uname" >&5
+echo "configure:2418: checking OS version for uname" >&5
 if eval "test \"`echo '$''{'libc_cv_uname_version'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -2431,7 +2436,7 @@ else
 fi
 
 echo $ac_n "checking stdio selection""... $ac_c" 1>&6
-echo "configure:2435: checking stdio selection" >&5
+echo "configure:2440: checking stdio selection" >&5
 
 case $stdio in
 libio) cat >> confdefs.h <<\EOF
@@ -2443,7 +2448,7 @@ esac
 echo "$ac_t""$stdio" 1>&6
 
 echo $ac_n "checking ldap selection""... $ac_c" 1>&6
-echo "configure:2447: checking ldap selection" >&5
+echo "configure:2452: checking ldap selection" >&5
 
 case $add_ons in
 *ldap*)
@@ -2493,7 +2498,7 @@ if test $shared = default; then
 fi
 
 echo $ac_n "checking whether -fPIC is default""... $ac_c" 1>&6
-echo "configure:2497: checking whether -fPIC is default" >&5
+echo "configure:2502: checking whether -fPIC is default" >&5
 if eval "test \"`echo '$''{'pic_default'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
diff --git a/configure.in b/configure.in
index 2ff1af5c00..80fe259b32 100644
--- a/configure.in
+++ b/configure.in
@@ -82,8 +82,13 @@ AC_ARG_ENABLE(versioning, dnl
 dnl Generic infrastructure for drop-in additions to libc.
 AC_ARG_ENABLE(add-ons, dnl
 [  --enable-add-ons=DIR1,DIR2... configure and build named extra directories],
-   	      [add_ons=`echo "$enableval" | sed 's/,/ /g'`],
-	      [add_ons=])
+  [case "$enableval" in
+    yes) add_ons=`echo $srcdir/*/configure | \
+		  sed -e "s!$srcdir/!!g" -e 's!/configure!!g'`;;
+    *) add_ons=`echo "$enableval" | sed 's/,/ /g'`;;
+   esac],
+  [add_ons=])
+
 AC_CONFIG_SUBDIRS($add_ons)
 add_ons_pfx=
 if test x"$add_ons" != x; then
diff --git a/gen-FAQ.pl b/gen-FAQ.pl
new file mode 100755
index 0000000000..e8b55ac7ab
--- /dev/null
+++ b/gen-FAQ.pl
@@ -0,0 +1,144 @@
+#! /usr/local/bin/perl
+
+=pod
+This is a silly little program for generating the libc FAQ.
+
+The input format is:
+top boilerplate
+^L
+? section name (one line)
+?? question...
+...
+{ID} answer...
+...
+^L
+{ID} name <email@address>
+...
+
+which gets mapped to:
+
+top boilerplate
+^L
+1. section 1...
+1.1. q1.1
+1.2. q1.2
+...
+^L
+1. section 1...
+
+1.1. q1.1
+
+answer 1.1....
+
+
+^L
+Answers were provided by:
+...
+
+=cut
+
+# We slurp the whole file into a pair of assoc arrays indexed by
+# the 'section.question' number.
+%questions = ();
+%answers = ();
+$question = 0;
+
+# These arrays and counter keep track of the sections.
+@sectcount = ();
+@sections = ();
+$section = 0;
+
+# Cross reference list.
+%refs = ();
+
+# Separators.
+$sepmaj = "\f\n" . ('~ ' x 36) . "\n\n";
+$sepmin = "\f\n" . ('. ' x 36) . "\n\n";
+
+# Pass through the top boilerplate.
+while(<>)
+{
+    last if $_ eq "\f\n";
+    print;
+}
+
+# Now the body.
+while(<>)
+{
+    /\f/ && do
+    {
+	$sectcount[$section] = $question;
+	last;
+    };
+
+    s/^\?\s+// && do
+    {
+	chomp;
+	$sectcount[$section] = $question if $section > 0;
+	$section++;
+	$sections[$section] = $_;
+	$question = 0;
+	next;
+    };
+    s/^\?\?(\w*?)\s+// && do
+    {
+	$cur = \%questions;
+	$question++;
+	$questions{$section,$question} = $_;
+	$refs{$1} = "$section.$question" if $1 ne "";
+	next;
+    };
+    /^\{/ && do
+    {
+	$cur = \%answers;
+	$answers{$section,$question} .= $_;
+	next;
+    };
+
+    ${$cur}{$section,$question} .= $_;
+}
+
+# Now we have to clean up the newlines and deal with cross references.
+foreach(keys %questions) { $questions{$_} =~ s/\n+$//; }
+foreach(keys %answers)
+{
+    $answers{$_} =~ s/\n+$//;
+    $answers{$_} =~ s/(\s)\?(\w+)\b/$1 . "question " . ($refs{$2} or badref($2,$_), "!!$2")/eg;
+}
+
+# Now output the formatted FAQ.
+print $sepmaj;
+for($i = 1; $i <= $section; $i++)
+{
+    print "$i. $sections[$i]\n\n";
+    for($j = 1; $j <= $sectcount[$i]; $j++)
+    {
+	print "$i.$j.\t$questions{$i,$j}\n";
+    }
+    print "\n";
+}
+
+print $sepmaj;
+for($i = 1; $i <= $section; $i++)
+{
+    print "$i. $sections[$i]\n\n";
+    for($j = 1; $j <= $sectcount[$i]; $j++)
+    {
+	print "$i.$j.\t$questions{$i,$j}\n\n";
+	print $answers{$i,$j}, "\n\n";
+	print "\n" if $j < $sectcount[$i];
+    }
+    print $sepmin if $i < $section;
+}
+
+print $sepmaj;
+
+# Pass through the trailer.
+while(<>) { print; }
+
+sub badref
+{
+    my($ref,$quest) = @_;
+    $quest =~ s/$;/./;
+    print STDERR "Undefined reference to $ref in answer to Q$quest\n";
+}
diff --git a/iconvdata/Makefile b/iconvdata/Makefile
index f08a090363..52fbace463 100644
--- a/iconvdata/Makefile
+++ b/iconvdata/Makefile
@@ -25,7 +25,8 @@ subdir	:= iconvdata
 modules	:= ISO8859-1 ISO8859-2 ISO8859-3 ISO8859-4 ISO8859-5		\
 	   ISO8859-6 ISO8859-7 ISO8859-8 ISO8859-9 ISO8859-10		\
 	   T.61 ISO_6937 SJIS KOI-8 KOI8-R LATIN-GREEK LATIN-GREEK-1	\
-	   HP-ROMAN8 EBCDIC-AT-DE EBCDIC-AT-DE-A EBCDIC-CA-FR
+	   HP-ROMAN8 EBCDIC-AT-DE EBCDIC-AT-DE-A EBCDIC-CA-FR		\
+	   libJIS
 modules.so := $(addsuffix .so, $(modules))
 
 
@@ -52,12 +53,7 @@ HP-ROMAN8-routines := hp-roman8
 EBCDIC-AT-DE-routines := ebcdic-at-de
 EBCDIC-AT-DE-A-routines := ebcdic-at-de-a
 EBCDIC-CA-FR-routines := ebcdic-ca-fr
-
-extra-libs = libJIS
-extra-libs-others = $(extra-libs)
-
 libJIS-routines := jis0201 jis0208 jis0212
-libJIS-inhibit-o := $(filter-out .os,$(object-suffixes))
 
 distribute := 8bit-generic.c 8bit-gap.c gap.pl gaptab.pl \
 	      iso8859-1.c iso8859-2.c iso8859-3.c iso8859-4.c iso8859-5.c \
diff --git a/rt/librt.map b/rt/librt.map
new file mode 100644
index 0000000000..375a02877e
--- /dev/null
+++ b/rt/librt.map
@@ -0,0 +1,11 @@
+GLIBC_2.1 {
+  global:
+
+    # AIO functions.
+    aio_cancel; aio_cancel64; aio_error; aio_error64; aio_fsync; aio_fsync64;
+    aio_read; aio_read64; aio_return; aio_return64; aio_suspend; aio_suspend64;
+    aio_write; aio_write64; lio_listio; lio_listio64;
+
+  local:
+    *;
+};
diff --git a/string/bits/string2.h b/string/bits/string2.h
index f0172bf186..8779e35817 100644
--- a/string/bits/string2.h
+++ b/string/bits/string2.h
@@ -25,11 +25,11 @@
 #ifndef __NO_STRING_INLINES
 
 /* Unlike the definitions in the header <bits/string.h> the
-   definitions contained here are not optimizing down to assembler
-   level.  These optimizations are not always a good idea since this
+   definitions contained here are not optimized down to assembler
+   level.  Those optimizations are not always a good idea since this
    means the code size increases a lot.  Instead the definitions here
-   optimize some functions in a way which does not dramatically
-   increase the code size and which does not use assembler.  The main
+   optimize some functions in a way which do not dramatically
+   increase the code size and which do not use assembler.  The main
    trick is to use GNU CC's `__builtin_constant_p' function.
 
    Every function XXX which has a defined version in
diff --git a/string/string.h b/string/string.h
index 39d1d61193..2b4d6b9545 100644
--- a/string/string.h
+++ b/string/string.h
@@ -298,18 +298,18 @@ extern char *basename __P ((__const char *__filename));
 /* When using GNU CC we provide some optimized versions of selected
    functions from this header.  There are two kinds of optimizations:
 
-   - machine-dependent optmizations, most probably using inline
-     assembler code; these could be quite expensive since the code
-     size could increase significantly.
+   - machine-dependent optimizations, most probably using inline
+     assembler code; these might be quite expensive since the code
+     size can increase significantly.
      These optimizations are not used unless the symbol
 	__USE_STRING_INLINES
-     is defined before including this header
+     is defined before including this header.
 
    - machine-independent optimizations which do not increase the
      code size significantly and which optimize mainly situations
      where one or more arguments are compile-time constants.
      These optimizations are used always when the compiler is
-     taught to optimized.
+     taught to optimize.
 
    One can inhibit all optimizations by defining __NO_STRING_INLINES.  */
 
diff --git a/sunrpc/xcrypt.c b/sunrpc/xcrypt.c
index ec4110036c..d770a7d648 100644
--- a/sunrpc/xcrypt.c
+++ b/sunrpc/xcrypt.c
@@ -62,7 +62,7 @@ static char hex[16] =
   (c >= '0' && c <= '9'							      \
    ? c - '0'								      \
    : ({	int upp = toupper (c);						      \
-	upp >= 'a' && upp <= 'z' ? upp - 'a' + 10 : -1; }))
+	upp >= 'A' && upp <= 'Z' ? upp - 'A' + 10 : -1; }))
 #else
 static char hexval (char) internal_function;
 #endif
diff --git a/sysdeps/generic/enbl-secure.c b/sysdeps/generic/enbl-secure.c
index 8e1327c878..3520ad5fb0 100644
--- a/sysdeps/generic/enbl-secure.c
+++ b/sysdeps/generic/enbl-secure.c
@@ -32,7 +32,7 @@ uid_t __libc_uid;
 void
 __libc_init_secure (void)
 {
-  __libc_uid == __getuid ();
+  __libc_uid = __getuid ();
   __libc_enable_secure = (__geteuid () != __libc_uid
 			  || __getegid () != __getgid ());
 }
diff --git a/sysdeps/unix/sysv/linux/bits/socket.h b/sysdeps/unix/sysv/linux/bits/socket.h
index f48f2d1403..42a4f8b74f 100644
--- a/sysdeps/unix/sysv/linux/bits/socket.h
+++ b/sysdeps/unix/sysv/linux/bits/socket.h
@@ -66,7 +66,15 @@ enum __socket_type
 #define	PF_AAL5		8	/* Reserved for Werner's ATM.  */
 #define	PF_X25		9	/* Reserved for X.25 project.  */
 #define	PF_INET6	10	/* IP version 6.  */
-#define	PF_MAX		12	/* For now.. */
+#define	PF_ROSE		11	/* Amateur Radio X.25 PLP       */
+#define	PF_DECnet	12	/* Reserved for DECnet project  */
+#define	PF_NETBEUI	13	/* Reserved for 802.2LLC project*/
+#define	PF_SECURITY	14	/* Security callback pseudo AF */
+#define	pseudo_PF_KEY	15	/* PF_KEY key management API */
+#define	PF_NETLINK	16
+#define	PF_ROUTE	PF_NETLINK /* Alias to emulate 4.4BSD */
+#define	PF_PACKET	17	/* Packet family                */
+#define	PF_MAX		32	/* For now.. */
 
 /* Address families.  */
 #define	AF_UNSPEC	PF_UNSPEC
@@ -82,6 +90,14 @@ enum __socket_type
 #define	AF_AAL5		PF_AAL5
 #define	AF_X25		PF_X25
 #define	AF_INET6	PF_INET6
+#define	AF_ROSE		PF_ROSE
+#define	AF_DECnet	PF_DECnet
+#define	AF_NETBEUI	PF_NETBEUI
+#define	AF_SECURITY	PF_SECURITY
+#define	AF_KEY		pseudo_PF_KEY
+#define	AF_NETLINK	PF_NETLINK
+#define	AF_ROUTE	PF_ROUTE
+#define	AF_PACKET	PF_PACKET
 #define	AF_MAX		PF_MAX
 
 /* Socket level values.  Others are defined in the appropriate headers.
diff --git a/sysdeps/unix/sysv/linux/i386/s_pread64.S b/sysdeps/unix/sysv/linux/i386/s_pread64.S
new file mode 100644
index 0000000000..22ce79b3f0
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/i386/s_pread64.S
@@ -0,0 +1,45 @@
+/* pread64 syscall for Linux/ix86.
+   Copyright (C) 1997 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Library General Public License as
+   published by the Free Software Foundation; either version 2 of the
+   License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Library General Public License for more details.
+
+   You should have received a copy of the GNU Library General Public
+   License along with the GNU C Library; see the file COPYING.LIB.  If not,
+   write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+   Boston, MA 02111-1307, USA.  */
+
+#include <sysdep.h>
+
+/* Please consult the file sysdeps/unix/sysv/linux/i386/sysdep.h for
+   more information about the value -4095 used below.*/
+
+	.text
+ENTRY (__syscall_pread64)
+
+	PUSHARGS_5		/* Save register contents.  */
+
+	/* Load arguments.  This is unfortunately a little bit of a problem
+	   since the kernel expects the arguments in a different order.  */
+	movl	0x20(%esp,1),%esi
+	movl	0x1c(%esp,1),%edi
+	movl	0x18(%esp,1),%edx
+	movl	0x14(%esp,1),%ecx
+	movl	0x10(%esp,1),%ebx
+	/* Load syscall number into %eax.  */
+	movl	$SYS_ify(pread), %eax
+	int	$0x80		/* Do the system call.  */
+	POPARGS_5		/* Restore register contents.  */
+	cmpl	$-4095, %eax	/* Check %eax for error.  */
+	jae	syscall_error	/* Jump to error handler if error.  */
+	ret			/* Return to caller.  */
+
+PSEUDO_END (__syscall_pread64)
diff --git a/sysdeps/unix/sysv/linux/i386/s_pwrite64.S b/sysdeps/unix/sysv/linux/i386/s_pwrite64.S
new file mode 100644
index 0000000000..6a1987b72e
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/i386/s_pwrite64.S
@@ -0,0 +1,45 @@
+/* pwrite64 syscall for Linux/ix86.
+   Copyright (C) 1997 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Library General Public License as
+   published by the Free Software Foundation; either version 2 of the
+   License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Library General Public License for more details.
+
+   You should have received a copy of the GNU Library General Public
+   License along with the GNU C Library; see the file COPYING.LIB.  If not,
+   write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+   Boston, MA 02111-1307, USA.  */
+
+#include <sysdep.h>
+
+/* Please consult the file sysdeps/unix/sysv/linux/i386/sysdep.h for
+   more information about the value -4095 used below.*/
+
+	.text
+ENTRY (__syscall_pwrite64)
+
+	PUSHARGS_5		/* Save register contents.  */
+
+	/* Load arguments.  This is unfortunately a little bit of a problem
+	   since the kernel expects the arguments in a different order.  */
+	movl	0x20(%esp,1),%esi
+	movl	0x1c(%esp,1),%edi
+	movl	0x18(%esp,1),%edx
+	movl	0x14(%esp,1),%ecx
+	movl	0x10(%esp,1),%ebx
+	/* Load syscall number into %eax.  */
+	movl	$SYS_ify(pwrite), %eax
+	int	$0x80		/* Do the system call.  */
+	POPARGS_5		/* Restore register contents.  */
+	cmpl	$-4095, %eax	/* Check %eax for error.  */
+	jae	syscall_error	/* Jump to error handler if error.  */
+	ret			/* Return to caller.  */
+
+PSEUDO_END (__syscall_pwrite64)
diff --git a/sysdeps/unix/sysv/linux/i386/sigaction.c b/sysdeps/unix/sysv/linux/i386/sigaction.c
index 99ed694f49..90d61a08a1 100644
--- a/sysdeps/unix/sysv/linux/i386/sigaction.c
+++ b/sysdeps/unix/sysv/linux/i386/sigaction.c
@@ -28,8 +28,8 @@
 #include <kernel_sigaction.h>
 
 
-extern int __syscall_rt_signal (int, const struct sigaction *,
-				struct sigaction *, size_t);
+extern int __syscall_rt_sigaction (int, const struct sigaction *,
+				   struct sigaction *, size_t);
 
 /* The variable is shared between all wrappers around signal handling
    functions which have RT equivalents.  It is defined in sigsuspend.c.  */
diff --git a/sysdeps/unix/sysv/linux/rt_sigprocmask.c b/sysdeps/unix/sysv/linux/rt_sigprocmask.c
index 0ce2815780..c9adaf08c4 100644
--- a/sysdeps/unix/sysv/linux/rt_sigprocmask.c
+++ b/sysdeps/unix/sysv/linux/rt_sigprocmask.c
@@ -20,7 +20,7 @@
 #include <signal.h>
 
 int
-__syscall_rt_sigprocmask (int how, const sigset *set, sigset_t *oset,
+__syscall_rt_sigprocmask (int how, const sigset_t *set, sigset_t *oset,
 			  size_t setsize)
 {
   __set_errno (ENOSYS);
diff --git a/sysdeps/unix/sysv/linux/rt_sigqueueinfo.c b/sysdeps/unix/sysv/linux/rt_sigqueueinfo.c
index ff99e9e555..ec9f9803a7 100644
--- a/sysdeps/unix/sysv/linux/rt_sigqueueinfo.c
+++ b/sysdeps/unix/sysv/linux/rt_sigqueueinfo.c
@@ -18,6 +18,7 @@
 
 #include <errno.h>
 #include <signal.h>
+#include <sys/types.h>
 
 int
 __syscall_rt_sigqueueinfo (pid_t pid, int sig, siginfo_t *uinfo)
diff --git a/sysdeps/unix/sysv/linux/rt_sigsuspend.c b/sysdeps/unix/sysv/linux/rt_sigsuspend.c
index 59fb5c4bcd..dc32dcc067 100644
--- a/sysdeps/unix/sysv/linux/rt_sigsuspend.c
+++ b/sysdeps/unix/sysv/linux/rt_sigsuspend.c
@@ -20,7 +20,7 @@
 #include <signal.h>
 
 int
-__syscall_rt_sigsuspend (const sigset *set, size_t setsize)
+__syscall_rt_sigsuspend (const sigset_t *set, size_t setsize)
 {
   if (set == NULL)
     {
diff --git a/sysdeps/unix/sysv/linux/sigreturn.c b/sysdeps/unix/sysv/linux/sigreturn.c
index e57ac74212..ecef3d67ad 100644
--- a/sysdeps/unix/sysv/linux/sigreturn.c
+++ b/sysdeps/unix/sysv/linux/sigreturn.c
@@ -18,7 +18,6 @@
 
 #include <errno.h>
 #include <signal.h>
-#include <sigcontext.h>
 #include <unistd.h>
 
 extern int __syscall_sigreturn (struct sigcontext *);
diff --git a/sysdeps/unix/sysv/linux/sys/pci.h b/sysdeps/unix/sysv/linux/sys/pci.h
index 03d9b9a768..8c190d644f 100644
--- a/sysdeps/unix/sysv/linux/sys/pci.h
+++ b/sysdeps/unix/sysv/linux/sys/pci.h
@@ -20,6 +20,6 @@
 #define _SYS_PCI_H	1
 
 /* We use the constants from the kernel.  */
-#include <asm/pci.h>
+#include <linux/pci.h>
 
 #endif /* sys/pci.h */
diff --git a/sysdeps/wordsize-32/bits/environments.h b/sysdeps/wordsize-32/bits/environments.h
index 40a53ab236..8d1403fefe 100644
--- a/sysdeps/wordsize-32/bits/environments.h
+++ b/sysdeps/wordsize-32/bits/environments.h
@@ -16,8 +16,9 @@
    write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
    Boston, MA 02111-1307, USA.  */
 
-#ifndef _BITS_ENVIRONMENTS_H
-#define _BITS_ENVIRONMENTS_H	1
+#ifndef _UNISTD_H
+# error "Never include this file directly.  Use <unistd.h> instead"
+#endif
 
 /* By default we have 32-bit wide `int', `long int', pointers and `off_t'.  */
 #define _XBS5_ILP32_OFF32	1
@@ -28,5 +29,3 @@
 /* We can never provide environments with 64-bit wide pointers.  */
 #define _XBS5_LP64_OFF64	-1
 #define _XBS5_LPBIG_OFFBIG	-1
-
-#endif /* bits/environments.h */
diff --git a/sysdeps/wordsize-64/bits/environments.h b/sysdeps/wordsize-64/bits/environments.h
index af2d212618..f1d5bb8135 100644
--- a/sysdeps/wordsize-64/bits/environments.h
+++ b/sysdeps/wordsize-64/bits/environments.h
@@ -16,15 +16,14 @@
    write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
    Boston, MA 02111-1307, USA.  */
 
-#ifndef _BITS_ENVIRONMENTS_H
-#define _BITS_ENVIRONMENTS_H	1
+#ifndef _UNISTD_H
+# error "Never include this file directly.  Use <unistd.h> instead"
+#endif
 
-/* We can never provide environments with 64-bit wide pointers.  */
+/* We can never provide environments with 32-bit wide pointers.  */
 #define _XBS5_ILP32_OFF32	-1
 #define _XBS5_ILP32_OFFBIG	-1
 
-/* By default we have 64-bit wide `int', `long int', pointers and `off_t'.  */
+/* By default we have 64-bit wide `long int', pointers and `off_t'.  */
 #define _XBS5_LP64_OFF32	1
 #define _XBS5_LPBIG_OFFBIG	1
-
-#endif /* bits/environments.h */