aboutsummaryrefslogtreecommitdiff
path: root/FAQ
diff options
context:
space:
mode:
authorUlrich Drepper <drepper@redhat.com>1998-04-09 20:41:47 +0000
committerUlrich Drepper <drepper@redhat.com>1998-04-09 20:41:47 +0000
commitff44f2a57a9442d86e7c40975a3cd45a3ff7de72 (patch)
tree9b36da44c2d9975cafc72379705cd4c2ee0cb390 /FAQ
parent834e195429b277d519fae256284c535dc2315c9b (diff)
downloadglibc-ff44f2a57a9442d86e7c40975a3cd45a3ff7de72.zip
glibc-ff44f2a57a9442d86e7c40975a3cd45a3ff7de72.tar.gz
glibc-ff44f2a57a9442d86e7c40975a3cd45a3ff7de72.tar.bz2
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.
Diffstat (limited to 'FAQ')
-rw-r--r--FAQ67
1 files changed, 62 insertions, 5 deletions
diff --git a/FAQ b/FAQ
index e2b9f0d..895d8e9 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.
+
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~