From ff44f2a57a9442d86e7c40975a3cd45a3ff7de72 Mon Sep 17 00:00:00 2001 From: Ulrich Drepper Date: Thu, 9 Apr 1998 20:41:47 +0000 Subject: Update. 1998-04-09 Ulrich Drepper * sysdeps/i386/i486/bits/string.h: Remove unused variables. * misc/syslog.c (closelog_internal): Set LogTag to NULL. --- FAQ | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 62 insertions(+), 5 deletions(-) (limited to 'FAQ') 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 , 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. + ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -- cgit v1.2.3