| Frequently Asked Questions about the GNU C Library |
| |
| 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 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 |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| |
| 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 archiver? |
| 1.5. Which compiler should I use for powerpc? |
| 1.6. Do I need some more things to compile GNU C Library? |
| 1.7. What version of the Linux kernel headers should be used? |
| 1.8. The compiler hangs while building iconvdata modules. What's |
| wrong? |
| 1.9. When I run `nm -u libc.so' on the produced library I still |
| find unresolved symbols. Can this be ok? |
| 1.10. What are these `add-ons'? |
| 1.11. My XXX kernel emulates a floating-point coprocessor for me. |
| Should I enable --with-fp? |
| 1.12. When compiling GNU libc I get lots of errors saying functions |
| in glibc are duplicated in libgcc. |
| 1.13. Why do I get messages about missing thread functions when I use |
| librt? I don't even use threads. |
| 1.14. What's the problem with configure --enable-omitfp? |
| 1.15. I get failures during `make check'. What shall I do? |
| |
| 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. How can I compile gcc 2.7.2.1 from the gcc source code using |
| glibc 2.x? |
| 2.9. The `gencat' utility cannot process the catalog sources which |
| were used on my Linux libc5 based system. Why? |
| 2.10. Programs using libc have their messages translated, but other |
| behavior is not localized (e.g. collating order); why? |
| 2.11. 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.12. I have killed ypbind to stop using NIS, but glibc |
| continues using NIS. |
| 2.13. Under Linux/Alpha, I always get "do_ypcall: clnt_call: |
| RPC: Unable to receive; errno = Connection refused" when using NIS. |
| 2.14. After installing glibc name resolving doesn't work properly. |
| 2.15. How do I create the databases for NSS? |
| 2.16. I have /usr/include/net and /usr/include/scsi as symlinks |
| into my Linux source tree. Is that wrong? |
| 2.17. Programs like `logname', `top', `uptime' `users', `w' and |
| `who', show incorrect information about the (number of) |
| users on my system. Why? |
| 2.18. After upgrading to glibc 2.1 with symbol versioning I get |
| errors about undefined symbols. What went wrong? |
| 2.19. 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.20. What do I need for C++ development? |
| 2.21. Even statically linked programs need some shared libraries |
| which is not acceptable for me. What can I do? |
| 2.22. I just upgraded my Linux system to glibc and now I get |
| errors whenever I try to link any program. |
| |
| 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. |
| |
| 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? |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| |
| 1. Compiling glibc |
| |
| 1.1. What systems does the GNU C Library run on? |
| |
| {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. |
| |
| The systems glibc is known to work on as of this release, and most probably |
| in the future, are: |
| |
| *-*-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 |
| 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. Currently no |
| ports to other operating systems are underway, although a few people have |
| expressed interest. |
| |
| If you have a system not listed above (or in the `README' file) and you are |
| really interested in porting it, contact |
| |
| <bug-glibc@gnu.org> |
| |
| |
| 1.2. What compiler do I need to build GNU libc? |
| |
| {UD} You must use GNU CC to compile GNU libc. A lot of extensions of GNU CC |
| are used to increase portability and speed. |
| |
| GNU CC is found, like all other GNU packages, on |
| |
| ftp://ftp.gnu.org/pub/gnu |
| |
| and the many mirror sites. ftp.gnu.org is always overloaded, so try to find |
| a local mirror first. |
| |
| 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 |
| egcs (1.0.2) and GNU CC (2.8.1) should work with the GNU C library (for |
| powerpc see question question 1.5). |
| |
| |
| 1.3. When I try to compile glibc I get only error messages. |
| What's wrong? |
| |
| {UD} You definitely need GNU make to translate GNU libc. No other make |
| program has the needed functionality. |
| |
| We recommend version GNU make version 3.75. Versions 3.76 and 3.76.1 have |
| bugs which appear when building big projects like GNU libc. Versions before |
| 3.74 have bugs and/or are missing features. |
| |
| |
| 1.4. Do I need a special linker or archiver? |
| |
| {UD} You may be able to use your system linker, but GNU libc works best with |
| GNU binutils. |
| |
| On systems where the native linker does not support weak symbols you will |
| not get a fully 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. |
| |
| Always get the newest release of GNU binutils available. Older releases are |
| known to have bugs that prevent a successful compilation. |
| |
| {ZW} As of release 2.1 a linker supporting symbol versions is required. For |
| Linux, get binutils-2.8.1.0.23 or later. Other systems may have native |
| linker support, but it's moot right now, because glibc has not been ported |
| to them. |
| |
| |
| 1.5. Which compiler should I use for powerpc? |
| |
| {GK} You want to use egcs 1.0.1 or later (together with the right versions |
| of all the other tools, of course). |
| |
| In fact, egcs 1.0.1 has a serious bug that prevents a clean make, relating |
| to switch statement folding. It also causes the resulting shared libraries |
| to use more memory than they should. There is a patch at: |
| |
| <http://discus.anu.edu.au/~geoffk/egcs-1.0.1-geoffk.diff> |
| |
| Later versions of egcs may fix these problems. |
| |
| |
| 1.6. Do I need some more things to compile GNU C Library? |
| |
| {UD} Yes, there are some more :-). |
| |
| * 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.) |
| |
| * 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. |
| |
| * Some scripts need perl5 - but at the moment those scripts are not |
| vital for building and installing GNU libc (some data files will not |
| be created). |
| |
| * When compiling for Linux, the header files of the Linux kernel must |
| be available to the compiler as <linux/*.h> and <asm/*.h>. |
| |
| * lots of disk space (~170MB for i?86-linux; more for RISC platforms, |
| as much as 400MB). |
| |
| * plenty of time. Compiling just the shared and static libraries for |
| i?86-linux takes approximately 1h on an i586@133, or 2.5h on |
| i486@66, or 4.5h on i486@33. 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. |
| |
| You should avoid compiling in a NFS mounted filesystem. This is |
| very slow. |
| |
| James Troup <J.J.Troup@comp.brad.ac.uk> reports a compile time 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) |
| |
| If you have some more measurements let me know. |
| |
| |
| 1.7. What version of the Linux kernel headers should be used? |
| |
| {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 when using old kernel headers for compiling the GNU C |
| library. |
| |
| {ZW} Even if you are using a 2.0 kernel on your machine, we recommend you |
| compile GNU libc with 2.1 kernel headers. That way you won't have to |
| recompile libc if you ever upgrade to kernel 2.1 or 2.2. To tell libc which |
| headers to use, give configure the --with-headers switch |
| (e.g. --with-headers=/usr/src/linux-2.1.107/include). |
| |
| Note that you must configure the 2.1 kernel if you do this; otherwise libc |
| will be unable to find <linux/version.h>. Just copy .config from your 2.0 |
| kernel sources to the 2.1 tree, do `make oldconfig', and say no to all the |
| new options. |
| |
| |
| 1.8. The compiler hangs while building iconvdata modules. What's |
| wrong? |
| |
| {ZW} This is a problem with all current releases of GCC. Initialization of |
| large static arrays is very slow. The compiler will eventually finish; give |
| it time. |
| |
| The problem will be fixed in egcs 1.1 but probably not before then. |
| |
| |
| 1.9. When I run `nm -u libc.so' on the produced library I still |
| find unresolved symbols. Can this be ok? |
| |
| {UD} Yes, this is ok. There can be several kinds of unresolved symbols: |
| |
| * magic symbols automatically generated by the linker. These have names |
| like __start_* and __stop_* |
| |
| * symbols starting with _dl_* come from the dynamic linker |
| |
| * weak symbols, which need not be resolved at all (fabs for example) |
| |
| Generally, you should make sure you find a real program which produces |
| errors while linking before deciding there is a problem. |
| |
| |
| 1.10. What are these `add-ons'? |
| |
| {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 question 2.5). |
| |
| 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: |
| |
| configure --enable-add-ons=crypt,linuxthreads |
| |
| for example. |
| |
| 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. |
| |
| |
| 1.11. My XXX kernel emulates a floating-point coprocessor for me. |
| Should I enable --with-fp? |
| |
| {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. |
| |
| 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. |
| |
| |
| 1.12. When compiling GNU libc I get lots of errors saying functions |
| in glibc are duplicated in libgcc. |
| |
| {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. |
| |
| 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. |
| |
| {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. |
| |
| |
| 1.13. Why do I get messages about missing thread functions when I use |
| librt? I don't even use threads. |
| |
| {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: |
| |
| gcc -o foo foo.c -Wl,-rpath-link=/some/other/dir -lrt |
| |
| 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. |
| |
| |
| 1.14. What's the problem with configure --enable-omitfp? |
| |
| {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. |
| |
| 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. |
| |
| Since a library build with --enable-omitfp is undebuggable on most systems, |
| debuggable libraries are also built - you can use it by appending "_g" to |
| the library names. |
| |
| The compilation of these extra libraries and the compiler optimizations slow |
| down the build process and need more disk space. |
| |
| |
| 1.15. I get failures during `make check'. What shall I do? |
| |
| {AJ} The testsuite should compile and run cleanly on your system, every |
| failure should be looked into. Depending on the failure I wouldn't advise |
| installing the library at all. |
| |
| 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. |
| |
| There are some failures which are not directly related to the GNU libc: |
| - Some compiler produce buggy code. The current egcs snapshots are ok and |
| the not yet released egcs 1.1 should be ok. gcc 2.8.1 might cause some |
| failures, gcc 2.7.2.x is so buggy, that explicit checks have been used so |
| that you can't build with it. |
| - 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. The current Linux 2.1 |
| development kernels have fixes for the floating point support on Alpha. |
| |
| |
| . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . |
| |
| 2. Installation and configuration issues |
| |
| 2.1. Can I replace the libc on my Linux system with GNU libc? |
| |
| {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. |
| |
| For Linux there are three major libc versions: |
| libc-4 a.out libc |
| libc-5 original ELF libc |
| libc-6 GNU libc |
| |
| 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 system configuration files. |
| |
| |
| 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.) |
| |
| The dangers when installing glibc in /usr are twofold: |
| |
| * 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 first. (Do not throw it away; you |
| will then lose the ability to compile programs against your old libc.) |
| |
| * 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. |
| |
| The situation is rather similar to the move from a.out to ELF which |
| long-time Linux users will remember. |
| |
| |
| 2.4. Do I need to use GNU CC to compile programs that will use the |
| GNU C Library? |
| |
| {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. |
| |
| 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. |
| |
| 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. |
| |
| |
| 2.5. When linking with the new libc I get unresolved symbols |
| `crypt' and `setkey'. Why aren't these functions in the |
| libc anymore? |
| |
| {UD} The US places restrictions on exporting cryptographic programs and |
| source code. Until this law gets abolished we cannot ship the cryptographic |
| functions together with glibc. |
| |
| The functions are available, as an add-on (see question 1.10). People in the US |
| may get it from the same place they got 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. |
| |
| If you already have the crypt code on your system the reason for the failure |
| is probably that you did not link with -lcrypt. The crypto functions are in |
| a separate library to make it possible to export GNU libc binaries from the |
| US. |
| |
| |
| 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. |
| |
| {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. |
| |
| For casual use of GNU libc you can just specify |
| -dynamic-linker=/lib/ld-linux.so.2 |
| |
| which is the glibc dynamic linker, on Linux systems. On other systems the |
| name is /lib/ld.so.1. |
| |
| 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-linux.so.2' |
| |
| - remove all expression `%{...:-lgmon}'; there is no libgmon in glibc |
| |
| - fix a minor bug by changing %{pipe:-} to %| |
| |
| Here is what the gcc-2.7.2 specs file should look like when GNU libc is |
| installed at /usr: |
| |
| ----------------------------------------------------------------------- |
| *asm: |
| %{V} %{v:%{!V:-V}} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} |
| |
| *asm_final: |
| %| |
| |
| *cpp: |
| %{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} %{!m386:-D__i486__} %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} |
| |
| *cc1: |
| %{profile:-p} |
| |
| *cc1plus: |
| |
| |
| *endfile: |
| %{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s |
| |
| *link: |
| -m elf_i386 %{shared:-shared} %{!shared: %{!ibcs: %{!static: %{rdynamic:-export-dynamic} %{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2}} %{static:-static}}} |
| |
| *lib: |
| %{!shared: %{pthread:-lpthread} %{profile:-lc_p} %{!profile: -lc}} |
| |
| *libgcc: |
| -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} |
| |
| *switches_need_spaces: |
| |
| |
| *signed_char: |
| %{funsigned-char:-D__CHAR_UNSIGNED__} |
| |
| *predefines: |
| -D__ELF__ -Dunix -Di386 -Dlinux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386) |
| |
| *cross_compile: |
| 0 |
| |
| *multilib: |
| . ; |
| |
| ----------------------------------------------------------------------- |
| |
| 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. |
| |
| |
| 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? |
| |
| {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 libc_nonshared.a ) |
| |
| |
| 2.8. How can I compile gcc 2.7.2.1 from the gcc source code using |
| glibc 2.x? |
| |
| {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.8.1 or egcs 1.0.2 (or later versions) |
| instead. |
| |
| |
| 2.9. The `gencat' utility cannot process the catalog sources which |
| were used on my Linux libc5 based system. Why? |
| |
| {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. |
| |
| Here is a simple SED script to convert at least some Linux specific catalog |
| files to the XPG4 form: |
| |
| ----------------------------------------------------------------------- |
| # Change catalog source in Linux specific format to standard XPG format. |
| # Ulrich Drepper <drepper@cygnus.com>, 1996. |
| # |
| /^\$ #/ { |
| h |
| s/\$ #\([^ ]*\).*/\1/ |
| x |
| s/\$ #[^ ]* *\(.*\)/\$ \1/ |
| } |
| |
| /^# / { |
| s/^# \(.*\)/\1/ |
| G |
| s/\(.*\)\n\(.*\)/\2 \1/ |
| } |
| ----------------------------------------------------------------------- |
| |
| |
| 2.10. Programs using libc have their messages translated, but other |
| behavior is not localized (e.g. collating order); why? |
| |
| {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 |
| |
| localedef -i fr_CA -f ISO-8859-1 fr_CA |
| |
| Please see localedata/README in the source tree for further details. |
| |
| |
| 2.11. 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 |
| |
| http://www-vt.uni-paderborn.de/~kukuk/linux/nisplus.html |
| |
| |
| 2.12. I have killed ypbind to stop using NIS, but glibc |
| continues using NIS. |
| |
| {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-glibc3.diff. |
| |
| |
| 2.13. 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. |
| |
| |
| 2.14. 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. |
| |
| |
| 2.15. How do I create the databases for NSS? |
| |
| {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 |
| neccessary 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. |
| |
| |
| 2.16. I have /usr/include/net and /usr/include/scsi as symlinks |
| into my Linux source tree. Is that wrong? |
| |
| {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. |
| |
| |
| 2.17. 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.18. 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. |
| |
| |
| 2.19. 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? |
| |
| {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. |
| |
| 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 a symbol changed size when that should not have happened. |
| So in case of doubt report such a warning message as a problem. |
| |
| |
| 2.20. What do I need for C++ development? |
| |
| {HJ,AJ} You need either egcs 1.0.2 or gcc-2.8.1 with libstdc++ 2.8.1 (or |
| more recent versions). 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. |
| |
| |
| 2.21. 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. |
| |
| |
| 2.22. 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. |
| |
| |
| . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . |
| |
| 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? |
| |
| {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. |
| |
| {MK} There is however a (partial) solution for this problem. Please take a |
| look at the file `login/README.utmpd'. |
| |
| |
| 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. |
| |
| |
| 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: |
| |
| * BSD-style signals that occur in the middle of a system call do not |
| affect the system call; System V signals cause the system call to |
| fail and set errno to EINTR. |
| |
| * BSD signal handlers remain installed once triggered. System V signal |
| handlers work only once, so one must reinstall them each time. |
| |
| * 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 interrupted |
| by other signals. |
| |
| There is general consensus that for `casual' programming with signals, the |
| BSD semantics are preferable. You don't need to worry about system calls |
| returning EINTR, and you don't need to worry about the race conditions |
| associated with one-shot signal handlers. |
| |
| If you are porting an old program that relies on the old semantics, you can |
| quickly fix the problem by changing signal() to sysv_signal() throughout. |
| Alternatively, define _XOPEN_SOURCE before including <signal.h>. |
| |
| 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 |
| siginterrupt(). |
| |
| |
| 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. |
| |
| The optimized string functions are only used when compiling with |
| 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 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 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. |
| |
| One can disable the string optimizations selectively. Instead of writing |
| |
| cp = strcpy (foo, "lkj"); |
| |
| one can write |
| |
| cp = (strcpy) (foo, "lkj"); |
| |
| 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. |
| |
| |
| . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . |
| |
| 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. |
| |
| 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 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. |
| |
| |
| 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 accessable |
| 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. |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| |
| Answers were given by: |
| {UD} Ulrich Drepper, <drepper@cygnus.com> |
| {DMT} David Mosberger-Tang, <davidm@AZStarNet.com> |
| {RM} Roland McGrath, <roland@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> |
| {ZW} Zack Weinberg, <zack@rabi.phys.columbia.edu> |
| {TK} Thorsten Kukuk, <kukuk@vt.uni-paderborn.de> |
| {GK} Geoffrey Keating, <geoffk@ozemail.com.au> |
| {HJ} H.J. Lu, <hjl@gnu.org> |
| |
| Local Variables: |
| mode:outline |
| outline-regexp:"\\?" |
| fill-column:76 |
| End: |