]>
Commit | Line | Data |
---|---|---|
61952351 | 1 | Frequently Asked Questions about the GNU C Library |
f8cac037 | 2 | |
f12944ec UD |
3 | This document tries to answer questions a user might have when installing |
4 | and using glibc. Please make sure you read this before sending questions or | |
5 | bug reports to the maintainers. | |
f8cac037 | 6 | |
f12944ec | 7 | The GNU C library is very complex. The installation process has not been |
fdacb17d | 8 | completely automated; there are too many variables. You can do substantial |
f12944ec UD |
9 | damage to your system by installing the library incorrectly. Make sure you |
10 | understand what you are undertaking before you begin. | |
f8cac037 | 11 | |
41f27456 RM |
12 | If you have any questions you think should be answered in this document, |
13 | please let me know. | |
f8cac037 RM |
14 | |
15 | --drepper@cygnus.com | |
16 | \f | |
61952351 UD |
17 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
18 | ||
19 | 1. Compiling glibc | |
20 | ||
21 | 1.1. What systems does the GNU C Library run on? | |
22 | 1.2. What compiler do I need to build GNU libc? | |
23 | 1.3. When I try to compile glibc I get only error messages. | |
24 | What's wrong? | |
25 | 1.4. Do I need a special linker or archiver? | |
8619129f | 26 | 1.5. Which compiler should I use for powerpc? |
4775243a | 27 | 1.6. Do I need some more things to compile GNU C Library? |
a35cb74d | 28 | 1.7. What version of the Linux kernel headers should be used? |
f12944ec UD |
29 | 1.8. The compiler hangs while building iconvdata modules. What's |
30 | wrong? | |
31 | 1.9. When I run `nm -u libc.so' on the produced library I still | |
61952351 | 32 | find unresolved symbols. Can this be ok? |
f12944ec UD |
33 | 1.10. What are these `add-ons'? |
34 | 1.11. My XXX kernel emulates a floating-point coprocessor for me. | |
61952351 | 35 | Should I enable --with-fp? |
f12944ec | 36 | 1.12. When compiling GNU libc I get lots of errors saying functions |
61952351 | 37 | in glibc are duplicated in libgcc. |
f12944ec | 38 | 1.13. Why do I get messages about missing thread functions when I use |
a35cb74d | 39 | librt? I don't even use threads. |
f12944ec | 40 | 1.14. What's the problem with configure --enable-omitfp? |
b0610668 | 41 | 1.15. I get failures during `make check'. What shall I do? |
a379e56a | 42 | 1.16. What is symbol versioning good for? Do I need it? |
61952351 UD |
43 | |
44 | 2. Installation and configuration issues | |
45 | ||
46 | 2.1. Can I replace the libc on my Linux system with GNU libc? | |
47 | 2.2. How do I configure GNU libc so that the essential libraries | |
48 | like libc.so go into /lib and the other into /usr/lib? | |
49 | 2.3. How should I avoid damaging my system when I install GNU libc? | |
50 | 2.4. Do I need to use GNU CC to compile programs that will use the | |
51 | GNU C Library? | |
52 | 2.5. When linking with the new libc I get unresolved symbols | |
53 | `crypt' and `setkey'. Why aren't these functions in the | |
54 | libc anymore? | |
55 | 2.6. When I use GNU libc on my Linux system by linking against | |
56 | the libc.so which comes with glibc all I get is a core dump. | |
57 | 2.7. Looking through the shared libc file I haven't found the | |
58 | functions `stat', `lstat', `fstat', and `mknod' and while | |
59 | linking on my Linux system I get error messages. How is | |
60 | this supposed to work? | |
61 | 2.8. How can I compile gcc 2.7.2.1 from the gcc source code using | |
62 | glibc 2.x? | |
63 | 2.9. The `gencat' utility cannot process the catalog sources which | |
64 | were used on my Linux libc5 based system. Why? | |
a35cb74d UD |
65 | 2.10. Programs using libc have their messages translated, but other |
66 | behavior is not localized (e.g. collating order); why? | |
67 | 2.11. I have set up /etc/nis.conf, and the Linux libc 5 with NYS | |
61952351 | 68 | works great. But the glibc NIS+ doesn't seem to work. |
a35cb74d | 69 | 2.12. I have killed ypbind to stop using NIS, but glibc |
3dcf8ea6 | 70 | continues using NIS. |
a35cb74d | 71 | 2.13. Under Linux/Alpha, I always get "do_ypcall: clnt_call: |
3dcf8ea6 | 72 | RPC: Unable to receive; errno = Connection refused" when using NIS. |
a35cb74d | 73 | 2.14. After installing glibc name resolving doesn't work properly. |
3dcf8ea6 UD |
74 | 2.15. How do I create the databases for NSS? |
75 | 2.16. I have /usr/include/net and /usr/include/scsi as symlinks | |
61952351 | 76 | into my Linux source tree. Is that wrong? |
3dcf8ea6 | 77 | 2.17. Programs like `logname', `top', `uptime' `users', `w' and |
61952351 UD |
78 | `who', show incorrect information about the (number of) |
79 | users on my system. Why? | |
3dcf8ea6 | 80 | 2.18. After upgrading to glibc 2.1 with symbol versioning I get |
61952351 | 81 | errors about undefined symbols. What went wrong? |
3dcf8ea6 | 82 | 2.19. When I start the program XXX after upgrading the library |
61952351 UD |
83 | I get |
84 | XXX: Symbol `_sys_errlist' has different size in shared | |
85 | object, consider re-linking | |
86 | Why? What should I do? | |
3dcf8ea6 UD |
87 | 2.20. What do I need for C++ development? |
88 | 2.21. Even statically linked programs need some shared libraries | |
ff44f2a5 | 89 | which is not acceptable for me. What can I do? |
fdacb17d UD |
90 | 2.22. I just upgraded my Linux system to glibc and now I get |
91 | errors whenever I try to link any program. | |
48244d09 | 92 | 2.23. When I use nscd the machine freezes. |
61952351 UD |
93 | |
94 | 3. Source and binary incompatibilities, and what to do about them | |
95 | ||
96 | 3.1. I expect GNU libc to be 100% source code compatible with | |
97 | the old Linux based GNU libc. Why isn't it like this? | |
98 | 3.2. Why does getlogin() always return NULL on my Linux box? | |
99 | 3.3. Where are the DST_* constants found in <sys/time.h> on many | |
100 | systems? | |
101 | 3.4. The prototypes for `connect', `accept', `getsockopt', | |
102 | `setsockopt', `getsockname', `getpeername', `send', | |
103 | `sendto', and `recvfrom' are different in GNU libc from | |
104 | any other system I saw. This is a bug, isn't it? | |
105 | 3.5. On Linux I've got problems with the declarations in Linux | |
106 | kernel headers. | |
107 | 3.6. I don't include any kernel headers myself but the compiler | |
108 | still complains about redeclarations of types in the kernel | |
109 | headers. | |
110 | 3.7. Why don't signals interrupt system calls anymore? | |
111 | 3.8. I've got errors compiling code that uses certain string | |
112 | functions. Why? | |
4775243a UD |
113 | 3.9. I get compiler messages "Initializer element not constant" with |
114 | stdin/stdout/stderr. Why? | |
115 | 3.10. I can't compile with gcc -traditional (or | |
116 | -traditional-cpp). Why? | |
117 | 3.11. I get some errors with `gcc -ansi'. Isn't glibc ANSI compatible? | |
a35cb74d UD |
118 | 3.12. I can't access some functions anymore. nm shows that they do |
119 | exist but linking fails nevertheless. | |
a5f4e34a UD |
120 | 3.13. When using the db-2 library which comes with glibc is used in |
121 | the Perl db modules the testsuite is not passed. This did not | |
122 | happen with db-1, gdbm, or ndbm. | |
5148d49f UD |
123 | 3.14. The pow() inline function I get when including <math.h> is broken. |
124 | I get segmentation faults when I run the program. | |
61952351 UD |
125 | |
126 | 4. Miscellaneous | |
127 | ||
128 | 4.1. After I changed configure.in I get `Autoconf version X.Y. | |
129 | or higher is required for this script'. What can I do? | |
130 | 4.2. When I try to compile code which uses IPv6 headers and | |
131 | definitions on my Linux 2.x.y system I am in trouble. | |
132 | Nothing seems to work. | |
aa802e96 | 133 | 4.3. When I set the timezone by setting the TZ environment variable |
ff44f2a5 UD |
134 | to EST5EDT things go wrong since glibc computes the wrong time |
135 | from this information. | |
fdacb17d | 136 | 4.4. What other sources of documentation about glibc are available? |
f8cac037 | 137 | |
61952351 UD |
138 | \f |
139 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | |
f4017d20 | 140 | |
61952351 | 141 | 1. Compiling glibc |
04be94a8 | 142 | |
61952351 | 143 | 1.1. What systems does the GNU C Library run on? |
613a76ff | 144 | |
f12944ec UD |
145 | {UD} This is difficult to answer. The file `README' lists the architectures |
146 | GNU libc was known to run on *at some time*. This does not mean that it | |
147 | still can be compiled and run on them now. | |
f8cac037 | 148 | |
f12944ec UD |
149 | The systems glibc is known to work on as of this release, and most probably |
150 | in the future, are: | |
f8cac037 RM |
151 | |
152 | *-*-gnu GNU Hurd | |
4775243a UD |
153 | i[3456]86-*-linux-gnu Linux-2.x on Intel |
154 | m68k-*-linux-gnu Linux-2.x on Motorola 680x0 | |
155 | alpha-*-linux-gnu Linux-2.x on DEC Alpha | |
9a0a462c | 156 | powerpc-*-linux-gnu Linux and MkLinux on PowerPC systems |
4775243a UD |
157 | sparc-*-linux-gnu Linux-2.x on SPARC |
158 | sparc64-*-linux-gnu Linux-2.x on UltraSPARC | |
ff44f2a5 UD |
159 | arm-*-none ARM standalone systems |
160 | arm-*-linuxaout Linux-2.x on ARM using a.out binaries | |
f8cac037 | 161 | |
f12944ec UD |
162 | Ports to other Linux platforms are in development, and may in fact work |
163 | already, but no one has sent us success reports for them. Currently no | |
164 | ports to other operating systems are underway, although a few people have | |
165 | expressed interest. | |
f8cac037 | 166 | |
f12944ec UD |
167 | If you have a system not listed above (or in the `README' file) and you are |
168 | really interested in porting it, contact | |
f8cac037 | 169 | |
4775243a | 170 | <bug-glibc@gnu.org> |
f8cac037 RM |
171 | |
172 | ||
61952351 | 173 | 1.2. What compiler do I need to build GNU libc? |
f8cac037 | 174 | |
f12944ec UD |
175 | {UD} You must use GNU CC to compile GNU libc. A lot of extensions of GNU CC |
176 | are used to increase portability and speed. | |
f8cac037 | 177 | |
61952351 | 178 | GNU CC is found, like all other GNU packages, on |
f12944ec | 179 | |
a35cb74d | 180 | ftp://ftp.gnu.org/pub/gnu |
f12944ec | 181 | |
a35cb74d | 182 | and the many mirror sites. ftp.gnu.org is always overloaded, so try to find |
61952351 | 183 | a local mirror first. |
f8cac037 | 184 | |
b0610668 | 185 | You should always try to use the latest official release. Older versions |
f12944ec | 186 | may not have all the features GNU libc requires. The current releases of |
a379e56a UD |
187 | egcs (1.0.3 and 1.1) and GNU CC (2.8.1) should work with the GNU C library |
188 | (for powerpc see question question 1.5). | |
f8cac037 RM |
189 | |
190 | ||
61952351 UD |
191 | 1.3. When I try to compile glibc I get only error messages. |
192 | What's wrong? | |
f8cac037 | 193 | |
f12944ec UD |
194 | {UD} You definitely need GNU make to translate GNU libc. No other make |
195 | program has the needed functionality. | |
f8cac037 | 196 | |
f12944ec UD |
197 | We recommend version GNU make version 3.75. Versions 3.76 and 3.76.1 have |
198 | bugs which appear when building big projects like GNU libc. Versions before | |
199 | 3.74 have bugs and/or are missing features. | |
cbdee279 | 200 | |
f8cac037 | 201 | |
61952351 | 202 | 1.4. Do I need a special linker or archiver? |
f8cac037 | 203 | |
f12944ec UD |
204 | {UD} You may be able to use your system linker, but GNU libc works best with |
205 | GNU binutils. | |
f8cac037 | 206 | |
f12944ec UD |
207 | On systems where the native linker does not support weak symbols you will |
208 | not get a fully ISO C compliant C library. Generally speaking you should | |
209 | use the GNU binutils if they provide at least the same functionality as your | |
210 | system's tools. | |
f8cac037 | 211 | |
f12944ec UD |
212 | Always get the newest release of GNU binutils available. Older releases are |
213 | known to have bugs that prevent a successful compilation. | |
41f27456 | 214 | |
a379e56a UD |
215 | {AJ} Please don't use binutils 2.7. That release contains some bugs which |
216 | might make it necessary that you've got to recompile all your glibc2 | |
217 | binaries when upgrading the GNU C library. | |
218 | ||
f12944ec UD |
219 | {ZW} As of release 2.1 a linker supporting symbol versions is required. For |
220 | Linux, get binutils-2.8.1.0.23 or later. Other systems may have native | |
221 | linker support, but it's moot right now, because glibc has not been ported | |
222 | to them. | |
f8cac037 | 223 | |
f8cac037 | 224 | |
8619129f | 225 | 1.5. Which compiler should I use for powerpc? |
4775243a | 226 | |
48244d09 | 227 | {GK} You want to use egcs 1.1 or later (together with the right versions |
f12944ec | 228 | of all the other tools, of course). |
4775243a | 229 | |
48244d09 UD |
230 | In fact, egcs 1.1 has a bug that causes linuxthreads to be |
231 | miscompiled, resulting in segmentation faults when using condition | |
232 | variables. There is a temporary patch at: | |
4775243a | 233 | |
48244d09 | 234 | <http://discus.anu.edu.au/~geoffk/egcs-3.diff> |
4775243a | 235 | |
48244d09 | 236 | Later versions of egcs may fix this problem. |
4775243a UD |
237 | |
238 | ||
239 | 1.6. Do I need some more things to compile GNU C Library? | |
f8cac037 | 240 | |
61952351 | 241 | {UD} Yes, there are some more :-). |
78b5ba3e | 242 | |
61952351 UD |
243 | * GNU gettext. This package contains the tools needed to construct |
244 | `message catalog' files containing translated versions of system | |
a35cb74d | 245 | messages. See ftp://ftp.gnu.org/pub/gnu or better any mirror |
61952351 UD |
246 | site. (We distribute compiled message catalogs, but they may not be |
247 | updated in patches.) | |
f8cac037 | 248 | |
61952351 UD |
249 | * Some files depend on special tools. E.g., files ending in .gperf |
250 | need a `gperf' program. The GNU version (part of libg++) is known | |
251 | to work while some vendor versions do not. | |
f8cac037 | 252 | |
61952351 | 253 | You should not need these tools unless you change the source files. |
1f205a47 | 254 | |
4775243a UD |
255 | * Some scripts need perl5 - but at the moment those scripts are not |
256 | vital for building and installing GNU libc (some data files will not | |
257 | be created). | |
258 | ||
61952351 UD |
259 | * When compiling for Linux, the header files of the Linux kernel must |
260 | be available to the compiler as <linux/*.h> and <asm/*.h>. | |
f8cac037 | 261 | |
8619129f UD |
262 | * lots of disk space (~170MB for i?86-linux; more for RISC platforms, |
263 | as much as 400MB). | |
af6f3906 | 264 | |
61952351 UD |
265 | * plenty of time. Compiling just the shared and static libraries for |
266 | i?86-linux takes approximately 1h on an i586@133, or 2.5h on | |
267 | i486@66, or 4.5h on i486@33. Multiply this by 1.5 or 2.0 if you | |
268 | build profiling and/or the highly optimized version as well. For | |
269 | Hurd systems times are much higher. | |
f8cac037 | 270 | |
61952351 UD |
271 | You should avoid compiling in a NFS mounted filesystem. This is |
272 | very slow. | |
0200214b | 273 | |
61952351 | 274 | James Troup <J.J.Troup@comp.brad.ac.uk> reports a compile time of |
4775243a UD |
275 | 45h34m for a full build (shared, static, and profiled) on Atari |
276 | Falcon (Motorola 68030 @ 16 Mhz, 14 Mb memory) and Jan Barte | |
277 | <yann@plato.uni-paderborn.de> reports 22h48m on Atari TT030 | |
278 | (Motorola 68030 @ 32 Mhz, 34 Mb memory) | |
0200214b | 279 | |
61952351 | 280 | If you have some more measurements let me know. |
0200214b | 281 | |
ba1ffaa1 | 282 | |
a35cb74d UD |
283 | 1.7. What version of the Linux kernel headers should be used? |
284 | ||
f12944ec UD |
285 | {AJ,UD} The headers from the most recent Linux kernel should be used. The |
286 | headers used while compiling the GNU C library and the kernel binary used | |
287 | when using the library do not need to match. The GNU C library runs without | |
288 | problems on kernels that are older than the kernel headers used. The other | |
289 | way round (compiling the GNU C library with old kernel headers and running | |
290 | on a recent kernel) does not necessarily work. For example you can't use | |
291 | new kernel features when using old kernel headers for compiling the GNU C | |
292 | library. | |
293 | ||
b0610668 UD |
294 | {ZW} Even if you are using a 2.0 kernel on your machine, we recommend you |
295 | compile GNU libc with 2.1 kernel headers. That way you won't have to | |
296 | recompile libc if you ever upgrade to kernel 2.1 or 2.2. To tell libc which | |
297 | headers to use, give configure the --with-headers switch | |
298 | (e.g. --with-headers=/usr/src/linux-2.1.107/include). | |
299 | ||
300 | Note that you must configure the 2.1 kernel if you do this; otherwise libc | |
301 | will be unable to find <linux/version.h>. Just copy .config from your 2.0 | |
302 | kernel sources to the 2.1 tree, do `make oldconfig', and say no to all the | |
303 | new options. | |
304 | ||
f12944ec UD |
305 | |
306 | 1.8. The compiler hangs while building iconvdata modules. What's | |
307 | wrong? | |
308 | ||
a379e56a UD |
309 | {ZW} This is a problem of older GCC. Initialization of large static arrays |
310 | is very slow. The compiler will eventually finish; give it time. | |
a35cb74d | 311 | |
a379e56a | 312 | The problem is fixed in egcs 1.1 but not in earlier releases. |
a35cb74d | 313 | |
f12944ec UD |
314 | |
315 | 1.9. When I run `nm -u libc.so' on the produced library I still | |
61952351 | 316 | find unresolved symbols. Can this be ok? |
f8cac037 | 317 | |
f12944ec | 318 | {UD} Yes, this is ok. There can be several kinds of unresolved symbols: |
f8cac037 | 319 | |
61952351 UD |
320 | * magic symbols automatically generated by the linker. These have names |
321 | like __start_* and __stop_* | |
f8cac037 | 322 | |
78b5ba3e RM |
323 | * symbols starting with _dl_* come from the dynamic linker |
324 | ||
61952351 | 325 | * weak symbols, which need not be resolved at all (fabs for example) |
f8cac037 RM |
326 | |
327 | Generally, you should make sure you find a real program which produces | |
41f27456 | 328 | errors while linking before deciding there is a problem. |
f8cac037 RM |
329 | |
330 | ||
f12944ec | 331 | 1.10. What are these `add-ons'? |
999493cb | 332 | |
f12944ec UD |
333 | {UD} To avoid complications with export rules or external source code some |
334 | optional parts of the libc are distributed as separate packages (e.g., the | |
335 | crypt package, see question 2.5). | |
999493cb | 336 | |
f12944ec UD |
337 | To use these packages as part of GNU libc, just unpack the tarfiles in the |
338 | libc source directory and tell the configuration script about them using the | |
339 | --enable-add-ons option. If you give just --enable-add-ons configure tries | |
340 | to find all the add-on packages in your source tree. This may not work. If | |
341 | it doesn't, or if you want to select only a subset of the add-ons, give a | |
342 | comma-separated list of the add-ons to enable: | |
613a76ff | 343 | |
61952351 | 344 | configure --enable-add-ons=crypt,linuxthreads |
41f27456 | 345 | |
61952351 | 346 | for example. |
0200214b | 347 | |
f12944ec UD |
348 | Add-ons can add features (including entirely new shared libraries), override |
349 | files, provide support for additional architectures, and just about anything | |
350 | else. The existing makefiles do most of the work; only some few stub rules | |
351 | must be written to get everything running. | |
613a76ff | 352 | |
613a76ff | 353 | |
f12944ec | 354 | 1.11. My XXX kernel emulates a floating-point coprocessor for me. |
61952351 | 355 | Should I enable --with-fp? |
613a76ff | 356 | |
f12944ec UD |
357 | {ZW} An emulated FPU is just as good as a real one, as far as the C library |
358 | is concerned. You only need to say --without-fp if your machine has no way | |
359 | to execute floating-point instructions. | |
f8cac037 | 360 | |
61952351 UD |
361 | People who are interested in squeezing the last drop of performance |
362 | out of their machine may wish to avoid the trap overhead, but this is | |
363 | far more trouble than it's worth: you then have to compile | |
364 | *everything* this way, including the compiler's internal libraries | |
365 | (libgcc.a for GNU C), because the calling conventions change. | |
a1470b6f | 366 | |
999493cb | 367 | |
f12944ec | 368 | 1.12. When compiling GNU libc I get lots of errors saying functions |
61952351 | 369 | in glibc are duplicated in libgcc. |
5290baf0 | 370 | |
f12944ec UD |
371 | {EY} This is *exactly* the same problem that I was having. The problem was |
372 | due to the fact that configure didn't correctly detect that the linker flag | |
373 | --no-whole-archive was supported in my linker. In my case it was because I | |
374 | had run ./configure with bogus CFLAGS, and the test failed. | |
78b5ba3e | 375 | |
f12944ec UD |
376 | One thing that is particularly annoying about this problem is that once this |
377 | is misdetected, running configure again won't fix it unless you first delete | |
378 | config.cache. | |
78b5ba3e | 379 | |
f12944ec UD |
380 | {UD} Starting with glibc-2.0.3 there should be a better test to avoid some |
381 | problems of this kind. The setting of CFLAGS is checked at the very | |
382 | beginning and if it is not usable `configure' will bark. | |
78b5ba3e | 383 | |
af6f3906 | 384 | |
f12944ec | 385 | 1.13. Why do I get messages about missing thread functions when I use |
a35cb74d | 386 | librt? I don't even use threads. |
4775243a | 387 | |
a35cb74d UD |
388 | {UD} In this case you probably mixed up your installation. librt uses |
389 | threads internally and has implicit references to the thread library. | |
f12944ec UD |
390 | Normally these references are satisfied automatically but if the thread |
391 | library is not in the expected place you must tell the linker where it is. | |
392 | When using GNU ld it works like this: | |
4775243a UD |
393 | |
394 | gcc -o foo foo.c -Wl,-rpath-link=/some/other/dir -lrt | |
395 | ||
f12944ec UD |
396 | The `/some/other/dir' should contain the thread library. `ld' will use the |
397 | given path to find the implicitly referenced library while not disturbing | |
398 | any other link path. | |
4775243a UD |
399 | |
400 | ||
f12944ec | 401 | 1.14. What's the problem with configure --enable-omitfp? |
78b5ba3e | 402 | |
61952351 | 403 | {AJ} When --enable-omitfp is set the libraries are built without frame |
fdacb17d | 404 | pointers. Some compilers produce buggy code for this model and therefore we |
f12944ec | 405 | don't advise using it at the moment. |
66219c07 | 406 | |
fdacb17d | 407 | If you use --enable-omitfp, you're on your own. If you encounter problems |
f12944ec UD |
408 | with a library that was build this way, we advise you to rebuild the library |
409 | without --enable-omitfp. If the problem vanishes consider tracking the | |
410 | problem down and report it as compiler failure. | |
66219c07 | 411 | |
f12944ec UD |
412 | Since a library build with --enable-omitfp is undebuggable on most systems, |
413 | debuggable libraries are also built - you can use it by appending "_g" to | |
414 | the library names. | |
66219c07 | 415 | |
f12944ec UD |
416 | The compilation of these extra libraries and the compiler optimizations slow |
417 | down the build process and need more disk space. | |
66219c07 | 418 | |
b0610668 UD |
419 | |
420 | 1.15. I get failures during `make check'. What shall I do? | |
421 | ||
422 | {AJ} The testsuite should compile and run cleanly on your system, every | |
423 | failure should be looked into. Depending on the failure I wouldn't advise | |
424 | installing the library at all. | |
425 | ||
426 | You should consider using the `glibcbug' script to report the failure, | |
427 | providing as much detail as possible. If you run a test directly, please | |
428 | remember to set up the environment correctly. You want to test the compiled | |
429 | library - and not your installed one. The best way is to copy the exact | |
430 | command line which failed and run the test from the subdirectory for this | |
431 | test in the sources. | |
432 | ||
433 | There are some failures which are not directly related to the GNU libc: | |
a379e56a UD |
434 | - Some compiler produce buggy code. The egcs 1.1 release should be ok. gcc |
435 | 2.8.1 might cause some failures, gcc 2.7.2.x is so buggy, that explicit | |
436 | checks have been used so that you can't build with it. | |
b0610668 UD |
437 | - The kernel might have bugs. For example on Linux/Alpha 2.0.34 the |
438 | floating point handling has quite a number of bugs and therefore most of | |
439 | the test cases in the math subdirectory will fail. The current Linux 2.1 | |
440 | development kernels have fixes for the floating point support on Alpha. | |
441 | ||
a379e56a UD |
442 | |
443 | 1.16. What is symbol versioning good for? Do I need it? | |
444 | ||
445 | {AJ} Symbol versioning solves problems that are related to interface | |
446 | changes. One version of an interface might have been introduced in a | |
447 | previous version of the GNU C library but the interface or the semantics of | |
448 | the function has been changed in the meantime. For binary compatibility | |
449 | with the old library, a newer library needs to still have the old interface | |
450 | for old programs. On the other hand new programs should use the new | |
451 | interface. Symbol versioning is the solution for this problem. The GNU | |
452 | libc version 2.1 uses by default symbol versioning if the binutils support | |
453 | it. | |
454 | ||
455 | We don't advise to build without symbol versioning since you lose binary | |
456 | compatibility if you do - for ever! The binary compatibility you lose is | |
457 | not only against the previous version of the GNU libc (version 2.0) but also | |
458 | against future versions. | |
459 | ||
61952351 UD |
460 | \f |
461 | . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | |
e6c9a67a | 462 | |
61952351 | 463 | 2. Installation and configuration issues |
e6c9a67a | 464 | |
61952351 | 465 | 2.1. Can I replace the libc on my Linux system with GNU libc? |
e6c9a67a | 466 | |
f12944ec UD |
467 | {UD} You cannot replace any existing libc for Linux with GNU libc. It is |
468 | binary incompatible and therefore has a different major version. You can, | |
469 | however, install it alongside your existing libc. | |
e6c9a67a | 470 | |
61952351 UD |
471 | For Linux there are three major libc versions: |
472 | libc-4 a.out libc | |
473 | libc-5 original ELF libc | |
474 | libc-6 GNU libc | |
e6c9a67a | 475 | |
f12944ec UD |
476 | You can have any combination of these three installed. For more information |
477 | consult documentation for shared library handling. The Makefiles of GNU | |
478 | libc will automatically generate the needed symbolic links which the linker | |
479 | will use. | |
e6c9a67a RM |
480 | |
481 | ||
61952351 UD |
482 | 2.2. How do I configure GNU libc so that the essential libraries |
483 | like libc.so go into /lib and the other into /usr/lib? | |
ec42724d | 484 | |
61952351 UD |
485 | {UD,AJ} Like all other GNU packages GNU libc is designed to use a base |
486 | directory and install all files relative to this. The default is | |
f12944ec UD |
487 | /usr/local, because this is safe (it will not damage the system if installed |
488 | there). If you wish to install GNU libc as the primary C library on your | |
489 | system, set the base directory to /usr (i.e. run configure --prefix=/usr | |
490 | <other_options>). Note that this can damage your system; see question 2.3 for | |
491 | details. | |
492 | ||
493 | Some systems like Linux have a filesystem standard which makes a difference | |
494 | between essential libraries and others. Essential libraries are placed in | |
495 | /lib because this directory is required to be located on the same disk | |
496 | partition as /. The /usr subtree might be found on another | |
497 | partition/disk. If you configure for Linux with --prefix=/usr, then this | |
498 | will be done automatically. | |
ec42724d | 499 | |
61952351 | 500 | To install the essential libraries which come with GNU libc in /lib on |
f12944ec UD |
501 | systems other than Linux one must explicitly request it. Autoconf has no |
502 | option for this so you have to use a `configparms' file (see the `INSTALL' | |
503 | file for details). It should contain: | |
ec42724d RM |
504 | |
505 | slibdir=/lib | |
506 | sysconfdir=/etc | |
507 | ||
f12944ec UD |
508 | The first line specifies the directory for the essential libraries, the |
509 | second line the directory for system configuration files. | |
ec42724d | 510 | |
5290baf0 | 511 | |
61952351 | 512 | 2.3. How should I avoid damaging my system when I install GNU libc? |
ec42724d | 513 | |
f12944ec UD |
514 | {ZW} If you wish to be cautious, do not configure with --prefix=/usr. If |
515 | you don't specify a prefix, glibc will be installed in /usr/local, where it | |
516 | will probably not break anything. (If you wish to be certain, set the | |
517 | prefix to something like /usr/local/glibc2 which is not used for anything.) | |
845dcb57 | 518 | |
61952351 | 519 | The dangers when installing glibc in /usr are twofold: |
845dcb57 | 520 | |
61952351 UD |
521 | * glibc will overwrite the headers in /usr/include. Other C libraries |
522 | install a different but overlapping set of headers there, so the | |
523 | effect will probably be that you can't compile anything. You need to | |
524 | rename /usr/include out of the way first. (Do not throw it away; you | |
525 | will then lose the ability to compile programs against your old libc.) | |
845dcb57 | 526 | |
61952351 UD |
527 | * None of your old libraries, static or shared, can be used with a |
528 | different C library major version. For shared libraries this is not a | |
529 | problem, because the filenames are different and the dynamic linker | |
530 | will enforce the restriction. But static libraries have no version | |
531 | information. You have to evacuate all the static libraries in | |
532 | /usr/lib to a safe location. | |
845dcb57 | 533 | |
61952351 UD |
534 | The situation is rather similar to the move from a.out to ELF which |
535 | long-time Linux users will remember. | |
845dcb57 | 536 | |
845dcb57 | 537 | |
61952351 UD |
538 | 2.4. Do I need to use GNU CC to compile programs that will use the |
539 | GNU C Library? | |
845dcb57 | 540 | |
f12944ec UD |
541 | {ZW} In theory, no; the linker does not care, and the headers are supposed |
542 | to check for GNU CC before using its extensions to the C language. | |
845dcb57 | 543 | |
f12944ec UD |
544 | However, there are currently no ports of glibc to systems where another |
545 | compiler is the default, so no one has tested the headers extensively | |
546 | against another compiler. You may therefore encounter difficulties. If you | |
547 | do, please report them as bugs. | |
845dcb57 | 548 | |
61952351 UD |
549 | Also, in several places GNU extensions provide large benefits in code |
550 | quality. For example, the library has hand-optimized, inline assembly | |
f12944ec UD |
551 | versions of some string functions. These can only be used with GCC. See |
552 | question 3.8 for details. | |
845dcb57 | 553 | |
845dcb57 | 554 | |
61952351 UD |
555 | 2.5. When linking with the new libc I get unresolved symbols |
556 | `crypt' and `setkey'. Why aren't these functions in the | |
557 | libc anymore? | |
845dcb57 | 558 | |
f12944ec UD |
559 | {UD} The US places restrictions on exporting cryptographic programs and |
560 | source code. Until this law gets abolished we cannot ship the cryptographic | |
561 | functions together with glibc. | |
845dcb57 | 562 | |
f12944ec UD |
563 | The functions are available, as an add-on (see question 1.10). People in the US |
564 | may get it from the same place they got GNU libc from. People outside the | |
565 | US should get the code from ftp://ftp.ifi.uio.no/pub/gnu, or another archive | |
566 | site outside the USA. The README explains how to install the sources. | |
c4029823 | 567 | |
f12944ec UD |
568 | If you already have the crypt code on your system the reason for the failure |
569 | is probably that you did not link with -lcrypt. The crypto functions are in | |
570 | a separate library to make it possible to export GNU libc binaries from the | |
571 | US. | |
c4029823 | 572 | |
c4029823 | 573 | |
61952351 UD |
574 | 2.6. When I use GNU libc on my Linux system by linking against |
575 | the libc.so which comes with glibc all I get is a core dump. | |
c4029823 | 576 | |
f12944ec UD |
577 | {UD} On Linux, gcc sets the dynamic linker to /lib/ld-linux.so.1 unless the |
578 | user specifies a -dynamic-linker argument. This is the name of the libc5 | |
579 | dynamic linker, which does not work with glibc. | |
61952351 | 580 | |
a379e56a UD |
581 | For casual use of GNU libc you can just specify to the linker |
582 | --dynamic-linker=/lib/ld-linux.so.2 | |
61952351 | 583 | |
f12944ec | 584 | which is the glibc dynamic linker, on Linux systems. On other systems the |
a379e56a UD |
585 | name is /lib/ld.so.1. When linking via gcc, you've got to add |
586 | -Wl,--dynamic-linker=/lib/ld-linux.so.2 | |
587 | ||
588 | to the gcc command line. | |
c4029823 | 589 | |
f12944ec UD |
590 | To change your environment to use GNU libc for compiling you need to change |
591 | the `specs' file of your gcc. This file is normally found at | |
c4029823 UD |
592 | |
593 | /usr/lib/gcc-lib/<arch>/<version>/specs | |
594 | ||
595 | In this file you have to change a few things: | |
596 | ||
61952351 | 597 | - change `ld-linux.so.1' to `ld-linux.so.2' |
c4029823 UD |
598 | |
599 | - remove all expression `%{...:-lgmon}'; there is no libgmon in glibc | |
600 | ||
f4017d20 UD |
601 | - fix a minor bug by changing %{pipe:-} to %| |
602 | ||
f12944ec UD |
603 | Here is what the gcc-2.7.2 specs file should look like when GNU libc is |
604 | installed at /usr: | |
c4029823 UD |
605 | |
606 | ----------------------------------------------------------------------- | |
607 | *asm: | |
608 | %{V} %{v:%{!V:-V}} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} | |
609 | ||
610 | *asm_final: | |
f4017d20 | 611 | %| |
c4029823 UD |
612 | |
613 | *cpp: | |
68dbb3a6 | 614 | %{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} %{!m386:-D__i486__} %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} |
c4029823 UD |
615 | |
616 | *cc1: | |
68dbb3a6 | 617 | %{profile:-p} |
c4029823 UD |
618 | |
619 | *cc1plus: | |
620 | ||
621 | ||
622 | *endfile: | |
68dbb3a6 | 623 | %{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s |
c4029823 UD |
624 | |
625 | *link: | |
68dbb3a6 | 626 | -m elf_i386 %{shared:-shared} %{!shared: %{!ibcs: %{!static: %{rdynamic:-export-dynamic} %{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2}} %{static:-static}}} |
c4029823 UD |
627 | |
628 | *lib: | |
68dbb3a6 | 629 | %{!shared: %{pthread:-lpthread} %{profile:-lc_p} %{!profile: -lc}} |
c4029823 UD |
630 | |
631 | *libgcc: | |
68dbb3a6 | 632 | -lgcc |
c4029823 UD |
633 | |
634 | *startfile: | |
61952351 | 635 | %{!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} |
c4029823 UD |
636 | |
637 | *switches_need_spaces: | |
638 | ||
639 | ||
640 | *signed_char: | |
641 | %{funsigned-char:-D__CHAR_UNSIGNED__} | |
642 | ||
643 | *predefines: | |
644 | -D__ELF__ -Dunix -Di386 -Dlinux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386) | |
645 | ||
646 | *cross_compile: | |
647 | 0 | |
648 | ||
649 | *multilib: | |
650 | . ; | |
651 | ||
652 | ----------------------------------------------------------------------- | |
653 | ||
f12944ec UD |
654 | Things get a bit more complicated if you have GNU libc installed in some |
655 | other place than /usr, i.e., if you do not want to use it instead of the old | |
656 | libc. In this case the needed startup files and libraries are not found in | |
657 | the regular places. So the specs file must tell the compiler and linker | |
658 | exactly what to use. | |
0d204b0a | 659 | |
f41c8091 | 660 | Version 2.7.2.3 does and future versions of GCC will automatically |
0d8733c4 | 661 | provide the correct specs. |
c4029823 UD |
662 | |
663 | ||
61952351 UD |
664 | 2.7. Looking through the shared libc file I haven't found the |
665 | functions `stat', `lstat', `fstat', and `mknod' and while | |
666 | linking on my Linux system I get error messages. How is | |
667 | this supposed to work? | |
c4029823 | 668 | |
f12944ec UD |
669 | {RM} Believe it or not, stat and lstat (and fstat, and mknod) are supposed |
670 | to be undefined references in libc.so.6! Your problem is probably a missing | |
671 | or incorrect /usr/lib/libc.so file; note that this is a small text file now, | |
672 | not a symlink to libc.so.6. It should look something like this: | |
c4029823 | 673 | |
ff44f2a5 | 674 | GROUP ( libc.so.6 libc_nonshared.a ) |
1f205a47 | 675 | |
c4029823 | 676 | |
61952351 UD |
677 | 2.8. How can I compile gcc 2.7.2.1 from the gcc source code using |
678 | glibc 2.x? | |
ba1ffaa1 | 679 | |
f12944ec UD |
680 | {AJ} There's only correct support for glibc 2.0.x in gcc 2.7.2.3 or later. |
681 | But you should get at least gcc 2.8.1 or egcs 1.0.2 (or later versions) | |
682 | instead. | |
ba1ffaa1 UD |
683 | |
684 | ||
61952351 UD |
685 | 2.9. The `gencat' utility cannot process the catalog sources which |
686 | were used on my Linux libc5 based system. Why? | |
47707456 | 687 | |
f12944ec UD |
688 | {UD} The `gencat' utility provided with glibc complies to the XPG standard. |
689 | The older Linux version did not obey the standard, so they are not | |
690 | compatible. | |
47707456 | 691 | |
61952351 | 692 | To ease the transition from the Linux version some of the non-standard |
f12944ec UD |
693 | features are also present in the `gencat' program of GNU libc. This mainly |
694 | includes the use of symbols for the message number and the automatic | |
61952351 UD |
695 | generation of header files which contain the needed #defines to map the |
696 | symbols to integers. | |
47707456 | 697 | |
f12944ec UD |
698 | Here is a simple SED script to convert at least some Linux specific catalog |
699 | files to the XPG4 form: | |
68dbb3a6 | 700 | |
61952351 UD |
701 | ----------------------------------------------------------------------- |
702 | # Change catalog source in Linux specific format to standard XPG format. | |
703 | # Ulrich Drepper <drepper@cygnus.com>, 1996. | |
704 | # | |
705 | /^\$ #/ { | |
706 | h | |
707 | s/\$ #\([^ ]*\).*/\1/ | |
708 | x | |
709 | s/\$ #[^ ]* *\(.*\)/\$ \1/ | |
710 | } | |
68dbb3a6 | 711 | |
61952351 UD |
712 | /^# / { |
713 | s/^# \(.*\)/\1/ | |
714 | G | |
715 | s/\(.*\)\n\(.*\)/\2 \1/ | |
716 | } | |
717 | ----------------------------------------------------------------------- | |
19361cb7 | 718 | |
19361cb7 | 719 | |
a35cb74d UD |
720 | 2.10. Programs using libc have their messages translated, but other |
721 | behavior is not localized (e.g. collating order); why? | |
722 | ||
723 | {ZW} Translated messages are automatically installed, but the locale | |
f12944ec UD |
724 | database that controls other behaviors is not. You need to run localedef to |
725 | install this database, after you have run `make install'. For example, to | |
726 | set up the French Canadian locale, simply issue the command | |
a35cb74d UD |
727 | |
728 | localedef -i fr_CA -f ISO-8859-1 fr_CA | |
729 | ||
730 | Please see localedata/README in the source tree for further details. | |
731 | ||
732 | ||
733 | 2.11. I have set up /etc/nis.conf, and the Linux libc 5 with NYS | |
61952351 | 734 | works great. But the glibc NIS+ doesn't seem to work. |
19361cb7 | 735 | |
f12944ec UD |
736 | {TK} The glibc NIS+ implementation uses a /var/nis/NIS_COLD_START file for |
737 | storing information about the NIS+ server and their public keys, because the | |
738 | nis.conf file does not contain all the necessary information. You have to | |
739 | copy a NIS_COLD_START file from a Solaris client (the NIS_COLD_START file is | |
740 | byte order independent) or generate it with nisinit from the nis-tools | |
741 | package; available at | |
742 | ||
743 | http://www-vt.uni-paderborn.de/~kukuk/linux/nisplus.html | |
19361cb7 | 744 | |
68dbb3a6 | 745 | |
a35cb74d | 746 | 2.12. I have killed ypbind to stop using NIS, but glibc |
3dcf8ea6 | 747 | continues using NIS. |
4d06461a | 748 | |
f12944ec UD |
749 | {TK} For faster NIS lookups, glibc uses the /var/yp/binding/ files from |
750 | ypbind. ypbind 3.3 and older versions don't always remove these files, so | |
751 | glibc will continue to use them. Other BSD versions seem to work correctly. | |
752 | Until ypbind 3.4 is released, you can find a patch at | |
753 | ||
bdbf022d | 754 | ftp://ftp.kernel.org/pub/linux/utils/net/NIS/ypbind-3.3-glibc3.diff.gz |
a35cb74d | 755 | |
4d06461a | 756 | |
a35cb74d | 757 | 2.13. Under Linux/Alpha, I always get "do_ypcall: clnt_call: |
3dcf8ea6 | 758 | RPC: Unable to receive; errno = Connection refused" when using NIS. |
4d06461a | 759 | |
f12944ec UD |
760 | {TK} You need a ypbind version which is 64bit clean. Some versions are not |
761 | 64bit clean. A 64bit clean implementation is ypbind-mt. For ypbind 3.3, | |
762 | you need the patch from ftp.kernel.org (See the previous question). I don't | |
763 | know about other versions. | |
a35cb74d UD |
764 | |
765 | ||
766 | 2.14. After installing glibc name resolving doesn't work properly. | |
68dbb3a6 | 767 | |
f12944ec UD |
768 | {AJ} You probably should read the manual section describing nsswitch.conf |
769 | (just type `info libc "NSS Configuration File"'). The NSS configuration | |
770 | file is usually the culprit. | |
22d57dd3 | 771 | |
22d57dd3 | 772 | |
3dcf8ea6 UD |
773 | 2.15. How do I create the databases for NSS? |
774 | ||
775 | {AJ} If you have an entry "db" in /etc/nsswitch.conf you should also create | |
776 | the database files. The glibc sources contain a Makefile which does the | |
a379e56a | 777 | necessary conversion and calls to create those files. The file is |
3dcf8ea6 UD |
778 | `db-Makefile' in the subdirectory `nss' and you can call it with `make -f |
779 | db-Makefile'. Please note that not all services are capable of using a | |
780 | database. Currently passwd, group, ethers, protocol, rpc, services shadow | |
781 | and netgroup are implemented. | |
782 | ||
783 | ||
784 | 2.16. I have /usr/include/net and /usr/include/scsi as symlinks | |
61952351 | 785 | into my Linux source tree. Is that wrong? |
22d57dd3 | 786 | |
f12944ec UD |
787 | {PB} This was necessary for libc5, but is not correct when using glibc. |
788 | Including the kernel header files directly in user programs usually does not | |
789 | work (see question 3.5). glibc provides its own <net/*> and <scsi/*> header | |
790 | files to replace them, and you may have to remove any symlink that you have | |
791 | in place before you install glibc. However, /usr/include/asm and | |
792 | /usr/include/linux should remain as they were. | |
22d57dd3 | 793 | |
22d57dd3 | 794 | |
3dcf8ea6 | 795 | 2.17. Programs like `logname', `top', `uptime' `users', `w' and |
61952351 UD |
796 | `who', show incorrect information about the (number of) |
797 | users on my system. Why? | |
22d57dd3 | 798 | |
61952351 | 799 | {MK} See question 3.2. |
22d57dd3 | 800 | |
22d57dd3 | 801 | |
3dcf8ea6 | 802 | 2.18. After upgrading to glibc 2.1 with symbol versioning I get |
61952351 | 803 | errors about undefined symbols. What went wrong? |
26dee9c4 | 804 | |
f12944ec UD |
805 | {AJ} The problem is caused either by wrong program code or tools. In the |
806 | versioned libc a lot of symbols are now local that were global symbols in | |
807 | previous versions. It seems that programs linked against older versions | |
808 | often accidentally used libc global variables -- something that should not | |
809 | happen. | |
26dee9c4 | 810 | |
f12944ec UD |
811 | The only way to fix this is to recompile your program. Sorry, that's the |
812 | price you might have to pay once for quite a number of advantages with | |
813 | symbol versioning. | |
26dee9c4 | 814 | |
26dee9c4 | 815 | |
3dcf8ea6 | 816 | 2.19. When I start the program XXX after upgrading the library |
61952351 UD |
817 | I get |
818 | XXX: Symbol `_sys_errlist' has different size in shared | |
819 | object, consider re-linking | |
820 | Why? What should I do? | |
26dee9c4 | 821 | |
f12944ec UD |
822 | {UD} As the message says, relink the binary. The problem is that a few |
823 | symbols from the library can change in size and there is no way to avoid | |
824 | this. _sys_errlist is a good example. Occasionally there are new error | |
825 | numbers added to the kernel and this must be reflected at user level, | |
826 | breaking programs that refer to them directly. | |
a2b08ee5 | 827 | |
f12944ec UD |
828 | Such symbols should normally not be used at all. There are mechanisms to |
829 | avoid using them. In the case of _sys_errlist, there is the strerror() | |
830 | function which should _always_ be used instead. So the correct fix is to | |
831 | rewrite that part of the application. | |
a2b08ee5 | 832 | |
f12944ec UD |
833 | In some situations (especially when testing a new library release) it might |
834 | be possible that a symbol changed size when that should not have happened. | |
835 | So in case of doubt report such a warning message as a problem. | |
a2b08ee5 | 836 | |
a35cb74d | 837 | |
3dcf8ea6 | 838 | 2.20. What do I need for C++ development? |
a35cb74d | 839 | |
f12944ec UD |
840 | {HJ,AJ} You need either egcs 1.0.2 or gcc-2.8.1 with libstdc++ 2.8.1 (or |
841 | more recent versions). libg++ 2.7.2 (and the Linux Versions 2.7.2.x) doesn't | |
842 | work very well with the GNU C library due to vtable thunks. If you're | |
843 | upgrading from glibc 2.0.x to 2.1 you have to recompile libstdc++ since the | |
844 | library compiled for 2.0 is not compatible due to the new Large File Support | |
845 | (LFS) in version 2.1. | |
a35cb74d | 846 | |
ff44f2a5 | 847 | |
3dcf8ea6 | 848 | 2.21. Even statically linked programs need some shared libraries |
ff44f2a5 UD |
849 | which is not acceptable for me. What can I do? |
850 | ||
f12944ec UD |
851 | {AJ} NSS (for details just type `info libc "Name Service Switch"') won't |
852 | work properly without shared libraries. NSS allows using different services | |
853 | (e.g. NIS, files, db, hesiod) by just changing one configuration file | |
854 | (/etc/nsswitch.conf) without relinking any programs. The only disadvantage | |
855 | is that now static libraries need to access shared libraries. This is | |
856 | handled transparently by the GNU C library. | |
ff44f2a5 | 857 | |
f12944ec UD |
858 | A solution is to configure glibc with --enable-static-nss. In this case you |
859 | can create a static binary that will use only the services dns and files | |
860 | (change /etc/nsswitch.conf for this). You need to link explicitly against | |
861 | all these services. For example: | |
ff44f2a5 UD |
862 | |
863 | gcc -static test-netdb.c -o test-netdb.c \ | |
864 | -lc -lnss_files -lnss_dns -lresolv | |
865 | ||
866 | The problem with this approach is that you've got to link every static | |
867 | program that uses NSS routines with all those libraries. | |
868 | ||
869 | {UD} In fact, one cannot say anymore that a libc compiled with this | |
870 | option is using NSS. There is no switch anymore. Therefore it is | |
871 | *highly* recommended *not* to use --enable-static-nss since this makes | |
872 | the behaviour of the programs on the system inconsistent. | |
873 | ||
fdacb17d UD |
874 | |
875 | 2.22. I just upgraded my Linux system to glibc and now I get | |
876 | errors whenever I try to link any program. | |
877 | ||
878 | {ZW} This happens when you have installed glibc as the primary C library but | |
879 | have stray symbolic links pointing at your old C library. If the first | |
880 | `libc.so' the linker finds is libc 5, it will use that. Your program | |
881 | expects to be linked with glibc, so the link fails. | |
882 | ||
883 | The most common case is that glibc put its `libc.so' in /usr/lib, but there | |
884 | was a `libc.so' from libc 5 in /lib, which gets searched first. To fix the | |
885 | problem, just delete /lib/libc.so. You may also need to delete other | |
886 | symbolic links in /lib, such as /lib/libm.so if it points to libm.so.5. | |
887 | ||
888 | {AJ} The perl script test-installation.pl which is run as last step during | |
889 | an installation of glibc that is configured with --prefix=/usr should help | |
890 | detect these situations. If the script reports problems, something is | |
891 | really screwed up. | |
892 | ||
48244d09 UD |
893 | |
894 | 2.23. When I use nscd the machine freezes. | |
895 | ||
896 | {UD} It is well known that you cannot use nscd with Linux 2.0.*. There | |
897 | is functionality missing in the kernel and work-arounds are not suitable. | |
898 | Beside this some parts of the kernel are too buggy when it comes to using | |
899 | threads. | |
900 | ||
901 | So you have the possibilities to run Linux 2.0.* or update to a higher | |
902 | version and start using nscd. | |
903 | ||
904 | Note that I have at this point no information about any other platform. | |
905 | ||
61952351 UD |
906 | \f |
907 | . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | |
a5a0310d | 908 | |
61952351 | 909 | 3. Source and binary incompatibilities, and what to do about them |
a5a0310d | 910 | |
61952351 UD |
911 | 3.1. I expect GNU libc to be 100% source code compatible with |
912 | the old Linux based GNU libc. Why isn't it like this? | |
a5a0310d | 913 | |
f12944ec UD |
914 | {DMT,UD} Not every extension in Linux libc's history was well thought-out. |
915 | In fact it had a lot of problems with standards compliance and with | |
916 | cleanliness. With the introduction of a new version number these errors can | |
917 | now be corrected. Here is a list of the known source code | |
61952351 | 918 | incompatibilities: |
af6f3906 | 919 | |
61952351 UD |
920 | * _GNU_SOURCE: glibc does not make the GNU extensions available |
921 | automatically. If a program depends on GNU extensions or some | |
922 | other non-standard functionality, it is necessary to compile it | |
923 | with the C compiler option -D_GNU_SOURCE, or better, to put | |
924 | `#define _GNU_SOURCE' at the beginning of your source files, before | |
925 | any C library header files are included. This difference normally | |
926 | manifests itself in the form of missing prototypes and/or data type | |
927 | definitions. Thus, if you get such errors, the first thing you | |
928 | should do is try defining _GNU_SOURCE and see if that makes the | |
929 | problem go away. | |
af6f3906 | 930 | |
61952351 UD |
931 | For more information consult the file `NOTES' in the GNU C library |
932 | sources. | |
af6f3906 | 933 | |
61952351 UD |
934 | * reboot(): GNU libc sanitizes the interface of reboot() to be more |
935 | compatible with the interface used on other OSes. reboot() as | |
936 | implemented in glibc takes just one argument. This argument | |
937 | corresponds to the third argument of the Linux reboot system call. | |
938 | That is, a call of the form reboot(a, b, c) needs to be changed into | |
939 | reboot(c). Beside this the header <sys/reboot.h> defines the needed | |
940 | constants for the argument. These RB_* constants should be used | |
941 | instead of the cryptic magic numbers. | |
942 | ||
943 | * swapon(): the interface of this function didn't change, but the | |
944 | prototype is in a separate header file <sys/swap.h>. This header | |
945 | file also provides the SWAP_* constants defined by <linux/swap.h>; | |
946 | you should use them for the second argument to swapon(). | |
947 | ||
948 | * errno: If a program uses the variable "errno", then it _must_ | |
949 | include <errno.h>. The old libc often (erroneously) declared this | |
950 | variable implicitly as a side-effect of including other libc header | |
951 | files. glibc is careful to avoid such namespace pollution, which, | |
952 | in turn, means that you really need to include the header files that | |
953 | you depend on. This difference normally manifests itself in the | |
954 | form of the compiler complaining about references to an undeclared | |
955 | symbol "errno". | |
dd7d45e8 | 956 | |
61952351 UD |
957 | * Linux-specific syscalls: All Linux system calls now have appropriate |
958 | library wrappers and corresponding declarations in various header files. | |
959 | This is because the syscall() macro that was traditionally used to | |
960 | work around missing syscall wrappers are inherently non-portable and | |
961 | error-prone. The following table lists all the new syscall stubs, | |
962 | the header-file declaring their interface and the system call name. | |
dd7d45e8 | 963 | |
61952351 UD |
964 | syscall name: wrapper name: declaring header file: |
965 | ------------- ------------- ---------------------- | |
966 | bdflush bdflush <sys/kdaemon.h> | |
967 | syslog ksyslog_ctl <sys/klog.h> | |
dd7d45e8 | 968 | |
61952351 UD |
969 | * lpd: Older versions of lpd depend on a routine called _validuser(). |
970 | The library does not provide this function, but instead provides | |
971 | __ivaliduser() which has a slightly different interface. Simply | |
972 | upgrading to a newer lpd should fix this problem (e.g., the 4.4BSD | |
973 | lpd is known to be working). | |
dd7d45e8 | 974 | |
61952351 UD |
975 | * resolver functions/BIND: like on many other systems the functions of |
976 | the resolver library are not included in libc itself. There is a | |
977 | separate library libresolv. If you get undefined symbol errors for | |
978 | symbols starting with `res_*' simply add -lresolv to your linker | |
979 | command line. | |
dd7d45e8 | 980 | |
61952351 UD |
981 | * the `signal' function's behavior corresponds to the BSD semantic and |
982 | not the SysV semantic as it was in libc-5. The interface on all GNU | |
983 | systems shall be the same and BSD is the semantic of choice. To use | |
984 | the SysV behavior simply use `sysv_signal', or define _XOPEN_SOURCE. | |
985 | See question 3.7 for details. | |
1cab5444 | 986 | |
1cab5444 | 987 | |
61952351 UD |
988 | 3.2. Why does getlogin() always return NULL on my Linux box? |
989 | ||
f12944ec UD |
990 | {UD} The GNU C library has a format for the UTMP and WTMP file which differs |
991 | from what your system currently has. It was extended to fulfill the needs | |
992 | of the next years when IPv6 is introduced. The record size is different and | |
993 | some fields have different positions. The files written by functions from | |
994 | the one library cannot be read by functions from the other library. Sorry, | |
995 | but this is what a major release is for. It's better to have a cut now than | |
996 | having no means to support the new techniques later. | |
1cab5444 | 997 | |
f12944ec UD |
998 | {MK} There is however a (partial) solution for this problem. Please take a |
999 | look at the file `login/README.utmpd'. | |
1cab5444 | 1000 | |
6973fc01 | 1001 | |
61952351 UD |
1002 | 3.3. Where are the DST_* constants found in <sys/time.h> on many |
1003 | systems? | |
6973fc01 | 1004 | |
f12944ec UD |
1005 | {UD} These constants come from the old BSD days and are not used anymore |
1006 | (libc5 does not actually implement the handling although the constants are | |
1007 | defined). | |
6973fc01 | 1008 | |
f12944ec UD |
1009 | Instead GNU libc contains zone database support and compatibility code for |
1010 | POSIX TZ environment variable handling. | |
6973fc01 UD |
1011 | |
1012 | ||
61952351 UD |
1013 | 3.4. The prototypes for `connect', `accept', `getsockopt', |
1014 | `setsockopt', `getsockname', `getpeername', `send', | |
1015 | `sendto', and `recvfrom' are different in GNU libc from | |
1016 | any other system I saw. This is a bug, isn't it? | |
f4017d20 | 1017 | |
f12944ec UD |
1018 | {UD} No, this is no bug. This version of GNU libc already follows the new |
1019 | Single Unix specifications (and I think the POSIX.1g draft which adopted the | |
1020 | solution). The type for a parameter describing a size is now `socklen_t', a | |
1021 | new type. | |
f4017d20 | 1022 | |
f4017d20 | 1023 | |
61952351 UD |
1024 | 3.5. On Linux I've got problems with the declarations in Linux |
1025 | kernel headers. | |
f4017d20 | 1026 | |
f12944ec UD |
1027 | {UD,AJ} On Linux, the use of kernel headers is reduced to the minimum. This |
1028 | gives Linus the ability to change the headers more freely. Also, user | |
8f1c9b09 | 1029 | programs are now insulated from changes in the size of kernel data |
f12944ec | 1030 | structures. |
f4017d20 | 1031 | |
f12944ec UD |
1032 | For example, the sigset_t type is 32 or 64 bits wide in the kernel. In |
1033 | glibc it is 1024 bits wide. This guarantees that when the kernel gets a | |
1034 | bigger sigset_t (for POSIX.1e realtime support, say) user programs will not | |
1035 | have to be recompiled. Consult the header files for more information about | |
1036 | the changes. | |
61952351 | 1037 | |
f12944ec UD |
1038 | Therefore you shouldn't include Linux kernel header files directly if glibc |
1039 | has defined a replacement. Otherwise you might get undefined results because | |
1040 | of type conflicts. | |
f4017d20 | 1041 | |
f4017d20 | 1042 | |
61952351 UD |
1043 | 3.6. I don't include any kernel headers myself but the compiler |
1044 | still complains about redeclarations of types in the kernel | |
1045 | headers. | |
1046 | ||
f12944ec UD |
1047 | {UD} The kernel headers before Linux 2.1.61 and 2.0.32 don't work correctly |
1048 | with glibc. Compiling C programs is possible in most cases but C++ programs | |
1049 | have (due to the change of the name lookups for `struct's) problems. One | |
1050 | prominent example is `struct fd_set'. | |
61952351 | 1051 | |
f12944ec UD |
1052 | There might be some problems left but 2.1.61/2.0.32 fix most of the known |
1053 | ones. See the BUGS file for other known problems. | |
61952351 UD |
1054 | |
1055 | ||
1056 | 3.7. Why don't signals interrupt system calls anymore? | |
1057 | ||
f12944ec UD |
1058 | {ZW} By default GNU libc uses the BSD semantics for signal(), unlike Linux |
1059 | libc 5 which used System V semantics. This is partially for compatibility | |
1060 | with other systems and partially because the BSD semantics tend to make | |
1061 | programming with signals easier. | |
f4017d20 UD |
1062 | |
1063 | There are three differences: | |
1064 | ||
1065 | * BSD-style signals that occur in the middle of a system call do not | |
1066 | affect the system call; System V signals cause the system call to | |
1067 | fail and set errno to EINTR. | |
1068 | ||
1069 | * BSD signal handlers remain installed once triggered. System V signal | |
1070 | handlers work only once, so one must reinstall them each time. | |
1071 | ||
1072 | * A BSD signal is blocked during the execution of its handler. In other | |
1073 | words, a handler for SIGCHLD (for example) does not need to worry about | |
61952351 | 1074 | being interrupted by another SIGCHLD. It may, however, be interrupted |
f4017d20 UD |
1075 | by other signals. |
1076 | ||
1077 | There is general consensus that for `casual' programming with signals, the | |
1078 | BSD semantics are preferable. You don't need to worry about system calls | |
1079 | returning EINTR, and you don't need to worry about the race conditions | |
1080 | associated with one-shot signal handlers. | |
1081 | ||
1082 | If you are porting an old program that relies on the old semantics, you can | |
1083 | quickly fix the problem by changing signal() to sysv_signal() throughout. | |
1084 | Alternatively, define _XOPEN_SOURCE before including <signal.h>. | |
1085 | ||
1086 | For new programs, the sigaction() function allows you to specify precisely | |
1087 | how you want your signals to behave. All three differences listed above are | |
1088 | individually switchable on a per-signal basis with this function. | |
1089 | ||
f12944ec UD |
1090 | If all you want is for one specific signal to cause system calls to fail and |
1091 | return EINTR (for example, to implement a timeout) you can do this with | |
f4017d20 UD |
1092 | siginterrupt(). |
1093 | ||
1094 | ||
61952351 UD |
1095 | 3.8. I've got errors compiling code that uses certain string |
1096 | functions. Why? | |
1097 | ||
f12944ec | 1098 | {AJ} glibc 2.1 has special string functions that are faster than the normal |
fdacb17d | 1099 | library functions. Some of the functions are additionally implemented as |
3dcf8ea6 | 1100 | inline functions and others as macros. |
04be94a8 | 1101 | |
04be94a8 | 1102 | The optimized string functions are only used when compiling with |
fdacb17d | 1103 | optimizations (-O1 or higher). The behavior can be changed with two feature |
f12944ec | 1104 | macros: |
61952351 UD |
1105 | |
1106 | * __NO_STRING_INLINES: Don't do any string optimizations. | |
1107 | * __USE_STRING_INLINES: Use assembly language inline functions (might | |
1108 | increase code size dramatically). | |
04be94a8 | 1109 | |
f12944ec UD |
1110 | Since some of these string functions are now additionally defined as macros, |
1111 | code like "char *strncpy();" doesn't work anymore (and is unnecessary, since | |
fdacb17d | 1112 | <string.h> has the necessary declarations). Either change your code or |
f12944ec | 1113 | define __NO_STRING_INLINES. |
04be94a8 | 1114 | |
f12944ec UD |
1115 | {UD} Another problem in this area is that gcc still has problems on machines |
1116 | with very few registers (e.g., ix86). The inline assembler code can require | |
1117 | almost all the registers and the register allocator cannot always handle | |
1118 | this situation. | |
04be94a8 | 1119 | |
61952351 | 1120 | One can disable the string optimizations selectively. Instead of writing |
04be94a8 UD |
1121 | |
1122 | cp = strcpy (foo, "lkj"); | |
1123 | ||
1124 | one can write | |
1125 | ||
1126 | cp = (strcpy) (foo, "lkj"); | |
1127 | ||
61952351 UD |
1128 | This disables the optimization for that specific call. |
1129 | ||
4775243a UD |
1130 | |
1131 | 3.9. I get compiler messages "Initializer element not constant" with | |
1132 | stdin/stdout/stderr. Why? | |
1133 | ||
1134 | {RM,AJ} Constructs like: | |
1135 | static FILE *InPtr = stdin; | |
1136 | ||
fdacb17d UD |
1137 | lead to this message. This is correct behaviour with glibc since stdin is |
1138 | not a constant expression. Please note that a strict reading of ISO C does | |
f12944ec | 1139 | not allow above constructs. |
4775243a | 1140 | |
f12944ec UD |
1141 | One of the advantages of this is that you can assign to stdin, stdout, and |
1142 | stderr just like any other global variable (e.g. `stdout = my_stream;'), | |
1143 | which can be very useful with custom streams that you can write with libio | |
fdacb17d | 1144 | (but beware this is not necessarily portable). The reason to implement it |
f12944ec | 1145 | this way were versioning problems with the size of the FILE structure. |
4775243a | 1146 | |
fdacb17d UD |
1147 | To fix those programs you've got to initialize the variable at run time. |
1148 | This can be done, e.g. in main, like: | |
1149 | ||
1150 | static FILE *InPtr; | |
bfcd44c3 | 1151 | int main(void) |
fdacb17d UD |
1152 | { |
1153 | InPtr = stdin; | |
1154 | } | |
1155 | ||
1156 | or by constructors (beware this is gcc specific): | |
1157 | ||
1158 | static FILE *InPtr; | |
1159 | static void inPtr_construct (void) __attribute__((constructor)); | |
1160 | static void inPtr_construct (void) { InPtr = stdin; } | |
1161 | ||
4775243a UD |
1162 | |
1163 | 3.10. I can't compile with gcc -traditional (or | |
1164 | -traditional-cpp). Why? | |
1165 | ||
1166 | {AJ} glibc2 does break -traditional and -traditonal-cpp - and will continue | |
fdacb17d | 1167 | to do so. For example constructs of the form: |
f12944ec | 1168 | |
4775243a UD |
1169 | enum {foo |
1170 | #define foo foo | |
1171 | } | |
f12944ec UD |
1172 | |
1173 | are useful for debugging purposes (you can use foo with your debugger that's | |
1174 | why we need the enum) and for compatibility (other systems use defines and | |
1175 | check with #ifdef). | |
4775243a UD |
1176 | |
1177 | ||
1178 | 3.11. I get some errors with `gcc -ansi'. Isn't glibc ANSI compatible? | |
1179 | ||
1180 | {AJ} The GNU C library is compatible with the ANSI/ISO C standard. If | |
f12944ec | 1181 | you're using `gcc -ansi', the glibc includes which are specified in the |
fdacb17d | 1182 | standard follow the standard. The ANSI/ISO C standard defines what has to be |
f12944ec UD |
1183 | in the include files - and also states that nothing else should be in the |
1184 | include files (btw. you can still enable additional standards with feature | |
1185 | flags). | |
4775243a | 1186 | |
f12944ec UD |
1187 | The GNU C library is conforming to ANSI/ISO C - if and only if you're only |
1188 | using the headers and library functions defined in the standard. | |
4775243a | 1189 | |
a35cb74d UD |
1190 | |
1191 | 3.12. I can't access some functions anymore. nm shows that they do | |
1192 | exist but linking fails nevertheless. | |
1193 | ||
f12944ec UD |
1194 | {AJ} With the introduction of versioning in glibc 2.1 it is possible to |
1195 | export only those identifiers (functions, variables) that are really needed | |
1196 | by application programs and by other parts of glibc. This way a lot of | |
1197 | internal interfaces are now hidden. nm will still show those identifiers | |
1198 | but marking them as internal. ISO C states that identifiers beginning with | |
1199 | an underscore are internal to the libc. An application program normally | |
1200 | shouldn't use those internal interfaces (there are exceptions, | |
1201 | e.g. __ivaliduser). If a program uses these interfaces, it's broken. These | |
1202 | internal interfaces might change between glibc releases or dropped | |
1203 | completely. | |
a35cb74d | 1204 | |
a5f4e34a UD |
1205 | |
1206 | 3.13. When using the db-2 library which comes with glibc is used in | |
1207 | the Perl db modules the testsuite is not passed. This did not | |
1208 | happen with db-1, gdbm, or ndbm. | |
1209 | ||
1210 | {UD} You are using an outdated copy of the DB_File Perl module. In fact db-2 | |
1211 | finally removed the handling of zero-sized keys which was one of the features | |
1212 | tested by the old Perl testsuite and therefore you see an error. But this | |
1213 | never was documented and guaranteed, only broken programs used this feature. | |
1214 | ||
1215 | Consequently db-2 does not need to support this feature and instead signals | |
1216 | an error which leads to easier debugging. The DB_File module maintainer | |
1217 | Paul Marquess <pmarquess@bfsec.bt.co.uk> acknowledged this change and fixed | |
1218 | the testsuite so that if you use DB_File v1.60 or later you should not have | |
1219 | any more problems with db-2. | |
1220 | ||
5148d49f UD |
1221 | |
1222 | 3.14. The pow() inline function I get when including <math.h> is broken. | |
1223 | I get segmentation faults when I run the program. | |
1224 | ||
1225 | {UD} Nope, the implementation is correct. The problem is with egcs version | |
1226 | prior to 1.1. I.e., egcs 1.0 to 1.0.3 are all broken (at least on Intel). | |
1227 | If you have to use this compiler you must define __NO_MATH_INLINES before | |
1228 | including <math.h> to prevent the inline functions from being used. egcs 1.1 | |
1229 | fixes the problem. I don't know about gcc 2.8 and 2.8.1. | |
1230 | ||
61952351 UD |
1231 | \f |
1232 | . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | |
1233 | ||
1234 | 4. Miscellaneous | |
1235 | ||
1236 | 4.1. After I changed configure.in I get `Autoconf version X.Y. | |
1237 | or higher is required for this script'. What can I do? | |
1238 | ||
1239 | {UD} You have to get the specified autoconf version (or a later one) | |
a35cb74d | 1240 | from your favorite mirror of ftp.gnu.org. |
61952351 | 1241 | |
04be94a8 | 1242 | |
61952351 UD |
1243 | 4.2. When I try to compile code which uses IPv6 headers and |
1244 | definitions on my Linux 2.x.y system I am in trouble. | |
1245 | Nothing seems to work. | |
1246 | ||
f12944ec UD |
1247 | {UD} The problem is that IPv6 development still has not reached a point |
1248 | where the headers are stable. There are still lots of incompatible changes | |
1249 | made and the libc headers have to follow. | |
61952351 UD |
1250 | |
1251 | Also, make sure you have a suitably recent kernel. As of the 970401 | |
4775243a UD |
1252 | snapshot, according to Philip Blundell <Philip.Blundell@pobox.com>, the |
1253 | required kernel version is at least 2.1.30. | |
04be94a8 | 1254 | |
ff44f2a5 | 1255 | |
aa802e96 | 1256 | 4.3. When I set the timezone by setting the TZ environment variable |
ff44f2a5 UD |
1257 | to EST5EDT things go wrong since glibc computes the wrong time |
1258 | from this information. | |
1259 | ||
f12944ec UD |
1260 | {UD} The problem is that people still use the braindamaged POSIX method to |
1261 | select the timezone using the TZ environment variable with a format EST5EDT | |
1262 | or whatever. People, read the POSIX standard, the implemented behaviour is | |
1263 | correct! What you see is in fact the result of the decisions made while | |
1264 | POSIX.1 was created. We've only implemented the handling of TZ this way to | |
1265 | be POSIX compliant. It is not really meant to be used. | |
1266 | ||
1267 | The alternative approach to handle timezones which is implemented is the | |
1268 | correct one to use: use the timezone database. This avoids all the problems | |
1269 | the POSIX method has plus it is much easier to use. Simply run the tzselect | |
1270 | shell script, answer the question and use the name printed in the end by | |
1271 | making a symlink to /usr/share/zoneinfo/NAME (NAME is the returned value | |
1272 | from tzselect) from the file /etc/localtime. That's all. You never again | |
1273 | have to worry. | |
1274 | ||
1275 | So, please avoid sending bug reports about time related problems if you use | |
1276 | the POSIX method and you have not verified something is really broken by | |
1277 | reading the POSIX standards. | |
ff44f2a5 | 1278 | |
fdacb17d UD |
1279 | |
1280 | 4.4. What other sources of documentation about glibc are available? | |
1281 | ||
1282 | {AJ} The FSF has a page about the GNU C library at | |
1283 | <http://www.gnu.org/software/libc/>. The problem data base of open and | |
1284 | solved bugs in GNU libc is available at | |
1285 | <http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl>. Eric Green has written | |
1286 | a HowTo for converting from Linux libc5 to glibc2. The HowTo is accessable | |
1287 | via the FSF page and at <http://www.imaxx.net/~thrytis/glibc>. Frodo | |
1288 | Looijaard describes a different way installing glibc2 as secondary libc at | |
1289 | <http://huizen.dds.nl/~frodol/glibc>. | |
1290 | ||
1291 | Please note that this is not a complete list. | |
1292 | ||
f8cac037 | 1293 | \f |
61952351 UD |
1294 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
1295 | ||
f8cac037 RM |
1296 | Answers were given by: |
1297 | {UD} Ulrich Drepper, <drepper@cygnus.com> | |
613a76ff | 1298 | {DMT} David Mosberger-Tang, <davidm@AZStarNet.com> |
dd7d45e8 | 1299 | {RM} Roland McGrath, <roland@gnu.org> |
1f205a47 | 1300 | {AJ} Andreas Jaeger, <aj@arthur.rhein-neckar.de> |
22d57dd3 | 1301 | {EY} Eric Youngdale, <eric@andante.jic.com> |
a5a0310d | 1302 | {PB} Phil Blundell, <Philip.Blundell@pobox.com> |
af6f3906 | 1303 | {MK} Mark Kettenis, <kettenis@phys.uva.nl> |
f4017d20 | 1304 | {ZW} Zack Weinberg, <zack@rabi.phys.columbia.edu> |
4775243a | 1305 | {TK} Thorsten Kukuk, <kukuk@vt.uni-paderborn.de> |
8619129f | 1306 | {GK} Geoffrey Keating, <geoffk@ozemail.com.au> |
a35cb74d | 1307 | {HJ} H.J. Lu, <hjl@gnu.org> |
f8cac037 RM |
1308 | \f |
1309 | Local Variables: | |
61952351 UD |
1310 | mode:outline |
1311 | outline-regexp:"\\?" | |
f12944ec | 1312 | fill-column:76 |
f8cac037 | 1313 | End: |