- Frequently Asked Question on GNU C Library
+ Frequently Asked Questions about the GNU C Library
-As every FAQ this one also tries to answer questions the user might have
-when using the package. Please make sure you read this before sending
-questions or bug reports to the maintainers.
+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 building process exploits the
-features available in tools generally available. But many things can
-only be done using GNU tools. Also the code is sometimes hard to
-understand because it has to be portable but on the other hand must be
-fast. But you need not understand the details to use GNU C Library.
-This will only be necessary if you intend to contribute or change it.
+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
\f
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q1] ``What systems does the GNU C Library run on?''
+~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
+
+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?
+
+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?
+
+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.
-[Q2] ``What compiler do I need to build GNU libc?''
+\f
+~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q3] ``When starting make I get only error messages.
- What's wrong?''
+1. Compiling glibc
-[Q4] ``After I changed configure.in I get `Autoconf version X.Y.
- or higher is required for this script'. What can I do?''
+1.1. What systems does the GNU C Library run on?
-[Q5] ``Do I need a special linker or archiver?''
+{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.
-[Q6] ``Do I need some more things to compile GNU C Library?''
+The systems glibc is known to work on as of this release, and most probably
+in the future, are:
-[Q7] ``When I run `nm -u libc.so' on the produced library I still
- find unresolved symbols? Can this be ok?''
+ *-*-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
-[Q8] ``Can I replace the libc on my Linux system with GNU libc?''
+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.
-[Q9] ``I expect GNU libc to be 100% source code compatible with
- the old Linux based GNU libc. Why isn't it like this?''
+If you have a system not listed above (or in the `README' file) and you are
+really interested in porting it, contact
-[Q10] ``Why does getlogin() always return NULL on my Linux box?''
+ <bug-glibc@gnu.org>
-[Q11] ``Where are the DST_* constants found in <sys/time.h> on many
- systems?''
-[Q12] ``The `gencat' utility cannot process the input which are
- successfully used on my Linux libc based system. Why?''
+1.2. What compiler do I need to build GNU libc?
-[Q13] ``How do I configure GNU libc so that the essential libraries
- like libc.so go into /lib and the other into /usr/lib?''
-\f
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q1] ``What systems does the GNU C Library run on?''
+{UD} You must use GNU CC to compile GNU libc. A lot of extensions of GNU CC
+are used to increase portability and speed.
-[A1] {UD} This is difficult to answer. The file `README' lists the
-architectures GNU libc is known to run *at some time*. This does not
-mean that it still can be compiled and run on them in the moment.
+GNU CC is found, like all other GNU packages, on
-The systems glibc is known to work on in the moment and most probably
-in the future are:
+ ftp://ftp.gnu.org/pub/gnu
- *-*-gnu GNU Hurd
- i[3456]86-*-linux Linux-2.0 on Intel
- m68k-*-linux Linux-2.0 on Motorola 680x0
- alpha-*-linux Linux-2.0 on DEC Alpha
+and the many mirror sites. ftp.gnu.org is always overloaded, so try to find
+a local mirror first.
-Other Linux platforms are also on the way to be supported but I need
-some success reports first.
+You always should 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).
-If you have a system not listed above (or in the `README' file) and
-you are really interested in porting it, contact
- <bug-glibc@prep.ai.mit.edu>
+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.
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q2] ``What compiler do I need to build GNU libc?''
+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.
-[A2] {UD} It is (almost) impossible to compile GNU C Library using a
-different compiler than GNU CC. A lot of extensions of GNU CC are
-used to increase the portability and speed.
-But this does not mean you have to use GNU CC for using the GNU C
-Library. In fact you should be able to use the native C compiler
-because the success only depends on the binutils: the linker and
-archiver.
+1.4. Do I need a special linker or archiver?
-The GNU CC is found like all other GNU packages on
- ftp://prep.ai.mit.edu/pub/gnu
-or better one of the many mirror sites.
+{UD} You may be able to use your system linker, but GNU libc works best with
+GNU binutils.
-You always should try to use the latest official release. Older
-versions might not have all the features GNU libc could use.
+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.
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q3] ``When starting `make' I get only errors messages.
- What's wrong?''
+{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.
-[A3] {UD} You definitely need GNU make to translate GNU libc. No
-other make program has the needed functionality.
-Versions before 3.74 have bugs which prevent correct execution so you
-should upgrade to the latest version before starting the compilation.
+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).
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q4] ``After I changed configure.in I get `Autoconf version X.Y.
- or higher is required for this script'. What can I do?''
+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:
-[A4] {UD} You have to get the specified autoconf version (or a later)
-from your favourite mirror of prep.ai.mit.edu.
+<http://discus.anu.edu.au/~geoffk/egcs-1.0.1-geoffk.diff>
+Later versions of egcs may fix these problems.
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q5] ``Do I need a special linker or archiver?''
-[A5] {UD} If your native versions are not too buggy you can probably
-work with them. But GNU libc works best with GNU binutils.
+1.6. Do I need some more things to compile GNU C Library?
-On systems where the native linker does not support weak symbols you
-will not get a really 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.
+{UD} Yes, there are some more :-).
-Always get the newest release of GNU binutils available.
-Older releases are known to have bugs that affect building the GNU C
-Library.
+* 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.
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q6] ``Do I need some more things to compile GNU C Library?''
+ You should not need these tools unless you change the source files.
-[A6] {UD} Yes, there are some more :-).
+* 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).
-* GNU gettext; the GNU libc is internationalized and partly localized.
- For bringing the messages for the different languages in the needed
- form the tools from the GNU gettext package are necessary. See
- ftp://prep.ai.mit.edu/pub/gnu or better any mirror site.
+* 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 diskspace (for i?86-linux this means, e.g., ~70MB).
+* lots of disk space (~170MB for i?86-linux; more for RISC platforms,
+ as much as 400MB).
- You should avoid compiling on a NFS mounted device. This is very
- slow.
+* 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.
-* plenty of time (approx 1h for i?86-linux on i586@133 or 2.5h on
- i486@66 or 4.5h on i486@33).
+ 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.
-* 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.
-* When compiling for Linux:
+1.7. What version of the Linux kernel headers should be used?
- + the header files of the Linux kernel must be available in the
- search path of the CPP as <linux/*.h> and <asm/*.h>.
+{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.
-* 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.
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q7] ``When I run `nm -u libc.so' on the produced library I still
- find unresolved symbols? Can this be ok?''
+1.8. The compiler hangs while building iconvdata modules. What's
+ wrong?
-[A7] {UD} Yes, this is ok. There can be several kinds of unresolved
-symbols:
+{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.
-* magic symbols automatically generated by the linker. Names are
- often like __start_* and __stop_*
+The problem will be fixed in egcs 1.1 but probably not before then.
-* symbols starting with _dl_* come from the dynamic linker
-* symbols resolved by using libgcc.a
- (__udivdi3, __umoddi3, or similar)
+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_*
-* weak symbols, which need not be resolved at all
- (currently fabs among others; this gets resolved if the program
- is linked against libm, too.)
+* 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.
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q8] ``Can I replace the libc on my Linux system with GNU libc?''
+1.10. What are these `add-ons'?
-[A8] {UD} You cannot replace any existing libc for Linux with GNU
-libc. There are different versions of C libraries and you can run
-libcs with different major version independently.
+{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).
-For Linux there are today two libc versions:
- libc-4 old a.out libc
- libc-5 current ELF libc
+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:
-GNU libc will have the major number 6 and therefore you can have this
-additionally 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.
+ configure --enable-add-ons=crypt,linuxthreads
+for example.
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q9] ``I expect GNU libc to be 100% source code compatible with
- the old Linux based GNU libc. Why isn't it like this?''
+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.
-[A9] {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 now can be corrected. Here is a list of the known source code
-incompatibilities:
-* _GNU_SOURCE: glibc does not automatically define _GNU_SOURCE. Thus,
- if a program depends on GNU extensions or some other non-standard
- functionality, it is necessary to compile it with 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.
+1.11. My XXX kernel emulates a floating-point coprocessor for me.
+ Should I enable --with-fp?
- For more information consult the file `NOTES' part of the GNU C
- library sources.
+{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.
-* reboot(): GNU libc sanitizes the interface of reboot() to be more
- compatible with the interface used on other OSes. In particular,
- 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 changed, but the
- prototype is in a separate header file <sys/swap.h>. For the additional
- argument of of swapon() you should use the SWAP_* constants from
- <linux/swap.h>, which get defined when <sys/swap.h> is included.
-
-* errno: If a program uses variable "errno", then it _must_ include header
- file <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 the references of the undeclared symbol "errno".
+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.
-* 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 tables 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>
- create_module create_module <sys/module.h>
- delete_module delete_module <sys/module.h>
- get_kernel_syms get_kernel_syms <sys/module.h>
- init_module init_module <sys/module.h>
- syslog ksyslog_ctl <sys/klog.h>
+1.12. When compiling GNU libc I get lots of errors saying functions
+ in glibc are duplicated in libgcc.
-* 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 interfaces. Simply
- upgrading to a newer lpd should fix this problem (e.g., the 4.4BSD
- lpd is known to be working).
+{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.
-* resolver functions/BIND: like on many other systems the functions of
- the resolver library are not included in the libc itself. There is
- a separate library libresolv. If you find some symbols starting with
- `res_*' undefined simply add -lresolv to your call of the linker.
+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.
+
+\f
+. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
+
+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.)
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q10] ``Why does getlogin() always return NULL on my Linux box?''
+The dangers when installing glibc in /usr are twofold:
-[A10] {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. So the
-record size is different, fields might have a different position and
-so reading 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.
+* 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.
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q11] ``Where are the DST_* constants found in <sys/time.h> on many
- systems?''
+The situation is rather similar to the move from a.out to ELF which
+long-time Linux users will remember.
-[A11] {UD} These constants come from the old BSD days and are not used
-today anymore (even the Linux based glibc does not implement the handling
-although the constants are defined).
-Instead GNU libc contains the zone database handling and compatibility
-code for POSIX TZ environment variable handling.
+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.
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q12] ``The `gencat' utility cannot process the input which are
- successfully used on my Linux libc based system. Why?''
+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.
-[A12] {UD} Unlike the author of the `gencat' program which is distributed
-with Linux libc I have read the underlying standards before writing the
-code. It is completely compatible with the specification given in
-X/Open Portability Guide.
+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
+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:
+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.
-----------------------------------------------------------------------
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q13] ``How do I configure GNU libc so that the essential libraries
- like libc.so go into /lib and the other into /usr/lib?''
+2.10. Programs using libc have their messages translated, but other
+ behavior is not localized (e.g. collating order); why?
-[A13] {UD} Like all other GNU packages GNU libc is configured to use a
-base directory and install all files relative to this. If you intend
-to really use GNU libc on your system this base directory is /usr. I.e.,
-you run
- configure --prefix=/usr <other_options>
+{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
-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.
+ localedef -i fr_CA -f ISO-8859-1 fr_CA
-To install the essential libraries which come with GNU libc in /lib
-one must explicitly tell this. Autoconf has no option for this so you
-have to use the file where all user supplied additional information
-should go in: `configparms' (see the `INSTALL' file). For Linux the
-`configparms' file should contain:
+Please see localedata/README in the source tree for further details.
-slibdir=/lib
-sysconfdir=/etc
-The first line specifies the directory for the essential libraries,
-the second line the directory for file which are by tradition placed
-in a directory named /etc.
+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.
+
+\f
+. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
+
+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.
+
+
+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.
+
\f
+. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
+
+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.
+
+\f
+~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
+
Answers were given by:
{UD} Ulrich Drepper, <drepper@cygnus.com>
{DMT} David Mosberger-Tang, <davidm@AZStarNet.com>
-
-Amended by:
-{RM} Roland McGrath, <roland@gnu.ai.mit.edu>
+{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>
\f
Local Variables:
- mode:text
+ mode:outline
+ outline-regexp:"\\?"
+ fill-column:76
End:
projects / kopensolaris-gnu / glibc.git / blobdiff