Update.

1 files changed, 129 insertions, 7 deletions

diff --git a/FAQ b/FAQ
index d4af13b05b..653bbbfa7f 100644
--- a/FAQ
+++ b/FAQ
@@ -87,6 +87,28 @@ please let me know.
 
 [Q24]	``I have set up /etc/nis.conf, and the Linux libc 5 with NYS
 	  works great.  But the glibc NIS+ doesn't seem to work.''
+
+[Q25]	``After installing glibc name resolving doesn't work properly.''
+
+
+[Q26]	``I have /usr/include/net and /usr/include/scsi as symlinks
+	  into my Linux source tree.  Is that wrong?''
+
+[Q27]	``Programs like `logname', `top', `uptime' `users', `w' and
+	  `who', show incorrect information about the (number of)
+	  users on my system.  Why?''
+
+[Q28]	``After upgrading to a glibc 2.1 with symbol versioning I get
+	  errors about undefined symbols.  What went wrong?''
+
+[Q29]	``I don't include any kernel header myself but still the
+	  compiler complains about type redeclarations of types in the
+	  kernel headers.''
+
+[Q30]	``When I start the program XXX after upgrading the library
+	  I get
+	    XXX: Symbol `_sys_errlist' has different size in shared object, consider re-linking
+	  Why?  What to do?''
 
 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
 [Q1]	``What systems does the GNU C Library run on?''
@@ -102,6 +124,9 @@ in the future are:
 	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
 
 Other Linux platforms are also on the way to be supported but I need
 some success reports first.
@@ -129,7 +154,9 @@ The GNU CC is found like all other GNU packages on
 or better one of the many mirror sites.
 
 You always should try to use the latest official release.  Older
-versions might not have all the features GNU libc could use.
+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.
 
 
 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
@@ -177,19 +204,24 @@ Library.
   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., ~70MB).
+* lots of diskspace (for i?86-linux this means, e.g., ~170MB; for ppc-linux
+  even ~200MB).
 
   You should avoid compiling on a NFS mounted device.  This is very
   slow.
 
 * 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).
-  For Hurd systems times are much higher.
+  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.
 
   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.
 
+  For Atari TT030 (Motorola 68030 @ 32 Mhz, 34 Mb memory) (full build)
+  a compile time of 22h48m.
+
   If you have some more measurements let me know.
 
 * When compiling for Linux:
@@ -336,6 +368,9 @@ be read by functions from the other library.  Sorry, but this is what
 a major release is for.  It's better to have a cut now than having no
 means to support the new techniques later.
 
+{MK} There is however a (partial) solution for this problem.  Please
+take a look at the file `README.utmpd'.
+
 
 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
 [Q11]	``Where are the DST_* constants found in <sys/time.h> on many
@@ -430,7 +465,7 @@ programs and source code.  Until this law gets abolished we cannot
 ship the cryptographic function together with the 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 way get it
+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
@@ -647,7 +682,7 @@ results because of type conflicts.
 a point where it is stable.  There are still lots of incompatible changes
 made and the libc headers have to follow.
 
-Currently (as of 970401) according to Philip Blundell <pjb27@cam.ac.uk>
+Currently (as of 970401) according to Philip Blundell <philb@gnu.ai.mit.edu>
 the required kernel version is 2.1.30.
 
 
@@ -685,14 +720,101 @@ http://www-vt.uni-paderborn.de/~kukuk/linux/nisplus.html).
 
 
 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
+[Q25]	``After installing glibc name resolving doesn't work properly.''
+
+[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.
+
+
+~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
+[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.
+
+
+~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
+[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.
+
+
+~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
+[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:
+
+"msgfmt: error in loading shared libraries: : undefined symbol: _nl_domain_bindings"
+
+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.
+
+
+~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
+[Q29]	``I don't include any kernel header myself but still the
+	  compiler complains about type redeclarations of types in the
+	  kernel headers.''
+
+[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.
+
+
+~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
+[Q30]	``When I start the program XXX after upgrading the library
+	  I get
+	    XXX: Symbol `_sys_errlist' has different size in shared object, consider re-linking
+	  Why?  What to do?''
+
+[A30] {UD} As the message says, relink the binary.  The problem is that
+very few symbols from the library can change in size and there is no way
+to avoid this.  _sys_errlist is a good example.  Occasionally there are
+new error numbers added to the kernel and this must be reflected at user
+level.
+
+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.
+
+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.
+
+
+~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
 
 Answers were given by:
 {UD} Ulrich Drepper, <drepper@cygnus.com>
 {DMT} David Mosberger-Tang, <davidm@AZStarNet.com>
-{RM} Roland McGrath, <roland@gnu.ai.mit.edu>
-{HJL} H.J. Lu, <hjl@gnu.ai.mit.edu>
+{RM} Roland McGrath, <roland@gnu.org>
+{HJL} H.J. Lu, <hjl@gnu.org>
 {AJ} Andreas Jaeger, <aj@arthur.rhein-neckar.de>
 {EY} Eric Youngdale, <eric@andante.jic.com>
+{PB} Phil Blundell, <Philip.Blundell@pobox.com>
+{MK} Mark Kettenis, <kettenis@phys.uva.nl>
 
 Local Variables:
  mode:text