Remove sys/segments.h dependency
[kopensolaris-gnu/glibc.git] / FAQ
diff --git a/FAQ b/FAQ
index c555488..77bd47e 100644 (file)
--- a/FAQ
+++ b/FAQ
-               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
+                                                 --drepper@redhat.com
 \f
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[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 assembler?
+1.5.   Which compiler should I use for powerpc?
+1.6.   Which tools should I use for ARM?
+1.7.   Do I need some more things to compile the GNU C Library?
+1.8.   What version of the Linux kernel headers should be used?
+1.9.   The compiler hangs while building iconvdata modules.  What's
+       wrong?
+1.10.  When I run `nm -u libc.so' on the produced library I still
+       find unresolved symbols.  Can this be ok?
+1.11.  What are these `add-ons'?
+1.12.  My XXX kernel emulates a floating-point coprocessor for me.
+       Should I enable --with-fp?
+1.13.  When compiling GNU libc I get lots of errors saying functions
+       in glibc are duplicated in libgcc.
+1.14.  Why do I get messages about missing thread functions when I use
+       librt?  I don't even use threads.
+1.15.  What's the problem with configure --enable-omitfp?
+1.16.  I get failures during `make check'.  What should I do?
+1.17.  What is symbol versioning good for?  Do I need it?
+1.18.  How can I compile on my fast ix86 machine a working libc for my slow
+       i386?  After installing libc, programs abort with "Illegal
+       Instruction".
+1.19.  `make' complains about a missing dlfcn/libdl.so when building
+       malloc/libmemprof.so.  How can I fix this?
+1.20.  Which tools should I use for MIPS?
+1.21.  Which compiler should I use for powerpc64?
+1.22.  `make' fails when running rpcgen the first time,
+       what is going on? How do I fix this?
+
+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.   When I run an executable on one system which I compiled on
+       another, I get dynamic linker errors.  Both systems have the same
+       version of glibc installed.  What's wrong?
+2.9.   How can I compile gcc 2.7.2.1 from the gcc source code using
+       glibc 2.x?
+2.10.  The `gencat' utility cannot process the catalog sources which
+       were used on my Linux libc5 based system.  Why?
+2.11.  Programs using libc have their messages translated, but other
+       behavior is not localized (e.g. collating order); why?
+2.12.  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.13.  I have killed ypbind to stop using NIS, but glibc
+       continues using NIS.
+2.14.  Under Linux/Alpha, I always get "do_ypcall: clnt_call:
+       RPC: Unable to receive; errno = Connection refused" when using NIS.
+2.15.  After installing glibc name resolving doesn't work properly.
+2.16.  How do I create the databases for NSS?
+2.17.  I have /usr/include/net and /usr/include/scsi as symlinks
+       into my Linux source tree.  Is that wrong?
+2.18.  Programs like `logname', `top', `uptime' `users', `w' and
+       `who', show incorrect information about the (number of)
+       users on my system.  Why?
+2.19.  After upgrading to glibc 2.1 with symbol versioning I get
+       errors about undefined symbols.  What went wrong?
+2.20.  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?
+2.21.  What do I need for C++ development?
+2.22.  Even statically linked programs need some shared libraries
+       which is not acceptable for me.  What can I do?
+2.23.  I just upgraded my Linux system to glibc and now I get
+       errors whenever I try to link any program.
+2.24.  When I use nscd the machine freezes.
+2.25.  I need lots of open files.  What do I have to do?
+2.26.  How do I get the same behavior on parsing /etc/passwd and
+       /etc/group as I have with libc5 ?
+2.27.  What needs to be recompiled when upgrading from glibc 2.0 to glibc
+       2.1?
+2.28.  Why is extracting files via tar so slow?
+2.29.  Compiling programs I get parse errors in libio.h (e.g. "parse error
+       before `_IO_seekoff'").  How should I fix this?
+2.30.  After upgrading to glibc 2.1, libraries that were compiled against
+       glibc 2.0.x don't work anymore.
+2.31.  What happened to the Berkeley DB libraries?  Can I still use db
+       in /etc/nsswitch.conf?
+2.32.  What has do be done when upgrading to glibc 2.2?
+2.33.  The makefiles want to do a CVS commit.
+2.34.  When compiling C++ programs, I get a compilation error in streambuf.h.
+2.35.  When recompiling GCC, I get compilation errors in libio.
+2.36.  Why shall glibc never get installed on GNU/Linux systems in
+/usr/local?
+2.37.  When recompiling GCC, I get compilation errors in libstdc++.
+
+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?
+3.9.   I get compiler messages "Initializer element not constant" with
+       stdin/stdout/stderr. Why?
+3.10.  I can't compile with gcc -traditional (or
+       -traditional-cpp). Why?
+3.11.  I get some errors with `gcc -ansi'. Isn't glibc ANSI compatible?
+3.12.  I can't access some functions anymore.  nm shows that they do
+       exist but linking fails nevertheless.
+3.13.  When using the db-2 library which comes with glibc is used in
+       the Perl db modules the testsuite is not passed.  This did not
+       happen with db-1, gdbm, or ndbm.
+3.14.  The pow() inline function I get when including <math.h> is broken.
+       I get segmentation faults when I run the program.
+3.15.  The sys/sem.h file lacks the definition of `union semun'.
+3.16.  Why has <netinet/ip_fw.h> disappeared?
+3.17.  I get floods of warnings when I use -Wconversion and include
+       <string.h> or <math.h>.
+3.18.  After upgrading to glibc 2.1, I receive errors about
+       unresolved symbols, like `_dl_initial_searchlist' and can not
+       execute any binaries.  What went wrong?
+3.19.  bonnie reports that char i/o with glibc 2 is much slower than with
+       libc5.  What can be done?
+3.20.  Programs compiled with glibc 2.1 can't read db files made with glibc
+       2.0.  What has changed that programs like rpm break?
+3.21.  Autoconf's AC_CHECK_FUNC macro reports that a function exists, but
+       when I try to use it, it always returns -1 and sets errno to ENOSYS.
+3.22.  My program segfaults when I call fclose() on the FILE* returned
+       from setmntent().  Is this a glibc bug?
+3.23.  I get "undefined reference to `atexit'"
+
+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.
+4.3.   When I set the timezone by setting the TZ environment variable
+       to EST5EDT things go wrong since glibc computes the wrong time
+       from this information.
+4.4.   What other sources of documentation about glibc are available?
+4.5.   The timezone string for Sydney/Australia is wrong since even when
+       daylight saving time is in effect the timezone string is EST.
+4.6.   I've build make 3.77 against glibc 2.1 and now make gets
+       segmentation faults.
+4.7.   Why do so many programs using math functions fail on my AlphaStation?
+4.8.   The conversion table for character set XX does not match with
+what I expect.
+4.9.   How can I find out which version of glibc I am using in the moment?
+4.10.  Context switching with setcontext() does not work from within
+       signal handlers.
 
-[Q2]   ``What compiler do I need to build GNU libc?''
+\f
+~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 
 
-[Q3]   ``When starting make I get only error messages.
-         What's wrong?''
+1. Compiling glibc
 
-[Q4]   ``After I changed configure.in I get `Autoconf version X.Y.
-         or higher is required for this script'.  What can I do?''
+1.1.   What systems does the GNU C Library run on?
 
-[Q5]   ``Do I need a special linker or archiver?''
+{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.
 
-[Q6]   ``Do I need some more things to compile GNU C Library?''
+The systems glibc is known to work on as of this release, and most probably
+in the future, are:
 
-[Q7]   ``When I run `nm -u libc.so' on the produced library I still
-         find unresolved symbols?  Can this be ok?''
+       *-*-gnu                 GNU Hurd
+       i[3456]86-*-linux-gnu   Linux-2.x on Intel
+       m68k-*-linux-gnu        Linux-2.x on Motorola 680x0
+       alpha*-*-linux-gnu      Linux-2.x on DEC Alpha
+       powerpc-*-linux-gnu     Linux and MkLinux on PowerPC systems
+       powerpc64-*-linux-gnu   Linux-2.4+ on 64-bit PowerPC systems
+       sparc-*-linux-gnu       Linux-2.x on SPARC
+       sparc64-*-linux-gnu     Linux-2.x on UltraSPARC
+       arm-*-none              ARM standalone systems
+       arm-*-linux             Linux-2.x on ARM
+       arm-*-linuxaout         Linux-2.x on ARM using a.out binaries
+       mips*-*-linux-gnu       Linux-2.x on MIPS
+       ia64-*-linux-gnu        Linux-2.x on ia64
+       s390-*-linux-gnu        Linux-2.x on IBM S/390
+       s390x-*-linux-gnu       Linux-2.x on IBM S/390 64-bit
+       cris-*-linux-gnu        Linux-2.4+ on CRIS
 
-[Q8]   ``Can I replace the libc on my Linux system with GNU libc?''
+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.
 
-[Q9]   ``I expect GNU libc to be 100% source code compatible with
-         the old Linux based GNU libc.  Why isn't it like this?''
+If you have a system not listed above (or in the `README' file) and you are
+really interested in porting it, see the GNU C Library web pages to learn
+how to start contributing:
 
-[Q10]  ``Why does getlogin() always return NULL on my Linux box?''
+       http://www.gnu.org/software/libc/resources.html
 
-[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?''
+1.2.   What compiler do I need to build GNU libc?
 
-[Q13]  ``How do I configure GNU libc so that the essential libraries
-         like libc.so go into /lib and the other into /usr/lib?''
+{UD} You must use GNU CC to compile GNU libc.  A lot of extensions of GNU CC
+are used to increase portability and speed.
 
-[Q14]  ``When linking with the new libc I get unresolved symbols
-         `crypt' and `setkey'.  Why aren't these functions in the
-         libc anymore?''
+GNU CC is found, like all other GNU packages, on
 
-[Q15]  ``What are these `add-ons'?''
+       ftp://ftp.gnu.org/pub/gnu
 
-[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.''
+and the many mirror sites.  ftp.gnu.org is always overloaded, so try to find
+a local mirror first.
 
-[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?''
+You should always try to use the latest official release.  Older versions
+may not have all the features GNU libc requires.  The current releases of
+gcc (3.2 or newer) should work with the GNU C library (for MIPS see question 1.20).
 
-[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?''
+Please note that gcc 2.95 and 2.95.x cannot compile glibc on Alpha due to
+problems in the complex float support.
 
-[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?
+1.3.   When I try to compile glibc I get only error messages.
+       What's wrong?
 
-[Q21]    ``On Linux I've got problems with the declarations in Linux
-           kernel headers.''
+{UD} You definitely need GNU make to build GNU libc.  No other make
+program has the needed functionality.
 
-[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.''
+We recommend version GNU make version 3.79 or newer.  Older versions have
+bugs and/or are missing features.
 
-[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.''
+1.4.   Do I need a special linker or assembler?
 
-[Q25]  ``After installing glibc name resolving doesn't work properly.''
+{ZW} If you want a shared library, you need a linker and assembler that
+understand all the features of ELF, including weak and versioned symbols.
+The static library can be compiled with less featureful tools, but lacks key
+features such as NSS.
 
+For Linux or Hurd, you want binutils 2.13 or higher.  These are the only
+versions we've tested and found reliable.  Other versions may work but we
+don't recommend them, especially not when C++ is involved.
 
-[Q26]  ``I have /usr/include/net and /usr/include/scsi as symlinks
-         into my Linux source tree.  Is that wrong?''
+Other operating systems may come with system tools that have all the
+necessary features, but this is moot because glibc hasn't been ported to
+them.
 
-[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?''
+1.5.   Which compiler should I use for powerpc?
 
-[Q29]  ``I don't include any kernel header myself but still the
-         compiler complains about type redeclarations of types in the
-         kernel headers.''
+{} Removed.  Does not apply anymore.
 
-[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?''
+1.6.   Which tools should I use for ARM?
 
-[Q32]  ``Why don't signals interrupt system calls anymore?''
+{} Removed.  Does not apply anymore.
 
-[Q33]  ``I've got errors compiling code that uses certain string
-         functions.  Why?''
-\f
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q1]   ``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.
+1.7.   Do I need some more things to compile the GNU C Library?
 
-The systems glibc is known to work on in the moment and most probably
-in the future are:
+{UD} Yes, there are some more :-).
 
-       *-*-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
+* GNU gettext.  This package contains the tools needed to construct
+  `message catalog' files containing translated versions of system
+  messages. See ftp://ftp.gnu.org/pub/gnu or better any mirror
+  site.  (We distribute compiled message catalogs, but they may not be
+  updated in patches.)
 
-Other Linux platforms are also on the way to be supported but I need
-some success reports first.
+* Some files are built with special tools.  E.g., files ending in .gperf
+  need a `gperf' program.  The GNU version (now available in a separate
+  package, formerly only as part of libg++) is known to work while some
+  vendor versions do not.
 
-If you have a system not listed above (or in the `README' file) and
-you are really interested in porting it, contact
+  You should not need these tools unless you change the source files.
 
-       <bug-glibc@prep.ai.mit.edu>
+* Perl 5 is needed if you wish to test an installation of GNU libc
+  as the primary C library.
 
+* When compiling for Linux, the header files of the Linux kernel must
+  be available to the compiler as <linux/*.h> and <asm/*.h>.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q2]   ``What compiler do I need to build GNU libc?''
+* lots of disk space (~400MB for i?86-linux; more for RISC platforms).
 
-[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.
+* plenty of time.  Compiling just the shared and static libraries for
+  35mins on a 2xPIII@550Mhz w/ 512MB RAM.  On a 2xUltraSPARC-II@360Mhz
+  w/ 1GB RAM it takes about 14 minutes.  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.
 
-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.
+  You should avoid compiling in a NFS mounted filesystem.  This is
+  very slow.
 
-The 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.
+  James Troup <J.J.Troup@comp.brad.ac.uk> reports a compile time for
+  an earlier (and smaller!) version of glibc of 45h34m for a full build
+  (shared, static, and profiled) on Atari Falcon (Motorola 68030 @ 16 Mhz,
+  14 Mb memory) and Jan Barte <yann@plato.uni-paderborn.de> reports
+  22h48m on Atari TT030 (Motorola 68030 @ 32 Mhz, 34 Mb memory)
 
-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.
+  A full build of the PowerPC library took 1h on a PowerPC 750@400Mhz w/
+  64MB of RAM, and about 9h on a 601@60Mhz w/ 72Mb.
 
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q3]   ``When starting `make' I get only errors messages.
-         What's wrong?''
+1.8.   What version of the Linux kernel headers should be used?
 
-[A3] {UD} You definitely need GNU make to translate GNU libc.  No
-other make program has the needed functionality.
+{AJ,UD} The headers from the most recent Linux kernel should be used.  The
+headers used while compiling the GNU C library and the kernel binary used
+when using the library do not need to match.  The GNU C library runs without
+problems on kernels that are older than the kernel headers used.  The other
+way round (compiling the GNU C library with old kernel headers and running
+on a recent kernel) does not necessarily work.  For example you can't use
+new kernel features if you used old kernel headers to compile the GNU C
+library.
 
-Versions before 3.74 have bugs which prevent correct execution so you
-should upgrade to the latest version before starting the compilation.
+{ZW} Even if you are using a 2.0 kernel on your machine, we recommend you
+compile GNU libc with 2.2 kernel headers.  That way you won't have to
+recompile libc if you ever upgrade to kernel 2.2.  To tell libc which
+headers to use, give configure the --with-headers switch
+(e.g. --with-headers=/usr/src/linux-2.2.0/include).
 
+Note that you must configure the 2.2 kernel if you do this, otherwise libc
+will be unable to find <linux/version.h>.  Just change the current directory
+to the root of the 2.2 tree and do `make include/linux/version.h'.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q4]   ``After I changed configure.in I get `Autoconf version X.Y.
-         or higher is required for this script'.  What can I do?''
 
-[A4] {UD} You have to get the specified autoconf version (or a later)
-from your favourite mirror of prep.ai.mit.edu.
+1.9.   The compiler hangs while building iconvdata modules.  What's
+       wrong?
 
+{} Removed.  Does not apply anymore.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[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.
+1.10.  When I run `nm -u libc.so' on the produced library I still
+       find unresolved symbols.  Can this be ok?
 
-On systems where the native linker does not support weak symbols you
-will not get a really 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.
+{UD} Yes, this is ok.  There can be several kinds of unresolved symbols:
 
-Always get the newest release of GNU binutils available.
-Older releases are known to have bugs that affect building the GNU C
-Library.
+* magic symbols automatically generated by the linker.  These have names
+  like __start_* and __stop_*
 
+* symbols starting with _dl_* come from the dynamic linker
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q6]   ``Do I need some more things to compile GNU C Library?''
+* weak symbols, which need not be resolved at all (fabs for example)
 
-[A6] {UD} Yes, there are some more :-).
+Generally, you should make sure you find a real program which produces
+errors while linking before deciding there is a problem.
 
-* 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.
 
-* lots of diskspace (for i?86-linux this means, e.g., ~170MB; for ppc-linux
-  even ~200MB).
+1.11.  What are these `add-ons'?
 
-  You should avoid compiling on a NFS mounted device.  This is very
-  slow.
+{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
+linuxthreads package.
 
-* 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.
+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:
 
-  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.
+       configure --enable-add-ons=linuxthreads
 
-  For Atari TT030 (Motorola 68030 @ 32 Mhz, 34 Mb memory) (full build)
-  a compile time of 22h48m.
+for example.
 
-  If you have some more measurements let me know.
+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.
 
-* When compiling for Linux:
+Most add-ons are tightly coupled to a specific GNU libc version.  Please
+check that the add-ons work with the GNU libc.  For example the linuxthreads
+add-on has the same numbering scheme as the libc and will in general only
+work with the corresponding libc.
 
-  + the header files of the Linux kernel must be available in the
-    search path of the CPP as <linux/*.h> and <asm/*.h>.
+{AJ} With glibc 2.2 the crypt add-on and with glibc 2.1 the localedata
+add-on have been integrated into the normal glibc distribution, crypt and
+localedata are therefore not anymore add-ons.
 
-* 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.
+1.12.  My XXX kernel emulates a floating-point coprocessor for me.
+       Should I enable --with-fp?
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q7]   ``When I run `nm -u libc.so' on the produced library I still
-         find unresolved symbols?  Can this be ok?''
+{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.
 
-[A7] {UD} Yes, this is ok.  There can be several kinds of unresolved
-symbols:
+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.
 
-* magic symbols automatically generated by the linker.  Names are
-  often like __start_* and __stop_*
 
-* symbols starting with _dl_* come from the dynamic linker
+1.13.  When compiling GNU libc I get lots of errors saying functions
+       in glibc are duplicated in libgcc.
 
-* symbols resolved by using libgcc.a
-  (__udivdi3, __umoddi3, or similar)
+{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.
 
-* weak symbols, which need not be resolved at all
-  (currently fabs among others; this gets resolved if the program
-   is linked against libm, too.)
+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.
 
-Generally, you should make sure you find a real program which produces
-errors while linking before deciding there is a problem.
+{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.
 
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q8]   ``Can I replace the libc on my Linux system with GNU libc?''
+1.14.  Why do I get messages about missing thread functions when I use
+       librt?  I don't even use threads.
 
-[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.
+{UD} In this case you probably mixed up your installation.  librt uses
+threads internally and has implicit references to the thread library.
+Normally these references are satisfied automatically but if the thread
+library is not in the expected place you must tell the linker where it is.
+When using GNU ld it works like this:
 
-For Linux there are today two libc versions:
-       libc-4          old a.out libc
-       libc-5          current ELF libc
+       gcc -o foo foo.c -Wl,-rpath-link=/some/other/dir -lrt
 
-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.
+The `/some/other/dir' should contain the thread library.  `ld' will use the
+given path to find the implicitly referenced library while not disturbing
+any other link path.
 
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q9]   ``I expect GNU libc to be 100% source code compatible with
-         the old Linux based GNU libc.  Why isn't it like this?''
+1.15.  What's the problem with configure --enable-omitfp?
 
-[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:
+{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.
 
-* _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.
+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.
 
-  For more information consult the file `NOTES' part of the GNU C
-  library sources.
+Since a library built with --enable-omitfp is undebuggable on most systems,
+debuggable libraries are also built - you can use them by appending "_g" to
+the library names.
 
-* 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".
+The compilation of these extra libraries and the compiler optimizations slow
+down the build process and need more disk space.
 
-* 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.
 
-       syscall name:   wrapper name:   declaring header file:
-       -------------   -------------   ----------------------
-       bdflush         bdflush         <sys/kdaemon.h>
-       create_module   create_module   <sys/module.h>
-       delete_module   delete_module   <sys/module.h>
-       get_kernel_syms get_kernel_syms <sys/module.h>
-       init_module     init_module     <sys/module.h>
-       syslog          ksyslog_ctl     <sys/klog.h>
+1.16.  I get failures during `make check'.  What should I do?
 
-* 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).
+{AJ} The testsuite should compile and run cleanly on your system; every
+failure should be looked into.  Depending on the failures, you probably
+should not install the library at all.
 
-* 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.
+You should consider using the `glibcbug' script to report the failure,
+providing as much detail as possible.  If you run a test directly, please
+remember to set up the environment correctly.  You want to test the compiled
+library - and not your installed one.  The best way is to copy the exact
+command line which failed and run the test from the subdirectory for this
+test in the sources.
 
-* 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.
+There are some failures which are not directly related to the GNU libc:
+- Some compilers produce buggy code.  No compiler gets single precision
+  complex numbers correct on Alpha.  Otherwise, gcc-3.2 should be ok.
+- The kernel might have bugs.  For example on Linux/Alpha 2.0.34 the
+  floating point handling has quite a number of bugs and therefore most of
+  the test cases in the math subdirectory will fail.  Linux 2.2 has
+  fixes for the floating point support on Alpha.  The Linux/SPARC kernel has
+  also some bugs in the FPU emulation code (as of Linux 2.2.0).
+- Other tools might have problems.  For example bash 2.03 gives a
+  segmentation fault running the tst-rpmatch.sh test script.
 
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q10]  ``Why does getlogin() always return NULL on my Linux box?''
+1.17.  What is symbol versioning good for?  Do I need it?
 
-[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.
+{AJ} Symbol versioning solves problems that are related to interface
+changes.  One version of an interface might have been introduced in a
+previous version of the GNU C library but the interface or the semantics of
+the function has been changed in the meantime.  For binary compatibility
+with the old library, a newer library needs to still have the old interface
+for old programs.  On the other hand, new programs should use the new
+interface.  Symbol versioning is the solution for this problem.  The GNU
+libc version 2.1 uses symbol versioning by default if the installed binutils
+supports it.
 
-{MK} There is however a (partial) solution for this problem.  Please
-take a look at the file `README.utmpd'.
+We don't advise building without symbol versioning, since you lose binary
+compatibility - forever!  The binary compatibility you lose is not only
+against the previous version of the GNU libc (version 2.0) but also against
+all future versions.
 
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q11]  ``Where are the DST_* constants found in <sys/time.h> on many
-         systems?''
+1.18.  How can I compile on my fast ix86 machine a working libc for my slow
+       i386?  After installing libc, programs abort with "Illegal
+       Instruction".
 
-[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).
+{AJ} glibc and gcc might generate some instructions on your machine that
+aren't available on i386.  You've got to tell glibc that you're configuring
+for i386 with adding i386 as your machine, for example:
 
-Instead GNU libc contains the zone database handling and compatibility
-code for POSIX TZ environment variable handling.
+       ../configure --prefix=/usr i386-pc-linux-gnu
 
+And you need to tell gcc to only generate i386 code, just add `-mcpu=i386'
+(just -m386 doesn't work) to your CFLAGS.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q12]  ``The `gencat' utility cannot process the input which are
-         successfully used on my Linux libc based system.  Why?''
+{UD} This applies not only to the i386.  Compiling on a i686 for any older
+model will also fail if the above  methods are not used.
 
-[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.
 
-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.
+1.19.  `make' complains about a missing dlfcn/libdl.so when building
+       malloc/libmemprof.so.  How can I fix this?
 
-Here is a simple SED script to convert at least some Linux specific
-catalog files to the XPG4 form:
+{AJ} Older make version (<= 3.78.90) have a bug which was hidden by a bug in
+glibc (<= 2.1.2).  You need to upgrade make to a newer or fixed version.
 
------------------------------------------------------------------------
-# Change catalog source in Linux specific format to standard XPG format.
-# Ulrich Drepper <drepper@cygnus.com>, 1996.
-#
-/^\$ #/ {
-  h
-  s/\$ #\([^ ]*\).*/\1/
-  x
-  s/\$ #[^ ]* *\(.*\)/\$ \1/
-}
+After upgrading make, you should remove the file sysd-sorted in your build
+directory.  The problem is that the broken make creates a wrong order for
+one list in that file.  The list has to be recreated with the new make -
+which happens if you remove the file.
 
-/^# / {
-  s/^# \(.*\)/\1/
-  G
-  s/\(.*\)\n\(.*\)/\2 \1/
-}
------------------------------------------------------------------------
+You might encounter this bug also in other situations where make scans
+directories.  I strongly advise to upgrade your make version to 3.79 or
+newer.
+
+
+1.20.  Which tools should I use for MIPS?
+
+{AJ} You should use the current development version of gcc 3.2 or newer from
+CVS.
+
+You need also recent binutils, anything before and including 2.11 will not
+work correctly.  Either try the Linux binutils 2.11.90.0.5 from HJ Lu or the
+current development version of binutils from CVS.
+
+Please note that `make check' might fail for a number of the math tests
+because of problems of the FPU emulation in the Linux kernel (the MIPS FPU
+doesn't handle all cases and needs help from the kernel).
+
+For details check also my page <http://www.suse.de/~aj/glibc-mips.html>.
+
+
+1.21.  Which compiler should I use for powerpc64?
+
+{SM} You want to use at least gcc 3.2 (together with the right versions
+of all the other tools, of course).
+
+
+1.22.  `make' fails when running rpcgen the first time,
+       what is going on? How do I fix this?
+
+{CO} The first invocation of rpcgen is also the first use of the recently
+compiled dynamic loader.  If there is any problem with the dynamic loader
+it will more than likely fail to run rpcgen properly. This could be due to
+any number of problems.
+
+The only real solution is to debug the loader and determine the problem
+yourself. Please remember that for each architecture there may be various
+patches required to get glibc HEAD into a runnable state. The best course
+of action is to determine if you have all the required patches.
+
+\f
+. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
 
+2. Installation and configuration issues
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[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.1.   Can I replace the libc on my Linux system with GNU libc?
 
-[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} 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.
 
-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.
+For Linux there are three major libc versions:
+       libc-4          a.out libc
+       libc-5          original ELF libc
+       libc-6          GNU libc
 
-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:
+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.
+
+
+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?
+
+{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. 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 file which are by tradition placed
-in a directory named /etc.
+The first line specifies the directory for the essential libraries, 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?
 
+{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.)
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q14]  ``When linking with the new libc I get unresolved symbols
-         `crypt' and `setkey'.  Why aren't these functions in the
-         libc anymore?''
+The dangers when installing glibc in /usr are twofold:
 
-[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.
+* 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 before running `make install'.  (Do not throw
+  it away; you will then lose the ability to compile programs against your
+  old libc.)
 
-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.
+* 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.
 
-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.
+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'?''
+2.4.   Do I need to use GNU CC to compile programs that will use the
+       GNU C Library?
 
-[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).
+{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.
 
-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
+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.
 
-       configure --enable-add-ons=crypt,XXX ...
+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.
 
-where XXX are possible other add-ons and ... means the rest of the
-normal option list.
 
-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.
+2.5.   When linking with the new libc I get unresolved symbols
+       `crypt' and `setkey'.  Why aren't these functions in the
+       libc anymore?
 
-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.
+{} Removed.  Does not apply anymore.
 
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[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.''
+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.
 
-[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.
+{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.
 
-Normally this is done by the compiler.  The gcc will use
+For casual use of GNU libc you can just specify to the linker
+    --dynamic-linker=/lib/ld-linux.so.2
 
-       -dynamic-linker /lib/ld-linux.so.1
+which is the glibc dynamic linker, on Linux systems.  On other systems the
+name is /lib/ld.so.1.  When linking via gcc, you've got to add
+    -Wl,--dynamic-linker=/lib/ld-linux.so.2
 
-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.
+to the gcc command line.
 
-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
+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.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 +753,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,247 +772,683 @@ 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)
-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:
+{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 )
+GROUP ( libc.so.6 libc_nonshared.a )
 
-or in ix86/Linux and alpha/Linux:
 
-GROUP ( libc.so.6 ld-linux.so.2 libc.a )
+2.8.   When I run an executable on one system which I compiled on
+       another, I get dynamic linker errors.  Both systems have the same
+       version of glibc installed.  What's wrong?
 
+{ZW} Glibc on one of these systems was compiled with gcc 2.7 or 2.8, the
+other with egcs (any version).  Egcs has functions in its internal
+`libgcc.a' to support exception handling with C++.  They are linked into
+any program or dynamic library compiled with egcs, whether it needs them or
+not.  Dynamic libraries then turn around and export those functions again
+unless special steps are taken to prevent them.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[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?''
+When you link your program, it resolves its references to the exception
+functions to the ones exported accidentally by libc.so.  That works fine as
+long as libc has those functions.  On the other system, libc doesn't have
+those functions because it was compiled by gcc 2.8, and you get undefined
+symbol errors.  The symbols in question are named things like
+`__register_frame_info'.
 
-[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.
+For glibc 2.0, the workaround is to not compile libc with egcs.  We've also
+incorporated a patch which should prevent the EH functions sneaking into
+libc.  It doesn't matter what compiler you use to compile your program.
 
+For glibc 2.1, we've chosen to do it the other way around: libc.so
+explicitly provides the EH functions.  This is to prevent other shared
+libraries from doing it.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q19]  ``My XXX kernel emulates a floating-point coprocessor for me.
-         Should I enable --with-fp?''
+{UD} Starting with glibc 2.1.1 you can compile glibc with gcc 2.8.1 or
+newer since we have explicitly add references to the functions causing the
+problem.  But you nevertheless should use EGCS for other reasons
+(see question 1.2).
 
-[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.
+{GK} On some Linux distributions for PowerPC, you can see this when you have
+built gcc or egcs from the Web sources (gcc versions 2.95 or earlier), then
+re-built glibc.  This happens because in these versions of gcc, exception
+handling is implemented using an older method; the people making the
+distributions are a little ahead of their time.
 
+A quick solution to this is to find the libgcc.a file that came with the
+distribution (it would have been installed under /usr/lib/gcc-lib), do
+`ar x libgcc.a frame.o' to get the frame.o file out, and add a line saying
+`LDLIBS-c.so += frame.o' to the file `configparms' in the directory you're
+building in.  You can check you've got the right `frame.o' file by running
+`nm frame.o' and checking that it has the symbols defined that you're
+missing.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q20]  ``How can I compile gcc 2.7.2.1 from the gcc source code using
-         glibc 2.x?
+This will let you build glibc with the C compiler.  The C++ compiler
+will still be binary incompatible with any C++ shared libraries that
+you got with your distribution.
 
-[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.
 
+2.9.   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.''
+{AJ} There's only correct support for glibc 2.0.x in gcc 2.7.2.3 or later.
+But you should get at least gcc 2.95.3 (or later versions) anyway
 
-[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.
 
-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.
+2.10.  The `gencat' utility cannot process the catalog sources which
+       were used on my Linux libc5 based system.  Why?
 
-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.
+{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.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[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.''
+Here is a simple SED script to convert at least some Linux specific catalog
+files to the XPG4 form:
 
-[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.
+-----------------------------------------------------------------------
+# Change catalog source in Linux specific format to standard XPG format.
+# Ulrich Drepper <drepper@redhat.com>, 1996.
+#
+/^\$ #/ {
+  h
+  s/\$ #\([^ ]*\).*/\1/
+  x
+  s/\$ #[^ ]* *\(.*\)/\$ \1/
+}
 
-Currently (as of 970401) according to Philip Blundell <philb@gnu.ai.mit.edu>
-the required kernel version is 2.1.30.
+/^# / {
+  s/^# \(.*\)/\1/
+  G
+  s/\(.*\)\n\(.*\)/\2 \1/
+}
+-----------------------------------------------------------------------
 
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q23]  ``When compiling GNU libc I get lots of errors saying functions
-         in glibc are duplicated in libgcc.''
+2.11.  Programs using libc have their messages translated, but other
+       behavior is not localized (e.g. collating order); why?
 
-[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.
+{ZW} Translated messages are automatically installed, but the locale
+database that controls other behaviors is not.  You need to run localedef to
+install this database, after you have run `make install'.  For example, to
+set up the French Canadian locale, simply issue the command
 
-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.
+    localedef -i fr_CA -f ISO-8859-1 fr_CA
 
-{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.
+Please see localedata/README in the source tree for further details.
 
 
+2.12.  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.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[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.''
+{TK} 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
 
-[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).
+    http://www.suse.de/~kukuk/linux/nisplus.html
 
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q25]  ``After installing glibc name resolving doesn't work properly.''
+2.13.  I have killed ypbind to stop using NIS, but glibc
+       continues using NIS.
 
-[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.
+{TK} For faster NIS lookups, glibc uses the /var/yp/binding/ files from
+ypbind.  ypbind 3.3 and older versions don't always remove these files, so
+glibc will continue to use them.  Other BSD versions seem to work correctly.
+Until ypbind 3.4 is released, you can find a patch at
 
+    <ftp://ftp.kernel.org/pub/linux/utils/net/NIS/ypbind-3.3-glibc4.diff.gz>
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[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.
+2.14.  Under Linux/Alpha, I always get "do_ypcall: clnt_call:
+       RPC: Unable to receive; errno = Connection refused" when using NIS.
 
+{TK} You need a ypbind version which is 64bit clean.  Some versions are not
+64bit clean.  A 64bit clean implementation is ypbind-mt.  For ypbind 3.3,
+you need the patch from ftp.kernel.org (See the previous question).  I don't
+know about other versions.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q27]  ``Programs like `logname', `top', `uptime' `users', `w' and
-         `who', show incorrect information about the (number of)
-         users on my system.  Why?''
 
-[A27] {MK} See Q10.
+2.15.  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.
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q28]  ``After upgrading to a glibc 2.1 with symbol versioning I get
-         errors about undefined symbols.  What went wrong?''
 
-[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:
+2.16.  How do I create the databases for NSS?
 
-"msgfmt: error in loading shared libraries: : undefined symbol: _nl_domain_bindings"
+{AJ} If you have an entry "db" in /etc/nsswitch.conf you should also create
+the database files.  The glibc sources contain a Makefile which does the
+necessary conversion and calls to create those files.  The file is
+`db-Makefile' in the subdirectory `nss' and you can call it with `make -f
+db-Makefile'.  Please note that not all services are capable of using a
+database.  Currently passwd, group, ethers, protocol, rpc, services shadow
+and netgroup are implemented.  See also question 2.31.
 
-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.
 
+2.17.  I have /usr/include/net and /usr/include/scsi as symlinks
+       into my Linux source tree.  Is that wrong?
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q29]  ``I don't include any kernel header myself but still the
-         compiler complains about type redeclarations of types in the
-         kernel headers.''
+{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.
 
-[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.
+2.18.  Programs like `logname', `top', `uptime' `users', `w' and
+       `who', show incorrect information about the (number of)
+       users on my system.  Why?
+
+{MK} See question 3.2.
+
+
+2.19.  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.
 
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[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?''
+2.20.  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?
 
-[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.
+{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.
 
-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.
+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 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.
+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.
+
+
+2.21.  What do I need for C++ development?
+
+{HJ,AJ} You need either egcs 1.1 which comes directly with libstdc++ or
+gcc-2.8.1 together with libstdc++ 2.8.1.1.  egcs 1.1 has the better C++
+support and works directly with glibc 2.1.  If you use gcc-2.8.1 with
+libstdc++ 2.8.1.1, you need to modify libstdc++ a bit.  A patch is available
+as:
+       <ftp://alpha.gnu.org/gnu/libstdc++-2.8.1.1-glibc2.1-diff.gz>
+
+Please note that libg++ 2.7.2 (and the Linux Versions 2.7.2.x) doesn't work
+very well with the GNU C library due to vtable thunks.  If you're upgrading
+from glibc 2.0.x to 2.1 you have to recompile libstdc++ since the library
+compiled for 2.0 is not compatible due to the new Large File Support (LFS)
+in version 2.1.
+
+{UD} But since in the case of a shared libstdc++ the version numbers should
+be different existing programs will continue to work.
+
+
+2.22.  Even statically linked programs need some shared libraries
+       which is not acceptable for me.  What can I do?
+
+{AJ} NSS (for details just type `info libc "Name Service Switch"') won't
+work properly without shared libraries.  NSS allows using different services
+(e.g. NIS, files, db, hesiod) by just changing one configuration file
+(/etc/nsswitch.conf) without relinking any programs.  The only disadvantage
+is that now static libraries need to access shared libraries.  This is
+handled transparently by the GNU C library.
+
+A solution is to configure glibc with --enable-static-nss.  In this case you
+can create a static binary that will use only the services dns and files
+(change /etc/nsswitch.conf for this).  You need to link explicitly against
+all these services. For example:
+
+  gcc -static test-netdb.c -o test-netdb \
+    -Wl,--start-group -lc -lnss_files -lnss_dns -lresolv -Wl,--end-group
+
+The problem with this approach is that you've got to link every static
+program that uses NSS routines with all those libraries.
+
+{UD} In fact, one cannot say anymore that a libc compiled with this
+option is using NSS.  There is no switch anymore.  Therefore it is
+*highly* recommended *not* to use --enable-static-nss since this makes
+the behaviour of the programs on the system inconsistent.
+
+
+2.23.  I just upgraded my Linux system to glibc and now I get
+       errors whenever I try to link any program.
+
+{ZW} This happens when you have installed glibc as the primary C library but
+have stray symbolic links pointing at your old C library.  If the first
+`libc.so' the linker finds is libc 5, it will use that.  Your program
+expects to be linked with glibc, so the link fails.
+
+The most common case is that glibc put its `libc.so' in /usr/lib, but there
+was a `libc.so' from libc 5 in /lib, which gets searched first.  To fix the
+problem, just delete /lib/libc.so.  You may also need to delete other
+symbolic links in /lib, such as /lib/libm.so if it points to libm.so.5.
+
+{AJ} The perl script test-installation.pl which is run as last step during
+an installation of glibc that is configured with --prefix=/usr should help
+detect these situations.  If the script reports problems, something is
+really screwed up.
+
+
+2.24.  When I use nscd the machine freezes.
+
+{UD} You cannot use nscd with Linux 2.0.*.  There is functionality missing
+in the kernel and work-arounds are not suitable.  Besides, some parts of the
+kernel are too buggy when it comes to using threads.
+
+If you need nscd, you have to use at least a 2.1 kernel.
+
+Note that I have at this point no information about any other platform.
+
+
+2.25.  I need lots of open files.  What do I have to do?
+
+{AJ} This is at first a kernel issue.  The kernel defines limits with
+OPEN_MAX the number of simultaneous open files and with FD_SETSIZE the
+number of used file descriptors.  You need to change these values in your
+kernel and recompile the kernel so that the kernel allows more open
+files.  You don't necessarily need to recompile the GNU C library since the
+only place where OPEN_MAX and FD_SETSIZE is really needed in the library
+itself is the size of fd_set which is used by select.
+
+The GNU C library is now select free.  This means it internally has no
+limits imposed by the `fd_set' type.  Instead all places where the
+functionality is needed the `poll' function is used.
+
+If you increase the number of file descriptors in the kernel you don't need
+to recompile the C library.
+
+{UD} You can always get the maximum number of file descriptors a process is
+allowed to have open at any time using
+
+       number = sysconf (_SC_OPEN_MAX);
+
+This will work even if the kernel limits change.
+
+
+2.26.  How do I get the same behavior on parsing /etc/passwd and
+       /etc/group as I have with libc5 ?
+
+{TK} The name switch setup in /etc/nsswitch.conf selected by most Linux
+distributions does not support +/- and netgroup entries in the files like
+/etc/passwd.  Though this is the preferred setup some people might have
+setups coming over from the libc5 days where it was the default to recognize
+lines like this.  To get back to the old behaviour one simply has to change
+the rules for passwd, group, and shadow in the nsswitch.conf file as
+follows:
 
+passwd: compat
+group:  compat
+shadow: compat
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q31]  ``What's the problem with configure --enable-omitfp?''
+passwd_compat: nis
+group_compat: nis
+shadow_compat: nis
 
-[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.
 
-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.
+2.27.  What needs to be recompiled when upgrading from glibc 2.0 to glibc
+       2.1?
 
-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.
+{AJ,CG} If you just upgrade the glibc from 2.0.x (x <= 7) to 2.1, binaries
+that have been linked against glibc 2.0 will continue to work.
 
-The compilation of this extra libraries and the compiler optimizations
-slow down the build process and need more disk space.
+If you compile your own binaries against glibc 2.1, you also need to
+recompile some other libraries.  The problem is that libio had to be changed
+and therefore libraries that are based or depend on the libio of glibc,
+e.g. ncurses, slang and most C++ libraries, need to be recompiled.  If you
+experience strange segmentation faults in your programs linked against glibc
+2.1, you might need to recompile your libraries.
 
+Another problem is that older binaries that were linked statically against
+glibc 2.0 will reference the older nss modules (libnss_files.so.1 instead of
+libnss_files.so.2), so don't remove them.  Also, the old glibc-2.0 compiled
+static libraries (libfoo.a) which happen to depend on the older libio
+behavior will be broken by the glibc 2.1 upgrade.  We plan to produce a
+compatibility library that people will be able to link in if they want
+to compile a static library generated against glibc 2.0 into a program
+on a glibc 2.1 system.  You just add -lcompat and you should be fine.
+
+The glibc-compat add-on will provide the libcompat.a library, the older
+nss modules, and a few other files.  Together, they should make it
+possible to do development with old static libraries on a glibc 2.1
+system.  This add-on is still in development.  You can get it from
+       <ftp://alpha.gnu.org/gnu/glibc/glibc-compat-2.1.tar.gz>
+but please keep in mind that it is experimental.
+
+
+2.28.  Why is extracting files via tar so slow?
+
+{AJ} Extracting of tar archives might be quite slow since tar has to look up
+userid and groupids and doesn't cache negative results.  If you have nis or
+nisplus in your /etc/nsswitch.conf for the passwd and/or group database,
+each file extractions needs a network connection.  There are two possible
+solutions:
+
+- do you really need NIS/NIS+ (some Linux distributions add by default
+  nis/nisplus even if it's not needed)?  If not, just remove the entries.
+
+- if you need NIS/NIS+, use the Name Service Cache Daemon nscd that comes
+  with glibc 2.1.
+
+
+2.29.  Compiling programs I get parse errors in libio.h (e.g. "parse error
+       before `_IO_seekoff'").  How should I fix this?
+
+{AJ} You might get the following errors when upgrading to glibc 2.1:
+
+  In file included from /usr/include/stdio.h:57,
+                   from ...
+  /usr/include/libio.h:335: parse error before `_IO_seekoff'
+  /usr/include/libio.h:335: parse error before `_G_off64_t'
+  /usr/include/libio.h:336: parse error before `_IO_seekpos'
+  /usr/include/libio.h:336: parse error before `_G_fpos64_t'
+
+The problem is a wrong _G_config.h file in your include path.  The
+_G_config.h file that comes with glibc 2.1 should be used and not one from
+libc5 or from a compiler directory.  To check which _G_config.h file the
+compiler uses, compile your program with `gcc -E ...|grep G_config.h' and
+remove that file.  Your compiler should pick up the file that has been
+installed by glibc 2.1 in your include directory.
+
+
+2.30.  After upgrading to glibc 2.1, libraries that were compiled against
+       glibc 2.0.x don't work anymore.
+
+{AJ} See question 2.27.
+
+
+2.31.  What happened to the Berkeley DB libraries?  Can I still use db
+       in /etc/nsswitch.conf?
+
+{AJ} Due to too many incompatible changes in disk layout and API of Berkeley
+DB and a too tight coupling of libc and libdb, the db library has been
+removed completely from glibc 2.2.  The only place that really used the
+Berkeley DB was the NSS db module.
+
+The NSS db module has been rewritten to support a number of different
+versions of Berkeley DB for the NSS db module.  Currently the releases 2.x
+and 3.x of Berkeley DB are supported.  The older db 1.85 library is not
+supported.  You can use the version from glibc 2.1.x or download a version
+from Sleepycat Software (http://www.sleepycat.com).  The library has to be
+compiled as shared library and installed in the system lib directory
+(normally /lib).  The library needs to have a special soname to be found by
+the NSS module.
+
+If public structures change in a new Berkeley db release, this needs to be
+reflected in glibc.
+
+Currently the code searches for libraries with a soname of "libdb.so.3"
+(that's the name from db 2.4.14 which comes with glibc 2.1.x) and
+"libdb-3.0.so" (the name used by db 3.0.55 as default).
+
+The nss_db module is now in a separate package since it requires a database
+library being available.
+
+
+2.32.  What has do be done when upgrading to glibc 2.2?
+
+{AJ} The upgrade to glibc 2.2 should run smoothly, there's in general no
+need to recompile programs or libraries.  Nevertheless, some changes might
+be needed after upgrading:
+- The utmp daemon has been removed and is not supported by glibc anymore.
+  If it has been in use, it should be switched off.
+- Programs using IPv6 have to be recompiled due to incompatible changes in
+  sockaddr_in6 by the IPv6 working group.
+- The Berkeley db libraries have been removed (for details see question 2.31).
+- The format of the locale files has changed, all locales should be
+  regenerated with localedef.  All statically linked applications which use
+  i18n should be recompiled, otherwise they'll not be localized.
+- glibc comes with a number of new applications.  For example ldconfig has
+  been implemented for glibc, the libc5 version of ldconfig is not needed
+  anymore.
+- There's no more K&R compatibility in the glibc headers.  The GNU C library
+  requires a C compiler that handles especially prototypes correctly.
+  Especially gcc -traditional will not work with glibc headers.
+
+Please read also the NEWS file which is the authoritative source for this
+and gives more details for some topics.
+
+
+2.33.  The makefiles want to do a CVS commit.
+
+{UD} Only if you are not specifying the --without-cvs flag at configure
+time.  This is what you always have to use if you are checking sources
+directly out of the public CVS repository or you have your own private
+repository.
+
+
+2.34.  When compiling C++ programs, I get a compilation error in streambuf.h.
+
+{BH} You are using g++ 2.95.2? After upgrading to glibc 2.2, you need to
+apply a patch to the include files in /usr/include/g++, because the fpos_t
+type has changed in glibc 2.2.  The patch is at
+
+  http://www.haible.de/bruno/gccinclude-glibc-2.2-compat.diff
+
+
+2.35.  When recompiling GCC, I get compilation errors in libio.
+
+{BH} You are trying to recompile gcc 2.95.2?  Use gcc 2.95.3 instead.
+This version is needed because the fpos_t type and a few libio internals
+have changed in glibc 2.2, and gcc 2.95.3 contains a corresponding patch.
+
+
+2.36.  Why shall glibc never get installed on GNU/Linux systems in
+/usr/local?
+
+{AJ} The GNU C compiler treats /usr/local/include and /usr/local/lib in a
+special way, these directories will be searched before the system
+directories.  Since on GNU/Linux the system directories /usr/include and
+/usr/lib contain a --- possibly different --- version of glibc and mixing
+certain files from different glibc installations is not supported and will
+break, you risk breaking your complete system.  If you want to test a glibc
+installation, use another directory as argument to --prefix.  If you like to
+install this glibc version as default version, overriding the existing one,
+use --prefix=/usr and everything will go in the right places.
+
+
+2.37.  When recompiling GCC, I get compilation errors in libstdc++.
+
+{BH} You are trying to recompile gcc 3.2?  You need to patch gcc 3.2,
+because some last minute changes were made in glibc 2.3 which were not
+known when gcc 3.2 was released.  The patch is at
+
+  http://www.haible.de/bruno/gcc-3.2-glibc-2.3-compat.diff
+
+\f
+. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q32]  ``Why don't signals interrupt system calls anymore?''
+3. Source and binary incompatibilities, and what to do about them
 
-[A32] {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.
+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?
+
+{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 question 3.7 for details.
+
+
+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.
+
+
+3.3.   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.  For former is very much preferred
+(see question 4.3).
+
+
+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?
+
+{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.
+
+
+3.5.   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.
+
+
+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 and 2.0.32 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/2.0.32 fix 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.
 
 There are three differences:
 
@@ -851,7 +1461,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
@@ -867,38 +1477,38 @@ 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
+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().
 
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[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 additionally implemented as
+inline functions and others as macros.  This might lead to problems with
+existing codes but it is explicitly allowed by ISO C.
 
-[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
-feature macros:
-* __NO_STRING_INLINES: Don't use string optimizations.
-* __USE_STRING_INLINES: Use also assembler inline functions (might
-  increase code use dramatically).
+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 even
-unneccessary since <string.h> has the necessary declarations). Either
-change your code or define __NO_STRING_INLINES.
+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 the 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.
+{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.
 
-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,23 +1516,450 @@ 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.
+
+
+3.9.   I get compiler messages "Initializer element not constant" with
+       stdin/stdout/stderr. Why?
+
+{RM,AJ} Constructs like:
+   static FILE *InPtr = stdin;
+
+lead to this message.  This is correct behaviour with glibc since stdin is
+not a constant expression.  Please note that a strict reading of ISO C does
+not allow above constructs.
+
+One of the advantages of this is that you can assign to stdin, stdout, and
+stderr just like any other global variable (e.g. `stdout = my_stream;'),
+which can be very useful with custom streams that you can write with libio
+(but beware this is not necessarily portable).  The reason to implement it
+this way were versioning problems with the size of the FILE structure.
+
+To fix those programs you've got to initialize the variable at run time.
+This can be done, e.g. in main, like:
+
+   static FILE *InPtr;
+   int main(void)
+   {
+     InPtr = stdin;
+   }
+
+or by constructors (beware this is gcc specific):
+
+   static FILE *InPtr;
+   static void inPtr_construct (void) __attribute__((constructor));
+   static void inPtr_construct (void) { InPtr = stdin; }
+
+
+3.10.  I can't compile with gcc -traditional (or
+       -traditional-cpp). Why?
+
+{AJ} glibc2 does break -traditional and -traditonal-cpp - and will continue
+to do so.  For example constructs of the form:
+
+   enum {foo
+   #define foo foo
+   }
+
+are useful for debugging purposes (you can use foo with your debugger that's
+why we need the enum) and for compatibility (other systems use defines and
+check with #ifdef).
+
+
+3.11.  I get some errors with `gcc -ansi'. Isn't glibc ANSI compatible?
+
+{AJ} The GNU C library is compatible with the ANSI/ISO C standard.  If
+you're using `gcc -ansi', the glibc includes which are specified in the
+standard follow the standard.  The ANSI/ISO C standard defines what has to be
+in the include files - and also states that nothing else should be in the
+include files (btw. you can still enable additional standards with feature
+flags).
+
+The GNU C library is conforming to ANSI/ISO C - if and only if you're only
+using the headers and library functions defined in the standard.
+
+
+3.12.  I can't access some functions anymore.  nm shows that they do
+       exist but linking fails nevertheless.
+
+{AJ} With the introduction of versioning in glibc 2.1 it is possible to
+export only those identifiers (functions, variables) that are really needed
+by application programs and by other parts of glibc.  This way a lot of
+internal interfaces are now hidden.  nm will still show those identifiers
+but marking them as internal.  ISO C states that identifiers beginning with
+an underscore are internal to the libc.  An application program normally
+shouldn't use those internal interfaces (there are exceptions,
+e.g. __ivaliduser).  If a program uses these interfaces, it's broken.  These
+internal interfaces might change between glibc releases or dropped
+completely.
+
+
+3.13.  When using the db-2 library which comes with glibc is used in
+       the Perl db modules the testsuite is not passed.  This did not
+       happen with db-1, gdbm, or ndbm.
+
+{} Removed.  Does not apply anymore.
+
+
+3.14.  The pow() inline function I get when including <math.h> is broken.
+       I get segmentation faults when I run the program.
+
+{UD} Nope, the implementation is correct.  The problem is with egcs version
+prior to 1.1.  I.e., egcs 1.0 to 1.0.3 are all broken (at least on Intel).
+If you have to use this compiler you must define __NO_MATH_INLINES before
+including <math.h> to prevent the inline functions from being used.  egcs 1.1
+fixes the problem.  I don't know about gcc 2.8 and 2.8.1.
+
+
+3.15.  The sys/sem.h file lacks the definition of `union semun'.
+
+{UD} Nope.  This union has to be provided by the user program.  Former glibc
+versions defined this but it was an error since it does not make much sense
+when thinking about it.  The standards describing the System V IPC functions
+define it this way and therefore programs must be adopted.
+
+
+3.16.  Why has <netinet/ip_fw.h> disappeared?
+
+{AJ} The corresponding Linux kernel data structures and constants are
+totally different in Linux 2.0 and Linux 2.2.  This situation has to be
+taken care in user programs using the firewall structures and therefore
+those programs (ipfw is AFAIK the only one) should deal with this problem
+themselves.
+
+
+3.17.  I get floods of warnings when I use -Wconversion and include
+       <string.h> or <math.h>.
 
+{ZW} <string.h> and <math.h> intentionally use prototypes to override
+argument promotion.  -Wconversion warns about all these.  You can safely
+ignore the warnings.
+
+-Wconversion isn't really intended for production use, only for shakedown
+compiles after converting an old program to standard C.
+
+
+3.18.  After upgrading to glibc 2.1, I receive errors about
+       unresolved symbols, like `_dl_initial_searchlist' and can not
+       execute any binaries.  What went wrong?
+
+{AJ} This normally happens if your libc and ld (dynamic linker) are from
+different releases of glibc.  For example, the dynamic linker
+/lib/ld-linux.so.2 comes from glibc 2.0.x, but the version of libc.so.6 is
+from glibc 2.1.
+
+The path /lib/ld-linux.so.2 is hardcoded in every glibc2 binary but
+libc.so.6 is searched via /etc/ld.so.cache and in some special directories
+like /lib and /usr/lib.  If you run configure with another prefix than /usr
+and put this prefix before /lib in /etc/ld.so.conf, your system will break.
+
+So what can you do?  Either of the following should work:
+
+* Run `configure' with the same prefix argument you've used for glibc 2.0.x
+  so that the same paths are used.
+* Replace /lib/ld-linux.so.2 with a link to the dynamic linker from glibc
+  2.1.
+
+You can even call the dynamic linker by hand if everything fails.  You've
+got to set LD_LIBRARY_PATH so that the corresponding libc is found and also
+need to provide an absolute path to your binary:
+
+       LD_LIBRARY_PATH=<path-where-libc.so.6-lives> \
+       <path-where-corresponding-dynamic-linker-lives>/ld-linux.so.2 \
+       <path-to-binary>/binary
+
+For example `LD_LIBRARY_PATH=/libold /libold/ld-linux.so.2 /bin/mv ...'
+might be useful in fixing a broken system (if /libold contains dynamic
+linker and corresponding libc).
+
+With that command line no path is used.  To further debug problems with the
+dynamic linker, use the LD_DEBUG environment variable, e.g.
+`LD_DEBUG=help echo' for the help text.
+
+If you just want to test this release, don't put the lib directory in
+/etc/ld.so.conf.  You can call programs directly with full paths (as above).
+When compiling new programs against glibc 2.1, you've got to specify the
+correct paths to the compiler (option -I with gcc) and linker (options
+--dynamic-linker, -L and --rpath).
+
+
+3.19.  bonnie reports that char i/o with glibc 2 is much slower than with
+       libc5.  What can be done?
+
+{AJ} The GNU C library uses thread safe functions by default and libc5 used
+non thread safe versions.  The non thread safe functions have in glibc the
+suffix `_unlocked', for details check <stdio.h>.  Using `putc_unlocked' etc.
+instead of `putc' should give nearly the same speed with bonnie (bonnie is a
+benchmark program for measuring disk access).
+
+
+3.20.  Programs compiled with glibc 2.1 can't read db files made with glibc
+       2.0.  What has changed that programs like rpm break?
+
+{} Removed.  Does not apply anymore.
+
+
+3.21.  Autoconf's AC_CHECK_FUNC macro reports that a function exists, but
+       when I try to use it, it always returns -1 and sets errno to ENOSYS.
+
+{ZW} You are using a 2.0 Linux kernel, and the function you are trying to
+use is only implemented in 2.1/2.2.  Libc considers this to be a function
+which exists, because if you upgrade to a 2.2 kernel, it will work.  One
+such function is sigaltstack.
+
+Your program should check at runtime whether the function works, and
+implement a fallback.  Note that Autoconf cannot detect unimplemented
+functions in other systems' C libraries, so you need to do this anyway.
+
+
+3.22.  My program segfaults when I call fclose() on the FILE* returned
+       from setmntent().  Is this a glibc bug?
+
+{GK} No.  Don't do this.  Use endmntent(), that's what it's for.
+
+In general, you should use the correct deallocation routine.  For instance,
+if you open a file using fopen(), you should deallocate the FILE * using
+fclose(), not free(), even though the FILE * is also a pointer.
+
+In the case of setmntent(), it may appear to work in most cases, but it
+won't always work.  Unfortunately, for compatibility reasons, we can't
+change the return type of setmntent() to something other than FILE *.
+
+
+3.23.  I get "undefined reference to `atexit'"
+
+{UD} This means that your installation is somehow broken.  The situation is
+the same as for 'stat', 'fstat', etc (see question 2.7).  Investigate why the
+linker does not pick up libc_nonshared.a.
+
+If a similar message is issued at runtime this means that the application or
+DSO is not linked against libc.  This can cause problems since 'atexit' is
+not exported anymore.
+
+\f
+. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
+
+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 ftp.gnu.org.
+
+
+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.
+
+{PB} The 2.1 release of GNU libc aims to comply with the current versions of
+all the relevant standards.  The IPv6 support libraries for older Linux
+systems used a different naming convention and so code written to work with
+them may need to be modified.  If the standards make incompatible changes in
+the future then the libc may need to change again.
+
+IPv6 will not work with a 2.0.x kernel.  When kernel 2.2 is released it
+should contain all the necessary support; until then you should use the
+latest 2.1.x release you can find.  As of 98/11/26 the currently recommended
+kernel for IPv6 is 2.1.129.
+
+Also, as of the 2.1 release the IPv6 API provided by GNU libc is not
+100% complete.
+
+
+4.3.   When I set the timezone by setting the TZ environment variable
+       to EST5EDT things go wrong since glibc computes the wrong time
+       from this information.
+
+{UD} The problem is that people still use the braindamaged POSIX method to
+select the timezone using the TZ environment variable with a format EST5EDT
+or whatever.  People, if you insist on using TZ instead of the timezone
+database (see below), read the POSIX standard, the implemented behaviour is
+correct!  What you see is in fact the result of the decisions made while
+POSIX.1 was created.  We've only implemented the handling of TZ this way to
+be POSIX compliant.  It is not really meant to be used.
+
+The alternative approach to handle timezones which is implemented is the
+correct one to use: use the timezone database.  This avoids all the problems
+the POSIX method has plus it is much easier to use.  Simply run the tzselect
+shell script, answer the question and use the name printed in the end by
+making a symlink /etc/localtime pointing to /usr/share/zoneinfo/NAME (NAME
+is the returned value from tzselect).  That's all.  You never again have to
+worry.
+
+So, please avoid sending bug reports about time related problems if you use
+the POSIX method and you have not verified something is really broken by
+reading the POSIX standards.
+
+
+4.4.   What other sources of documentation about glibc are available?
+
+{AJ} The FSF has a page about the GNU C library at
+<http://www.gnu.org/software/libc/>.  The problem data base of open and
+solved bugs in GNU libc is available at
+<http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl>.  Eric Green has written
+a HowTo for converting from Linux libc5 to glibc2.  The HowTo is accessible
+via the FSF page and at <http://www.imaxx.net/~thrytis/glibc>.  Frodo
+Looijaard describes a different way installing glibc2 as secondary libc at
+<http://huizen.dds.nl/~frodol/glibc>.
+
+Please note that this is not a complete list.
+
+
+4.5.   The timezone string for Sydney/Australia is wrong since even when
+       daylight saving time is in effect the timezone string is EST.
+
+{UD} The problem for some timezones is that the local authorities decided
+to use the term "summer time" instead of "daylight saving time".  In this
+case the abbreviation character `S' is the same as the standard one.  So,
+for Sydney we have
+
+       Eastern Standard Time   = EST
+       Eastern Summer Time     = EST
+
+Great!  To get this bug fixed convince the authorities to change the laws
+and regulations of the country this effects.  glibc behaves correctly.
+
+
+4.6.   I've build make 3.77 against glibc 2.1 and now make gets
+       segmentation faults.
+
+{} Removed.  Does not apply anymore, use make 3.79 or newer.
+
+
+4.7.   Why do so many programs using math functions fail on my AlphaStation?
+
+{AO} The functions floor() and floorf() use an instruction that is not
+implemented in some old PALcodes of AlphaStations.  This may cause
+`Illegal Instruction' core dumps or endless loops in programs that
+catch these signals.  Updating the firmware to a 1999 release has
+fixed the problem on an AlphaStation 200 4/166.
+
+
+4.8.   The conversion table for character set XX does not match with
+what I expect.
+
+{UD} I don't doubt for a minute that some of the conversion tables contain
+errors.  We tried the best we can and relied on automatic generation of the
+data to prevent human-introduced errors but this still is no guarantee.  If
+you think you found a problem please send a bug report describing it and
+give an authoritive reference.  The latter is important since otherwise
+the current behaviour is as good as the proposed one.
+
+Before doing this look through the list of known problem first:
+
+- the GBK (simplified Chinese) encoding is based on Unicode tables.  This
+  is good.  These tables, however, differ slightly from the tables used
+  by the M$ people.  The differences are these [+ Unicode, - M$]:
+
+    +0xA1AA 0x2015
+    +0xA844 0x2014
+    -0xA1AA 0x2014
+    -0xA844 0x2015
+
+  In addition the Unicode tables contain mappings for the GBK characters
+  0xA8BC, 0xA8BF, 0xA989 to 0xA995, and 0xFE50 to 0xFEA0.
+
+- when mapping from EUC-CN to GBK and vice versa we ignore the fact that
+  the coded character at position 0xA1A4 maps to different Unicode
+  characters.  Since the iconv() implementation can do whatever it wants
+  if it cannot directly map a character this is a perfectly good solution
+  since the semantics and appearance of the character does not change.
+
+
+4.9.   How can I find out which version of glibc I am using in the moment?
+
+{UD} If you want to find out about the version from the command line simply
+run the libc binary.  This is probably not possible on all platforms but
+where it is simply locate the libc DSO and start it as an application.  On
+Linux like
+
+       /lib/libc.so.6
+
+This will produce all the information you need.
+
+What always will work is to use the API glibc provides.  Compile and run the
+following little program to get the version information:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+#include <stdio.h>
+#include <gnu/libc-version.h>
+int main (void) { puts (gnu_get_libc_version ()); return 0; }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This interface can also obviously be used to perform tests at runtime if
+this should be necessary.
+
+
+4.10.  Context switching with setcontext() does not work from within
+       signal handlers.
+
+{DMT} The Linux implementations (IA-64, S390 so far) of setcontext()
+supports synchronous context switches only.  There are several reasons for
+this:
+
+- UNIX provides no other (portable) way of effecting a synchronous
+  context switch (also known as co-routine switch).  Some versions
+  support this via setjmp()/longjmp() but this does not work
+  universally.
+
+- As defined by the UNIX '98 standard, the only way setcontext()
+  could trigger an asychronous context switch is if this function
+  were invoked on the ucontext_t pointer passed as the third argument
+  to a signal handler.  But according to draft 5, XPG6, XBD 2.4.3,
+  setcontext() is not among the set of routines that may be called
+  from a signal handler.
+
+- If setcontext() were to be used for asynchronous context switches,
+  all kinds of synchronization and re-entrancy issues could arise and
+  these problems have already been solved by real multi-threading
+  libraries (e.g., POSIX threads or Linux threads).
+
+- Synchronous context switching can be implemented entirely in
+  user-level and less state needs to be saved/restored than for an
+  asynchronous context switch.  It is therefore useful to distinguish
+  between the two types of context switches.  Indeed, some
+  application vendors are known to use setcontext() to implement
+  co-routines on top of normal (heavier-weight) pre-emptable threads.
+
+It should be noted that if someone was dead-bent on using setcontext()
+on the third arg of a signal handler, then IA-64 Linux could support
+this via a special version of sigaction() which arranges that all
+signal handlers start executing in a shim function which takes care of
+saving the preserved registers before calling the real signal handler
+and restoring them afterwards.  In other words, we could provide a
+compatibility layer which would support setcontext() for asynchronous
+context switches.  However, given the arguments above, I don't think
+that makes sense.  setcontext() provides a decent co-routine interface
+and we should just discourage any asynchronous use (which just calls
+for trouble at any rate).
 
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
 \f
+~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 
+
 Answers were given by:
-{UD} Ulrich Drepper, <drepper@cygnus.com>
-{DMT} David Mosberger-Tang, <davidm@AZStarNet.com>
+{UD} Ulrich Drepper, <drepper@redhat.com>
+{DMT} David Mosberger-Tang, <davidm@hpl.hp.com>
 {RM} Roland McGrath, <roland@gnu.org>
-{HJL} H.J. Lu, <hjl@gnu.org>
-{AJ} Andreas Jaeger, <aj@arthur.rhein-neckar.de>
+{AJ} Andreas Jaeger, <aj@suse.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>
+{TK} Thorsten Kukuk, <kukuk@suse.de>
+{GK} Geoffrey Keating, <geoffk@redhat.com>
+{HJ} H.J. Lu, <hjl@gnu.org>
+{CG} Cristian Gafton, <gafton@redhat.com>
+{AO} Alexandre Oliva, <aoliva@redhat.com>
+{BH} Bruno Haible, <haible@clisp.cons.org>
+{SM} Steven Munroe, <sjmunroe@us.ibm.com>
 \f
 Local Variables:
- mode:text
+ mode:outline
+ outline-regexp:"\\?"
+  fill-column:76
 End: