Update.

1998-04-09  Ulrich Drepper  <drepper@cygnus.com>

	* sysdeps/i386/i486/bits/string.h: Remove unused variables.

	* misc/syslog.c (closelog_internal): Set LogTag to NULL.

1 files changed, 62 insertions, 5 deletions

diff --git a/FAQ b/FAQ
index e2b9f0d5ea..895d8e96c6 100644
--- a/FAQ
+++ b/FAQ
@@ -81,6 +81,8 @@ please let me know.
 	  object, consider re-linking
 	Why?  What should I do?
 2.19.	What do I need for C++ development?
+2.20.	Even statically linked programs need some shared libraries
+	which is not acceptable for me.  What can I do?
 
 3. Source and binary incompatibilities, and what to do about them
 
@@ -116,6 +118,9 @@ please let me know.
 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 I'm by setting the TZ environment variable
+	to EST5EDT things go wrong since glibc computes the wrong time
+	from this information.
 
 
 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 
@@ -138,6 +143,8 @@ probably in the future, are:
 	powerpc-*-linux-gnu     Linux and MkLinux on PowerPC systems
 	sparc-*-linux-gnu	Linux-2.x on SPARC
 	sparc64-*-linux-gnu	Linux-2.x on UltraSPARC
+	arm-*-none		ARM standalone systems
+	arm-*-linuxaout		Linux-2.x on ARM using a.out binaries
 
 Ports to other Linux platforms are in development, and may in fact
 work already, but no one has sent us success reports for them.
@@ -597,11 +604,7 @@ probably a missing or incorrect /usr/lib/libc.so file; note that this
 is a small text file now, not a symlink to libc.so.6.  It should look
 something like this:
 
-GROUP ( libc.so.6 ld.so.1 libc.a )
-
-or in ix86/Linux and alpha/Linux:
-
-GROUP ( libc.so.6 ld-linux.so.2 libc.a )
+GROUP ( libc.so.6 libc_nonshared.a )
 
 
 2.8.	How can I compile gcc 2.7.2.1 from the gcc source code using
@@ -763,6 +766,34 @@ 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.
 
+
+2.20.	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.c \
+    -lc -lnss_files -lnss_dns -lresolv
+
+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.
+
 
 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
 
@@ -1071,6 +1102,32 @@ Also, make sure you have a suitably recent kernel.  As of the 970401
 snapshot, according to Philip Blundell <Philip.Blundell@pobox.com>, the
 required kernel version is at least 2.1.30.
 
+
+4.3.	When I set the timezone I'm 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, 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 to
+/usr/share/zoneinfo/NAME (NAME is the returned value from tzselect)
+from the file /etc/localtime.  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.
+
 
 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~