diff options
| -rw-r--r-- | FAQ | 749 | ||||
| -rw-r--r-- | FAQ.in | 722 | ||||
| -rw-r--r-- | linuxthreads/ChangeLog | 5 | ||||
| -rw-r--r-- | linuxthreads/ptlongjmp.c | 8 | ||||
| -rw-r--r-- | manual/install.texi | 22 |
5 files changed, 771 insertions, 735 deletions
@@ -1,14 +1,13 @@ 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. +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. +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. @@ -27,16 +26,18 @@ please let me know. 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. When I run `nm -u libc.so' on the produced library I still +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.9. What are these `add-ons'? -1.10. My XXX kernel emulates a floating-point coprocessor for me. +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.11. When compiling GNU libc I get lots of errors saying functions +1.12. When compiling GNU libc I get lots of errors saying functions in glibc are duplicated in libgcc. -1.12. Why do I get messages about missing thread functions when I use +1.13. Why do I get messages about missing thread functions when I use librt? I don't even use threads. -1.13. What's the problem with configure --enable-omitfp? +1.14. What's the problem with configure --enable-omitfp? 2. Installation and configuration issues @@ -129,12 +130,12 @@ please let me know. 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. +{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: +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 @@ -146,72 +147,73 @@ probably in the future, are: 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. +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 +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. +{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 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). +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). 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. +{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. +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. +{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. +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. +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. +{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). +{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: +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> @@ -264,21 +266,30 @@ Later versions of egcs may fix these problems. 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. +{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. + + +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.8. When I run `nm -u libc.so' on the produced library I still + +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: +{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_* @@ -291,36 +302,35 @@ Generally, you should make sure you find a real program which produces errors while linking before deciding there is a problem. -1.9. What are these `add-ons'? +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). +{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: +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. +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.10. My XXX kernel emulates a floating-point coprocessor for me. +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. +{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 @@ -329,57 +339,56 @@ far more trouble than it's worth: you then have to compile (libgcc.a for GNU C), because the calling conventions change. -1.11. When compiling GNU libc I get lots of errors saying functions +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. +{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. +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. +{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.12. Why do I get messages about missing thread functions when I use +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: +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. +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.13. What's the problem with configure --enable-omitfp? +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. +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. +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. +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. +The compilation of these extra libraries and the compiler optimizations slow +down the build process and need more disk space. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . @@ -388,19 +397,19 @@ slow down the build process and need more disk space. 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. +{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. +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 @@ -408,38 +417,37 @@ links which the linker will use. {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. +/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: +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. +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.) +{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: @@ -463,56 +471,54 @@ 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. +{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. +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. +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. +{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.9). 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. +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. +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. +{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. +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 +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 @@ -524,8 +530,8 @@ In this file you have to change a few things: - 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: +Here is what the gcc-2.7.2 specs file should look like when GNU libc is +installed at /usr: ----------------------------------------------------------------------- *asm: @@ -575,11 +581,11 @@ is installed at /usr: ----------------------------------------------------------------------- -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. +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. @@ -590,11 +596,10 @@ provide the correct specs. 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: +{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 ) @@ -602,26 +607,26 @@ 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. +{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. +{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. @@ -646,10 +651,9 @@ catalog files to the XPG4 form: 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 +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 @@ -659,50 +663,52 @@ 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). +{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. +{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. +{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. +{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. 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. +{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.16. Programs like `logname', `top', `uptime' `users', `w' and @@ -715,15 +721,15 @@ any symlink that you have in place before you install glibc. However, 2.17. 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. +{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. +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.18. When I start the program XXX after upgrading the library @@ -732,48 +738,46 @@ with symbol versioning. 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. +{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. +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. +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.19. 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. +{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.20. Even statically linked programs need some shared libraries which is not acceptable for me. What can I do? -{AJ} NSS (for details just type `info libc "Name Service Switch"') -won't work properly without shared libraries. NSS allows using -different services (e.g. NIS, files, db, hesiod) by just changing one -configuration file (/etc/nsswitch.conf) without relinking any -programs. The only disadvantage is that now static libraries need to -access shared libraries. This is handled transparently by the GNU C -library. +{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: +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 @@ -794,10 +798,10 @@ the behaviour of the programs on the system inconsistent. 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 +{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 @@ -870,28 +874,27 @@ incompatibilities: 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. +{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'. +{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). +{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. +Instead GNU libc contains zone database support and compatibility code for +POSIX TZ environment variable handling. 3.4. The prototypes for `connect', `accept', `getsockopt', @@ -899,50 +902,50 @@ for POSIX TZ environment variable handling. `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. +{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. +{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. +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. +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'. +{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. +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. +{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: @@ -971,35 +974,35 @@ 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 +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 -implemented as inline functions and others as macros. +{AJ} glibc 2.1 has special string functions that are faster than the normal +library functions. Some of the functions are 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: +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. +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. +{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 @@ -1018,16 +1021,15 @@ This disables the optimization for that specific call. {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. +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. +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 @@ -1035,40 +1037,42 @@ problems with the size of the FILE structure. {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). + +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). +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. +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. +{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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . @@ -1086,9 +1090,9 @@ from your favorite mirror of ftp.gnu.org. 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. +{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 @@ -1099,26 +1103,24 @@ required kernel version is at least 2.1.30. 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. +{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. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ @@ -1139,4 +1141,5 @@ Answers were given by: Local Variables: mode:outline outline-regexp:"\\?" + fill-column:76 End: @@ -1,14 +1,13 @@ 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. +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. +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. @@ -19,12 +18,12 @@ please let me know. ?? 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. +{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: +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 @@ -36,68 +35,69 @@ probably in the future, are: 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. +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 +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> ?? 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. +{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 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 ?powerpc). +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 ?powerpc). ?? 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. +{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. +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. ?? 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. +{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. +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. +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. +{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. ??powerpc 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). +{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: +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> @@ -149,20 +149,28 @@ Later versions of egcs may fix these problems. ?? 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. +{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. + +?? 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. ?? 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: +{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_* @@ -176,33 +184,32 @@ errors while linking before deciding there is a problem. ??addon 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 ?crypt). +{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 ?crypt). -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: +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. +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. ?? 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. +{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 @@ -213,107 +220,105 @@ far more trouble than it's worth: you then have to compile ?? 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. +{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. +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. +{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. ?? 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: +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. +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. ?? 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. +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. +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. +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. +The compilation of these extra libraries and the compiler optimizations slow +down the build process and need more disk space. ? Installation and configuration issues ?? 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. +{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. +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. ?? 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 ?safety 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. +/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 ?safety 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: +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. +The first line specifies the directory for the essential libraries, the +second line the directory for system configuration files. ??safety 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.) +{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: @@ -336,54 +341,52 @@ long-time Linux users will remember. ?? 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. +{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. +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 ?string for details. +versions of some string functions. These can only be used with GCC. See +?string for details. ??crypt 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. +{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 ?addon). 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. +The functions are available, as an add-on (see ?addon). 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. +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. ?? 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. +{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. +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 +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 @@ -395,8 +398,8 @@ In this file you have to change a few things: - 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: +Here is what the gcc-2.7.2 specs file should look like when GNU libc is +installed at /usr: ----------------------------------------------------------------------- *asm: @@ -446,11 +449,11 @@ is installed at /usr: ----------------------------------------------------------------------- -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. +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. @@ -460,36 +463,35 @@ provide the correct specs. 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: +{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 ) ?? 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. +{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. ?? 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. +{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. @@ -513,10 +515,9 @@ catalog files to the XPG4 form: 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 +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 @@ -525,47 +526,49 @@ Please see localedata/README in the source tree for further details. ?? 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). +{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 ?? 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. +{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. ?? 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. +{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. ?? 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. +{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. ?? 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 ?kerhdr). 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. +{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 ?kerhdr). 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. ?? Programs like `logname', `top', `uptime' `users', `w' and `who', show incorrect information about the (number of) @@ -576,15 +579,15 @@ any symlink that you have in place before you install glibc. However, ?? 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. +{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. +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. ?? When I start the program XXX after upgrading the library I get @@ -592,46 +595,44 @@ with symbol versioning. 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. +{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. +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. +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. ?? 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. +{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. ?? 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. +{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: +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 @@ -649,10 +650,10 @@ the behaviour of the programs on the system inconsistent. ?? 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 +{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 @@ -724,74 +725,73 @@ incompatibilities: ??getlog 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. +{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'. +{MK} There is however a (partial) solution for this problem. Please take a +look at the file `login/README.utmpd'. ?? 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). +{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. +Instead GNU libc contains zone database support and compatibility code for +POSIX TZ environment variable handling. ?? 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. +{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. ??kerhdr 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. +{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. +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. +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. ?? 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'. +{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. +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. ??signal 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. +{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: @@ -820,35 +820,35 @@ 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 +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(). ??string 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 -implemented as inline functions and others as macros. +{AJ} glibc 2.1 has special string functions that are faster than the normal +library functions. Some of the functions are 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: +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. +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. +{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 @@ -866,16 +866,15 @@ This disables the optimization for that specific call. {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. +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. +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. ?? I can't compile with gcc -traditional (or @@ -883,38 +882,40 @@ problems with the size of the FILE structure. {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). + +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). ?? 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). +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. +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. ?? 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. +{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. ? Miscellaneous @@ -929,9 +930,9 @@ from your favorite mirror of ftp.gnu.org. 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. +{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 @@ -941,26 +942,24 @@ required kernel version is at least 2.1.30. 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. +{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. Answers were given by: @@ -979,4 +978,5 @@ Answers were given by: Local Variables: mode:outline outline-regexp:"\\?" + fill-column:76 End: diff --git a/linuxthreads/ChangeLog b/linuxthreads/ChangeLog index ba2a20f4d0..0d276a9aba 100644 --- a/linuxthreads/ChangeLog +++ b/linuxthreads/ChangeLog @@ -1,3 +1,8 @@ +1998-04-21 Ulrich Drepper <drepper@cygnus.com> + + * ptlongjmp.c: Add prorotypes for __libc_siglongjmp and + __libc_longjmp. + 1998-04-20 14:55 Ulrich Drepper <drepper@cygnus.com> * Makefile (libpthread-routines): Add ptlongjmp and spinlock. diff --git a/linuxthreads/ptlongjmp.c b/linuxthreads/ptlongjmp.c index 1397dba43a..c5704f9e9a 100644 --- a/linuxthreads/ptlongjmp.c +++ b/linuxthreads/ptlongjmp.c @@ -19,6 +19,14 @@ #include "pthread.h" #include "internals.h" +/* These functions are not declared anywhere since they shouldn't be + used at another place but here. */ +extern void __libc_siglongjmp (sigjmp_buf env, int val) + __attribute__ ((noreturn)); +extern void __libc_longjmp (sigjmp_buf env, int val) + __attribute__ ((noreturn)); + + static void pthread_cleanup_upto(__jmp_buf target) { pthread_descr self = thread_self(); diff --git a/manual/install.texi b/manual/install.texi index f57bb17d71..716c2b9f46 100644 --- a/manual/install.texi +++ b/manual/install.texi @@ -103,6 +103,20 @@ sources. To use them, unpack them into your source tree, and give If you do not wish to use some add-on package that you have present in your source tree, give this option a list of the add-ons that you @emph{do} want used, like this: @samp{--enable-add-ons=crypt,linuxthreads} + +@item --with-headers=DIRECTORY +Search only DIRECTORY and the C compiler's private directory for header +files not found in the libc sources. @file{/usr/include} will not be +searched if this option is given. On Linux, DIRECTORY should be the +kernel's private include directory (usually +@file{/usr/src/linux/include}). + +This option is primarily of use on a system where the headers in +@file{/usr/include} come from an older version of glibc. Conflicts can +occasionally happen in this case. Note that Linux libc5 qualifies as an +older version of glibc. You can also use this option if you want to +compile glibc with a newer set of kernel headers than the ones found in +@file{/usr/include}. @end table You should not build the library in the same directory as the sources, @@ -150,12 +164,18 @@ Some of the machine-dependent code for some machines uses extensions in the GNU C compiler, so you may need to compile the library with GCC. (In fact, all of the existing complete ports require GCC.) - To build the library and related programs, type @code{make}. This will produce a lot of output, some of which may look like errors from @code{make} (but isn't). Look for error messages from @code{make} containing @samp{***}. Those indicate that something is really wrong. +The compilation process takes several hours even on fast hardware; +expect at least two hours for the default configuration on i586 for +Linux. For Hurd times are much longer. All current releases of GCC +have a problem which causes them to take several minutes to compile +certain files in the iconvdata directory. Do not panic if the compiler +appears to hang. + To build and run some test programs which exercise some of the library facilities, type @code{make check}. This will produce several files with names like @file{@var{program}.out}. |