diff options
| -rw-r--r-- | ChangeLog | 70 | ||||
| -rw-r--r-- | FAQ | 1167 | ||||
| -rw-r--r-- | FAQ.in | 787 | ||||
| -rw-r--r-- | Makeconfig | 2 | ||||
| -rw-r--r-- | Makefile | 2 | ||||
| -rwxr-xr-x | configure | 143 | ||||
| -rw-r--r-- | configure.in | 9 | ||||
| -rwxr-xr-x | gen-FAQ.pl | 144 | ||||
| -rw-r--r-- | iconvdata/Makefile | 8 | ||||
| -rw-r--r-- | rt/librt.map | 11 | ||||
| -rw-r--r-- | string/bits/string2.h | 8 | ||||
| -rw-r--r-- | string/string.h | 10 | ||||
| -rw-r--r-- | sunrpc/xcrypt.c | 2 | ||||
| -rw-r--r-- | sysdeps/generic/enbl-secure.c | 2 | ||||
| -rw-r--r-- | sysdeps/unix/sysv/linux/bits/socket.h | 18 | ||||
| -rw-r--r-- | sysdeps/unix/sysv/linux/i386/s_pread64.S | 45 | ||||
| -rw-r--r-- | sysdeps/unix/sysv/linux/i386/s_pwrite64.S | 45 | ||||
| -rw-r--r-- | sysdeps/unix/sysv/linux/i386/sigaction.c | 4 | ||||
| -rw-r--r-- | sysdeps/unix/sysv/linux/rt_sigprocmask.c | 2 | ||||
| -rw-r--r-- | sysdeps/unix/sysv/linux/rt_sigqueueinfo.c | 1 | ||||
| -rw-r--r-- | sysdeps/unix/sysv/linux/rt_sigsuspend.c | 2 | ||||
| -rw-r--r-- | sysdeps/unix/sysv/linux/sigreturn.c | 1 | ||||
| -rw-r--r-- | sysdeps/unix/sysv/linux/sys/pci.h | 2 | ||||
| -rw-r--r-- | sysdeps/wordsize-32/bits/environments.h | 7 | ||||
| -rw-r--r-- | sysdeps/wordsize-64/bits/environments.h | 11 |
25 files changed, 1807 insertions, 696 deletions
@@ -1,3 +1,73 @@ +1997-12-05 00:01 Ulrich Drepper <drepper@cygnus.com> + + The kernel expects the arguments in a different order. + * sysdeps/unix/sysv/linux/i386/s_pread64.S: New file. + * sysdeps/unix/sysv/linux/i386/s_pwrite64.S: New file. + + * FAQ.in: New file. + * gen-FAQ.pl: New file. + * Makefile (FAQ): Add rule to generate from FAQ.in. + + * iconvdata/Makefile: Treat libJIS like the other modules. + + * rt/librt.map: New file. + + * sysdeps/wordsize-32/bits/environments.h: Add test for direct + inclusion. + * sysdeps/wordsize-64/bits/environments.h: Likewise. Correct + comment. + +1997-12-04 22:29 Ulrich Drepper <drepper@cygnus.com> + + * sysdeps/unix/sysv/linux/rt_sigprocmask.c: Fix prototype. + * sysdeps/unix/sysv/linux/rt_sigsuspend.c: Likewise. + * sysdeps/unix/sysv/linux/rt_sigqueueinfo.c: Include <sys/types.h>. + Patches by Thorsten Kukuk <kukuk@weber.uni-paderborn.de>. + +1997-11-27 Andreas Jaeger <aj@arthur.rhein-neckar.de> + + * string/bits/string2.h: Fix spellings. + + * string/string.h: Fix spellings. + +1997-12-04 Andreas Jaeger <aj@arthur.rhein-neckar.de> + + * sysdeps/unix/sysv/linux/i386/sigaction.c: Rename extern + declaration to __syscall_rt_sigaction. + + * sysdeps/unix/sysv/linux/sigreturn.c: Remove inclusion of + non-existant <sigcontext.h>. + +1997-12-04 Andreas Jaeger <aj@arthur.rhein-neckar.de> + + * sysdeps/generic/enbl-secure.c (__libc_init_secure): Correct + typo. + +1997-12-04 Andreas Jaeger <aj@arthur.rhein-neckar.de> + + * sysdeps/wordsize-64/bits/environments.h: Correct spelling. + + * Makeconfig (shared-thread-library): Correct spelling. + + * sysdeps/unix/sysv/linux/sys/pci.h: Include <linux/pci.h> and not + <asm/pci.h>. + +1997-12-04 Andreas Jaeger <aj@arthur.rhein-neckar.de> + + * sysdeps/unix/sysv/linux/bits/socket.h: Add AF_* and PF_ + constants from Linux headers. Pointed out by + csmall@scooter.o.i.net. [PR libc/369] + +1997-12-04 10:21 Thorsten Kukuk <kukuk@vt.uni-paderborn.de> + + * sunrpc/xcrypt.c: Fix lower/upper characters in optimized hexval. + +1997-12-04 00:06 Zack Weinberg <zack@rabi.phys.columbia.edu> + + * configure.in: If --enable-add-ons is given without an + argument, set the addons list to all subdirs with a configure + script. + 1997-12-03 23:50 Ulrich Drepper <drepper@cygnus.com> * Makeconfig: Add shared-thread-library variable. @@ -1,131 +1,117 @@ - Frequently Asked Question on GNU C Library + Frequently Asked Questions about the GNU C Library -As every FAQ this one also tries to answer questions the user might have -when using the package. Please make sure you read this before sending -questions or bug reports to the maintainers. +This document tries to answer questions a user might have when +installing and using glibc. Please make sure you read this before +sending questions or bug reports to the maintainers. -The GNU C Library is very complex. The building process exploits the -features available in tools generally available. But many things can -only be done using GNU tools. Also the code is sometimes hard to -understand because it has to be portable but on the other hand must be -fast. But you need not understand the details to use GNU C Library. -This will only be necessary if you intend to contribute or change it. +The GNU C library is very complex. The installation process has not +been completely automated; there are too many variables. You can do +substantial damage to your system by installing the library +incorrectly. Make sure you understand what you are undertaking before +you begin. If you have any questions you think should be answered in this document, please let me know. --drepper@cygnus.com -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q1] ``What systems does the GNU C Library run on?'' +~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ + +1. Compiling glibc + +1.1. What systems does the GNU C Library run on? +1.2. What compiler do I need to build GNU libc? +1.3. When I try to compile glibc I get only error messages. + What's wrong? +1.4. Do I need a special linker or archiver? +1.5. Do I need some more things to compile GNU C Library? +1.6. When I run `nm -u libc.so' on the produced library I still + find unresolved symbols. Can this be ok? +1.7. What are these `add-ons'? +1.8. My XXX kernel emulates a floating-point coprocessor for me. + Should I enable --with-fp? +1.9. When compiling GNU libc I get lots of errors saying functions + in glibc are duplicated in libgcc. +1.10. What's the problem with configure --enable-omitfp? + +2. Installation and configuration issues + +2.1. Can I replace the libc on my Linux system with GNU libc? +2.2. How do I configure GNU libc so that the essential libraries + like libc.so go into /lib and the other into /usr/lib? +2.3. How should I avoid damaging my system when I install GNU libc? +2.4. Do I need to use GNU CC to compile programs that will use the + GNU C Library? +2.5. When linking with the new libc I get unresolved symbols + `crypt' and `setkey'. Why aren't these functions in the + libc anymore? +2.6. When I use GNU libc on my Linux system by linking against + the libc.so which comes with glibc all I get is a core dump. +2.7. Looking through the shared libc file I haven't found the + functions `stat', `lstat', `fstat', and `mknod' and while + linking on my Linux system I get error messages. How is + this supposed to work? +2.8. How can I compile gcc 2.7.2.1 from the gcc source code using + glibc 2.x? +2.9. The `gencat' utility cannot process the catalog sources which + were used on my Linux libc5 based system. Why? +2.10. I have set up /etc/nis.conf, and the Linux libc 5 with NYS + works great. But the glibc NIS+ doesn't seem to work. +2.11. After installing glibc name resolving doesn't work properly. +2.12. I have /usr/include/net and /usr/include/scsi as symlinks + into my Linux source tree. Is that wrong? +2.13. Programs like `logname', `top', `uptime' `users', `w' and + `who', show incorrect information about the (number of) + users on my system. Why? +2.14. After upgrading to glibc 2.1 with symbol versioning I get + errors about undefined symbols. What went wrong? +2.15. When I start the program XXX after upgrading the library + I get + XXX: Symbol `_sys_errlist' has different size in shared + object, consider re-linking + Why? What should I do? + +3. Source and binary incompatibilities, and what to do about them + +3.1. I expect GNU libc to be 100% source code compatible with + the old Linux based GNU libc. Why isn't it like this? +3.2. Why does getlogin() always return NULL on my Linux box? +3.3. Where are the DST_* constants found in <sys/time.h> on many + systems? +3.4. The prototypes for `connect', `accept', `getsockopt', + `setsockopt', `getsockname', `getpeername', `send', + `sendto', and `recvfrom' are different in GNU libc from + any other system I saw. This is a bug, isn't it? +3.5. On Linux I've got problems with the declarations in Linux + kernel headers. +3.6. I don't include any kernel headers myself but the compiler + still complains about redeclarations of types in the kernel + headers. +3.7. Why don't signals interrupt system calls anymore? +3.8. I've got errors compiling code that uses certain string + functions. Why? + +4. Miscellaneous + +4.1. After I changed configure.in I get `Autoconf version X.Y. + or higher is required for this script'. What can I do? +4.2. When I try to compile code which uses IPv6 headers and + definitions on my Linux 2.x.y system I am in trouble. + Nothing seems to work. -[Q2] ``What compiler do I need to build GNU libc?'' - -[Q3] ``When starting make I get only error messages. - What's wrong?'' - -[Q4] ``After I changed configure.in I get `Autoconf version X.Y. - or higher is required for this script'. What can I do?'' - -[Q5] ``Do I need a special linker or archiver?'' - -[Q6] ``Do I need some more things to compile GNU C Library?'' - -[Q7] ``When I run `nm -u libc.so' on the produced library I still - find unresolved symbols? Can this be ok?'' - -[Q8] ``Can I replace the libc on my Linux system with GNU libc?'' - -[Q9] ``I expect GNU libc to be 100% source code compatible with - the old Linux based GNU libc. Why isn't it like this?'' - -[Q10] ``Why does getlogin() always return NULL on my Linux box?'' - -[Q11] ``Where are the DST_* constants found in <sys/time.h> on many - systems?'' - -[Q12] ``The `gencat' utility cannot process the input which are - successfully used on my Linux libc based system. Why?'' - -[Q13] ``How do I configure GNU libc so that the essential libraries - like libc.so go into /lib and the other into /usr/lib?'' - -[Q14] ``When linking with the new libc I get unresolved symbols - `crypt' and `setkey'. Why aren't these functions in the - libc anymore?'' - -[Q15] ``What are these `add-ons'?'' - -[Q16] ``When I use GNU libc on my Linux system by linking against - to libc.so which comes with glibc all I get is a core dump.'' - -[Q17] ``Looking through the shared libc file I haven't found the - functions `stat', `lstat', `fstat', and `mknod' and while - linking on my Linux system I get error messages. How is - this supposed to work?'' - -[Q18] ``The prototypes for `connect', `accept', `getsockopt', - `setsockopt', `getsockname', `getpeername', `send', - `sendto', and `recvfrom' are different in GNU libc than - on any other system I saw. This is a bug, isn't it?'' - -[Q19] ``My XXX kernel emulates a floating-point coprocessor for me. - Should I enable --with-fp?'' - -[Q20] ``How can I compile gcc 2.7.2.1 from the gcc source code using - glibc 2.x? - -[Q21] ``On Linux I've got problems with the declarations in Linux - kernel headers.'' - -[Q22] ``When I try to compile code which uses IPv6 header and - definitions on my Linux 2.x.y system I am in trouble. - Nothing seems to work.'' - -[Q23] ``When compiling GNU libc I get lots of errors saying functions - in glibc are duplicated in libgcc.'' - -[Q24] ``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.'' - -[Q25] ``After installing glibc name resolving doesn't work properly.'' - - -[Q26] ``I have /usr/include/net and /usr/include/scsi as symlinks - into my Linux source tree. Is that wrong?'' - -[Q27] ``Programs like `logname', `top', `uptime' `users', `w' and - `who', show incorrect information about the (number of) - users on my system. Why?'' - -[Q28] ``After upgrading to a glibc 2.1 with symbol versioning I get - errors about undefined symbols. What went wrong?'' - -[Q29] ``I don't include any kernel header myself but still the - compiler complains about type redeclarations of types in the - kernel headers.'' - -[Q30] ``When I start the program XXX after upgrading the library - I get - XXX: Symbol `_sys_errlist' has different size in shared object, consider re-linking - Why? What to do?'' - -[Q31] ``What's the problem with configure --enable-omitfp?'' + +~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q32] ``Why don't signals interrupt system calls anymore?'' +1. Compiling glibc -[Q33] ``I've got errors compiling code that uses certain string - functions. Why?'' - -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q1] ``What systems does the GNU C Library run on?'' +1.1. What systems does the GNU C Library run on? -[A1] {UD} This is difficult to answer. The file `README' lists the -architectures GNU libc is known to run *at some time*. This does not -mean that it still can be compiled and run on them in the moment. +{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 in the moment 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.0 on Intel @@ -135,8 +121,10 @@ in the future are: sparc-*-linux-gnu Linux-2.0 on SPARC sparc64-*-linux-gnu Linux-2.0 on UltraSPARC -Other Linux platforms are also on the way to be supported but I need -some success reports first. +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 @@ -144,389 +132,312 @@ you are really interested in porting it, contact <bug-glibc@prep.ai.mit.edu> -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q2] ``What compiler do I need to build GNU libc?'' +1.2. What compiler do I need to build GNU libc? -[A2] {UD} It is (almost) impossible to compile GNU C Library using a -different compiler than GNU CC. A lot of extensions of GNU CC are -used to increase the portability and speed. +{UD} You must use GNU CC to compile GNU libc. A lot of extensions of +GNU CC are used to increase portability and speed. -But this does not mean you have to use GNU CC for using the GNU C -Library. In fact you should be able to use the native C compiler -because the success only depends on the binutils: the linker and -archiver. - -The GNU CC is found like all other GNU packages on +GNU CC is found, like all other GNU packages, on ftp://prep.ai.mit.edu/pub/gnu -or better one of the many mirror sites. +and the many mirror sites. prep is always overloaded, so try to find +a local mirror first. You always should try to use the latest official release. Older -versions might not have all the features GNU libc could use. It is -known that on most platforms compilers earlier than 2.7.2.3 fail so -at least use this version. +versions may not have all the features GNU libc requires. On most +supported platforms, 2.7.2.3 is the earliest version that works at all. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q3] ``When starting `make' I get only errors messages. - What's wrong?'' +1.3. When I try to compile glibc I get only error messages. + What's wrong? -[A3] {UD} You definitely need GNU make to translate GNU libc. No +{UD} You definitely need GNU make to translate GNU libc. No other make program has the needed functionality. -Versions before 3.74 have bugs which prevent correct execution so you -should upgrade to the latest version before starting the compilation. - -We recommend version GNU make version 3.75. Versions 3.76 and -3.76.1 are known to have bugs which only show up in big projects like -GNU libc. +We recommend version GNU make version 3.75. Versions 3.76 and 3.76.1 +have bugs which appear when building big projects like GNU libc. +Versions before 3.74 have bugs and/or are missing features. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q4] ``After I changed configure.in I get `Autoconf version X.Y. - or higher is required for this script'. What can I do?'' +1.4. Do I need a special linker or archiver? -[A4] {UD} You have to get the specified autoconf version (or a later) -from your favourite mirror of prep.ai.mit.edu. - - -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q5] ``Do I need a special linker or archiver?'' - -[A5] {UD} If your native versions are not too buggy you can probably -work with them. But GNU libc works best with GNU binutils. +{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 really ISO C compliant C library. Generally speaking +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 affect building the GNU C -Library. +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.17 or later. Other systems +may have native linker support, but it's moot right now, because glibc +has not been ported to them. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q6] ``Do I need some more things to compile GNU C Library?'' -[A6] {UD} Yes, there are some more :-). +1.5. Do I need some more things to compile GNU C Library? -* GNU gettext; the GNU libc is internationalized and partly localized. - For bringing the messages for the different languages in the needed - form the tools from the GNU gettext package are necessary. See - ftp://prep.ai.mit.edu/pub/gnu or better any mirror site. +{UD} Yes, there are some more :-). -* lots of diskspace (for i?86-linux this means, e.g., ~170MB; for ppc-linux - even ~200MB). +* GNU gettext. This package contains the tools needed to construct + `message catalog' files containing translated versions of system + messages. See ftp://prep.ai.mit.edu/pub/gnu or better any mirror + site. (We distribute compiled message catalogs, but they may not be + updated in patches.) - You should avoid compiling on a NFS mounted device. This is very - slow. +* Some files depend on special tools. E.g., files ending in .gperf + need a `gperf' program. The GNU version (part of libg++) is known + to work while some vendor versions do not. -* plenty of time (approx 1h for i?86-linux on i586@133 or 2.5h on - i486@66 or 4.5h on i486@33), both for shared and static only). - Multiply this by 1.5 or 2.0 if you build profiling and/or the highly - optimized version as well. For Hurd systems times are much higher. + You should not need these tools unless you change the source files. - For Atari Falcon (Motorola 68030 @ 16 Mhz, 14 Mb memory) James Troup - <J.J.Troup@comp.brad.ac.uk> reports for a full build (shared, static, - and profiled) a compile time of 45h34m. +* When compiling for Linux, the header files of the Linux kernel must + be available to the compiler as <linux/*.h> and <asm/*.h>. - For Atari TT030 (Motorola 68030 @ 32 Mhz, 34 Mb memory) (full build) - a compile time of 22h48m. +* lots of disk space (~170MB for i?86-linux; more for RISC platforms). - If you have some more measurements let me know. +* plenty of time. Compiling just the shared and static libraries for + i?86-linux takes approximately 1h on an i586@133, or 2.5h on + i486@66, or 4.5h on i486@33. Multiply this by 1.5 or 2.0 if you + build profiling and/or the highly optimized version as well. For + Hurd systems times are much higher. -* When compiling for Linux: + You should avoid compiling in a NFS mounted filesystem. This is + very slow. - + the header files of the Linux kernel must be available in the - search path of the CPP as <linux/*.h> and <asm/*.h>. + James Troup <J.J.Troup@comp.brad.ac.uk> reports a compile time of + 45h34m for a full build (shared, static, and profiled) on + Atari Falcon (Motorola 68030 @ 16 Mhz, 14 Mb memory) and 22h48m + on Atari TT030 (Motorola 68030 @ 32 Mhz, 34 Mb memory) -* Some files depend on special tools. E.g., files ending in .gperf - need a `gperf' program. The GNU version (part of libg++) is known - to work while some vendor versions do not. + If you have some more measurements let me know. - You should not need these tools unless you change the source files. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q7] ``When I run `nm -u libc.so' on the produced library I still - find unresolved symbols? Can this be ok?'' +1.6. When I run `nm -u libc.so' on the produced library I still + find unresolved symbols. Can this be ok? -[A7] {UD} Yes, this is ok. There can be several kinds of unresolved +{UD} Yes, this is ok. There can be several kinds of unresolved symbols: -* magic symbols automatically generated by the linker. Names are - often like __start_* and __stop_* +* magic symbols automatically generated by the linker. These have names + like __start_* and __stop_* * symbols starting with _dl_* come from the dynamic linker * symbols resolved by using libgcc.a (__udivdi3, __umoddi3, or similar) -* weak symbols, which need not be resolved at all - (currently fabs among others; this gets resolved if the program - is linked against libm, too.) +* weak symbols, which need not be resolved at all (fabs for example) Generally, you should make sure you find a real program which produces errors while linking before deciding there is a problem. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q8] ``Can I replace the libc on my Linux system with GNU libc?'' - -[A8] {UD} You cannot replace any existing libc for Linux with GNU -libc. There are different versions of C libraries and you can run -libcs with different major version independently. - -For Linux there are today two libc versions: - libc-4 old a.out libc - libc-5 current ELF libc - -GNU libc will have the major number 6 and therefore you can have this -additionally installed. For more information consult documentation for -shared library handling. The Makefiles of GNU libc will automatically -generate the needed symbolic links which the linker will use. +1.7. 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). -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q9] ``I expect GNU libc to be 100% source code compatible with - the old Linux based GNU libc. Why isn't it like this?'' +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: -[A9] {DMT,UD} Not every extension in Linux libc's history was well -thought-out. In fact it had a lot of problems with standards compliance -and with cleanliness. With the introduction of a new version number these -errors now can be corrected. Here is a list of the known source code -incompatibilities: + configure --enable-add-ons=crypt,linuxthreads -* _GNU_SOURCE: glibc does not automatically define _GNU_SOURCE. Thus, - if a program depends on GNU extensions or some other non-standard - functionality, it is necessary to compile it with C compiler option - -D_GNU_SOURCE, or better, to put `#define _GNU_SOURCE' at the beginning - of your source files, before any C library header files are included. - This difference normally manifests itself in the form of missing - prototypes and/or data type definitions. Thus, if you get such errors, - the first thing you should do is try defining _GNU_SOURCE and see if - that makes the problem go away. +for example. - For more information consult the file `NOTES' part of the GNU C - library sources. +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. -* reboot(): GNU libc sanitizes the interface of reboot() to be more - compatible with the interface used on other OSes. In particular, - reboot() as implemented in glibc takes just one argument. This argument - corresponds to the third argument of the Linux reboot system call. - That is, a call of the form reboot(a, b, c) needs to be changed into - reboot(c). - Beside this the header <sys/reboot.h> defines the needed constants - for the argument. These RB_* constants should be used instead of the - cryptic magic numbers. - -* swapon(): the interface of this function didn't changed, but the - prototype is in a separate header file <sys/swap.h>. For the additional - argument of swapon() you should use the SWAP_* constants from - <linux/swap.h>, which get defined when <sys/swap.h> is included. - -* errno: If a program uses variable "errno", then it _must_ include header - file <errno.h>. The old libc often (erroneously) declared this variable - implicitly as a side-effect of including other libc header files. glibc - is careful to avoid such namespace pollution, which, in turn, means that - you really need to include the header files that you depend on. This - difference normally manifests itself in the form of the compiler - complaining about the references of the undeclared symbol "errno". -* Linux-specific syscalls: All Linux system calls now have appropriate - library wrappers and corresponding declarations in various header files. - This is because the syscall() macro that was traditionally used to - work around missing syscall wrappers are inherently non-portable and - error-prone. The following tables lists all the new syscall stubs, - the header-file declaring their interface and the system call name. +1.8. My XXX kernel emulates a floating-point coprocessor for me. + Should I enable --with-fp? - syscall name: wrapper name: declaring header file: - ------------- ------------- ---------------------- - bdflush bdflush <sys/kdaemon.h> - syslog ksyslog_ctl <sys/klog.h> +{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. -* lpd: Older versions of lpd depend on a routine called _validuser(). - The library does not provide this function, but instead provides - __ivaliduser() which has a slightly different interfaces. Simply - upgrading to a newer lpd should fix this problem (e.g., the 4.4BSD - lpd is known to be working). +People who are interested in squeezing the last drop of performance +out of their machine may wish to avoid the trap overhead, but this is +far more trouble than it's worth: you then have to compile +*everything* this way, including the compiler's internal libraries +(libgcc.a for GNU C), because the calling conventions change. -* resolver functions/BIND: like on many other systems the functions of - the resolver library are not included in the libc itself. There is - a separate library libresolv. If you find some symbols starting with - `res_*' undefined simply add -lresolv to your call of the linker. -* the `signal' function's behaviour corresponds to the BSD semantic and - not the SysV semantic as it was in libc-5. The interface on all GNU - systems shall be the same and BSD is the semantic of choice. To use - the SysV behaviour simply use `sysv_signal', or define _XOPEN_SOURCE. - See question 32 for details. +1.9. 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. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q10] ``Why does getlogin() always return NULL on my Linux box?'' +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. -[A10] {UD} The GNU C library has a format for the UTMP and WTMP file -which differs from what your system currently has. It was extended to -fulfill the needs of the next years when IPv6 is introduced. So the -record size is different, fields might have a different position and -so reading the files written by functions from the one library cannot -be read by functions from the other library. Sorry, but this is what -a major release is for. It's better to have a cut now than having no -means to support the new techniques later. +{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. -{MK} There is however a (partial) solution for this problem. Please -take a look at the file `README.utmpd'. +1.10. What's the problem with configure --enable-omitfp? -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q11] ``Where are the DST_* constants found in <sys/time.h> on many - systems?'' +{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. -[A11] {UD} These constants come from the old BSD days and are not used -today anymore (even the Linux based glibc does not implement the handling -although the constants are defined). +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. -Instead GNU libc contains the zone database handling and compatibility -code for POSIX TZ environment variable handling. +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. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q12] ``The `gencat' utility cannot process the input which are - successfully used on my Linux libc based system. Why?'' + +. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -[A12] {UD} Unlike the author of the `gencat' program which is distributed -with Linux libc I have read the underlying standards before writing the -code. It is completely compatible with the specification given in -X/Open Portability Guide. +2. Installation and configuration issues -To ease the transition from the Linux version some of the non-standard -features are also present in the `gencat' program of GNU libc. This -mainly includes the use of symbols for the message number and the automatic -generation of header files which contain the needed #defines to map the -symbols to integers. +2.1. Can I replace the libc on my Linux system with GNU libc? -Here is a simple SED script to convert at least some Linux specific -catalog files to the XPG4 form: +{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. ------------------------------------------------------------------------ -# Change catalog source in Linux specific format to standard XPG format. -# Ulrich Drepper <drepper@cygnus.com>, 1996. -# -/^\$ #/ { - h - s/\$ #\([^ ]*\).*/\1/ - x - s/\$ #[^ ]* *\(.*\)/\$ \1/ -} +For Linux there are three major libc versions: + libc-4 a.out libc + libc-5 original ELF libc + libc-6 GNU libc -/^# / { - s/^# \(.*\)/\1/ - G - s/\(.*\)\n\(.*\)/\2 \1/ -} ------------------------------------------------------------------------ +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. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q13] ``How do I configure GNU libc so that the essential libraries - like libc.so go into /lib and the other into /usr/lib?'' +2.2. How do I configure GNU libc so that the essential libraries + like libc.so go into /lib and the other into /usr/lib? -[A13] {UD,AJ} Like all other GNU packages GNU libc is configured to -use a base directory and install all files relative to this. If you -intend to really use GNU libc on your system this base directory is -/usr. I.e., you run - configure --prefix=/usr <other_options> +{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. +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 -one must explicitly tell this (except on Linux, see below). Autoconf -has no option for this so you have to use the file where all user -supplied additional information should go in: `configparms' (see the -`INSTALL' file). Therefore the `configparms' file should contain: +To install the essential libraries which come with GNU libc in /lib on +systems other than Linux one must explicitly request it. Autoconf has +no option for this so you have to use a `configparms' file (see the +`INSTALL' file for details). It should contain: slibdir=/lib sysconfdir=/etc The first line specifies the directory for the essential libraries, -the second line the directory for file which are by tradition placed -in a directory named /etc. +the second line the directory for system configuration files. -No rule without an exception: If you configure for Linux with ---prefix=/usr, then slibdir and sysconfdir will automatically be -defined as stated above. +2.3. How should I avoid damaging my system when I install GNU libc? -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q14] ``When linking with the new libc I get unresolved symbols - `crypt' and `setkey'. Why aren't these functions in the - libc anymore?'' +{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.) -[A14] {UD} Remember the US restrictions of exporting cryptographic -programs and source code. Until this law gets abolished we cannot -ship the cryptographic function together with the libc. +The dangers when installing glibc in /usr are twofold: -But of course we provide the code and there is an very easy way to use -this code. First get the extra package. People in the US may get it -from the same place they got the 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. +* glibc will overwrite the headers in /usr/include. Other C libraries + install a different but overlapping set of headers there, so the + effect will probably be that you can't compile anything. You need to + rename /usr/include out of the way first. (Do not throw it away; you + will then lose the ability to compile programs against your old libc.) -If you already have the crypt code on your system the reason for the -failure is probably that you failed to link with -lcrypt. The crypto -functions are in a separate library to make it possible to export GNU -libc binaries from the US. +* None of your old libraries, static or shared, can be used with a + different C library major version. For shared libraries this is not a + problem, because the filenames are different and the dynamic linker + will enforce the restriction. But static libraries have no version + information. You have to evacuate all the static libraries in + /usr/lib to a safe location. +The situation is rather similar to the move from a.out to ELF which +long-time Linux users will remember. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q15] ``What are these `add-ons'?'' -[A15] {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 Q14). +2.4. Do I need to use GNU CC to compile programs that will use the + GNU C Library? -To ease the use as part of GNU libc the installer just has to unpack -the package and tell the configuration script about these additional -subdirectories using the --enable-add-ons option. When you add the -crypt add-on you just have to use +{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. - configure --enable-add-ons=crypt,XXX ... +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. -where XXX are possible other add-ons and ... means the rest of the -normal option list. +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. -You can use add-ons also to overwrite some files in glibc. The add-on -system dependent subdirs are search first. It is also possible to add -banner files (use a file named `Banner') or create shared libraries. -Using add-ons has the big advantage that the makefiles of the GNU libc -can be used. Only some few stub rules must be written to get -everything running. Even handling of architecture dependent -compilation is provided. The GNU libc's sysdeps/ directory shows how -to use this feature. +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. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q16] ``When I use GNU libc on my Linux system by linking against - to libc.so which comes with glibc all I get is a core dump.'' +The functions are available, as an add-on (see question 1.7). 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. -[A16] {UD} It is not enough to simply link against the GNU libc -library itself. The GNU C library comes with its own dynamic linker -which really conforms to the ELF API standard. This dynamic linker -must be used. +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. -Normally this is done by the compiler. The gcc will use - -dynamic-linker /lib/ld-linux.so.1 +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. -unless the user specifies her/himself a -dynamic-linker argument. But -this is not the correct name for the GNU dynamic linker. The correct -name is /lib/ld.so.1 which is the name specified in the SVr4 ABi. +{UD} On Linux, gcc sets the dynamic linker to /lib/ld-linux.so.1 +unless the user specifies a -dynamic-linker argument. This is the +name of the libc5 dynamic linker, which does not work with glibc. + +For casual use of GNU libc you can just specify + -dynamic-linker=/lib/ld-linux.so.2 + +which is the glibc dynamic linker, on Linux systems. On other systems +the name is /lib/ld.so.1. To change your environment to use GNU libc for compiling you need to change the `specs' file of your gcc. This file is normally found at @@ -535,20 +446,14 @@ change the `specs' file of your gcc. This file is normally found at In this file you have to change a few things: -- change `ld-linux.so.1' to `ld.so.1' (or to ld-linux.so.2, see below) +- change `ld-linux.so.1' to `ld-linux.so.2' - remove all expression `%{...:-lgmon}'; there is no libgmon in glibc - fix a minor bug by changing %{pipe:-} to %| - -Things are getting 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. 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: @@ -579,7 +484,7 @@ the gcc-2.7.2 specs file should look like when GNU libc is installed at -lgcc *startfile: -%{!shared: %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} %{!p:%{profile:gcrt1.o%s} %{!profile:crt1.o%s}}}} crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s} +%{!shared: %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} %{!p:%{profile:gcrt1.o%s} %{!profile:crt1.o%s}}}} crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s} *switches_need_spaces: @@ -598,27 +503,22 @@ the gcc-2.7.2 specs file should look like when GNU libc is installed at ----------------------------------------------------------------------- -The above is currently correct for ix86/Linux. Because of -compatibility issues on this platform the dynamic linker must have -a different name: ld-linux.so.2. So you have to replace - - %{!dynamic-linker:-dynamic-linker=/home/gnu/lib/ld-linux.so.2} -by - %{!dynamic-linker:-dynamic-linker=/home/gnu/lib/ld.so.1} - -in the above example specs file to make it work for other systems. +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. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q17] ``Looking through the shared libc file I haven't found the - functions `stat', `lstat', `fstat', and `mknod' and while - linking on my Linux system I get error messages. How is - this supposed to work?'' +2.7. Looking through the shared libc file I haven't found the + functions `stat', `lstat', `fstat', and `mknod' and while + linking on my Linux system I get error messages. How is + this supposed to work? -[A17] {RM} Believe it or not, stat and lstat (and fstat, and mknod) +{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 @@ -631,211 +531,276 @@ or in ix86/Linux and alpha/Linux: GROUP ( libc.so.6 ld-linux.so.2 libc.a ) -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q18] ``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?'' +2.8. How can I compile gcc 2.7.2.1 from the gcc source code using + glibc 2.x? -[A18] {UD} No, this is no bug. This version of the GNU libc already -follows the Single Unix specifications (and I think the POSIX.1g -draft which adopted the solution). The type for parameter describing -a size is now `socklen_t', a new type. +{AJ} There's only correct support for glibc 2.0.x in gcc 2.7.2.3 +or later. You should get at least gcc 2.7.2.3. All previous versions +had problems with glibc support. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q19] ``My XXX kernel emulates a floating-point coprocessor for me. - Should I enable --with-fp?'' +2.9. The `gencat' utility cannot process the catalog sources which + were used on my Linux libc5 based system. Why? -[A19] {UD} As `configure --help' shows the default value is `yes' and -this should not be changed unless the FPU instructions would be -invalid. I.e., an emulated FPU is for the libc as good as a real one. +{UD} The `gencat' utility provided with glibc complies to the XPG +standard. The older Linux version did not obey the standard, so they +are not compatible. +To ease the transition from the Linux version some of the non-standard +features are also present in the `gencat' program of GNU libc. This +mainly includes the use of symbols for the message number and the automatic +generation of header files which contain the needed #defines to map the +symbols to integers. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q20] ``How can I compile gcc 2.7.2.1 from the gcc source code using - glibc 2.x? +Here is a simple SED script to convert at least some Linux specific +catalog files to the XPG4 form: -[A20] {AJ} There's only correct support for glibc 2.0.x in gcc 2.7.2.3 -or later. You should get at least gcc 2.7.2.3. All previous versions -had problems with glibc support. +----------------------------------------------------------------------- +# Change catalog source in Linux specific format to standard XPG format. +# Ulrich Drepper <drepper@cygnus.com>, 1996. +# +/^\$ #/ { + h + s/\$ #\([^ ]*\).*/\1/ + x + s/\$ #[^ ]* *\(.*\)/\$ \1/ +} +/^# / { + s/^# \(.*\)/\1/ + G + s/\(.*\)\n\(.*\)/\2 \1/ +} +----------------------------------------------------------------------- -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q21] ``On Linux I've got problems with the declarations in Linux - kernel headers.'' -[A21] {UD,AJ} On Linux, the use of kernel headers is reduced to a very -minimum. Besides giving Linus the possibility to change the headers -more freely it has another reason: user level programs now do not -always use the same types like the kernel does. +2.10. 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. -I.e., the libc abstracts the use of types. E.g., the sigset_t type is -in the kernel 32 or 64 bits wide. In glibc it is 1024 bits wide, in -preparation for future development. The reasons are obvious: we don't -want to have a new major release when the Linux kernel gets these -functionality. Consult the headers for more information about the changes. +{??} 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). -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. +2.11. After installing glibc name resolving doesn't work properly. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q22] ``When I try to compile code which uses IPv6 header and - definitions on my Linux 2.x.y system I am in trouble. - Nothing seems to work.'' +{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. -[A22] {UD} The problem is that the IPv6 development still has not reached -a point where it is stable. There are still lots of incompatible changes -made and the libc headers have to follow. -Currently (as of 970401) according to Philip Blundell <philb@gnu.ai.mit.edu> -the required kernel version is 2.1.30. +2.12. 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. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q23] ``When compiling GNU libc I get lots of errors saying functions - in glibc are duplicated in libgcc.'' -[A23] {EY} This is *exactly* the same problem that I was having. The -problem was due to the fact that the autoconfigure didn't correctly -detect that 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. +2.13. Programs like `logname', `top', `uptime' `users', `w' and + `who', show incorrect information about the (number of) + users on my system. Why? -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. +{MK} See question 3.2. -{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. +2.14. 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. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q24] ``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.'' +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. -[A24] 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 do not contain all necessary -information. You have to copy a NIS_COLD_START file from a Solaris -client (the NIS_COLD_START file is byte order independend) or generate -it new with nisinit from the nis-tools (look at -http://www-vt.uni-paderborn.de/~kukuk/linux/nisplus.html). +2.15. When I start the program XXX after upgrading the library + I get + XXX: Symbol `_sys_errlist' has different size in shared + object, consider re-linking + Why? What should I do? -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q25] ``After installing glibc name resolving doesn't work properly.'' +{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. -[A25] {AJ} You probable should read the manual section describing -``nsswitch.conf'' (just type `info libc "NSS Configuration File"'). -The NSS configuration file is usually the culprit. +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. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q26] ``I have /usr/include/net and /usr/include/scsi as symlinks - into my Linux source tree. Is that wrong?'' + +. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -[A26] {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 Q21). 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. +3. Source and binary incompatibilities, and what to do about them +3.1. I expect GNU libc to be 100% source code compatible with + the old Linux based GNU libc. Why isn't it like this? -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q27] ``Programs like `logname', `top', `uptime' `users', `w' and - `who', show incorrect information about the (number of) - users on my system. Why?'' +{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: -[A27] {MK} See Q10. +* _GNU_SOURCE: glibc does not make the GNU extensions available + automatically. If a program depends on GNU extensions or some + other non-standard functionality, it is necessary to compile it + with the C compiler option -D_GNU_SOURCE, or better, to put + `#define _GNU_SOURCE' at the beginning of your source files, before + any C library header files are included. This difference normally + manifests itself in the form of missing prototypes and/or data type + definitions. Thus, if you get such errors, the first thing you + should do is try defining _GNU_SOURCE and see if that makes the + problem go away. + For more information consult the file `NOTES' in the GNU C library + sources. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q28] ``After upgrading to a glibc 2.1 with symbol versioning I get - errors about undefined symbols. What went wrong?'' +* reboot(): GNU libc sanitizes the interface of reboot() to be more + compatible with the interface used on other OSes. reboot() as + implemented in glibc takes just one argument. This argument + corresponds to the third argument of the Linux reboot system call. + That is, a call of the form reboot(a, b, c) needs to be changed into + reboot(c). Beside this the header <sys/reboot.h> defines the needed + constants for the argument. These RB_* constants should be used + instead of the cryptic magic numbers. + +* swapon(): the interface of this function didn't change, but the + prototype is in a separate header file <sys/swap.h>. This header + file also provides the SWAP_* constants defined by <linux/swap.h>; + you should use them for the second argument to swapon(). + +* errno: If a program uses the variable "errno", then it _must_ + include <errno.h>. The old libc often (erroneously) declared this + variable implicitly as a side-effect of including other libc header + files. glibc is careful to avoid such namespace pollution, which, + in turn, means that you really need to include the header files that + you depend on. This difference normally manifests itself in the + form of the compiler complaining about references to an undeclared + symbol "errno". -[A28] {AJ} In a versioned libc a lot of symbols are now local that -have been global symbols in previous versions. When defining a extern -variable both in a user program and extern in the libc the links -resolves this to only one reference - the one in the library. The -problem is caused by either wrong program code or tools. In no case -the global variables from libc should be used by any program. Since -these reference are now local, you might see a message like: +* Linux-specific syscalls: All Linux system calls now have appropriate + library wrappers and corresponding declarations in various header files. + This is because the syscall() macro that was traditionally used to + work around missing syscall wrappers are inherently non-portable and + error-prone. The following table lists all the new syscall stubs, + the header-file declaring their interface and the system call name. -"msgfmt: error in loading shared libraries: : undefined symbol: _nl_domain_bindings" + syscall name: wrapper name: declaring header file: + ------------- ------------- ---------------------- + bdflush bdflush <sys/kdaemon.h> + syslog ksyslog_ctl <sys/klog.h> -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. +* lpd: Older versions of lpd depend on a routine called _validuser(). + The library does not provide this function, but instead provides + __ivaliduser() which has a slightly different interface. Simply + upgrading to a newer lpd should fix this problem (e.g., the 4.4BSD + lpd is known to be working). +* resolver functions/BIND: like on many other systems the functions of + the resolver library are not included in libc itself. There is a + separate library libresolv. If you get undefined symbol errors for + symbols starting with `res_*' simply add -lresolv to your linker + command line. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q29] ``I don't include any kernel header myself but still the - compiler complains about type redeclarations of types in the - kernel headers.'' +* the `signal' function's behavior corresponds to the BSD semantic and + not the SysV semantic as it was in libc-5. The interface on all GNU + systems shall be the same and BSD is the semantic of choice. To use + the SysV behavior simply use `sysv_signal', or define _XOPEN_SOURCE. + See question 3.7 for details. -[A29] {UD} The kernel headers before Linux 2.1.61 don't work correctly with -glibc since they pollute the name space in a not acceptable way. Compiling -C programs is possible in most cases but especially C++ programs have (due -to the change of the name lookups for `struct's) problem. One prominent -example is `struct fd_set'. -There might be some more problems left but 2.1.61 fixes some of the known -ones. See the BUGS file for other known problems. +3.2. Why does getlogin() always return NULL on my Linux box? + +{UD} The GNU C library has a format for the UTMP and WTMP file which +differs from what your system currently has. It was extended to +fulfill the needs of the next years when IPv6 is introduced. The +record size is different and some fields have different positions. +The files written by functions from the one library cannot be read by +functions from the other library. Sorry, but this is what a major +release is for. It's better to have a cut now than having no means to +support the new techniques later. +{MK} There is however a (partial) solution for this problem. Please +take a look at the file `README.utmpd'. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q30] ``When I start the program XXX after upgrading the library - I get - XXX: Symbol `_sys_errlist' has different size in shared object, consider re-linking - Why? What to do?'' -[A30] {UD} As the message says, relink the binary. The problem is that -very 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. +3.3. Where are the DST_* constants found in <sys/time.h> on many + systems? -But this does not mean all programs are doomed once such a change is -necessary. 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. +{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). -In some situations (especially when testing a new library release) it might -be possible that such a symbol size change slipped in though it must not -happen. So in case of doubt report such a warning message as a problem. +Instead GNU libc contains zone database support and compatibility code +for POSIX TZ environment variable handling. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q31] ``What's the problem with configure --enable-omitfp?'' +3.4. The prototypes for `connect', `accept', `getsockopt', + `setsockopt', `getsockname', `getpeername', `send', + `sendto', and `recvfrom' are different in GNU libc from + any other system I saw. This is a bug, isn't it? -[A31] {AJ} When configuring with --enable-omitfp the libraries are build -without frame pointers. Some compilers produce in this situation buggy -code and therefore we don't advise using it at the moment. +{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. -If you use --enable-omitfp, you're on your own. If you encounter -problems with a library that was build this way, I'll 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, a -debuggable library is also build - you can recognize it by the suffix -"_g" to the library names. +3.5. On Linux I've got problems with the declarations in Linux + kernel headers. -The compilation of this extra libraries and the compiler optimizations -slow down the build process and need more disk space. +{UD,AJ} On Linux, the use of kernel headers is reduced to the minimum. +This gives Linus the ability to change the headers more freely. Also, +user programs are now insulated from changes in the size of kernel +data structures. +For example, the sigset_t type is 32 or 64 bits wide in the kernel. +In glibc it is 1024 bits wide. This guarantees that when the kernel +gets a bigger sigset_t (for POSIX.1e realtime support, say) user +programs will not have to be recompiled. Consult the header files for +more information about the changes. + +Therefore you shouldn't include Linux kernel header files directly if +glibc has defined a replacement. Otherwise you might get undefined +results because of type conflicts. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q32] ``Why don't signals interrupt system calls anymore?'' -[A32] {ZW} By default GNU libc uses the BSD semantics for signal(), +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 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 fixes 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. @@ -851,7 +816,7 @@ There are three differences: * A BSD signal is blocked during the execution of its handler. In other words, a handler for SIGCHLD (for example) does not need to worry about - being interrupted by another SIGCHLD. It may, however, be interrrupted + being interrupted by another SIGCHLD. It may, however, be interrupted by other signals. There is general consensus that for `casual' programming with signals, the @@ -872,33 +837,32 @@ and return EINTR (for example, to implement a timeout) you can do this with siginterrupt(). -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -[Q33] ``I've got errors compiling code that uses certain string - functions. Why?'' +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. -[A33] {AJ} glibc 2.1 has the much asked for optimized 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 behaviour can be changed with two +optimizations (-O1 or higher). The behavior can be changed with two feature macros: -* __NO_STRING_INLINES: Don't use string optimizations. -* __USE_STRING_INLINES: Use also assembler inline functions (might - increase code use dramatically). + +* __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 even -unneccessary since <string.h> has the necessary declarations). Either +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 the gcc still has problems on +{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 sometimes requires many/all registers and the register allocator -cannot handle these situation in all cases. +code can require almost all the registers and the register allocator +cannot always handle this situation. -If a function is also defined as a macro in the libc headers one can prevent -the use of the macro easily. E.g., instead of +One can disable the string optimizations selectively. Instead of writing cp = strcpy (foo, "lkj"); @@ -906,17 +870,39 @@ one can write cp = (strcpy) (foo, "lkj"); -Using this method one can avoid using the optimizations for selected -function calls. +This disables the optimization for that specific call. + + +. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . + +4. Miscellaneous + +4.1. After I changed configure.in I get `Autoconf version X.Y. + or higher is required for this script'. What can I do? + +{UD} You have to get the specified autoconf version (or a later one) +from your favorite mirror of prep.ai.mit.edu. + +4.2. When I try to compile code which uses IPv6 headers and + definitions on my Linux 2.x.y system I am in trouble. + Nothing seems to work. + +{UD} The problem is that IPv6 development still has not reached a +point where the headers are stable. There are still lots of +incompatible changes made and the libc headers have to follow. + +Also, make sure you have a suitably recent kernel. As of the 970401 +snapshot, according to Philip Blundell <philb@gnu.ai.mit.edu>, the +required kernel version is 2.1.30. -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ +~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ + Answers were given by: {UD} Ulrich Drepper, <drepper@cygnus.com> {DMT} David Mosberger-Tang, <davidm@AZStarNet.com> {RM} Roland McGrath, <roland@gnu.org> -{HJL} H.J. Lu, <hjl@gnu.org> {AJ} Andreas Jaeger, <aj@arthur.rhein-neckar.de> {EY} Eric Youngdale, <eric@andante.jic.com> {PB} Phil Blundell, <Philip.Blundell@pobox.com> @@ -924,5 +910,6 @@ Answers were given by: {ZW} Zack Weinberg, <zack@rabi.phys.columbia.edu> Local Variables: - mode:text + mode:outline + outline-regexp:"\\?" End: diff --git a/FAQ.in b/FAQ.in new file mode 100644 index 0000000000..770bef4133 --- /dev/null +++ b/FAQ.in @@ -0,0 +1,787 @@ + Frequently Asked Questions about the GNU C Library + +This document tries to answer questions a user might have when +installing and using glibc. Please make sure you read this before +sending questions or bug reports to the maintainers. + +The GNU C library is very complex. The installation process has not +been completely automated; there are too many variables. You can do +substantial damage to your system by installing the library +incorrectly. Make sure you understand what you are undertaking before +you begin. + +If you have any questions you think should be answered in this document, +please let me know. + + --drepper@cygnus.com + +? Compiling glibc + +?? What systems does the GNU C Library run on? + +{UD} This is difficult to answer. The file `README' lists the +architectures GNU libc was known to run on *at some time*. This does +not mean that it still can be compiled and run on them now. + +The systems glibc is known to work on as of this release, and most +probably in the future, are: + + *-*-gnu GNU Hurd + i[3456]86-*-linux-gnu Linux-2.0 on Intel + m68k-*-linux-gnu Linux-2.0 on Motorola 680x0 + alpha-*-linux-gnu Linux-2.0 on DEC Alpha + powerpc-*-linux-gnu Linux and MkLinux on PowerPC systems + sparc-*-linux-gnu Linux-2.0 on SPARC + sparc64-*-linux-gnu Linux-2.0 on UltraSPARC + +Ports to other Linux platforms are in development, and may in fact +work already, but no one has sent us success reports for them. +Currently no ports to other operating systems are underway, although a +few people have expressed interest. + +If you have a system not listed above (or in the `README' file) and +you are really interested in porting it, contact + + <bug-glibc@prep.ai.mit.edu> + +?? What compiler do I need to build GNU libc? + +{UD} You must use GNU CC to compile GNU libc. A lot of extensions of +GNU CC are used to increase portability and speed. + +GNU CC is found, like all other GNU packages, on + ftp://prep.ai.mit.edu/pub/gnu +and the many mirror sites. prep 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. On most +supported platforms, 2.7.2.3 is the earliest version that works at all. + +?? When I try to compile glibc I get only error messages. + What's wrong? + +{UD} You definitely need GNU make to translate GNU libc. No +other make program has the needed functionality. + +We recommend version GNU make version 3.75. Versions 3.76 and 3.76.1 +have bugs which appear when building big projects like GNU libc. +Versions before 3.74 have bugs and/or are missing features. + +?? Do I need a special linker or archiver? + +{UD} You may be able to use your system linker, but GNU libc works +best with GNU binutils. + +On systems where the native linker does not support weak symbols you +will not get a fully ISO C compliant C library. Generally speaking +you should use the GNU binutils if they provide at least the same +functionality as your system's tools. + +Always get the newest release of GNU binutils available. Older +releases are known to have bugs that prevent a successful compilation. + +{ZW} As of release 2.1 a linker supporting symbol versions is +required. For Linux, get binutils-2.8.1.0.17 or later. Other systems +may have native linker support, but it's moot right now, because glibc +has not been ported to them. + +?? Do I need some more things to compile GNU C Library? + +{UD} Yes, there are some more :-). + +* GNU gettext. This package contains the tools needed to construct + `message catalog' files containing translated versions of system + messages. See ftp://prep.ai.mit.edu/pub/gnu or better any mirror + site. (We distribute compiled message catalogs, but they may not be + updated in patches.) + +* Some files depend on special tools. E.g., files ending in .gperf + need a `gperf' program. The GNU version (part of libg++) is known + to work while some vendor versions do not. + + You should not need these tools unless you change the source files. + +* When compiling for Linux, the header files of the Linux kernel must + be available to the compiler as <linux/*.h> and <asm/*.h>. + +* lots of disk space (~170MB for i?86-linux; more for RISC platforms). + +* plenty of time. Compiling just the shared and static libraries for + i?86-linux takes approximately 1h on an i586@133, or 2.5h on + i486@66, or 4.5h on i486@33. Multiply this by 1.5 or 2.0 if you + build profiling and/or the highly optimized version as well. For + Hurd systems times are much higher. + + You should avoid compiling in a NFS mounted filesystem. This is + very slow. + + James Troup <J.J.Troup@comp.brad.ac.uk> reports a compile time of + 45h34m for a full build (shared, static, and profiled) on + Atari Falcon (Motorola 68030 @ 16 Mhz, 14 Mb memory) and 22h48m + on Atari TT030 (Motorola 68030 @ 32 Mhz, 34 Mb memory) + + If you have some more measurements let me know. + +?? When I run `nm -u libc.so' on the produced library I still + find unresolved symbols. Can this be ok? + +{UD} Yes, this is ok. There can be several kinds of unresolved +symbols: + +* magic symbols automatically generated by the linker. These have names + like __start_* and __stop_* + +* symbols starting with _dl_* come from the dynamic linker + +* symbols resolved by using libgcc.a + (__udivdi3, __umoddi3, or similar) + +* weak symbols, which need not be resolved at all (fabs for example) + +Generally, you should make sure you find a real program which produces +errors while linking before deciding there is a problem. + +??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). + +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. + +?? My XXX kernel emulates a floating-point coprocessor for me. + Should I enable --with-fp? + +{ZW} An emulated FPU is just as good as a real one, as far as the C +library is concerned. You only need to say --without-fp if your +machine has no way to execute floating-point instructions. + +People who are interested in squeezing the last drop of performance +out of their machine may wish to avoid the trap overhead, but this is +far more trouble than it's worth: you then have to compile +*everything* this way, including the compiler's internal libraries +(libgcc.a for GNU C), because the calling conventions change. + +?? When compiling GNU libc I get lots of errors saying functions + in glibc are duplicated in libgcc. + +{EY} This is *exactly* the same problem that I was having. The +problem was due to the fact that configure didn't correctly detect +that the linker flag --no-whole-archive was supported in my linker. +In my case it was because I had run ./configure with bogus CFLAGS, and +the test failed. + +One thing that is particularly annoying about this problem is that +once this is misdetected, running configure again won't fix it unless +you first delete config.cache. + +{UD} Starting with glibc-2.0.3 there should be a better test to avoid +some problems of this kind. The setting of CFLAGS is checked at the +very beginning and if it is not usable `configure' will bark. + +?? What's the problem with configure --enable-omitfp? + +{AJ} When --enable-omitfp is set the libraries are built without frame +pointers. Some compilers produce buggy code for this model and +therefore we don't advise using it at the moment. + +If you use --enable-omitfp, you're on your own. If you encounter +problems with a library that was build this way, we advise you to +rebuild the library without --enable-omitfp. If the problem vanishes +consider tracking the problem down and report it as compiler failure. + +Since a library build with --enable-omitfp is undebuggable on most +systems, debuggable libraries are also built - you can use it by +appending "_g" to the library names. + +The compilation of these extra libraries and the compiler optimizations +slow down the build process and need more disk space. + +? 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. + +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. + +?? 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. + +To install the essential libraries which come with GNU libc in /lib on +systems other than Linux one must explicitly request it. Autoconf has +no option for this so you have to use a `configparms' file (see the +`INSTALL' file for details). It should contain: + +slibdir=/lib +sysconfdir=/etc + +The first line specifies the directory for the essential libraries, +the second line the directory for system configuration files. + +??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.) + +The dangers when installing glibc in /usr are twofold: + +* glibc will overwrite the headers in /usr/include. Other C libraries + install a different but overlapping set of headers there, so the + effect will probably be that you can't compile anything. You need to + rename /usr/include out of the way first. (Do not throw it away; you + will then lose the ability to compile programs against your old libc.) + +* None of your old libraries, static or shared, can be used with a + different C library major version. For shared libraries this is not a + problem, because the filenames are different and the dynamic linker + will enforce the restriction. But static libraries have no version + information. You have to evacuate all the static libraries in + /usr/lib to a safe location. + +The situation is rather similar to the move from a.out to ELF which +long-time Linux users will remember. + +?? Do I need to use GNU CC to compile programs that will use the + GNU C Library? + +{ZW} In theory, no; the linker does not care, and the headers are +supposed to check for GNU CC before using its extensions to the C +language. + +However, there are currently no ports of glibc to systems where +another compiler is the default, so no one has tested the headers +extensively against another compiler. You may therefore encounter +difficulties. If you do, please report them as bugs. + +Also, in several places GNU extensions provide large benefits in code +quality. For example, the library has hand-optimized, inline assembly +versions of some string functions. These can only be used with GCC. +See ?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. + +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. + +?? When I use GNU libc on my Linux system by linking against + the libc.so which comes with glibc all I get is a core dump. + +{UD} On Linux, gcc sets the dynamic linker to /lib/ld-linux.so.1 +unless the user specifies a -dynamic-linker argument. This is the +name of the libc5 dynamic linker, which does not work with glibc. + +For casual use of GNU libc you can just specify + -dynamic-linker=/lib/ld-linux.so.2 + +which is the glibc dynamic linker, on Linux systems. On other systems +the name is /lib/ld.so.1. + +To change your environment to use GNU libc for compiling you need to +change the `specs' file of your gcc. This file is normally found at + + /usr/lib/gcc-lib/<arch>/<version>/specs + +In this file you have to change a few things: + +- change `ld-linux.so.1' to `ld-linux.so.2' + +- remove all expression `%{...:-lgmon}'; there is no libgmon in glibc + +- fix a minor bug by changing %{pipe:-} to %| + +Here is what the gcc-2.7.2 specs file should look like when GNU libc +is installed at /usr: + +----------------------------------------------------------------------- +*asm: +%{V} %{v:%{!V:-V}} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} + +*asm_final: +%| + +*cpp: +%{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} %{!m386:-D__i486__} %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} + +*cc1: +%{profile:-p} + +*cc1plus: + + +*endfile: +%{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s + +*link: +-m elf_i386 %{shared:-shared} %{!shared: %{!ibcs: %{!static: %{rdynamic:-export-dynamic} %{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2}} %{static:-static}}} + +*lib: +%{!shared: %{pthread:-lpthread} %{profile:-lc_p} %{!profile: -lc}} + +*libgcc: +-lgcc + +*startfile: +%{!shared: %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} %{!p:%{profile:gcrt1.o%s} %{!profile:crt1.o%s}}}} crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s} + +*switches_need_spaces: + + +*signed_char: +%{funsigned-char:-D__CHAR_UNSIGNED__} + +*predefines: +-D__ELF__ -Dunix -Di386 -Dlinux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386) + +*cross_compile: +0 + +*multilib: +. ; + +----------------------------------------------------------------------- + +Things get a bit more complicated if you have GNU libc installed in +some other place than /usr, i.e., if you do not want to use it instead +of the old libc. In this case the needed startup files and libraries +are not found in the regular places. So the specs file must tell the +compiler and linker exactly what to use. + +Version 2.7.2.3 does and future versions of GCC will automatically +provide the correct specs. + +?? Looking through the shared libc file I haven't found the + functions `stat', `lstat', `fstat', and `mknod' and while + linking on my Linux system I get error messages. How is + this supposed to work? + +{RM} Believe it or not, stat and lstat (and fstat, and mknod) +are supposed to be undefined references in libc.so.6! Your problem is +probably a missing or incorrect /usr/lib/libc.so file; note that this +is a small text file now, not a symlink to libc.so.6. It should look +something like this: + +GROUP ( libc.so.6 ld.so.1 libc.a ) + +or in ix86/Linux and alpha/Linux: + +GROUP ( libc.so.6 ld-linux.so.2 libc.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. You should get at least gcc 2.7.2.3. All previous versions +had problems with glibc support. + +?? The `gencat' utility cannot process the catalog sources which + were used on my Linux libc5 based system. Why? + +{UD} The `gencat' utility provided with glibc complies to the XPG +standard. The older Linux version did not obey the standard, so they +are not compatible. + +To ease the transition from the Linux version some of the non-standard +features are also present in the `gencat' program of GNU libc. This +mainly includes the use of symbols for the message number and the automatic +generation of header files which contain the needed #defines to map the +symbols to integers. + +Here is a simple SED script to convert at least some Linux specific +catalog files to the XPG4 form: + +----------------------------------------------------------------------- +# Change catalog source in Linux specific format to standard XPG format. +# Ulrich Drepper <drepper@cygnus.com>, 1996. +# +/^\$ #/ { + h + s/\$ #\([^ ]*\).*/\1/ + x + s/\$ #[^ ]* *\(.*\)/\$ \1/ +} + +/^# / { + s/^# \(.*\)/\1/ + G + s/\(.*\)\n\(.*\)/\2 \1/ +} +----------------------------------------------------------------------- + +?? 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. + +{??} 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). + +?? 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. + +?? 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. + +?? Programs like `logname', `top', `uptime' `users', `w' and + `who', show incorrect information about the (number of) + users on my system. Why? + +{MK} See ?getlog. + +?? After upgrading to glibc 2.1 with symbol versioning I get + errors about undefined symbols. What went wrong? + +{AJ} The problem is caused either by wrong program code or tools. In +the versioned libc a lot of symbols are now local that were global +symbols in previous versions. It seems that programs linked against +older versions often accidentally used libc global variables -- +something that should not happen. + +The only way to fix this is to recompile your program. Sorry, that's +the price you might have to pay once for quite a number of advantages +with symbol versioning. + +?? When I start the program XXX after upgrading the library + I get + XXX: Symbol `_sys_errlist' has different size in shared + object, consider re-linking + Why? What should I do? + +{UD} As the message says, relink the binary. The problem is that +a few symbols from the library can change in size and there is no way +to avoid this. _sys_errlist is a good example. Occasionally there are +new error numbers added to the kernel and this must be reflected at user +level, breaking programs that refer to them directly. + +Such symbols should normally not be used at all. There are mechanisms +to avoid using them. In the case of _sys_errlist, there is the +strerror() function which should _always_ be used instead. So the +correct fix is to rewrite that part of the application. + +In some situations (especially when testing a new library release) it +might be possible that a symbol changed size when that should not have +happened. So in case of doubt report such a warning message as a +problem. + +? Source and binary incompatibilities, and what to do about them + +?? I expect GNU libc to be 100% source code compatible with + the old Linux based GNU libc. Why isn't it like this? + +{DMT,UD} Not every extension in Linux libc's history was well +thought-out. In fact it had a lot of problems with standards compliance +and with cleanliness. With the introduction of a new version number these +errors can now be corrected. Here is a list of the known source code +incompatibilities: + +* _GNU_SOURCE: glibc does not make the GNU extensions available + automatically. If a program depends on GNU extensions or some + other non-standard functionality, it is necessary to compile it + with the C compiler option -D_GNU_SOURCE, or better, to put + `#define _GNU_SOURCE' at the beginning of your source files, before + any C library header files are included. This difference normally + manifests itself in the form of missing prototypes and/or data type + definitions. Thus, if you get such errors, the first thing you + should do is try defining _GNU_SOURCE and see if that makes the + problem go away. + + For more information consult the file `NOTES' in the GNU C library + sources. + +* reboot(): GNU libc sanitizes the interface of reboot() to be more + compatible with the interface used on other OSes. reboot() as + implemented in glibc takes just one argument. This argument + corresponds to the third argument of the Linux reboot system call. + That is, a call of the form reboot(a, b, c) needs to be changed into + reboot(c). Beside this the header <sys/reboot.h> defines the needed + constants for the argument. These RB_* constants should be used + instead of the cryptic magic numbers. + +* swapon(): the interface of this function didn't change, but the + prototype is in a separate header file <sys/swap.h>. This header + file also provides the SWAP_* constants defined by <linux/swap.h>; + you should use them for the second argument to swapon(). + +* errno: If a program uses the variable "errno", then it _must_ + include <errno.h>. The old libc often (erroneously) declared this + variable implicitly as a side-effect of including other libc header + files. glibc is careful to avoid such namespace pollution, which, + in turn, means that you really need to include the header files that + you depend on. This difference normally manifests itself in the + form of the compiler complaining about references to an undeclared + symbol "errno". + +* Linux-specific syscalls: All Linux system calls now have appropriate + library wrappers and corresponding declarations in various header files. + This is because the syscall() macro that was traditionally used to + work around missing syscall wrappers are inherently non-portable and + error-prone. The following table lists all the new syscall stubs, + the header-file declaring their interface and the system call name. + + syscall name: wrapper name: declaring header file: + ------------- ------------- ---------------------- + bdflush bdflush <sys/kdaemon.h> + syslog ksyslog_ctl <sys/klog.h> + +* lpd: Older versions of lpd depend on a routine called _validuser(). + The library does not provide this function, but instead provides + __ivaliduser() which has a slightly different interface. Simply + upgrading to a newer lpd should fix this problem (e.g., the 4.4BSD + lpd is known to be working). + +* resolver functions/BIND: like on many other systems the functions of + the resolver library are not included in libc itself. There is a + separate library libresolv. If you get undefined symbol errors for + symbols starting with `res_*' simply add -lresolv to your linker + command line. + +* the `signal' function's behavior corresponds to the BSD semantic and + not the SysV semantic as it was in libc-5. The interface on all GNU + systems shall be the same and BSD is the semantic of choice. To use + the SysV behavior simply use `sysv_signal', or define _XOPEN_SOURCE. + See ?signal for details. + +??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. + +{MK} There is however a (partial) solution for this problem. Please +take a look at the file `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). + +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. + +??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. + +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. + +?? 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 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 fixes 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. + +There are three differences: + +* BSD-style signals that occur in the middle of a system call do not + affect the system call; System V signals cause the system call to + fail and set errno to EINTR. + +* BSD signal handlers remain installed once triggered. System V signal + handlers work only once, so one must reinstall them each time. + +* A BSD signal is blocked during the execution of its handler. In other + words, a handler for SIGCHLD (for example) does not need to worry about + being interrupted by another SIGCHLD. It may, however, be interrupted + by other signals. + +There is general consensus that for `casual' programming with signals, the +BSD semantics are preferable. You don't need to worry about system calls +returning EINTR, and you don't need to worry about the race conditions +associated with one-shot signal handlers. + +If you are porting an old program that relies on the old semantics, you can +quickly fix the problem by changing signal() to sysv_signal() throughout. +Alternatively, define _XOPEN_SOURCE before including <signal.h>. + +For new programs, the sigaction() function allows you to specify precisely +how you want your signals to behave. All three differences listed above are +individually switchable on a per-signal basis with this function. + +If all you want is for one specific signal to cause system calls to fail +and return EINTR (for example, to implement a timeout) you can do this with +siginterrupt(). + + +??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. + +The optimized string functions are only used when compiling with +optimizations (-O1 or higher). The behavior can be changed with two +feature macros: + +* __NO_STRING_INLINES: Don't do any string optimizations. +* __USE_STRING_INLINES: Use assembly language inline functions (might + increase code size dramatically). + +Since some of these string functions are now additionally defined as +macros, code like "char *strncpy();" doesn't work anymore (and is +unnecessary, since <string.h> has the necessary declarations). Either +change your code or define __NO_STRING_INLINES. + +{UD} Another problem in this area is that gcc still has problems on +machines with very few registers (e.g., ix86). The inline assembler +code can require almost all the registers and the register allocator +cannot always handle this situation. + +One can disable the string optimizations selectively. Instead of writing + + cp = strcpy (foo, "lkj"); + +one can write + + cp = (strcpy) (foo, "lkj"); + +This disables the optimization for that specific call. + +? Miscellaneous + +?? After I changed configure.in I get `Autoconf version X.Y. + or higher is required for this script'. What can I do? + +{UD} You have to get the specified autoconf version (or a later one) +from your favorite mirror of prep.ai.mit.edu. + +?? When I try to compile code which uses IPv6 headers and + definitions on my Linux 2.x.y system I am in trouble. + Nothing seems to work. + +{UD} The problem is that IPv6 development still has not reached a +point where the headers are stable. There are still lots of +incompatible changes made and the libc headers have to follow. + +Also, make sure you have a suitably recent kernel. As of the 970401 +snapshot, according to Philip Blundell <philb@gnu.ai.mit.edu>, the +required kernel version is 2.1.30. + + +Answers were given by: +{UD} Ulrich Drepper, <drepper@cygnus.com> +{DMT} David Mosberger-Tang, <davidm@AZStarNet.com> +{RM} Roland McGrath, <roland@gnu.org> +{AJ} Andreas Jaeger, <aj@arthur.rhein-neckar.de> +{EY} Eric Youngdale, <eric@andante.jic.com> +{PB} Phil Blundell, <Philip.Blundell@pobox.com> +{MK} Mark Kettenis, <kettenis@phys.uva.nl> +{ZW} Zack Weinberg, <zack@rabi.phys.columbia.edu> + +Local Variables: + mode:outline + outline-regexp:"\\?" +End: diff --git a/Makeconfig b/Makeconfig index 4d816a0815..44afe0fe30 100644 --- a/Makeconfig +++ b/Makeconfig @@ -688,7 +688,7 @@ ifndef rtld-version-installed-name rtld-version-installed-name = ld-$(version).so endif -# The librt must contain be linked with the thread library. It least +# The librt must be linked with the thread library, at least # for now. ifneq (,$(findstring linuxthreads,$(add-ons))) shared-thread-library = $(common-objpfx)linuxthreads/libpthread.so @@ -329,6 +329,8 @@ INSTALL: manual/maint.texi; $(format-me) NOTES: manual/creature.texi; $(format-me) manual/dir-add.texi manual/dir-add.info: FORCE $(MAKE) $(PARALLELMFLAGS) -C $(@D) $(@F) +FAQ: gen-FAQ.pl FAQ.in + $(PERL) $^ > $@.new && rm -f $@ && mv $@.new $@ && chmod a-w $@ FORCE: rpm/%: subdir_distinfo @@ -692,11 +692,16 @@ fi # Check whether --enable-add-ons or --disable-add-ons was given. if test "${enable_add_ons+set}" = set; then enableval="$enable_add_ons" - add_ons=`echo "$enableval" | sed 's/,/ /g'` + case "$enableval" in + yes) add_ons=`echo $srcdir/*/configure | \ + sed -e "s!$srcdir/!!g" -e 's!/configure!!g'`;; + *) add_ons=`echo "$enableval" | sed 's/,/ /g'`;; + esac else add_ons= fi + ac_aux_dir= for ac_dir in $srcdir $srcdir/.. $srcdir/../..; do if test -f $ac_dir/install-sh; then @@ -752,7 +757,7 @@ else { echo "configure: error: can not run $ac_config_sub" 1>&2; exit 1; } fi echo $ac_n "checking host system type""... $ac_c" 1>&6 -echo "configure:756: checking host system type" >&5 +echo "configure:761: checking host system type" >&5 host_alias=$host case "$host_alias" in @@ -871,7 +876,7 @@ fi # This can take a while to compute. sysdep_dir=$srcdir/sysdeps echo $ac_n "checking sysdep dirs""... $ac_c" 1>&6 -echo "configure:875: checking sysdep dirs" >&5 +echo "configure:880: checking sysdep dirs" >&5 # Make sco3.2v4 become sco3.2.4 and sunos4.1.1_U1 become sunos4.1.1.U1. os="`echo $os | sed 's/\([0-9A-Z]\)[v_]\([0-9A-Z]\)/\1.\2/g'`" @@ -1072,7 +1077,7 @@ echo "$ac_t""sysdeps/generic" 1>&6 # SVR4 /usr/ucb/install, which tries to use the nonexistent group "staff" # ./install, which can be erroneously created by make from ./install.sh. echo $ac_n "checking for a BSD compatible install""... $ac_c" 1>&6 -echo "configure:1076: checking for a BSD compatible install" >&5 +echo "configure:1081: checking for a BSD compatible install" >&5 if test -z "$INSTALL"; then if eval "test \"`echo '$''{'ac_cv_path_install'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 @@ -1126,7 +1131,7 @@ if test "$INSTALL" = "${srcdir}/install-sh -c"; then INSTALL='\$(..)./install-sh -c' fi echo $ac_n "checking whether ln -s works""... $ac_c" 1>&6 -echo "configure:1130: checking whether ln -s works" >&5 +echo "configure:1135: checking whether ln -s works" >&5 if eval "test \"`echo '$''{'ac_cv_prog_LN_S'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1151,7 +1156,7 @@ do # Extract the first word of "$ac_prog", so it can be a program name with args. set dummy $ac_prog; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 -echo "configure:1155: checking for $ac_word" >&5 +echo "configure:1160: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_MSGFMT'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1183,7 +1188,7 @@ test -n "$MSGFMT" || MSGFMT=":" # Extract the first word of "makeinfo", so it can be a program name with args. set dummy makeinfo; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 -echo "configure:1187: checking for $ac_word" >&5 +echo "configure:1192: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_MAKEINFO'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1223,7 +1228,7 @@ fi # Extract the first word of "gcc", so it can be a program name with args. set dummy gcc; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 -echo "configure:1227: checking for $ac_word" >&5 +echo "configure:1232: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_CC'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1252,7 +1257,7 @@ if test -z "$CC"; then # Extract the first word of "cc", so it can be a program name with args. set dummy cc; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 -echo "configure:1256: checking for $ac_word" >&5 +echo "configure:1261: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_CC'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1300,7 +1305,7 @@ fi fi echo $ac_n "checking whether the C compiler ($CC $CFLAGS $LDFLAGS) works""... $ac_c" 1>&6 -echo "configure:1304: checking whether the C compiler ($CC $CFLAGS $LDFLAGS) works" >&5 +echo "configure:1309: checking whether the C compiler ($CC $CFLAGS $LDFLAGS) works" >&5 ac_ext=c # CFLAGS is not in ac_cpp because -g, -O, etc. are not valid cpp options. @@ -1310,11 +1315,11 @@ ac_link='${CC-cc} -o conftest $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS cross_compiling=$ac_cv_prog_cc_cross cat > conftest.$ac_ext <<EOF -#line 1314 "configure" +#line 1319 "configure" #include "confdefs.h" main(){return(0);} EOF -if { (eval echo configure:1318: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then +if { (eval echo configure:1323: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then ac_cv_prog_cc_works=yes # If we can't run a trivial program, we are probably using a cross compiler. if (./conftest; exit) 2>/dev/null; then @@ -1337,13 +1342,13 @@ else cross_linkable=yes fi echo $ac_n "checking whether the C compiler ($CC $CFLAGS $LDFLAGS) is a cross-compiler""... $ac_c" 1>&6 -echo "configure:1341: checking whether the C compiler ($CC $CFLAGS $LDFLAGS) is a cross-compiler" >&5 +echo "configure:1346: checking whether the C compiler ($CC $CFLAGS $LDFLAGS) is a cross-compiler" >&5 echo "$ac_t""$ac_cv_prog_cc_cross" 1>&6 cross_compiling=$ac_cv_prog_cc_cross echo $ac_n "checking whether we are using GNU C""... $ac_c" 1>&6 -echo "configure:1347: checking whether we are using GNU C" >&5 +echo "configure:1352: checking whether we are using GNU C" >&5 if eval "test \"`echo '$''{'ac_cv_prog_gcc'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1352,7 +1357,7 @@ else yes; #endif EOF -if { ac_try='${CC-cc} -E conftest.c'; { (eval echo configure:1356: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } | egrep yes >/dev/null 2>&1; then +if { ac_try='${CC-cc} -E conftest.c'; { (eval echo configure:1361: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } | egrep yes >/dev/null 2>&1; then ac_cv_prog_gcc=yes else ac_cv_prog_gcc=no @@ -1369,7 +1374,7 @@ if test $ac_cv_prog_gcc = yes; then yes; #endif EOF - if { ac_try='${CC-cc} -E conftest.c'; { (eval echo configure:1373: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } | egrep yes >/dev/null 2>&1; then + if { ac_try='${CC-cc} -E conftest.c'; { (eval echo configure:1378: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } | egrep yes >/dev/null 2>&1; then if test -z "$CFLAGS"; then CFLAGS="-g -O2" fi @@ -1381,7 +1386,7 @@ else fi echo $ac_n "checking build system type""... $ac_c" 1>&6 -echo "configure:1385: checking build system type" >&5 +echo "configure:1390: checking build system type" >&5 build_alias=$build case "$build_alias" in @@ -1404,7 +1409,7 @@ do # Extract the first word of "$ac_prog", so it can be a program name with args. set dummy $ac_prog; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 -echo "configure:1408: checking for $ac_word" >&5 +echo "configure:1413: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_BUILD_CC'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1435,7 +1440,7 @@ done fi echo $ac_n "checking how to run the C preprocessor""... $ac_c" 1>&6 -echo "configure:1439: checking how to run the C preprocessor" >&5 +echo "configure:1444: checking how to run the C preprocessor" >&5 # On Suns, sometimes $CPP names a directory. if test -n "$CPP" && test -d "$CPP"; then CPP= @@ -1450,13 +1455,13 @@ else # On the NeXT, cc -E runs the code through the compiler's parser, # not just through cpp. cat > conftest.$ac_ext <<EOF -#line 1454 "configure" +#line 1459 "configure" #include "confdefs.h" #include <assert.h> Syntax Error EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" -{ (eval echo configure:1460: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } +{ (eval echo configure:1465: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out` if test -z "$ac_err"; then : @@ -1467,13 +1472,13 @@ else rm -rf conftest* CPP="${CC-cc} -E -traditional-cpp" cat > conftest.$ac_ext <<EOF -#line 1471 "configure" +#line 1476 "configure" #include "confdefs.h" #include <assert.h> Syntax Error EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" -{ (eval echo configure:1477: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } +{ (eval echo configure:1482: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out` if test -z "$ac_err"; then : @@ -1506,7 +1511,7 @@ LD=`$CC -print-file-name=ld` # Determine whether we are using GNU binutils. echo $ac_n "checking whether $AS is GNU as""... $ac_c" 1>&6 -echo "configure:1510: checking whether $AS is GNU as" >&5 +echo "configure:1515: checking whether $AS is GNU as" >&5 if eval "test \"`echo '$''{'libc_cv_prog_as_gnu'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1524,7 +1529,7 @@ rm -f a.out gnu_as=$libc_cv_prog_as_gnu echo $ac_n "checking whether $LD is GNU ld""... $ac_c" 1>&6 -echo "configure:1528: checking whether $LD is GNU ld" >&5 +echo "configure:1533: checking whether $LD is GNU ld" >&5 if eval "test \"`echo '$''{'libc_cv_prog_ld_gnu'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1548,7 +1553,7 @@ fi # Extract the first word of "${ac_tool_prefix}ar", so it can be a program name with args. set dummy ${ac_tool_prefix}ar; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 -echo "configure:1552: checking for $ac_word" >&5 +echo "configure:1557: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_AR'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1579,7 +1584,7 @@ fi # Extract the first word of "${ac_tool_prefix}ranlib", so it can be a program name with args. set dummy ${ac_tool_prefix}ranlib; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 -echo "configure:1583: checking for $ac_word" >&5 +echo "configure:1588: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_RANLIB'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1610,7 +1615,7 @@ if test -n "$ac_tool_prefix"; then # Extract the first word of "ranlib", so it can be a program name with args. set dummy ranlib; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 -echo "configure:1614: checking for $ac_word" >&5 +echo "configure:1619: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_RANLIB'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1645,7 +1650,7 @@ fi # Extract the first word of "bash", so it can be a program name with args. set dummy bash; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 -echo "configure:1649: checking for $ac_word" >&5 +echo "configure:1654: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_path_BASH'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1687,7 +1692,7 @@ if test "$BASH" = no; then # Extract the first word of "ksh", so it can be a program name with args. set dummy ksh; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 -echo "configure:1691: checking for $ac_word" >&5 +echo "configure:1696: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_path_KSH'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1733,7 +1738,7 @@ do # Extract the first word of "$ac_prog", so it can be a program name with args. set dummy $ac_prog; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 -echo "configure:1737: checking for $ac_word" >&5 +echo "configure:1742: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_path_PERL'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1768,7 +1773,7 @@ test -n "$PERL" || PERL="no" echo $ac_n "checking for signed size_t type""... $ac_c" 1>&6 -echo "configure:1772: checking for signed size_t type" >&5 +echo "configure:1777: checking for signed size_t type" >&5 if eval "test \"`echo '$''{'libc_cv_signed_size_t'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1792,12 +1797,12 @@ EOF fi echo $ac_n "checking for libc-friendly stddef.h""... $ac_c" 1>&6 -echo "configure:1796: checking for libc-friendly stddef.h" >&5 +echo "configure:1801: checking for libc-friendly stddef.h" >&5 if eval "test \"`echo '$''{'libc_cv_friendly_stddef'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 1801 "configure" +#line 1806 "configure" #include "confdefs.h" #define __need_size_t #define __need_wchar_t @@ -1812,7 +1817,7 @@ size_t size; wchar_t wchar; if (&size == NULL || &wchar == NULL) abort (); ; return 0; } EOF -if { (eval echo configure:1816: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:1821: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* libc_cv_friendly_stddef=yes else @@ -1831,7 +1836,7 @@ override stddef.h = # The installed <stddef.h> seems to be libc-friendly." fi echo $ac_n "checking whether we need to use -P to assemble .S files""... $ac_c" 1>&6 -echo "configure:1835: checking whether we need to use -P to assemble .S files" >&5 +echo "configure:1840: checking whether we need to use -P to assemble .S files" >&5 if eval "test \"`echo '$''{'libc_cv_need_minus_P'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1862,7 +1867,7 @@ if test $ac_cv_prog_gcc = yes; then # We must check this even if -pipe is not given here, because the user # might do `make CFLAGS=-pipe'. echo $ac_n "checking for gcc 2.7.x -pipe bug""... $ac_c" 1>&6 -echo "configure:1866: checking for gcc 2.7.x -pipe bug" >&5 +echo "configure:1871: checking for gcc 2.7.x -pipe bug" >&5 if eval "test \"`echo '$''{'libc_cv_gcc_pipe_bug'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1891,7 +1896,7 @@ else fi echo $ac_n "checking for assembler global-symbol directive""... $ac_c" 1>&6 -echo "configure:1895: checking for assembler global-symbol directive" >&5 +echo "configure:1900: checking for assembler global-symbol directive" >&5 if eval "test \"`echo '$''{'libc_cv_asm_global_directive'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1921,7 +1926,7 @@ EOF fi echo $ac_n "checking for .set assembler directive""... $ac_c" 1>&6 -echo "configure:1925: checking for .set assembler directive" >&5 +echo "configure:1930: checking for .set assembler directive" >&5 if eval "test \"`echo '$''{'libc_cv_asm_set_directive'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1955,7 +1960,7 @@ EOF fi echo $ac_n "checking for .symver assembler directive""... $ac_c" 1>&6 -echo "configure:1959: checking for .symver assembler directive" >&5 +echo "configure:1964: checking for .symver assembler directive" >&5 if eval "test \"`echo '$''{'libc_cv_asm_symver_directive'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1974,7 +1979,7 @@ fi echo "$ac_t""$libc_cv_asm_symver_directive" 1>&6 echo $ac_n "checking for ld --version-script""... $ac_c" 1>&6 -echo "configure:1978: checking for ld --version-script" >&5 +echo "configure:1983: checking for ld --version-script" >&5 if eval "test \"`echo '$''{'libc_cv_ld_version_script_option'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1997,7 +2002,7 @@ EOF if { ac_try='${CC-cc} $CFLAGS -shared -o conftest.so conftest.o -nostartfiles -nostdlib -Wl,--version-script,conftest.map - 1>&5'; { (eval echo configure:2001: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; + 1>&5'; { (eval echo configure:2006: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then libc_cv_ld_version_script_option=yes else @@ -2035,7 +2040,7 @@ if test $VERSIONING = no; then fi if test $elf = yes; then echo $ac_n "checking for .previous assembler directive""... $ac_c" 1>&6 -echo "configure:2039: checking for .previous assembler directive" >&5 +echo "configure:2044: checking for .previous assembler directive" >&5 if eval "test \"`echo '$''{'libc_cv_asm_previous_directive'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -2043,7 +2048,7 @@ else .section foo_section .previous EOF - if { ac_try='${CC-cc} -c $CFLAGS conftest.s 1>&5'; { (eval echo configure:2047: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then + if { ac_try='${CC-cc} -c $CFLAGS conftest.s 1>&5'; { (eval echo configure:2052: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then libc_cv_asm_previous_directive=yes else libc_cv_asm_previous_directive=no @@ -2059,7 +2064,7 @@ EOF else echo $ac_n "checking for .popsection assembler directive""... $ac_c" 1>&6 -echo "configure:2063: checking for .popsection assembler directive" >&5 +echo "configure:2068: checking for .popsection assembler directive" >&5 if eval "test \"`echo '$''{'libc_cv_asm_popsection_directive'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -2067,7 +2072,7 @@ else .pushsection foo_section .popsection EOF - if { ac_try='${CC-cc} -c $CFLAGS conftest.s 1>&5'; { (eval echo configure:2071: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then + if { ac_try='${CC-cc} -c $CFLAGS conftest.s 1>&5'; { (eval echo configure:2076: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then libc_cv_asm_popsection_directive=yes else libc_cv_asm_popsection_directive=no @@ -2087,12 +2092,12 @@ fi if test $elf != yes; then echo $ac_n "checking for .init and .fini sections""... $ac_c" 1>&6 -echo "configure:2091: checking for .init and .fini sections" >&5 +echo "configure:2096: checking for .init and .fini sections" >&5 if eval "test \"`echo '$''{'libc_cv_have_initfini'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 2096 "configure" +#line 2101 "configure" #include "confdefs.h" int main() { @@ -2101,7 +2106,7 @@ asm (".section .init"); asm (".text"); ; return 0; } EOF -if { (eval echo configure:2105: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:2110: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* libc_cv_have_initfini=yes else @@ -2129,19 +2134,19 @@ if test $elf = yes; then else if test $ac_cv_prog_cc_works = yes; then echo $ac_n "checking for _ prefix on C symbol names""... $ac_c" 1>&6 -echo "configure:2133: checking for _ prefix on C symbol names" >&5 +echo "configure:2138: checking for _ prefix on C symbol names" >&5 if eval "test \"`echo '$''{'libc_cv_asm_underscores'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 2138 "configure" +#line 2143 "configure" #include "confdefs.h" asm ("_glibc_foobar:"); int main() { glibc_foobar (); ; return 0; } EOF -if { (eval echo configure:2145: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then +if { (eval echo configure:2150: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then rm -rf conftest* libc_cv_asm_underscores=yes else @@ -2156,17 +2161,17 @@ fi echo "$ac_t""$libc_cv_asm_underscores" 1>&6 else echo $ac_n "checking for _ prefix on C symbol names""... $ac_c" 1>&6 -echo "configure:2160: checking for _ prefix on C symbol names" >&5 +echo "configure:2165: checking for _ prefix on C symbol names" >&5 if eval "test \"`echo '$''{'libc_cv_asm_underscores'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 2165 "configure" +#line 2170 "configure" #include "confdefs.h" void underscore_test(void) { return; } EOF -if { (eval echo configure:2170: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:2175: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then if grep _underscore_test conftest* >/dev/null; then rm -f conftest* libc_cv_asm_underscores=yes @@ -2199,7 +2204,7 @@ if test $elf = yes; then libc_cv_asm_weakext_directive=no else echo $ac_n "checking for assembler .weak directive""... $ac_c" 1>&6 -echo "configure:2203: checking for assembler .weak directive" >&5 +echo "configure:2208: checking for assembler .weak directive" >&5 if eval "test \"`echo '$''{'libc_cv_asm_weak_directive'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -2222,7 +2227,7 @@ echo "$ac_t""$libc_cv_asm_weak_directive" 1>&6 if test $libc_cv_asm_weak_directive = no; then echo $ac_n "checking for assembler .weakext directive""... $ac_c" 1>&6 -echo "configure:2226: checking for assembler .weakext directive" >&5 +echo "configure:2231: checking for assembler .weakext directive" >&5 if eval "test \"`echo '$''{'libc_cv_asm_weakext_directive'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -2259,7 +2264,7 @@ EOF fi echo $ac_n "checking for ld --no-whole-archive""... $ac_c" 1>&6 -echo "configure:2263: checking for ld --no-whole-archive" >&5 +echo "configure:2268: checking for ld --no-whole-archive" >&5 if eval "test \"`echo '$''{'libc_cv_ld_no_whole_archive'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -2270,7 +2275,7 @@ __throw () {} EOF if { ac_try='${CC-cc} $CFLAGS -nostdlib -nostartfiles -Wl,--no-whole-archive - -o conftest conftest.c 1>&5'; { (eval echo configure:2274: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then + -o conftest conftest.c 1>&5'; { (eval echo configure:2279: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then libc_cv_ld_no_whole_archive=yes else libc_cv_ld_no_whole_archive=no @@ -2281,7 +2286,7 @@ fi echo "$ac_t""$libc_cv_ld_no_whole_archive" 1>&6 echo $ac_n "checking for gcc -fno-exceptions""... $ac_c" 1>&6 -echo "configure:2285: checking for gcc -fno-exceptions" >&5 +echo "configure:2290: checking for gcc -fno-exceptions" >&5 if eval "test \"`echo '$''{'libc_cv_gcc_no_exceptions'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -2292,7 +2297,7 @@ __throw () {} EOF if { ac_try='${CC-cc} $CFLAGS -nostdlib -nostartfiles -fno-exceptions - -o conftest conftest.c 1>&5'; { (eval echo configure:2296: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then + -o conftest conftest.c 1>&5'; { (eval echo configure:2301: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then libc_cv_gcc_no_exceptions=yes else libc_cv_gcc_no_exceptions=no @@ -2303,12 +2308,12 @@ fi echo "$ac_t""$libc_cv_gcc_no_exceptions" 1>&6 echo $ac_n "checking for DWARF2 unwind info support""... $ac_c" 1>&6 -echo "configure:2307: checking for DWARF2 unwind info support" >&5 +echo "configure:2312: checking for DWARF2 unwind info support" >&5 if eval "test \"`echo '$''{'libc_cv_gcc_dwarf2_unwind_info'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.c <<EOF -#line 2312 "configure" +#line 2317 "configure" static char __EH_FRAME_BEGIN__; _start () { @@ -2329,7 +2334,7 @@ __bzero () {} EOF if { ac_try='${CC-cc} $CFLAGS -nostdlib -nostartfiles - -o conftest conftest.c -lgcc >&5'; { (eval echo configure:2333: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then + -o conftest conftest.c -lgcc >&5'; { (eval echo configure:2338: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then libc_cv_gcc_dwarf2_unwind_info=yes else libc_cv_gcc_dwarf2_unwind_info=no @@ -2387,7 +2392,7 @@ if test "$uname" = "sysdeps/generic"; then fi echo $ac_n "checking OS release for uname""... $ac_c" 1>&6 -echo "configure:2391: checking OS release for uname" >&5 +echo "configure:2396: checking OS release for uname" >&5 if eval "test \"`echo '$''{'libc_cv_uname_release'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -2409,7 +2414,7 @@ echo "$ac_t""$libc_cv_uname_release" 1>&6 uname_release="$libc_cv_uname_release" echo $ac_n "checking OS version for uname""... $ac_c" 1>&6 -echo "configure:2413: checking OS version for uname" >&5 +echo "configure:2418: checking OS version for uname" >&5 if eval "test \"`echo '$''{'libc_cv_uname_version'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -2431,7 +2436,7 @@ else fi echo $ac_n "checking stdio selection""... $ac_c" 1>&6 -echo "configure:2435: checking stdio selection" >&5 +echo "configure:2440: checking stdio selection" >&5 case $stdio in libio) cat >> confdefs.h <<\EOF @@ -2443,7 +2448,7 @@ esac echo "$ac_t""$stdio" 1>&6 echo $ac_n "checking ldap selection""... $ac_c" 1>&6 -echo "configure:2447: checking ldap selection" >&5 +echo "configure:2452: checking ldap selection" >&5 case $add_ons in *ldap*) @@ -2493,7 +2498,7 @@ if test $shared = default; then fi echo $ac_n "checking whether -fPIC is default""... $ac_c" 1>&6 -echo "configure:2497: checking whether -fPIC is default" >&5 +echo "configure:2502: checking whether -fPIC is default" >&5 if eval "test \"`echo '$''{'pic_default'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else diff --git a/configure.in b/configure.in index 2ff1af5c00..80fe259b32 100644 --- a/configure.in +++ b/configure.in @@ -82,8 +82,13 @@ AC_ARG_ENABLE(versioning, dnl dnl Generic infrastructure for drop-in additions to libc. AC_ARG_ENABLE(add-ons, dnl [ --enable-add-ons=DIR1,DIR2... configure and build named extra directories], - [add_ons=`echo "$enableval" | sed 's/,/ /g'`], - [add_ons=]) + [case "$enableval" in + yes) add_ons=`echo $srcdir/*/configure | \ + sed -e "s!$srcdir/!!g" -e 's!/configure!!g'`;; + *) add_ons=`echo "$enableval" | sed 's/,/ /g'`;; + esac], + [add_ons=]) + AC_CONFIG_SUBDIRS($add_ons) add_ons_pfx= if test x"$add_ons" != x; then diff --git a/gen-FAQ.pl b/gen-FAQ.pl new file mode 100755 index 0000000000..e8b55ac7ab --- /dev/null +++ b/gen-FAQ.pl @@ -0,0 +1,144 @@ +#! /usr/local/bin/perl + +=pod +This is a silly little program for generating the libc FAQ. + +The input format is: +top boilerplate +^L +? section name (one line) +?? question... +... +{ID} answer... +... +^L +{ID} name <email@address> +... + +which gets mapped to: + +top boilerplate +^L +1. section 1... +1.1. q1.1 +1.2. q1.2 +... +^L +1. section 1... + +1.1. q1.1 + +answer 1.1.... + + +^L +Answers were provided by: +... + +=cut + +# We slurp the whole file into a pair of assoc arrays indexed by +# the 'section.question' number. +%questions = (); +%answers = (); +$question = 0; + +# These arrays and counter keep track of the sections. +@sectcount = (); +@sections = (); +$section = 0; + +# Cross reference list. +%refs = (); + +# Separators. +$sepmaj = "\f\n" . ('~ ' x 36) . "\n\n"; +$sepmin = "\f\n" . ('. ' x 36) . "\n\n"; + +# Pass through the top boilerplate. +while(<>) +{ + last if $_ eq "\f\n"; + print; +} + +# Now the body. +while(<>) +{ + /\f/ && do + { + $sectcount[$section] = $question; + last; + }; + + s/^\?\s+// && do + { + chomp; + $sectcount[$section] = $question if $section > 0; + $section++; + $sections[$section] = $_; + $question = 0; + next; + }; + s/^\?\?(\w*?)\s+// && do + { + $cur = \%questions; + $question++; + $questions{$section,$question} = $_; + $refs{$1} = "$section.$question" if $1 ne ""; + next; + }; + /^\{/ && do + { + $cur = \%answers; + $answers{$section,$question} .= $_; + next; + }; + + ${$cur}{$section,$question} .= $_; +} + +# Now we have to clean up the newlines and deal with cross references. +foreach(keys %questions) { $questions{$_} =~ s/\n+$//; } +foreach(keys %answers) +{ + $answers{$_} =~ s/\n+$//; + $answers{$_} =~ s/(\s)\?(\w+)\b/$1 . "question " . ($refs{$2} or badref($2,$_), "!!$2")/eg; +} + +# Now output the formatted FAQ. +print $sepmaj; +for($i = 1; $i <= $section; $i++) +{ + print "$i. $sections[$i]\n\n"; + for($j = 1; $j <= $sectcount[$i]; $j++) + { + print "$i.$j.\t$questions{$i,$j}\n"; + } + print "\n"; +} + +print $sepmaj; +for($i = 1; $i <= $section; $i++) +{ + print "$i. $sections[$i]\n\n"; + for($j = 1; $j <= $sectcount[$i]; $j++) + { + print "$i.$j.\t$questions{$i,$j}\n\n"; + print $answers{$i,$j}, "\n\n"; + print "\n" if $j < $sectcount[$i]; + } + print $sepmin if $i < $section; +} + +print $sepmaj; + +# Pass through the trailer. +while(<>) { print; } + +sub badref +{ + my($ref,$quest) = @_; + $quest =~ s/$;/./; + print STDERR "Undefined reference to $ref in answer to Q$quest\n"; +} diff --git a/iconvdata/Makefile b/iconvdata/Makefile index f08a090363..52fbace463 100644 --- a/iconvdata/Makefile +++ b/iconvdata/Makefile @@ -25,7 +25,8 @@ subdir := iconvdata modules := ISO8859-1 ISO8859-2 ISO8859-3 ISO8859-4 ISO8859-5 \ ISO8859-6 ISO8859-7 ISO8859-8 ISO8859-9 ISO8859-10 \ T.61 ISO_6937 SJIS KOI-8 KOI8-R LATIN-GREEK LATIN-GREEK-1 \ - HP-ROMAN8 EBCDIC-AT-DE EBCDIC-AT-DE-A EBCDIC-CA-FR + HP-ROMAN8 EBCDIC-AT-DE EBCDIC-AT-DE-A EBCDIC-CA-FR \ + libJIS modules.so := $(addsuffix .so, $(modules)) @@ -52,12 +53,7 @@ HP-ROMAN8-routines := hp-roman8 EBCDIC-AT-DE-routines := ebcdic-at-de EBCDIC-AT-DE-A-routines := ebcdic-at-de-a EBCDIC-CA-FR-routines := ebcdic-ca-fr - -extra-libs = libJIS -extra-libs-others = $(extra-libs) - libJIS-routines := jis0201 jis0208 jis0212 -libJIS-inhibit-o := $(filter-out .os,$(object-suffixes)) distribute := 8bit-generic.c 8bit-gap.c gap.pl gaptab.pl \ iso8859-1.c iso8859-2.c iso8859-3.c iso8859-4.c iso8859-5.c \ diff --git a/rt/librt.map b/rt/librt.map new file mode 100644 index 0000000000..375a02877e --- /dev/null +++ b/rt/librt.map @@ -0,0 +1,11 @@ +GLIBC_2.1 { + global: + + # AIO functions. + aio_cancel; aio_cancel64; aio_error; aio_error64; aio_fsync; aio_fsync64; + aio_read; aio_read64; aio_return; aio_return64; aio_suspend; aio_suspend64; + aio_write; aio_write64; lio_listio; lio_listio64; + + local: + *; +}; diff --git a/string/bits/string2.h b/string/bits/string2.h index f0172bf186..8779e35817 100644 --- a/string/bits/string2.h +++ b/string/bits/string2.h @@ -25,11 +25,11 @@ #ifndef __NO_STRING_INLINES /* Unlike the definitions in the header <bits/string.h> the - definitions contained here are not optimizing down to assembler - level. These optimizations are not always a good idea since this + definitions contained here are not optimized down to assembler + level. Those optimizations are not always a good idea since this means the code size increases a lot. Instead the definitions here - optimize some functions in a way which does not dramatically - increase the code size and which does not use assembler. The main + optimize some functions in a way which do not dramatically + increase the code size and which do not use assembler. The main trick is to use GNU CC's `__builtin_constant_p' function. Every function XXX which has a defined version in diff --git a/string/string.h b/string/string.h index 39d1d61193..2b4d6b9545 100644 --- a/string/string.h +++ b/string/string.h @@ -298,18 +298,18 @@ extern char *basename __P ((__const char *__filename)); /* When using GNU CC we provide some optimized versions of selected functions from this header. There are two kinds of optimizations: - - machine-dependent optmizations, most probably using inline - assembler code; these could be quite expensive since the code - size could increase significantly. + - machine-dependent optimizations, most probably using inline + assembler code; these might be quite expensive since the code + size can increase significantly. These optimizations are not used unless the symbol __USE_STRING_INLINES - is defined before including this header + is defined before including this header. - machine-independent optimizations which do not increase the code size significantly and which optimize mainly situations where one or more arguments are compile-time constants. These optimizations are used always when the compiler is - taught to optimized. + taught to optimize. One can inhibit all optimizations by defining __NO_STRING_INLINES. */ diff --git a/sunrpc/xcrypt.c b/sunrpc/xcrypt.c index ec4110036c..d770a7d648 100644 --- a/sunrpc/xcrypt.c +++ b/sunrpc/xcrypt.c @@ -62,7 +62,7 @@ static char hex[16] = (c >= '0' && c <= '9' \ ? c - '0' \ : ({ int upp = toupper (c); \ - upp >= 'a' && upp <= 'z' ? upp - 'a' + 10 : -1; })) + upp >= 'A' && upp <= 'Z' ? upp - 'A' + 10 : -1; })) #else static char hexval (char) internal_function; #endif diff --git a/sysdeps/generic/enbl-secure.c b/sysdeps/generic/enbl-secure.c index 8e1327c878..3520ad5fb0 100644 --- a/sysdeps/generic/enbl-secure.c +++ b/sysdeps/generic/enbl-secure.c @@ -32,7 +32,7 @@ uid_t __libc_uid; void __libc_init_secure (void) { - __libc_uid == __getuid (); + __libc_uid = __getuid (); __libc_enable_secure = (__geteuid () != __libc_uid || __getegid () != __getgid ()); } diff --git a/sysdeps/unix/sysv/linux/bits/socket.h b/sysdeps/unix/sysv/linux/bits/socket.h index f48f2d1403..42a4f8b74f 100644 --- a/sysdeps/unix/sysv/linux/bits/socket.h +++ b/sysdeps/unix/sysv/linux/bits/socket.h @@ -66,7 +66,15 @@ enum __socket_type #define PF_AAL5 8 /* Reserved for Werner's ATM. */ #define PF_X25 9 /* Reserved for X.25 project. */ #define PF_INET6 10 /* IP version 6. */ -#define PF_MAX 12 /* For now.. */ +#define PF_ROSE 11 /* Amateur Radio X.25 PLP */ +#define PF_DECnet 12 /* Reserved for DECnet project */ +#define PF_NETBEUI 13 /* Reserved for 802.2LLC project*/ +#define PF_SECURITY 14 /* Security callback pseudo AF */ +#define pseudo_PF_KEY 15 /* PF_KEY key management API */ +#define PF_NETLINK 16 +#define PF_ROUTE PF_NETLINK /* Alias to emulate 4.4BSD */ +#define PF_PACKET 17 /* Packet family */ +#define PF_MAX 32 /* For now.. */ /* Address families. */ #define AF_UNSPEC PF_UNSPEC @@ -82,6 +90,14 @@ enum __socket_type #define AF_AAL5 PF_AAL5 #define AF_X25 PF_X25 #define AF_INET6 PF_INET6 +#define AF_ROSE PF_ROSE +#define AF_DECnet PF_DECnet +#define AF_NETBEUI PF_NETBEUI +#define AF_SECURITY PF_SECURITY +#define AF_KEY pseudo_PF_KEY +#define AF_NETLINK PF_NETLINK +#define AF_ROUTE PF_ROUTE +#define AF_PACKET PF_PACKET #define AF_MAX PF_MAX /* Socket level values. Others are defined in the appropriate headers. diff --git a/sysdeps/unix/sysv/linux/i386/s_pread64.S b/sysdeps/unix/sysv/linux/i386/s_pread64.S new file mode 100644 index 0000000000..22ce79b3f0 --- /dev/null +++ b/sysdeps/unix/sysv/linux/i386/s_pread64.S @@ -0,0 +1,45 @@ +/* pread64 syscall for Linux/ix86. + Copyright (C) 1997 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with the GNU C Library; see the file COPYING.LIB. If not, + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + +#include <sysdep.h> + +/* Please consult the file sysdeps/unix/sysv/linux/i386/sysdep.h for + more information about the value -4095 used below.*/ + + .text +ENTRY (__syscall_pread64) + + PUSHARGS_5 /* Save register contents. */ + + /* Load arguments. This is unfortunately a little bit of a problem + since the kernel expects the arguments in a different order. */ + movl 0x20(%esp,1),%esi + movl 0x1c(%esp,1),%edi + movl 0x18(%esp,1),%edx + movl 0x14(%esp,1),%ecx + movl 0x10(%esp,1),%ebx + /* Load syscall number into %eax. */ + movl $SYS_ify(pread), %eax + int $0x80 /* Do the system call. */ + POPARGS_5 /* Restore register contents. */ + cmpl $-4095, %eax /* Check %eax for error. */ + jae syscall_error /* Jump to error handler if error. */ + ret /* Return to caller. */ + +PSEUDO_END (__syscall_pread64) diff --git a/sysdeps/unix/sysv/linux/i386/s_pwrite64.S b/sysdeps/unix/sysv/linux/i386/s_pwrite64.S new file mode 100644 index 0000000000..6a1987b72e --- /dev/null +++ b/sysdeps/unix/sysv/linux/i386/s_pwrite64.S @@ -0,0 +1,45 @@ +/* pwrite64 syscall for Linux/ix86. + Copyright (C) 1997 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with the GNU C Library; see the file COPYING.LIB. If not, + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + +#include <sysdep.h> + +/* Please consult the file sysdeps/unix/sysv/linux/i386/sysdep.h for + more information about the value -4095 used below.*/ + + .text +ENTRY (__syscall_pwrite64) + + PUSHARGS_5 /* Save register contents. */ + + /* Load arguments. This is unfortunately a little bit of a problem + since the kernel expects the arguments in a different order. */ + movl 0x20(%esp,1),%esi + movl 0x1c(%esp,1),%edi + movl 0x18(%esp,1),%edx + movl 0x14(%esp,1),%ecx + movl 0x10(%esp,1),%ebx + /* Load syscall number into %eax. */ + movl $SYS_ify(pwrite), %eax + int $0x80 /* Do the system call. */ + POPARGS_5 /* Restore register contents. */ + cmpl $-4095, %eax /* Check %eax for error. */ + jae syscall_error /* Jump to error handler if error. */ + ret /* Return to caller. */ + +PSEUDO_END (__syscall_pwrite64) diff --git a/sysdeps/unix/sysv/linux/i386/sigaction.c b/sysdeps/unix/sysv/linux/i386/sigaction.c index 99ed694f49..90d61a08a1 100644 --- a/sysdeps/unix/sysv/linux/i386/sigaction.c +++ b/sysdeps/unix/sysv/linux/i386/sigaction.c @@ -28,8 +28,8 @@ #include <kernel_sigaction.h> -extern int __syscall_rt_signal (int, const struct sigaction *, - struct sigaction *, size_t); +extern int __syscall_rt_sigaction (int, const struct sigaction *, + struct sigaction *, size_t); /* The variable is shared between all wrappers around signal handling functions which have RT equivalents. It is defined in sigsuspend.c. */ diff --git a/sysdeps/unix/sysv/linux/rt_sigprocmask.c b/sysdeps/unix/sysv/linux/rt_sigprocmask.c index 0ce2815780..c9adaf08c4 100644 --- a/sysdeps/unix/sysv/linux/rt_sigprocmask.c +++ b/sysdeps/unix/sysv/linux/rt_sigprocmask.c @@ -20,7 +20,7 @@ #include <signal.h> int -__syscall_rt_sigprocmask (int how, const sigset *set, sigset_t *oset, +__syscall_rt_sigprocmask (int how, const sigset_t *set, sigset_t *oset, size_t setsize) { __set_errno (ENOSYS); diff --git a/sysdeps/unix/sysv/linux/rt_sigqueueinfo.c b/sysdeps/unix/sysv/linux/rt_sigqueueinfo.c index ff99e9e555..ec9f9803a7 100644 --- a/sysdeps/unix/sysv/linux/rt_sigqueueinfo.c +++ b/sysdeps/unix/sysv/linux/rt_sigqueueinfo.c @@ -18,6 +18,7 @@ #include <errno.h> #include <signal.h> +#include <sys/types.h> int __syscall_rt_sigqueueinfo (pid_t pid, int sig, siginfo_t *uinfo) diff --git a/sysdeps/unix/sysv/linux/rt_sigsuspend.c b/sysdeps/unix/sysv/linux/rt_sigsuspend.c index 59fb5c4bcd..dc32dcc067 100644 --- a/sysdeps/unix/sysv/linux/rt_sigsuspend.c +++ b/sysdeps/unix/sysv/linux/rt_sigsuspend.c @@ -20,7 +20,7 @@ #include <signal.h> int -__syscall_rt_sigsuspend (const sigset *set, size_t setsize) +__syscall_rt_sigsuspend (const sigset_t *set, size_t setsize) { if (set == NULL) { diff --git a/sysdeps/unix/sysv/linux/sigreturn.c b/sysdeps/unix/sysv/linux/sigreturn.c index e57ac74212..ecef3d67ad 100644 --- a/sysdeps/unix/sysv/linux/sigreturn.c +++ b/sysdeps/unix/sysv/linux/sigreturn.c @@ -18,7 +18,6 @@ #include <errno.h> #include <signal.h> -#include <sigcontext.h> #include <unistd.h> extern int __syscall_sigreturn (struct sigcontext *); diff --git a/sysdeps/unix/sysv/linux/sys/pci.h b/sysdeps/unix/sysv/linux/sys/pci.h index 03d9b9a768..8c190d644f 100644 --- a/sysdeps/unix/sysv/linux/sys/pci.h +++ b/sysdeps/unix/sysv/linux/sys/pci.h @@ -20,6 +20,6 @@ #define _SYS_PCI_H 1 /* We use the constants from the kernel. */ -#include <asm/pci.h> +#include <linux/pci.h> #endif /* sys/pci.h */ diff --git a/sysdeps/wordsize-32/bits/environments.h b/sysdeps/wordsize-32/bits/environments.h index 40a53ab236..8d1403fefe 100644 --- a/sysdeps/wordsize-32/bits/environments.h +++ b/sysdeps/wordsize-32/bits/environments.h @@ -16,8 +16,9 @@ write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ -#ifndef _BITS_ENVIRONMENTS_H -#define _BITS_ENVIRONMENTS_H 1 +#ifndef _UNISTD_H +# error "Never include this file directly. Use <unistd.h> instead" +#endif /* By default we have 32-bit wide `int', `long int', pointers and `off_t'. */ #define _XBS5_ILP32_OFF32 1 @@ -28,5 +29,3 @@ /* We can never provide environments with 64-bit wide pointers. */ #define _XBS5_LP64_OFF64 -1 #define _XBS5_LPBIG_OFFBIG -1 - -#endif /* bits/environments.h */ diff --git a/sysdeps/wordsize-64/bits/environments.h b/sysdeps/wordsize-64/bits/environments.h index af2d212618..f1d5bb8135 100644 --- a/sysdeps/wordsize-64/bits/environments.h +++ b/sysdeps/wordsize-64/bits/environments.h @@ -16,15 +16,14 @@ write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ -#ifndef _BITS_ENVIRONMENTS_H -#define _BITS_ENVIRONMENTS_H 1 +#ifndef _UNISTD_H +# error "Never include this file directly. Use <unistd.h> instead" +#endif -/* We can never provide environments with 64-bit wide pointers. */ +/* We can never provide environments with 32-bit wide pointers. */ #define _XBS5_ILP32_OFF32 -1 #define _XBS5_ILP32_OFFBIG -1 -/* By default we have 64-bit wide `int', `long int', pointers and `off_t'. */ +/* By default we have 64-bit wide `long int', pointers and `off_t'. */ #define _XBS5_LP64_OFF32 1 #define _XBS5_LPBIG_OFFBIG 1 - -#endif /* bits/environments.h */ |