]>
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 | 14 | |
934b77ac | 15 | --drepper@redhat.com |
f8cac037 | 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? | |
5edb9387 | 25 | 1.4. Do I need a special linker or assembler? |
8619129f | 26 | 1.5. Which compiler should I use for powerpc? |
348ed515 UD |
27 | 1.6. Which tools should I use for ARM? |
28 | 1.7. Do I need some more things to compile the GNU C Library? | |
29 | 1.8. What version of the Linux kernel headers should be used? | |
30 | 1.9. The compiler hangs while building iconvdata modules. What's | |
f12944ec | 31 | wrong? |
348ed515 | 32 | 1.10. When I run `nm -u libc.so' on the produced library I still |
61952351 | 33 | find unresolved symbols. Can this be ok? |
348ed515 UD |
34 | 1.11. What are these `add-ons'? |
35 | 1.12. My XXX kernel emulates a floating-point coprocessor for me. | |
61952351 | 36 | Should I enable --with-fp? |
348ed515 | 37 | 1.13. When compiling GNU libc I get lots of errors saying functions |
61952351 | 38 | in glibc are duplicated in libgcc. |
348ed515 | 39 | 1.14. Why do I get messages about missing thread functions when I use |
a35cb74d | 40 | librt? I don't even use threads. |
348ed515 | 41 | 1.15. What's the problem with configure --enable-omitfp? |
b1418d8f | 42 | 1.16. I get failures during `make check'. What should I do? |
348ed515 | 43 | 1.17. What is symbol versioning good for? Do I need it? |
c7f7281e UD |
44 | 1.18. How can I compile on my fast ix86 machine a working libc for my slow |
45 | i386? After installing libc, programs abort with "Illegal | |
46 | Instruction". | |
150ae521 UD |
47 | 1.19. `make' complains about a missing dlfcn/libdl.so when building |
48 | malloc/libmemprof.so. How can I fix this? | |
2c88f872 | 49 | 1.20. Which tools should I use for MIPS? |
dfc89273 | 50 | 1.21. Which compiler should I use for powerpc64? |
9cb97cd4 RM |
51 | 1.22. `make' fails when running rpcgen the first time, |
52 | what is going on? How do I fix this? | |
61952351 UD |
53 | |
54 | 2. Installation and configuration issues | |
55 | ||
56 | 2.1. Can I replace the libc on my Linux system with GNU libc? | |
57 | 2.2. How do I configure GNU libc so that the essential libraries | |
58 | like libc.so go into /lib and the other into /usr/lib? | |
59 | 2.3. How should I avoid damaging my system when I install GNU libc? | |
60 | 2.4. Do I need to use GNU CC to compile programs that will use the | |
61 | GNU C Library? | |
62 | 2.5. When linking with the new libc I get unresolved symbols | |
63 | `crypt' and `setkey'. Why aren't these functions in the | |
64 | libc anymore? | |
65 | 2.6. When I use GNU libc on my Linux system by linking against | |
66 | the libc.so which comes with glibc all I get is a core dump. | |
67 | 2.7. Looking through the shared libc file I haven't found the | |
68 | functions `stat', `lstat', `fstat', and `mknod' and while | |
69 | linking on my Linux system I get error messages. How is | |
70 | this supposed to work? | |
5edb9387 UD |
71 | 2.8. When I run an executable on one system which I compiled on |
72 | another, I get dynamic linker errors. Both systems have the same | |
73 | version of glibc installed. What's wrong? | |
74 | 2.9. How can I compile gcc 2.7.2.1 from the gcc source code using | |
61952351 | 75 | glibc 2.x? |
5edb9387 | 76 | 2.10. The `gencat' utility cannot process the catalog sources which |
61952351 | 77 | were used on my Linux libc5 based system. Why? |
5edb9387 | 78 | 2.11. Programs using libc have their messages translated, but other |
a35cb74d | 79 | behavior is not localized (e.g. collating order); why? |
5edb9387 | 80 | 2.12. I have set up /etc/nis.conf, and the Linux libc 5 with NYS |
61952351 | 81 | works great. But the glibc NIS+ doesn't seem to work. |
5edb9387 | 82 | 2.13. I have killed ypbind to stop using NIS, but glibc |
3dcf8ea6 | 83 | continues using NIS. |
5edb9387 | 84 | 2.14. Under Linux/Alpha, I always get "do_ypcall: clnt_call: |
3dcf8ea6 | 85 | RPC: Unable to receive; errno = Connection refused" when using NIS. |
5edb9387 UD |
86 | 2.15. After installing glibc name resolving doesn't work properly. |
87 | 2.16. How do I create the databases for NSS? | |
88 | 2.17. I have /usr/include/net and /usr/include/scsi as symlinks | |
61952351 | 89 | into my Linux source tree. Is that wrong? |
5edb9387 | 90 | 2.18. Programs like `logname', `top', `uptime' `users', `w' and |
61952351 UD |
91 | `who', show incorrect information about the (number of) |
92 | users on my system. Why? | |
5edb9387 | 93 | 2.19. After upgrading to glibc 2.1 with symbol versioning I get |
61952351 | 94 | errors about undefined symbols. What went wrong? |
5edb9387 | 95 | 2.20. When I start the program XXX after upgrading the library |
61952351 UD |
96 | I get |
97 | XXX: Symbol `_sys_errlist' has different size in shared | |
98 | object, consider re-linking | |
99 | Why? What should I do? | |
5edb9387 UD |
100 | 2.21. What do I need for C++ development? |
101 | 2.22. Even statically linked programs need some shared libraries | |
ff44f2a5 | 102 | which is not acceptable for me. What can I do? |
5edb9387 | 103 | 2.23. I just upgraded my Linux system to glibc and now I get |
fdacb17d | 104 | errors whenever I try to link any program. |
5edb9387 | 105 | 2.24. When I use nscd the machine freezes. |
0155a773 | 106 | 2.25. I need lots of open files. What do I have to do? |
7db169c9 UD |
107 | 2.26. How do I get the same behavior on parsing /etc/passwd and |
108 | /etc/group as I have with libc5 ? | |
b710a6e2 UD |
109 | 2.27. What needs to be recompiled when upgrading from glibc 2.0 to glibc |
110 | 2.1? | |
b7398be5 | 111 | 2.28. Why is extracting files via tar so slow? |
2ee511d9 UD |
112 | 2.29. Compiling programs I get parse errors in libio.h (e.g. "parse error |
113 | before `_IO_seekoff'"). How should I fix this? | |
4f7ea427 UD |
114 | 2.30. After upgrading to glibc 2.1, libraries that were compiled against |
115 | glibc 2.0.x don't work anymore. | |
9de4e203 UD |
116 | 2.31. What happened to the Berkeley DB libraries? Can I still use db |
117 | in /etc/nsswitch.conf? | |
2c88f872 | 118 | 2.32. What has do be done when upgrading to glibc 2.2? |
4442d7e8 | 119 | 2.33. The makefiles want to do a CVS commit. |
1324affa UD |
120 | 2.34. When compiling C++ programs, I get a compilation error in streambuf.h. |
121 | 2.35. When recompiling GCC, I get compilation errors in libio. | |
934b77ac UD |
122 | 2.36. Why shall glibc never get installed on GNU/Linux systems in |
123 | /usr/local? | |
4011dc70 | 124 | 2.37. When recompiling GCC, I get compilation errors in libstdc++. |
61952351 UD |
125 | |
126 | 3. Source and binary incompatibilities, and what to do about them | |
127 | ||
128 | 3.1. I expect GNU libc to be 100% source code compatible with | |
129 | the old Linux based GNU libc. Why isn't it like this? | |
130 | 3.2. Why does getlogin() always return NULL on my Linux box? | |
131 | 3.3. Where are the DST_* constants found in <sys/time.h> on many | |
132 | systems? | |
133 | 3.4. The prototypes for `connect', `accept', `getsockopt', | |
134 | `setsockopt', `getsockname', `getpeername', `send', | |
135 | `sendto', and `recvfrom' are different in GNU libc from | |
136 | any other system I saw. This is a bug, isn't it? | |
137 | 3.5. On Linux I've got problems with the declarations in Linux | |
138 | kernel headers. | |
139 | 3.6. I don't include any kernel headers myself but the compiler | |
140 | still complains about redeclarations of types in the kernel | |
141 | headers. | |
142 | 3.7. Why don't signals interrupt system calls anymore? | |
143 | 3.8. I've got errors compiling code that uses certain string | |
144 | functions. Why? | |
4775243a UD |
145 | 3.9. I get compiler messages "Initializer element not constant" with |
146 | stdin/stdout/stderr. Why? | |
147 | 3.10. I can't compile with gcc -traditional (or | |
148 | -traditional-cpp). Why? | |
149 | 3.11. I get some errors with `gcc -ansi'. Isn't glibc ANSI compatible? | |
a35cb74d UD |
150 | 3.12. I can't access some functions anymore. nm shows that they do |
151 | exist but linking fails nevertheless. | |
a5f4e34a UD |
152 | 3.13. When using the db-2 library which comes with glibc is used in |
153 | the Perl db modules the testsuite is not passed. This did not | |
154 | happen with db-1, gdbm, or ndbm. | |
5148d49f UD |
155 | 3.14. The pow() inline function I get when including <math.h> is broken. |
156 | I get segmentation faults when I run the program. | |
05f732b3 | 157 | 3.15. The sys/sem.h file lacks the definition of `union semun'. |
33127459 | 158 | 3.16. Why has <netinet/ip_fw.h> disappeared? |
28ab8526 UD |
159 | 3.17. I get floods of warnings when I use -Wconversion and include |
160 | <string.h> or <math.h>. | |
5ff1a70a UD |
161 | 3.18. After upgrading to glibc 2.1, I receive errors about |
162 | unresolved symbols, like `_dl_initial_searchlist' and can not | |
163 | execute any binaries. What went wrong? | |
7d1de115 UD |
164 | 3.19. bonnie reports that char i/o with glibc 2 is much slower than with |
165 | libc5. What can be done? | |
b93492aa UD |
166 | 3.20. Programs compiled with glibc 2.1 can't read db files made with glibc |
167 | 2.0. What has changed that programs like rpm break? | |
b5a9efcd UD |
168 | 3.21. Autoconf's AC_CHECK_FUNC macro reports that a function exists, but |
169 | when I try to use it, it always returns -1 and sets errno to ENOSYS. | |
170 | 3.22. My program segfaults when I call fclose() on the FILE* returned | |
171 | from setmntent(). Is this a glibc bug? | |
c891b2df | 172 | 3.23. I get "undefined reference to `atexit'" |
61952351 | 173 | |
7d1de115 | 174 | 4. Miscellaneous |
61952351 | 175 | |
7d1de115 | 176 | 4.1. After I changed configure.in I get `Autoconf version X.Y. |
61952351 | 177 | or higher is required for this script'. What can I do? |
7d1de115 | 178 | 4.2. When I try to compile code which uses IPv6 headers and |
61952351 UD |
179 | definitions on my Linux 2.x.y system I am in trouble. |
180 | Nothing seems to work. | |
7d1de115 | 181 | 4.3. When I set the timezone by setting the TZ environment variable |
ff44f2a5 UD |
182 | to EST5EDT things go wrong since glibc computes the wrong time |
183 | from this information. | |
7d1de115 UD |
184 | 4.4. What other sources of documentation about glibc are available? |
185 | 4.5. The timezone string for Sydney/Australia is wrong since even when | |
348ed515 | 186 | daylight saving time is in effect the timezone string is EST. |
7d1de115 | 187 | 4.6. I've build make 3.77 against glibc 2.1 and now make gets |
eeabe877 | 188 | segmentation faults. |
c63598bf | 189 | 4.7. Why do so many programs using math functions fail on my AlphaStation? |
8892c471 UD |
190 | 4.8. The conversion table for character set XX does not match with |
191 | what I expect. | |
be76803a | 192 | 4.9. How can I find out which version of glibc I am using in the moment? |
5e014387 UD |
193 | 4.10. Context switching with setcontext() does not work from within |
194 | signal handlers. | |
f8cac037 | 195 | |
61952351 UD |
196 | \f |
197 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | |
f4017d20 | 198 | |
61952351 | 199 | 1. Compiling glibc |
04be94a8 | 200 | |
61952351 | 201 | 1.1. What systems does the GNU C Library run on? |
613a76ff | 202 | |
f12944ec UD |
203 | {UD} This is difficult to answer. The file `README' lists the architectures |
204 | GNU libc was known to run on *at some time*. This does not mean that it | |
205 | still can be compiled and run on them now. | |
f8cac037 | 206 | |
f12944ec UD |
207 | The systems glibc is known to work on as of this release, and most probably |
208 | in the future, are: | |
f8cac037 RM |
209 | |
210 | *-*-gnu GNU Hurd | |
4775243a UD |
211 | i[3456]86-*-linux-gnu Linux-2.x on Intel |
212 | m68k-*-linux-gnu Linux-2.x on Motorola 680x0 | |
2bbc70d5 | 213 | alpha*-*-linux-gnu Linux-2.x on DEC Alpha |
9a0a462c | 214 | powerpc-*-linux-gnu Linux and MkLinux on PowerPC systems |
dfc89273 | 215 | powerpc64-*-linux-gnu Linux-2.4+ on 64-bit PowerPC systems |
4775243a UD |
216 | sparc-*-linux-gnu Linux-2.x on SPARC |
217 | sparc64-*-linux-gnu Linux-2.x on UltraSPARC | |
ff44f2a5 | 218 | arm-*-none ARM standalone systems |
348ed515 | 219 | arm-*-linux Linux-2.x on ARM |
ff44f2a5 | 220 | arm-*-linuxaout Linux-2.x on ARM using a.out binaries |
2bbc70d5 AJ |
221 | mips*-*-linux-gnu Linux-2.x on MIPS |
222 | ia64-*-linux-gnu Linux-2.x on ia64 | |
2c88f872 | 223 | s390-*-linux-gnu Linux-2.x on IBM S/390 |
4a5b72ff | 224 | s390x-*-linux-gnu Linux-2.x on IBM S/390 64-bit |
eacde9d0 | 225 | cris-*-linux-gnu Linux-2.4+ on CRIS |
f8cac037 | 226 | |
f12944ec UD |
227 | Ports to other Linux platforms are in development, and may in fact work |
228 | already, but no one has sent us success reports for them. Currently no | |
229 | ports to other operating systems are underway, although a few people have | |
230 | expressed interest. | |
f8cac037 | 231 | |
f12944ec | 232 | If you have a system not listed above (or in the `README' file) and you are |
65903cc5 RM |
233 | really interested in porting it, see the GNU C Library web pages to learn |
234 | how to start contributing: | |
f8cac037 | 235 | |
65903cc5 | 236 | http://www.gnu.org/software/libc/resources.html |
f8cac037 RM |
237 | |
238 | ||
61952351 | 239 | 1.2. What compiler do I need to build GNU libc? |
f8cac037 | 240 | |
f12944ec UD |
241 | {UD} You must use GNU CC to compile GNU libc. A lot of extensions of GNU CC |
242 | are used to increase portability and speed. | |
f8cac037 | 243 | |
61952351 | 244 | GNU CC is found, like all other GNU packages, on |
f12944ec | 245 | |
a35cb74d | 246 | ftp://ftp.gnu.org/pub/gnu |
f12944ec | 247 | |
a35cb74d | 248 | and the many mirror sites. ftp.gnu.org is always overloaded, so try to find |
61952351 | 249 | a local mirror first. |
f8cac037 | 250 | |
b0610668 | 251 | You should always try to use the latest official release. Older versions |
f12944ec | 252 | may not have all the features GNU libc requires. The current releases of |
4011dc70 | 253 | gcc (3.2 or newer) should work with the GNU C library (for MIPS see question 1.20). |
f8cac037 | 254 | |
6e8afc1c | 255 | Please note that gcc 2.95 and 2.95.x cannot compile glibc on Alpha due to |
bd952512 UD |
256 | problems in the complex float support. |
257 | ||
f8cac037 | 258 | |
61952351 UD |
259 | 1.3. When I try to compile glibc I get only error messages. |
260 | What's wrong? | |
f8cac037 | 261 | |
b1418d8f | 262 | {UD} You definitely need GNU make to build GNU libc. No other make |
f12944ec | 263 | program has the needed functionality. |
f8cac037 | 264 | |
2bbc70d5 AJ |
265 | We recommend version GNU make version 3.79 or newer. Older versions have |
266 | bugs and/or are missing features. | |
f8cac037 | 267 | |
f8cac037 | 268 | |
5edb9387 | 269 | 1.4. Do I need a special linker or assembler? |
f8cac037 | 270 | |
5edb9387 UD |
271 | {ZW} If you want a shared library, you need a linker and assembler that |
272 | understand all the features of ELF, including weak and versioned symbols. | |
273 | The static library can be compiled with less featureful tools, but lacks key | |
274 | features such as NSS. | |
41f27456 | 275 | |
1e2fb683 | 276 | For Linux or Hurd, you want binutils 2.13 or higher. These are the only |
b0ed91ae AJ |
277 | versions we've tested and found reliable. Other versions may work but we |
278 | don't recommend them, especially not when C++ is involved. | |
a379e56a | 279 | |
5edb9387 UD |
280 | Other operating systems may come with system tools that have all the |
281 | necessary features, but this is moot because glibc hasn't been ported to | |
282 | them. | |
f8cac037 | 283 | |
f8cac037 | 284 | |
8619129f | 285 | 1.5. Which compiler should I use for powerpc? |
4775243a | 286 | |
4011dc70 | 287 | {} Removed. Does not apply anymore. |
4775243a UD |
288 | |
289 | ||
348ed515 UD |
290 | 1.6. Which tools should I use for ARM? |
291 | ||
4011dc70 | 292 | {} Removed. Does not apply anymore. |
348ed515 UD |
293 | |
294 | ||
295 | 1.7. Do I need some more things to compile the GNU C Library? | |
f8cac037 | 296 | |
61952351 | 297 | {UD} Yes, there are some more :-). |
78b5ba3e | 298 | |
61952351 UD |
299 | * GNU gettext. This package contains the tools needed to construct |
300 | `message catalog' files containing translated versions of system | |
a35cb74d | 301 | messages. See ftp://ftp.gnu.org/pub/gnu or better any mirror |
61952351 | 302 | site. (We distribute compiled message catalogs, but they may not be |
c26b4f64 | 303 | updated in patches.) |
f8cac037 | 304 | |
5edb9387 UD |
305 | * Some files are built with special tools. E.g., files ending in .gperf |
306 | need a `gperf' program. The GNU version (now available in a separate | |
307 | package, formerly only as part of libg++) is known to work while some | |
308 | vendor versions do not. | |
f8cac037 | 309 | |
61952351 | 310 | You should not need these tools unless you change the source files. |
1f205a47 | 311 | |
5edb9387 UD |
312 | * Perl 5 is needed if you wish to test an installation of GNU libc |
313 | as the primary C library. | |
4775243a | 314 | |
61952351 UD |
315 | * When compiling for Linux, the header files of the Linux kernel must |
316 | be available to the compiler as <linux/*.h> and <asm/*.h>. | |
f8cac037 | 317 | |
02228370 | 318 | * lots of disk space (~400MB for i?86-linux; more for RISC platforms). |
af6f3906 | 319 | |
61952351 | 320 | * plenty of time. Compiling just the shared and static libraries for |
bb2fc850 UD |
321 | 35mins on a 2xPIII@550Mhz w/ 512MB RAM. On a 2xUltraSPARC-II@360Mhz |
322 | w/ 1GB RAM it takes about 14 minutes. Multiply this by 1.5 or 2.0 | |
323 | if you build profiling and/or the highly optimized version as well. | |
324 | For Hurd systems times are much higher. | |
f8cac037 | 325 | |
61952351 UD |
326 | You should avoid compiling in a NFS mounted filesystem. This is |
327 | very slow. | |
0200214b | 328 | |
bb2fc850 UD |
329 | James Troup <J.J.Troup@comp.brad.ac.uk> reports a compile time for |
330 | an earlier (and smaller!) version of glibc of 45h34m for a full build | |
331 | (shared, static, and profiled) on Atari Falcon (Motorola 68030 @ 16 Mhz, | |
332 | 14 Mb memory) and Jan Barte <yann@plato.uni-paderborn.de> reports | |
333 | 22h48m on Atari TT030 (Motorola 68030 @ 32 Mhz, 34 Mb memory) | |
0200214b | 334 | |
83f6a990 | 335 | A full build of the PowerPC library took 1h on a PowerPC 750@400Mhz w/ |
6e8afc1c | 336 | 64MB of RAM, and about 9h on a 601@60Mhz w/ 72Mb. |
83f6a990 | 337 | |
ba1ffaa1 | 338 | |
348ed515 | 339 | 1.8. What version of the Linux kernel headers should be used? |
a35cb74d | 340 | |
f12944ec UD |
341 | {AJ,UD} The headers from the most recent Linux kernel should be used. The |
342 | headers used while compiling the GNU C library and the kernel binary used | |
343 | when using the library do not need to match. The GNU C library runs without | |
344 | problems on kernels that are older than the kernel headers used. The other | |
345 | way round (compiling the GNU C library with old kernel headers and running | |
346 | on a recent kernel) does not necessarily work. For example you can't use | |
b1418d8f | 347 | new kernel features if you used old kernel headers to compile the GNU C |
f12944ec UD |
348 | library. |
349 | ||
b0610668 | 350 | {ZW} Even if you are using a 2.0 kernel on your machine, we recommend you |
b710a6e2 UD |
351 | compile GNU libc with 2.2 kernel headers. That way you won't have to |
352 | recompile libc if you ever upgrade to kernel 2.2. To tell libc which | |
b0610668 | 353 | headers to use, give configure the --with-headers switch |
b710a6e2 | 354 | (e.g. --with-headers=/usr/src/linux-2.2.0/include). |
b0610668 | 355 | |
b710a6e2 | 356 | Note that you must configure the 2.2 kernel if you do this, otherwise libc |
62595351 | 357 | will be unable to find <linux/version.h>. Just change the current directory |
b710a6e2 | 358 | to the root of the 2.2 tree and do `make include/linux/version.h'. |
b0610668 | 359 | |
f12944ec | 360 | |
348ed515 | 361 | 1.9. The compiler hangs while building iconvdata modules. What's |
f12944ec UD |
362 | wrong? |
363 | ||
bb2fc850 | 364 | {} Removed. Does not apply anymore. |
a35cb74d | 365 | |
f12944ec | 366 | |
348ed515 | 367 | 1.10. When I run `nm -u libc.so' on the produced library I still |
61952351 | 368 | find unresolved symbols. Can this be ok? |
f8cac037 | 369 | |
f12944ec | 370 | {UD} Yes, this is ok. There can be several kinds of unresolved symbols: |
f8cac037 | 371 | |
61952351 UD |
372 | * magic symbols automatically generated by the linker. These have names |
373 | like __start_* and __stop_* | |
f8cac037 | 374 | |
78b5ba3e RM |
375 | * symbols starting with _dl_* come from the dynamic linker |
376 | ||
61952351 | 377 | * weak symbols, which need not be resolved at all (fabs for example) |
f8cac037 RM |
378 | |
379 | Generally, you should make sure you find a real program which produces | |
41f27456 | 380 | errors while linking before deciding there is a problem. |
f8cac037 RM |
381 | |
382 | ||
348ed515 | 383 | 1.11. What are these `add-ons'? |
999493cb | 384 | |
f12944ec | 385 | {UD} To avoid complications with export rules or external source code some |
b669ab02 UD |
386 | optional parts of the libc are distributed as separate packages, e.g., the |
387 | linuxthreads package. | |
999493cb | 388 | |
f12944ec UD |
389 | To use these packages as part of GNU libc, just unpack the tarfiles in the |
390 | libc source directory and tell the configuration script about them using the | |
391 | --enable-add-ons option. If you give just --enable-add-ons configure tries | |
392 | to find all the add-on packages in your source tree. This may not work. If | |
393 | it doesn't, or if you want to select only a subset of the add-ons, give a | |
394 | comma-separated list of the add-ons to enable: | |
613a76ff | 395 | |
b669ab02 | 396 | configure --enable-add-ons=linuxthreads |
41f27456 | 397 | |
61952351 | 398 | for example. |
0200214b | 399 | |
f12944ec UD |
400 | Add-ons can add features (including entirely new shared libraries), override |
401 | files, provide support for additional architectures, and just about anything | |
402 | else. The existing makefiles do most of the work; only some few stub rules | |
403 | must be written to get everything running. | |
613a76ff | 404 | |
bd952512 | 405 | Most add-ons are tightly coupled to a specific GNU libc version. Please |
b669ab02 UD |
406 | check that the add-ons work with the GNU libc. For example the linuxthreads |
407 | add-on has the same numbering scheme as the libc and will in general only | |
408 | work with the corresponding libc. | |
409 | ||
410 | {AJ} With glibc 2.2 the crypt add-on and with glibc 2.1 the localedata | |
411 | add-on have been integrated into the normal glibc distribution, crypt and | |
412 | localedata are therefore not anymore add-ons. | |
bd952512 | 413 | |
613a76ff | 414 | |
348ed515 | 415 | 1.12. My XXX kernel emulates a floating-point coprocessor for me. |
61952351 | 416 | Should I enable --with-fp? |
613a76ff | 417 | |
f12944ec UD |
418 | {ZW} An emulated FPU is just as good as a real one, as far as the C library |
419 | is concerned. You only need to say --without-fp if your machine has no way | |
420 | to execute floating-point instructions. | |
f8cac037 | 421 | |
61952351 UD |
422 | People who are interested in squeezing the last drop of performance |
423 | out of their machine may wish to avoid the trap overhead, but this is | |
424 | far more trouble than it's worth: you then have to compile | |
425 | *everything* this way, including the compiler's internal libraries | |
426 | (libgcc.a for GNU C), because the calling conventions change. | |
a1470b6f | 427 | |
999493cb | 428 | |
348ed515 | 429 | 1.13. When compiling GNU libc I get lots of errors saying functions |
61952351 | 430 | in glibc are duplicated in libgcc. |
5290baf0 | 431 | |
f12944ec UD |
432 | {EY} This is *exactly* the same problem that I was having. The problem was |
433 | due to the fact that configure didn't correctly detect that the linker flag | |
434 | --no-whole-archive was supported in my linker. In my case it was because I | |
435 | had run ./configure with bogus CFLAGS, and the test failed. | |
78b5ba3e | 436 | |
f12944ec UD |
437 | One thing that is particularly annoying about this problem is that once this |
438 | is misdetected, running configure again won't fix it unless you first delete | |
439 | config.cache. | |
78b5ba3e | 440 | |
f12944ec UD |
441 | {UD} Starting with glibc-2.0.3 there should be a better test to avoid some |
442 | problems of this kind. The setting of CFLAGS is checked at the very | |
443 | beginning and if it is not usable `configure' will bark. | |
78b5ba3e | 444 | |
af6f3906 | 445 | |
348ed515 | 446 | 1.14. Why do I get messages about missing thread functions when I use |
a35cb74d | 447 | librt? I don't even use threads. |
4775243a | 448 | |
a35cb74d UD |
449 | {UD} In this case you probably mixed up your installation. librt uses |
450 | threads internally and has implicit references to the thread library. | |
f12944ec UD |
451 | Normally these references are satisfied automatically but if the thread |
452 | library is not in the expected place you must tell the linker where it is. | |
453 | When using GNU ld it works like this: | |
4775243a UD |
454 | |
455 | gcc -o foo foo.c -Wl,-rpath-link=/some/other/dir -lrt | |
456 | ||
f12944ec UD |
457 | The `/some/other/dir' should contain the thread library. `ld' will use the |
458 | given path to find the implicitly referenced library while not disturbing | |
459 | any other link path. | |
4775243a UD |
460 | |
461 | ||
348ed515 | 462 | 1.15. What's the problem with configure --enable-omitfp? |
78b5ba3e | 463 | |
61952351 | 464 | {AJ} When --enable-omitfp is set the libraries are built without frame |
fdacb17d | 465 | pointers. Some compilers produce buggy code for this model and therefore we |
f12944ec | 466 | don't advise using it at the moment. |
66219c07 | 467 | |
fdacb17d | 468 | If you use --enable-omitfp, you're on your own. If you encounter problems |
f12944ec UD |
469 | with a library that was build this way, we advise you to rebuild the library |
470 | without --enable-omitfp. If the problem vanishes consider tracking the | |
471 | problem down and report it as compiler failure. | |
66219c07 | 472 | |
b1418d8f UD |
473 | Since a library built with --enable-omitfp is undebuggable on most systems, |
474 | debuggable libraries are also built - you can use them by appending "_g" to | |
f12944ec | 475 | the library names. |
66219c07 | 476 | |
f12944ec UD |
477 | The compilation of these extra libraries and the compiler optimizations slow |
478 | down the build process and need more disk space. | |
66219c07 | 479 | |
b0610668 | 480 | |
b1418d8f | 481 | 1.16. I get failures during `make check'. What should I do? |
b0610668 | 482 | |
b1418d8f UD |
483 | {AJ} The testsuite should compile and run cleanly on your system; every |
484 | failure should be looked into. Depending on the failures, you probably | |
485 | should not install the library at all. | |
b0610668 UD |
486 | |
487 | You should consider using the `glibcbug' script to report the failure, | |
488 | providing as much detail as possible. If you run a test directly, please | |
489 | remember to set up the environment correctly. You want to test the compiled | |
490 | library - and not your installed one. The best way is to copy the exact | |
491 | command line which failed and run the test from the subdirectory for this | |
492 | test in the sources. | |
493 | ||
494 | There are some failures which are not directly related to the GNU libc: | |
b1418d8f | 495 | - Some compilers produce buggy code. No compiler gets single precision |
4011dc70 | 496 | complex numbers correct on Alpha. Otherwise, gcc-3.2 should be ok. |
b0610668 UD |
497 | - The kernel might have bugs. For example on Linux/Alpha 2.0.34 the |
498 | floating point handling has quite a number of bugs and therefore most of | |
b710a6e2 | 499 | the test cases in the math subdirectory will fail. Linux 2.2 has |
b1418d8f UD |
500 | fixes for the floating point support on Alpha. The Linux/SPARC kernel has |
501 | also some bugs in the FPU emulation code (as of Linux 2.2.0). | |
d32a4020 UD |
502 | - Other tools might have problems. For example bash 2.03 gives a |
503 | segmentation fault running the tst-rpmatch.sh test script. | |
b0610668 | 504 | |
a379e56a | 505 | |
348ed515 | 506 | 1.17. What is symbol versioning good for? Do I need it? |
a379e56a UD |
507 | |
508 | {AJ} Symbol versioning solves problems that are related to interface | |
509 | changes. One version of an interface might have been introduced in a | |
510 | previous version of the GNU C library but the interface or the semantics of | |
511 | the function has been changed in the meantime. For binary compatibility | |
512 | with the old library, a newer library needs to still have the old interface | |
b1418d8f | 513 | for old programs. On the other hand, new programs should use the new |
a379e56a | 514 | interface. Symbol versioning is the solution for this problem. The GNU |
b1418d8f UD |
515 | libc version 2.1 uses symbol versioning by default if the installed binutils |
516 | supports it. | |
a379e56a | 517 | |
b1418d8f UD |
518 | We don't advise building without symbol versioning, since you lose binary |
519 | compatibility - forever! The binary compatibility you lose is not only | |
520 | against the previous version of the GNU libc (version 2.0) but also against | |
521 | all future versions. | |
a379e56a | 522 | |
c7f7281e UD |
523 | |
524 | 1.18. How can I compile on my fast ix86 machine a working libc for my slow | |
525 | i386? After installing libc, programs abort with "Illegal | |
526 | Instruction". | |
527 | ||
528 | {AJ} glibc and gcc might generate some instructions on your machine that | |
529 | aren't available on i386. You've got to tell glibc that you're configuring | |
530 | for i386 with adding i386 as your machine, for example: | |
531 | ||
532 | ../configure --prefix=/usr i386-pc-linux-gnu | |
533 | ||
534 | And you need to tell gcc to only generate i386 code, just add `-mcpu=i386' | |
535 | (just -m386 doesn't work) to your CFLAGS. | |
536 | ||
537 | {UD} This applies not only to the i386. Compiling on a i686 for any older | |
538 | model will also fail if the above methods are not used. | |
539 | ||
150ae521 UD |
540 | |
541 | 1.19. `make' complains about a missing dlfcn/libdl.so when building | |
542 | malloc/libmemprof.so. How can I fix this? | |
543 | ||
544 | {AJ} Older make version (<= 3.78.90) have a bug which was hidden by a bug in | |
2bbc70d5 | 545 | glibc (<= 2.1.2). You need to upgrade make to a newer or fixed version. |
150ae521 UD |
546 | |
547 | After upgrading make, you should remove the file sysd-sorted in your build | |
548 | directory. The problem is that the broken make creates a wrong order for | |
549 | one list in that file. The list has to be recreated with the new make - | |
550 | which happens if you remove the file. | |
551 | ||
552 | You might encounter this bug also in other situations where make scans | |
2bbc70d5 AJ |
553 | directories. I strongly advise to upgrade your make version to 3.79 or |
554 | newer. | |
150ae521 | 555 | |
2c88f872 AJ |
556 | |
557 | 1.20. Which tools should I use for MIPS? | |
558 | ||
4011dc70 UD |
559 | {AJ} You should use the current development version of gcc 3.2 or newer from |
560 | CVS. | |
2c88f872 | 561 | |
02eca23b AJ |
562 | You need also recent binutils, anything before and including 2.11 will not |
563 | work correctly. Either try the Linux binutils 2.11.90.0.5 from HJ Lu or the | |
7e5fc672 AJ |
564 | current development version of binutils from CVS. |
565 | ||
566 | Please note that `make check' might fail for a number of the math tests | |
567 | because of problems of the FPU emulation in the Linux kernel (the MIPS FPU | |
568 | doesn't handle all cases and needs help from the kernel). | |
2c88f872 AJ |
569 | |
570 | For details check also my page <http://www.suse.de/~aj/glibc-mips.html>. | |
571 | ||
dfc89273 UD |
572 | |
573 | 1.21. Which compiler should I use for powerpc64? | |
574 | ||
575 | {SM} You want to use at least gcc 3.2 (together with the right versions | |
576 | of all the other tools, of course). | |
577 | ||
9cb97cd4 RM |
578 | |
579 | 1.22. `make' fails when running rpcgen the first time, | |
580 | what is going on? How do I fix this? | |
581 | ||
582 | {CO} The first invocation of rpcgen is also the first use of the recently | |
583 | compiled dynamic loader. If there is any problem with the dynamic loader | |
584 | it will more than likely fail to run rpcgen properly. This could be due to | |
585 | any number of problems. | |
586 | ||
587 | The only real solution is to debug the loader and determine the problem | |
588 | yourself. Please remember that for each architecture there may be various | |
589 | patches required to get glibc HEAD into a runnable state. The best course | |
590 | of action is to determine if you have all the required patches. | |
591 | ||
61952351 UD |
592 | \f |
593 | . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | |
e6c9a67a | 594 | |
61952351 | 595 | 2. Installation and configuration issues |
e6c9a67a | 596 | |
61952351 | 597 | 2.1. Can I replace the libc on my Linux system with GNU libc? |
e6c9a67a | 598 | |
f12944ec UD |
599 | {UD} You cannot replace any existing libc for Linux with GNU libc. It is |
600 | binary incompatible and therefore has a different major version. You can, | |
601 | however, install it alongside your existing libc. | |
e6c9a67a | 602 | |
61952351 UD |
603 | For Linux there are three major libc versions: |
604 | libc-4 a.out libc | |
605 | libc-5 original ELF libc | |
606 | libc-6 GNU libc | |
e6c9a67a | 607 | |
f12944ec UD |
608 | You can have any combination of these three installed. For more information |
609 | consult documentation for shared library handling. The Makefiles of GNU | |
610 | libc will automatically generate the needed symbolic links which the linker | |
611 | will use. | |
e6c9a67a RM |
612 | |
613 | ||
61952351 UD |
614 | 2.2. How do I configure GNU libc so that the essential libraries |
615 | like libc.so go into /lib and the other into /usr/lib? | |
ec42724d | 616 | |
61952351 UD |
617 | {UD,AJ} Like all other GNU packages GNU libc is designed to use a base |
618 | directory and install all files relative to this. The default is | |
f12944ec UD |
619 | /usr/local, because this is safe (it will not damage the system if installed |
620 | there). If you wish to install GNU libc as the primary C library on your | |
621 | system, set the base directory to /usr (i.e. run configure --prefix=/usr | |
622 | <other_options>). Note that this can damage your system; see question 2.3 for | |
623 | details. | |
624 | ||
625 | Some systems like Linux have a filesystem standard which makes a difference | |
626 | between essential libraries and others. Essential libraries are placed in | |
627 | /lib because this directory is required to be located on the same disk | |
628 | partition as /. The /usr subtree might be found on another | |
629 | partition/disk. If you configure for Linux with --prefix=/usr, then this | |
630 | will be done automatically. | |
ec42724d | 631 | |
61952351 | 632 | To install the essential libraries which come with GNU libc in /lib on |
f12944ec UD |
633 | systems other than Linux one must explicitly request it. Autoconf has no |
634 | option for this so you have to use a `configparms' file (see the `INSTALL' | |
635 | file for details). It should contain: | |
ec42724d RM |
636 | |
637 | slibdir=/lib | |
638 | sysconfdir=/etc | |
639 | ||
f12944ec UD |
640 | The first line specifies the directory for the essential libraries, the |
641 | second line the directory for system configuration files. | |
ec42724d | 642 | |
5290baf0 | 643 | |
61952351 | 644 | 2.3. How should I avoid damaging my system when I install GNU libc? |
ec42724d | 645 | |
f12944ec UD |
646 | {ZW} If you wish to be cautious, do not configure with --prefix=/usr. If |
647 | you don't specify a prefix, glibc will be installed in /usr/local, where it | |
648 | will probably not break anything. (If you wish to be certain, set the | |
649 | prefix to something like /usr/local/glibc2 which is not used for anything.) | |
845dcb57 | 650 | |
61952351 | 651 | The dangers when installing glibc in /usr are twofold: |
845dcb57 | 652 | |
61952351 | 653 | * glibc will overwrite the headers in /usr/include. Other C libraries |
27e309c1 UD |
654 | install a different but overlapping set of headers there, so the effect |
655 | will probably be that you can't compile anything. You need to rename | |
656 | /usr/include out of the way before running `make install'. (Do not throw | |
657 | it away; you will then lose the ability to compile programs against your | |
658 | old libc.) | |
845dcb57 | 659 | |
61952351 UD |
660 | * None of your old libraries, static or shared, can be used with a |
661 | different C library major version. For shared libraries this is not a | |
662 | problem, because the filenames are different and the dynamic linker | |
663 | will enforce the restriction. But static libraries have no version | |
664 | information. You have to evacuate all the static libraries in | |
665 | /usr/lib to a safe location. | |
845dcb57 | 666 | |
61952351 UD |
667 | The situation is rather similar to the move from a.out to ELF which |
668 | long-time Linux users will remember. | |
845dcb57 | 669 | |
845dcb57 | 670 | |
61952351 UD |
671 | 2.4. Do I need to use GNU CC to compile programs that will use the |
672 | GNU C Library? | |
845dcb57 | 673 | |
f12944ec UD |
674 | {ZW} In theory, no; the linker does not care, and the headers are supposed |
675 | to check for GNU CC before using its extensions to the C language. | |
845dcb57 | 676 | |
f12944ec UD |
677 | However, there are currently no ports of glibc to systems where another |
678 | compiler is the default, so no one has tested the headers extensively | |
679 | against another compiler. You may therefore encounter difficulties. If you | |
680 | do, please report them as bugs. | |
845dcb57 | 681 | |
61952351 UD |
682 | Also, in several places GNU extensions provide large benefits in code |
683 | quality. For example, the library has hand-optimized, inline assembly | |
f12944ec UD |
684 | versions of some string functions. These can only be used with GCC. See |
685 | question 3.8 for details. | |
845dcb57 | 686 | |
845dcb57 | 687 | |
61952351 UD |
688 | 2.5. When linking with the new libc I get unresolved symbols |
689 | `crypt' and `setkey'. Why aren't these functions in the | |
690 | libc anymore? | |
845dcb57 | 691 | |
037f8020 | 692 | {} Removed. Does not apply anymore. |
c4029823 | 693 | |
c4029823 | 694 | |
61952351 UD |
695 | 2.6. When I use GNU libc on my Linux system by linking against |
696 | the libc.so which comes with glibc all I get is a core dump. | |
c4029823 | 697 | |
f12944ec | 698 | {UD} On Linux, gcc sets the dynamic linker to /lib/ld-linux.so.1 unless the |
a582750d | 699 | user specifies a --dynamic-linker argument. This is the name of the libc5 |
f12944ec | 700 | dynamic linker, which does not work with glibc. |
61952351 | 701 | |
a379e56a UD |
702 | For casual use of GNU libc you can just specify to the linker |
703 | --dynamic-linker=/lib/ld-linux.so.2 | |
61952351 | 704 | |
f12944ec | 705 | which is the glibc dynamic linker, on Linux systems. On other systems the |
a379e56a UD |
706 | name is /lib/ld.so.1. When linking via gcc, you've got to add |
707 | -Wl,--dynamic-linker=/lib/ld-linux.so.2 | |
708 | ||
709 | to the gcc command line. | |
c4029823 | 710 | |
f12944ec UD |
711 | To change your environment to use GNU libc for compiling you need to change |
712 | the `specs' file of your gcc. This file is normally found at | |
c4029823 UD |
713 | |
714 | /usr/lib/gcc-lib/<arch>/<version>/specs | |
715 | ||
716 | In this file you have to change a few things: | |
717 | ||
61952351 | 718 | - change `ld-linux.so.1' to `ld-linux.so.2' |
c4029823 UD |
719 | |
720 | - remove all expression `%{...:-lgmon}'; there is no libgmon in glibc | |
721 | ||
f4017d20 UD |
722 | - fix a minor bug by changing %{pipe:-} to %| |
723 | ||
f12944ec UD |
724 | Here is what the gcc-2.7.2 specs file should look like when GNU libc is |
725 | installed at /usr: | |
c4029823 UD |
726 | |
727 | ----------------------------------------------------------------------- | |
728 | *asm: | |
729 | %{V} %{v:%{!V:-V}} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} | |
730 | ||
731 | *asm_final: | |
f4017d20 | 732 | %| |
c4029823 UD |
733 | |
734 | *cpp: | |
68dbb3a6 | 735 | %{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} %{!m386:-D__i486__} %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} |
c4029823 UD |
736 | |
737 | *cc1: | |
68dbb3a6 | 738 | %{profile:-p} |
c4029823 UD |
739 | |
740 | *cc1plus: | |
741 | ||
742 | ||
743 | *endfile: | |
68dbb3a6 | 744 | %{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s |
c4029823 UD |
745 | |
746 | *link: | |
68dbb3a6 | 747 | -m elf_i386 %{shared:-shared} %{!shared: %{!ibcs: %{!static: %{rdynamic:-export-dynamic} %{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2}} %{static:-static}}} |
c4029823 UD |
748 | |
749 | *lib: | |
68dbb3a6 | 750 | %{!shared: %{pthread:-lpthread} %{profile:-lc_p} %{!profile: -lc}} |
c4029823 UD |
751 | |
752 | *libgcc: | |
68dbb3a6 | 753 | -lgcc |
c4029823 UD |
754 | |
755 | *startfile: | |
61952351 | 756 | %{!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 |
757 | |
758 | *switches_need_spaces: | |
759 | ||
760 | ||
761 | *signed_char: | |
762 | %{funsigned-char:-D__CHAR_UNSIGNED__} | |
763 | ||
764 | *predefines: | |
765 | -D__ELF__ -Dunix -Di386 -Dlinux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386) | |
766 | ||
767 | *cross_compile: | |
768 | 0 | |
769 | ||
770 | *multilib: | |
771 | . ; | |
772 | ||
773 | ----------------------------------------------------------------------- | |
774 | ||
f12944ec UD |
775 | Things get a bit more complicated if you have GNU libc installed in some |
776 | other place than /usr, i.e., if you do not want to use it instead of the old | |
777 | libc. In this case the needed startup files and libraries are not found in | |
778 | the regular places. So the specs file must tell the compiler and linker | |
779 | exactly what to use. | |
0d204b0a | 780 | |
f41c8091 | 781 | Version 2.7.2.3 does and future versions of GCC will automatically |
0d8733c4 | 782 | provide the correct specs. |
c4029823 UD |
783 | |
784 | ||
61952351 UD |
785 | 2.7. Looking through the shared libc file I haven't found the |
786 | functions `stat', `lstat', `fstat', and `mknod' and while | |
787 | linking on my Linux system I get error messages. How is | |
788 | this supposed to work? | |
c4029823 | 789 | |
f12944ec UD |
790 | {RM} Believe it or not, stat and lstat (and fstat, and mknod) are supposed |
791 | to be undefined references in libc.so.6! Your problem is probably a missing | |
792 | or incorrect /usr/lib/libc.so file; note that this is a small text file now, | |
793 | not a symlink to libc.so.6. It should look something like this: | |
c4029823 | 794 | |
ff44f2a5 | 795 | GROUP ( libc.so.6 libc_nonshared.a ) |
1f205a47 | 796 | |
c4029823 | 797 | |
5edb9387 UD |
798 | 2.8. When I run an executable on one system which I compiled on |
799 | another, I get dynamic linker errors. Both systems have the same | |
800 | version of glibc installed. What's wrong? | |
801 | ||
802 | {ZW} Glibc on one of these systems was compiled with gcc 2.7 or 2.8, the | |
803 | other with egcs (any version). Egcs has functions in its internal | |
804 | `libgcc.a' to support exception handling with C++. They are linked into | |
805 | any program or dynamic library compiled with egcs, whether it needs them or | |
806 | not. Dynamic libraries then turn around and export those functions again | |
807 | unless special steps are taken to prevent them. | |
808 | ||
809 | When you link your program, it resolves its references to the exception | |
810 | functions to the ones exported accidentally by libc.so. That works fine as | |
811 | long as libc has those functions. On the other system, libc doesn't have | |
812 | those functions because it was compiled by gcc 2.8, and you get undefined | |
813 | symbol errors. The symbols in question are named things like | |
814 | `__register_frame_info'. | |
815 | ||
816 | For glibc 2.0, the workaround is to not compile libc with egcs. We've also | |
817 | incorporated a patch which should prevent the EH functions sneaking into | |
818 | libc. It doesn't matter what compiler you use to compile your program. | |
819 | ||
820 | For glibc 2.1, we've chosen to do it the other way around: libc.so | |
821 | explicitly provides the EH functions. This is to prevent other shared | |
95f7cecb UD |
822 | libraries from doing it. |
823 | ||
824 | {UD} Starting with glibc 2.1.1 you can compile glibc with gcc 2.8.1 or | |
825 | newer since we have explicitly add references to the functions causing the | |
826 | problem. But you nevertheless should use EGCS for other reasons | |
827 | (see question 1.2). | |
5edb9387 | 828 | |
83f6a990 UD |
829 | {GK} On some Linux distributions for PowerPC, you can see this when you have |
830 | built gcc or egcs from the Web sources (gcc versions 2.95 or earlier), then | |
831 | re-built glibc. This happens because in these versions of gcc, exception | |
832 | handling is implemented using an older method; the people making the | |
833 | distributions are a little ahead of their time. | |
834 | ||
835 | A quick solution to this is to find the libgcc.a file that came with the | |
6e8afc1c | 836 | distribution (it would have been installed under /usr/lib/gcc-lib), do |
83f6a990 UD |
837 | `ar x libgcc.a frame.o' to get the frame.o file out, and add a line saying |
838 | `LDLIBS-c.so += frame.o' to the file `configparms' in the directory you're | |
839 | building in. You can check you've got the right `frame.o' file by running | |
840 | `nm frame.o' and checking that it has the symbols defined that you're | |
841 | missing. | |
842 | ||
843 | This will let you build glibc with the C compiler. The C++ compiler | |
844 | will still be binary incompatible with any C++ shared libraries that | |
845 | you got with your distribution. | |
846 | ||
5edb9387 UD |
847 | |
848 | 2.9. How can I compile gcc 2.7.2.1 from the gcc source code using | |
61952351 | 849 | glibc 2.x? |
ba1ffaa1 | 850 | |
f12944ec | 851 | {AJ} There's only correct support for glibc 2.0.x in gcc 2.7.2.3 or later. |
4011dc70 | 852 | But you should get at least gcc 2.95.3 (or later versions) anyway |
ba1ffaa1 UD |
853 | |
854 | ||
5edb9387 | 855 | 2.10. The `gencat' utility cannot process the catalog sources which |
61952351 | 856 | were used on my Linux libc5 based system. Why? |
47707456 | 857 | |
f12944ec UD |
858 | {UD} The `gencat' utility provided with glibc complies to the XPG standard. |
859 | The older Linux version did not obey the standard, so they are not | |
860 | compatible. | |
47707456 | 861 | |
61952351 | 862 | To ease the transition from the Linux version some of the non-standard |
f12944ec UD |
863 | features are also present in the `gencat' program of GNU libc. This mainly |
864 | includes the use of symbols for the message number and the automatic | |
61952351 UD |
865 | generation of header files which contain the needed #defines to map the |
866 | symbols to integers. | |
47707456 | 867 | |
f12944ec UD |
868 | Here is a simple SED script to convert at least some Linux specific catalog |
869 | files to the XPG4 form: | |
68dbb3a6 | 870 | |
61952351 UD |
871 | ----------------------------------------------------------------------- |
872 | # Change catalog source in Linux specific format to standard XPG format. | |
934b77ac | 873 | # Ulrich Drepper <drepper@redhat.com>, 1996. |
61952351 UD |
874 | # |
875 | /^\$ #/ { | |
876 | h | |
877 | s/\$ #\([^ ]*\).*/\1/ | |
878 | x | |
879 | s/\$ #[^ ]* *\(.*\)/\$ \1/ | |
880 | } | |
68dbb3a6 | 881 | |
61952351 UD |
882 | /^# / { |
883 | s/^# \(.*\)/\1/ | |
884 | G | |
885 | s/\(.*\)\n\(.*\)/\2 \1/ | |
886 | } | |
887 | ----------------------------------------------------------------------- | |
19361cb7 | 888 | |
19361cb7 | 889 | |
5edb9387 | 890 | 2.11. Programs using libc have their messages translated, but other |
a35cb74d UD |
891 | behavior is not localized (e.g. collating order); why? |
892 | ||
893 | {ZW} Translated messages are automatically installed, but the locale | |
f12944ec UD |
894 | database that controls other behaviors is not. You need to run localedef to |
895 | install this database, after you have run `make install'. For example, to | |
896 | set up the French Canadian locale, simply issue the command | |
a35cb74d UD |
897 | |
898 | localedef -i fr_CA -f ISO-8859-1 fr_CA | |
899 | ||
900 | Please see localedata/README in the source tree for further details. | |
901 | ||
902 | ||
5edb9387 | 903 | 2.12. I have set up /etc/nis.conf, and the Linux libc 5 with NYS |
61952351 | 904 | works great. But the glibc NIS+ doesn't seem to work. |
19361cb7 | 905 | |
f12944ec UD |
906 | {TK} The glibc NIS+ implementation uses a /var/nis/NIS_COLD_START file for |
907 | storing information about the NIS+ server and their public keys, because the | |
908 | nis.conf file does not contain all the necessary information. You have to | |
909 | copy a NIS_COLD_START file from a Solaris client (the NIS_COLD_START file is | |
910 | byte order independent) or generate it with nisinit from the nis-tools | |
911 | package; available at | |
912 | ||
612fdf25 | 913 | http://www.suse.de/~kukuk/linux/nisplus.html |
19361cb7 | 914 | |
68dbb3a6 | 915 | |
5edb9387 | 916 | 2.13. I have killed ypbind to stop using NIS, but glibc |
3dcf8ea6 | 917 | continues using NIS. |
4d06461a | 918 | |
f12944ec UD |
919 | {TK} For faster NIS lookups, glibc uses the /var/yp/binding/ files from |
920 | ypbind. ypbind 3.3 and older versions don't always remove these files, so | |
921 | glibc will continue to use them. Other BSD versions seem to work correctly. | |
922 | Until ypbind 3.4 is released, you can find a patch at | |
923 | ||
66f6a52b | 924 | <ftp://ftp.kernel.org/pub/linux/utils/net/NIS/ypbind-3.3-glibc4.diff.gz> |
a35cb74d | 925 | |
4d06461a | 926 | |
5edb9387 | 927 | 2.14. Under Linux/Alpha, I always get "do_ypcall: clnt_call: |
3dcf8ea6 | 928 | RPC: Unable to receive; errno = Connection refused" when using NIS. |
4d06461a | 929 | |
f12944ec UD |
930 | {TK} You need a ypbind version which is 64bit clean. Some versions are not |
931 | 64bit clean. A 64bit clean implementation is ypbind-mt. For ypbind 3.3, | |
932 | you need the patch from ftp.kernel.org (See the previous question). I don't | |
933 | know about other versions. | |
a35cb74d UD |
934 | |
935 | ||
5edb9387 | 936 | 2.15. After installing glibc name resolving doesn't work properly. |
68dbb3a6 | 937 | |
f12944ec UD |
938 | {AJ} You probably should read the manual section describing nsswitch.conf |
939 | (just type `info libc "NSS Configuration File"'). The NSS configuration | |
940 | file is usually the culprit. | |
22d57dd3 | 941 | |
22d57dd3 | 942 | |
5edb9387 | 943 | 2.16. How do I create the databases for NSS? |
3dcf8ea6 UD |
944 | |
945 | {AJ} If you have an entry "db" in /etc/nsswitch.conf you should also create | |
946 | the database files. The glibc sources contain a Makefile which does the | |
a379e56a | 947 | necessary conversion and calls to create those files. The file is |
3dcf8ea6 UD |
948 | `db-Makefile' in the subdirectory `nss' and you can call it with `make -f |
949 | db-Makefile'. Please note that not all services are capable of using a | |
950 | database. Currently passwd, group, ethers, protocol, rpc, services shadow | |
199745d1 | 951 | and netgroup are implemented. See also question 2.31. |
3dcf8ea6 UD |
952 | |
953 | ||
5edb9387 | 954 | 2.17. I have /usr/include/net and /usr/include/scsi as symlinks |
61952351 | 955 | into my Linux source tree. Is that wrong? |
22d57dd3 | 956 | |
f12944ec UD |
957 | {PB} This was necessary for libc5, but is not correct when using glibc. |
958 | Including the kernel header files directly in user programs usually does not | |
959 | work (see question 3.5). glibc provides its own <net/*> and <scsi/*> header | |
960 | files to replace them, and you may have to remove any symlink that you have | |
961 | in place before you install glibc. However, /usr/include/asm and | |
962 | /usr/include/linux should remain as they were. | |
22d57dd3 | 963 | |
22d57dd3 | 964 | |
5edb9387 | 965 | 2.18. Programs like `logname', `top', `uptime' `users', `w' and |
61952351 UD |
966 | `who', show incorrect information about the (number of) |
967 | users on my system. Why? | |
22d57dd3 | 968 | |
61952351 | 969 | {MK} See question 3.2. |
22d57dd3 | 970 | |
22d57dd3 | 971 | |
5edb9387 | 972 | 2.19. After upgrading to glibc 2.1 with symbol versioning I get |
61952351 | 973 | errors about undefined symbols. What went wrong? |
26dee9c4 | 974 | |
f12944ec UD |
975 | {AJ} The problem is caused either by wrong program code or tools. In the |
976 | versioned libc a lot of symbols are now local that were global symbols in | |
977 | previous versions. It seems that programs linked against older versions | |
978 | often accidentally used libc global variables -- something that should not | |
979 | happen. | |
26dee9c4 | 980 | |
f12944ec UD |
981 | The only way to fix this is to recompile your program. Sorry, that's the |
982 | price you might have to pay once for quite a number of advantages with | |
983 | symbol versioning. | |
26dee9c4 | 984 | |
26dee9c4 | 985 | |
5edb9387 | 986 | 2.20. When I start the program XXX after upgrading the library |
61952351 UD |
987 | I get |
988 | XXX: Symbol `_sys_errlist' has different size in shared | |
989 | object, consider re-linking | |
990 | Why? What should I do? | |
26dee9c4 | 991 | |
f12944ec UD |
992 | {UD} As the message says, relink the binary. The problem is that a few |
993 | symbols from the library can change in size and there is no way to avoid | |
994 | this. _sys_errlist is a good example. Occasionally there are new error | |
995 | numbers added to the kernel and this must be reflected at user level, | |
996 | breaking programs that refer to them directly. | |
a2b08ee5 | 997 | |
f12944ec UD |
998 | Such symbols should normally not be used at all. There are mechanisms to |
999 | avoid using them. In the case of _sys_errlist, there is the strerror() | |
1000 | function which should _always_ be used instead. So the correct fix is to | |
1001 | rewrite that part of the application. | |
a2b08ee5 | 1002 | |
f12944ec UD |
1003 | In some situations (especially when testing a new library release) it might |
1004 | be possible that a symbol changed size when that should not have happened. | |
1005 | So in case of doubt report such a warning message as a problem. | |
a2b08ee5 | 1006 | |
a35cb74d | 1007 | |
5edb9387 UD |
1008 | 2.21. What do I need for C++ development? |
1009 | ||
1010 | {HJ,AJ} You need either egcs 1.1 which comes directly with libstdc++ or | |
1011 | gcc-2.8.1 together with libstdc++ 2.8.1.1. egcs 1.1 has the better C++ | |
1012 | support and works directly with glibc 2.1. If you use gcc-2.8.1 with | |
1013 | libstdc++ 2.8.1.1, you need to modify libstdc++ a bit. A patch is available | |
1014 | as: | |
66f6a52b | 1015 | <ftp://alpha.gnu.org/gnu/libstdc++-2.8.1.1-glibc2.1-diff.gz> |
a35cb74d | 1016 | |
5edb9387 UD |
1017 | Please note that libg++ 2.7.2 (and the Linux Versions 2.7.2.x) doesn't work |
1018 | very well with the GNU C library due to vtable thunks. If you're upgrading | |
1019 | from glibc 2.0.x to 2.1 you have to recompile libstdc++ since the library | |
1020 | compiled for 2.0 is not compatible due to the new Large File Support (LFS) | |
1021 | in version 2.1. | |
fb98e2bf UD |
1022 | |
1023 | {UD} But since in the case of a shared libstdc++ the version numbers should | |
1024 | be different existing programs will continue to work. | |
a35cb74d | 1025 | |
ff44f2a5 | 1026 | |
5edb9387 | 1027 | 2.22. Even statically linked programs need some shared libraries |
ff44f2a5 UD |
1028 | which is not acceptable for me. What can I do? |
1029 | ||
f12944ec UD |
1030 | {AJ} NSS (for details just type `info libc "Name Service Switch"') won't |
1031 | work properly without shared libraries. NSS allows using different services | |
1032 | (e.g. NIS, files, db, hesiod) by just changing one configuration file | |
1033 | (/etc/nsswitch.conf) without relinking any programs. The only disadvantage | |
1034 | is that now static libraries need to access shared libraries. This is | |
1035 | handled transparently by the GNU C library. | |
ff44f2a5 | 1036 | |
f12944ec UD |
1037 | A solution is to configure glibc with --enable-static-nss. In this case you |
1038 | can create a static binary that will use only the services dns and files | |
1039 | (change /etc/nsswitch.conf for this). You need to link explicitly against | |
1040 | all these services. For example: | |
ff44f2a5 | 1041 | |
2c88f872 AJ |
1042 | gcc -static test-netdb.c -o test-netdb \ |
1043 | -Wl,--start-group -lc -lnss_files -lnss_dns -lresolv -Wl,--end-group | |
ff44f2a5 UD |
1044 | |
1045 | The problem with this approach is that you've got to link every static | |
1046 | program that uses NSS routines with all those libraries. | |
1047 | ||
1048 | {UD} In fact, one cannot say anymore that a libc compiled with this | |
1049 | option is using NSS. There is no switch anymore. Therefore it is | |
1050 | *highly* recommended *not* to use --enable-static-nss since this makes | |
1051 | the behaviour of the programs on the system inconsistent. | |
1052 | ||
fdacb17d | 1053 | |
5edb9387 | 1054 | 2.23. I just upgraded my Linux system to glibc and now I get |
fdacb17d UD |
1055 | errors whenever I try to link any program. |
1056 | ||
1057 | {ZW} This happens when you have installed glibc as the primary C library but | |
1058 | have stray symbolic links pointing at your old C library. If the first | |
1059 | `libc.so' the linker finds is libc 5, it will use that. Your program | |
1060 | expects to be linked with glibc, so the link fails. | |
1061 | ||
1062 | The most common case is that glibc put its `libc.so' in /usr/lib, but there | |
1063 | was a `libc.so' from libc 5 in /lib, which gets searched first. To fix the | |
1064 | problem, just delete /lib/libc.so. You may also need to delete other | |
1065 | symbolic links in /lib, such as /lib/libm.so if it points to libm.so.5. | |
1066 | ||
1067 | {AJ} The perl script test-installation.pl which is run as last step during | |
1068 | an installation of glibc that is configured with --prefix=/usr should help | |
1069 | detect these situations. If the script reports problems, something is | |
1070 | really screwed up. | |
1071 | ||
48244d09 | 1072 | |
5edb9387 | 1073 | 2.24. When I use nscd the machine freezes. |
48244d09 | 1074 | |
5edb9387 UD |
1075 | {UD} You cannot use nscd with Linux 2.0.*. There is functionality missing |
1076 | in the kernel and work-arounds are not suitable. Besides, some parts of the | |
1077 | kernel are too buggy when it comes to using threads. | |
48244d09 | 1078 | |
b710a6e2 | 1079 | If you need nscd, you have to use at least a 2.1 kernel. |
48244d09 UD |
1080 | |
1081 | Note that I have at this point no information about any other platform. | |
1082 | ||
0155a773 UD |
1083 | |
1084 | 2.25. I need lots of open files. What do I have to do? | |
1085 | ||
1086 | {AJ} This is at first a kernel issue. The kernel defines limits with | |
1087 | OPEN_MAX the number of simultaneous open files and with FD_SETSIZE the | |
1088 | number of used file descriptors. You need to change these values in your | |
c0389ee4 | 1089 | kernel and recompile the kernel so that the kernel allows more open |
0155a773 UD |
1090 | files. You don't necessarily need to recompile the GNU C library since the |
1091 | only place where OPEN_MAX and FD_SETSIZE is really needed in the library | |
1092 | itself is the size of fd_set which is used by select. | |
1093 | ||
249fd241 UD |
1094 | The GNU C library is now select free. This means it internally has no |
1095 | limits imposed by the `fd_set' type. Instead all places where the | |
0155a773 UD |
1096 | functionality is needed the `poll' function is used. |
1097 | ||
1098 | If you increase the number of file descriptors in the kernel you don't need | |
6e8afc1c | 1099 | to recompile the C library. |
0155a773 UD |
1100 | |
1101 | {UD} You can always get the maximum number of file descriptors a process is | |
1102 | allowed to have open at any time using | |
1103 | ||
1104 | number = sysconf (_SC_OPEN_MAX); | |
1105 | ||
1106 | This will work even if the kernel limits change. | |
1107 | ||
7db169c9 UD |
1108 | |
1109 | 2.26. How do I get the same behavior on parsing /etc/passwd and | |
1110 | /etc/group as I have with libc5 ? | |
1111 | ||
1112 | {TK} The name switch setup in /etc/nsswitch.conf selected by most Linux | |
1113 | distributions does not support +/- and netgroup entries in the files like | |
1114 | /etc/passwd. Though this is the preferred setup some people might have | |
1115 | setups coming over from the libc5 days where it was the default to recognize | |
1116 | lines like this. To get back to the old behaviour one simply has to change | |
1117 | the rules for passwd, group, and shadow in the nsswitch.conf file as | |
1118 | follows: | |
1119 | ||
1120 | passwd: compat | |
1121 | group: compat | |
1122 | shadow: compat | |
1123 | ||
1124 | passwd_compat: nis | |
1125 | group_compat: nis | |
1126 | shadow_compat: nis | |
1127 | ||
b710a6e2 UD |
1128 | |
1129 | 2.27. What needs to be recompiled when upgrading from glibc 2.0 to glibc | |
1130 | 2.1? | |
1131 | ||
1132 | {AJ,CG} If you just upgrade the glibc from 2.0.x (x <= 7) to 2.1, binaries | |
1133 | that have been linked against glibc 2.0 will continue to work. | |
1134 | ||
1135 | If you compile your own binaries against glibc 2.1, you also need to | |
c19559b0 UD |
1136 | recompile some other libraries. The problem is that libio had to be changed |
1137 | and therefore libraries that are based or depend on the libio of glibc, | |
1138 | e.g. ncurses, slang and most C++ libraries, need to be recompiled. If you | |
1139 | experience strange segmentation faults in your programs linked against glibc | |
1140 | 2.1, you might need to recompile your libraries. | |
b710a6e2 UD |
1141 | |
1142 | Another problem is that older binaries that were linked statically against | |
1143 | glibc 2.0 will reference the older nss modules (libnss_files.so.1 instead of | |
1144 | libnss_files.so.2), so don't remove them. Also, the old glibc-2.0 compiled | |
1145 | static libraries (libfoo.a) which happen to depend on the older libio | |
1146 | behavior will be broken by the glibc 2.1 upgrade. We plan to produce a | |
1147 | compatibility library that people will be able to link in if they want | |
1148 | to compile a static library generated against glibc 2.0 into a program | |
1149 | on a glibc 2.1 system. You just add -lcompat and you should be fine. | |
1150 | ||
1151 | The glibc-compat add-on will provide the libcompat.a library, the older | |
1152 | nss modules, and a few other files. Together, they should make it | |
1153 | possible to do development with old static libraries on a glibc 2.1 | |
8d8c6efa | 1154 | system. This add-on is still in development. You can get it from |
df08cc56 | 1155 | <ftp://alpha.gnu.org/gnu/glibc/glibc-compat-2.1.tar.gz> |
b710a6e2 UD |
1156 | but please keep in mind that it is experimental. |
1157 | ||
b7398be5 UD |
1158 | |
1159 | 2.28. Why is extracting files via tar so slow? | |
1160 | ||
1161 | {AJ} Extracting of tar archives might be quite slow since tar has to look up | |
1162 | userid and groupids and doesn't cache negative results. If you have nis or | |
1163 | nisplus in your /etc/nsswitch.conf for the passwd and/or group database, | |
1164 | each file extractions needs a network connection. There are two possible | |
1165 | solutions: | |
1166 | ||
1167 | - do you really need NIS/NIS+ (some Linux distributions add by default | |
1168 | nis/nisplus even if it's not needed)? If not, just remove the entries. | |
1169 | ||
1170 | - if you need NIS/NIS+, use the Name Service Cache Daemon nscd that comes | |
1171 | with glibc 2.1. | |
1172 | ||
2ee511d9 UD |
1173 | |
1174 | 2.29. Compiling programs I get parse errors in libio.h (e.g. "parse error | |
1175 | before `_IO_seekoff'"). How should I fix this? | |
1176 | ||
1177 | {AJ} You might get the following errors when upgrading to glibc 2.1: | |
1178 | ||
1179 | In file included from /usr/include/stdio.h:57, | |
1180 | from ... | |
1181 | /usr/include/libio.h:335: parse error before `_IO_seekoff' | |
1182 | /usr/include/libio.h:335: parse error before `_G_off64_t' | |
1183 | /usr/include/libio.h:336: parse error before `_IO_seekpos' | |
1184 | /usr/include/libio.h:336: parse error before `_G_fpos64_t' | |
1185 | ||
1186 | The problem is a wrong _G_config.h file in your include path. The | |
1187 | _G_config.h file that comes with glibc 2.1 should be used and not one from | |
1188 | libc5 or from a compiler directory. To check which _G_config.h file the | |
1189 | compiler uses, compile your program with `gcc -E ...|grep G_config.h' and | |
1190 | remove that file. Your compiler should pick up the file that has been | |
1191 | installed by glibc 2.1 in your include directory. | |
1192 | ||
4f7ea427 UD |
1193 | |
1194 | 2.30. After upgrading to glibc 2.1, libraries that were compiled against | |
1195 | glibc 2.0.x don't work anymore. | |
1196 | ||
1197 | {AJ} See question 2.27. | |
1198 | ||
9de4e203 UD |
1199 | |
1200 | 2.31. What happened to the Berkeley DB libraries? Can I still use db | |
1201 | in /etc/nsswitch.conf? | |
1202 | ||
1203 | {AJ} Due to too many incompatible changes in disk layout and API of Berkeley | |
1204 | DB and a too tight coupling of libc and libdb, the db library has been | |
1205 | removed completely from glibc 2.2. The only place that really used the | |
1206 | Berkeley DB was the NSS db module. | |
1207 | ||
1208 | The NSS db module has been rewritten to support a number of different | |
1209 | versions of Berkeley DB for the NSS db module. Currently the releases 2.x | |
1210 | and 3.x of Berkeley DB are supported. The older db 1.85 library is not | |
1211 | supported. You can use the version from glibc 2.1.x or download a version | |
1212 | from Sleepycat Software (http://www.sleepycat.com). The library has to be | |
1213 | compiled as shared library and installed in the system lib directory | |
1214 | (normally /lib). The library needs to have a special soname to be found by | |
1215 | the NSS module. | |
1216 | ||
1217 | If public structures change in a new Berkeley db release, this needs to be | |
1218 | reflected in glibc. | |
1219 | ||
1220 | Currently the code searches for libraries with a soname of "libdb.so.3" | |
1221 | (that's the name from db 2.4.14 which comes with glibc 2.1.x) and | |
1222 | "libdb-3.0.so" (the name used by db 3.0.55 as default). | |
1223 | ||
2c88f872 AJ |
1224 | The nss_db module is now in a separate package since it requires a database |
1225 | library being available. | |
1226 | ||
1227 | ||
1228 | 2.32. What has do be done when upgrading to glibc 2.2? | |
1229 | ||
1230 | {AJ} The upgrade to glibc 2.2 should run smoothly, there's in general no | |
1231 | need to recompile programs or libraries. Nevertheless, some changes might | |
1232 | be needed after upgrading: | |
1233 | - The utmp daemon has been removed and is not supported by glibc anymore. | |
1234 | If it has been in use, it should be switched off. | |
1235 | - Programs using IPv6 have to be recompiled due to incompatible changes in | |
1236 | sockaddr_in6 by the IPv6 working group. | |
467cc99e | 1237 | - The Berkeley db libraries have been removed (for details see question 2.31). |
2c88f872 AJ |
1238 | - The format of the locale files has changed, all locales should be |
1239 | regenerated with localedef. All statically linked applications which use | |
1240 | i18n should be recompiled, otherwise they'll not be localized. | |
1241 | - glibc comes with a number of new applications. For example ldconfig has | |
1242 | been implemented for glibc, the libc5 version of ldconfig is not needed | |
1243 | anymore. | |
1244 | - There's no more K&R compatibility in the glibc headers. The GNU C library | |
1245 | requires a C compiler that handles especially prototypes correctly. | |
e0272133 | 1246 | Especially gcc -traditional will not work with glibc headers. |
2c88f872 AJ |
1247 | |
1248 | Please read also the NEWS file which is the authoritative source for this | |
1249 | and gives more details for some topics. | |
1250 | ||
4442d7e8 UD |
1251 | |
1252 | 2.33. The makefiles want to do a CVS commit. | |
1253 | ||
1254 | {UD} Only if you are not specifying the --without-cvs flag at configure | |
1255 | time. This is what you always have to use if you are checking sources | |
1256 | directly out of the public CVS repository or you have your own private | |
1257 | repository. | |
1258 | ||
1324affa UD |
1259 | |
1260 | 2.34. When compiling C++ programs, I get a compilation error in streambuf.h. | |
1261 | ||
1262 | {BH} You are using g++ 2.95.2? After upgrading to glibc 2.2, you need to | |
1263 | apply a patch to the include files in /usr/include/g++, because the fpos_t | |
1264 | type has changed in glibc 2.2. The patch is at | |
4011dc70 UD |
1265 | |
1266 | http://www.haible.de/bruno/gccinclude-glibc-2.2-compat.diff | |
1324affa UD |
1267 | |
1268 | ||
1269 | 2.35. When recompiling GCC, I get compilation errors in libio. | |
1270 | ||
4a5b72ff | 1271 | {BH} You are trying to recompile gcc 2.95.2? Use gcc 2.95.3 instead. |
5ef50d00 | 1272 | This version is needed because the fpos_t type and a few libio internals |
4a5b72ff | 1273 | have changed in glibc 2.2, and gcc 2.95.3 contains a corresponding patch. |
1324affa | 1274 | |
934b77ac UD |
1275 | |
1276 | 2.36. Why shall glibc never get installed on GNU/Linux systems in | |
1277 | /usr/local? | |
1278 | ||
1279 | {AJ} The GNU C compiler treats /usr/local/include and /usr/local/lib in a | |
1280 | special way, these directories will be searched before the system | |
1281 | directories. Since on GNU/Linux the system directories /usr/include and | |
1282 | /usr/lib contain a --- possibly different --- version of glibc and mixing | |
1283 | certain files from different glibc installations is not supported and will | |
1284 | break, you risk breaking your complete system. If you want to test a glibc | |
1285 | installation, use another directory as argument to --prefix. If you like to | |
1286 | install this glibc version as default version, overriding the existing one, | |
1287 | use --prefix=/usr and everything will go in the right places. | |
1288 | ||
4011dc70 UD |
1289 | |
1290 | 2.37. When recompiling GCC, I get compilation errors in libstdc++. | |
1291 | ||
1292 | {BH} You are trying to recompile gcc 3.2? You need to patch gcc 3.2, | |
1293 | because some last minute changes were made in glibc 2.3 which were not | |
1294 | known when gcc 3.2 was released. The patch is at | |
1295 | ||
1296 | http://www.haible.de/bruno/gcc-3.2-glibc-2.3-compat.diff | |
1297 | ||
61952351 UD |
1298 | \f |
1299 | . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | |
a5a0310d | 1300 | |
61952351 | 1301 | 3. Source and binary incompatibilities, and what to do about them |
a5a0310d | 1302 | |
61952351 UD |
1303 | 3.1. I expect GNU libc to be 100% source code compatible with |
1304 | the old Linux based GNU libc. Why isn't it like this? | |
a5a0310d | 1305 | |
f12944ec UD |
1306 | {DMT,UD} Not every extension in Linux libc's history was well thought-out. |
1307 | In fact it had a lot of problems with standards compliance and with | |
1308 | cleanliness. With the introduction of a new version number these errors can | |
1309 | now be corrected. Here is a list of the known source code | |
61952351 | 1310 | incompatibilities: |
af6f3906 | 1311 | |
61952351 UD |
1312 | * _GNU_SOURCE: glibc does not make the GNU extensions available |
1313 | automatically. If a program depends on GNU extensions or some | |
1314 | other non-standard functionality, it is necessary to compile it | |
1315 | with the C compiler option -D_GNU_SOURCE, or better, to put | |
1316 | `#define _GNU_SOURCE' at the beginning of your source files, before | |
1317 | any C library header files are included. This difference normally | |
1318 | manifests itself in the form of missing prototypes and/or data type | |
1319 | definitions. Thus, if you get such errors, the first thing you | |
1320 | should do is try defining _GNU_SOURCE and see if that makes the | |
1321 | problem go away. | |
af6f3906 | 1322 | |
61952351 UD |
1323 | For more information consult the file `NOTES' in the GNU C library |
1324 | sources. | |
af6f3906 | 1325 | |
61952351 UD |
1326 | * reboot(): GNU libc sanitizes the interface of reboot() to be more |
1327 | compatible with the interface used on other OSes. reboot() as | |
1328 | implemented in glibc takes just one argument. This argument | |
1329 | corresponds to the third argument of the Linux reboot system call. | |
1330 | That is, a call of the form reboot(a, b, c) needs to be changed into | |
1331 | reboot(c). Beside this the header <sys/reboot.h> defines the needed | |
1332 | constants for the argument. These RB_* constants should be used | |
1333 | instead of the cryptic magic numbers. | |
1334 | ||
1335 | * swapon(): the interface of this function didn't change, but the | |
1336 | prototype is in a separate header file <sys/swap.h>. This header | |
1337 | file also provides the SWAP_* constants defined by <linux/swap.h>; | |
1338 | you should use them for the second argument to swapon(). | |
1339 | ||
1340 | * errno: If a program uses the variable "errno", then it _must_ | |
1341 | include <errno.h>. The old libc often (erroneously) declared this | |
1342 | variable implicitly as a side-effect of including other libc header | |
1343 | files. glibc is careful to avoid such namespace pollution, which, | |
1344 | in turn, means that you really need to include the header files that | |
1345 | you depend on. This difference normally manifests itself in the | |
1346 | form of the compiler complaining about references to an undeclared | |
1347 | symbol "errno". | |
dd7d45e8 | 1348 | |
61952351 UD |
1349 | * Linux-specific syscalls: All Linux system calls now have appropriate |
1350 | library wrappers and corresponding declarations in various header files. | |
1351 | This is because the syscall() macro that was traditionally used to | |
1352 | work around missing syscall wrappers are inherently non-portable and | |
1353 | error-prone. The following table lists all the new syscall stubs, | |
1354 | the header-file declaring their interface and the system call name. | |
dd7d45e8 | 1355 | |
61952351 UD |
1356 | syscall name: wrapper name: declaring header file: |
1357 | ------------- ------------- ---------------------- | |
1358 | bdflush bdflush <sys/kdaemon.h> | |
1359 | syslog ksyslog_ctl <sys/klog.h> | |
dd7d45e8 | 1360 | |
61952351 UD |
1361 | * lpd: Older versions of lpd depend on a routine called _validuser(). |
1362 | The library does not provide this function, but instead provides | |
1363 | __ivaliduser() which has a slightly different interface. Simply | |
1364 | upgrading to a newer lpd should fix this problem (e.g., the 4.4BSD | |
1365 | lpd is known to be working). | |
dd7d45e8 | 1366 | |
61952351 UD |
1367 | * resolver functions/BIND: like on many other systems the functions of |
1368 | the resolver library are not included in libc itself. There is a | |
1369 | separate library libresolv. If you get undefined symbol errors for | |
1370 | symbols starting with `res_*' simply add -lresolv to your linker | |
1371 | command line. | |
dd7d45e8 | 1372 | |
61952351 UD |
1373 | * the `signal' function's behavior corresponds to the BSD semantic and |
1374 | not the SysV semantic as it was in libc-5. The interface on all GNU | |
1375 | systems shall be the same and BSD is the semantic of choice. To use | |
1376 | the SysV behavior simply use `sysv_signal', or define _XOPEN_SOURCE. | |
1377 | See question 3.7 for details. | |
1cab5444 | 1378 | |
1cab5444 | 1379 | |
61952351 UD |
1380 | 3.2. Why does getlogin() always return NULL on my Linux box? |
1381 | ||
f12944ec UD |
1382 | {UD} The GNU C library has a format for the UTMP and WTMP file which differs |
1383 | from what your system currently has. It was extended to fulfill the needs | |
1384 | of the next years when IPv6 is introduced. The record size is different and | |
1385 | some fields have different positions. The files written by functions from | |
1386 | the one library cannot be read by functions from the other library. Sorry, | |
1387 | but this is what a major release is for. It's better to have a cut now than | |
1388 | having no means to support the new techniques later. | |
1cab5444 | 1389 | |
6973fc01 | 1390 | |
61952351 UD |
1391 | 3.3. Where are the DST_* constants found in <sys/time.h> on many |
1392 | systems? | |
6973fc01 | 1393 | |
f12944ec UD |
1394 | {UD} These constants come from the old BSD days and are not used anymore |
1395 | (libc5 does not actually implement the handling although the constants are | |
1396 | defined). | |
6973fc01 | 1397 | |
f12944ec | 1398 | Instead GNU libc contains zone database support and compatibility code for |
8b4a4715 | 1399 | POSIX TZ environment variable handling. For former is very much preferred |
7d1de115 | 1400 | (see question 4.3). |
6973fc01 UD |
1401 | |
1402 | ||
61952351 UD |
1403 | 3.4. The prototypes for `connect', `accept', `getsockopt', |
1404 | `setsockopt', `getsockname', `getpeername', `send', | |
1405 | `sendto', and `recvfrom' are different in GNU libc from | |
1406 | any other system I saw. This is a bug, isn't it? | |
f4017d20 | 1407 | |
f12944ec UD |
1408 | {UD} No, this is no bug. This version of GNU libc already follows the new |
1409 | Single Unix specifications (and I think the POSIX.1g draft which adopted the | |
1410 | solution). The type for a parameter describing a size is now `socklen_t', a | |
1411 | new type. | |
f4017d20 | 1412 | |
f4017d20 | 1413 | |
61952351 UD |
1414 | 3.5. On Linux I've got problems with the declarations in Linux |
1415 | kernel headers. | |
f4017d20 | 1416 | |
f12944ec UD |
1417 | {UD,AJ} On Linux, the use of kernel headers is reduced to the minimum. This |
1418 | gives Linus the ability to change the headers more freely. Also, user | |
8f1c9b09 | 1419 | programs are now insulated from changes in the size of kernel data |
f12944ec | 1420 | structures. |
f4017d20 | 1421 | |
f12944ec UD |
1422 | For example, the sigset_t type is 32 or 64 bits wide in the kernel. In |
1423 | glibc it is 1024 bits wide. This guarantees that when the kernel gets a | |
1424 | bigger sigset_t (for POSIX.1e realtime support, say) user programs will not | |
1425 | have to be recompiled. Consult the header files for more information about | |
1426 | the changes. | |
61952351 | 1427 | |
f12944ec UD |
1428 | Therefore you shouldn't include Linux kernel header files directly if glibc |
1429 | has defined a replacement. Otherwise you might get undefined results because | |
1430 | of type conflicts. | |
f4017d20 | 1431 | |
f4017d20 | 1432 | |
61952351 UD |
1433 | 3.6. I don't include any kernel headers myself but the compiler |
1434 | still complains about redeclarations of types in the kernel | |
1435 | headers. | |
1436 | ||
f12944ec UD |
1437 | {UD} The kernel headers before Linux 2.1.61 and 2.0.32 don't work correctly |
1438 | with glibc. Compiling C programs is possible in most cases but C++ programs | |
1439 | have (due to the change of the name lookups for `struct's) problems. One | |
1440 | prominent example is `struct fd_set'. | |
61952351 | 1441 | |
f12944ec UD |
1442 | There might be some problems left but 2.1.61/2.0.32 fix most of the known |
1443 | ones. See the BUGS file for other known problems. | |
61952351 UD |
1444 | |
1445 | ||
1446 | 3.7. Why don't signals interrupt system calls anymore? | |
1447 | ||
f12944ec UD |
1448 | {ZW} By default GNU libc uses the BSD semantics for signal(), unlike Linux |
1449 | libc 5 which used System V semantics. This is partially for compatibility | |
1450 | with other systems and partially because the BSD semantics tend to make | |
1451 | programming with signals easier. | |
f4017d20 UD |
1452 | |
1453 | There are three differences: | |
1454 | ||
1455 | * BSD-style signals that occur in the middle of a system call do not | |
1456 | affect the system call; System V signals cause the system call to | |
1457 | fail and set errno to EINTR. | |
1458 | ||
1459 | * BSD signal handlers remain installed once triggered. System V signal | |
1460 | handlers work only once, so one must reinstall them each time. | |
1461 | ||
1462 | * A BSD signal is blocked during the execution of its handler. In other | |
1463 | words, a handler for SIGCHLD (for example) does not need to worry about | |
61952351 | 1464 | being interrupted by another SIGCHLD. It may, however, be interrupted |
f4017d20 UD |
1465 | by other signals. |
1466 | ||
1467 | There is general consensus that for `casual' programming with signals, the | |
1468 | BSD semantics are preferable. You don't need to worry about system calls | |
1469 | returning EINTR, and you don't need to worry about the race conditions | |
1470 | associated with one-shot signal handlers. | |
1471 | ||
1472 | If you are porting an old program that relies on the old semantics, you can | |
1473 | quickly fix the problem by changing signal() to sysv_signal() throughout. | |
1474 | Alternatively, define _XOPEN_SOURCE before including <signal.h>. | |
1475 | ||
1476 | For new programs, the sigaction() function allows you to specify precisely | |
1477 | how you want your signals to behave. All three differences listed above are | |
1478 | individually switchable on a per-signal basis with this function. | |
1479 | ||
f12944ec UD |
1480 | If all you want is for one specific signal to cause system calls to fail and |
1481 | return EINTR (for example, to implement a timeout) you can do this with | |
f4017d20 UD |
1482 | siginterrupt(). |
1483 | ||
1484 | ||
61952351 UD |
1485 | 3.8. I've got errors compiling code that uses certain string |
1486 | functions. Why? | |
1487 | ||
f12944ec | 1488 | {AJ} glibc 2.1 has special string functions that are faster than the normal |
fdacb17d | 1489 | library functions. Some of the functions are additionally implemented as |
a25f2023 UD |
1490 | inline functions and others as macros. This might lead to problems with |
1491 | existing codes but it is explicitly allowed by ISO C. | |
04be94a8 | 1492 | |
04be94a8 | 1493 | The optimized string functions are only used when compiling with |
fdacb17d | 1494 | optimizations (-O1 or higher). The behavior can be changed with two feature |
f12944ec | 1495 | macros: |
61952351 UD |
1496 | |
1497 | * __NO_STRING_INLINES: Don't do any string optimizations. | |
1498 | * __USE_STRING_INLINES: Use assembly language inline functions (might | |
1499 | increase code size dramatically). | |
04be94a8 | 1500 | |
f12944ec UD |
1501 | Since some of these string functions are now additionally defined as macros, |
1502 | code like "char *strncpy();" doesn't work anymore (and is unnecessary, since | |
fdacb17d | 1503 | <string.h> has the necessary declarations). Either change your code or |
f12944ec | 1504 | define __NO_STRING_INLINES. |
04be94a8 | 1505 | |
f12944ec UD |
1506 | {UD} Another problem in this area is that gcc still has problems on machines |
1507 | with very few registers (e.g., ix86). The inline assembler code can require | |
1508 | almost all the registers and the register allocator cannot always handle | |
1509 | this situation. | |
04be94a8 | 1510 | |
61952351 | 1511 | One can disable the string optimizations selectively. Instead of writing |
04be94a8 UD |
1512 | |
1513 | cp = strcpy (foo, "lkj"); | |
1514 | ||
1515 | one can write | |
1516 | ||
1517 | cp = (strcpy) (foo, "lkj"); | |
1518 | ||
61952351 UD |
1519 | This disables the optimization for that specific call. |
1520 | ||
4775243a UD |
1521 | |
1522 | 3.9. I get compiler messages "Initializer element not constant" with | |
1523 | stdin/stdout/stderr. Why? | |
1524 | ||
1525 | {RM,AJ} Constructs like: | |
66f6a52b | 1526 | static FILE *InPtr = stdin; |
4775243a | 1527 | |
fdacb17d UD |
1528 | lead to this message. This is correct behaviour with glibc since stdin is |
1529 | not a constant expression. Please note that a strict reading of ISO C does | |
f12944ec | 1530 | not allow above constructs. |
4775243a | 1531 | |
f12944ec UD |
1532 | One of the advantages of this is that you can assign to stdin, stdout, and |
1533 | stderr just like any other global variable (e.g. `stdout = my_stream;'), | |
1534 | which can be very useful with custom streams that you can write with libio | |
fdacb17d | 1535 | (but beware this is not necessarily portable). The reason to implement it |
f12944ec | 1536 | this way were versioning problems with the size of the FILE structure. |
4775243a | 1537 | |
fdacb17d UD |
1538 | To fix those programs you've got to initialize the variable at run time. |
1539 | This can be done, e.g. in main, like: | |
1540 | ||
66f6a52b UD |
1541 | static FILE *InPtr; |
1542 | int main(void) | |
1543 | { | |
1544 | InPtr = stdin; | |
1545 | } | |
fdacb17d UD |
1546 | |
1547 | or by constructors (beware this is gcc specific): | |
1548 | ||
66f6a52b UD |
1549 | static FILE *InPtr; |
1550 | static void inPtr_construct (void) __attribute__((constructor)); | |
1551 | static void inPtr_construct (void) { InPtr = stdin; } | |
fdacb17d | 1552 | |
4775243a UD |
1553 | |
1554 | 3.10. I can't compile with gcc -traditional (or | |
1555 | -traditional-cpp). Why? | |
1556 | ||
1557 | {AJ} glibc2 does break -traditional and -traditonal-cpp - and will continue | |
fdacb17d | 1558 | to do so. For example constructs of the form: |
f12944ec | 1559 | |
66f6a52b UD |
1560 | enum {foo |
1561 | #define foo foo | |
1562 | } | |
f12944ec UD |
1563 | |
1564 | are useful for debugging purposes (you can use foo with your debugger that's | |
1565 | why we need the enum) and for compatibility (other systems use defines and | |
1566 | check with #ifdef). | |
4775243a UD |
1567 | |
1568 | ||
1569 | 3.11. I get some errors with `gcc -ansi'. Isn't glibc ANSI compatible? | |
1570 | ||
1571 | {AJ} The GNU C library is compatible with the ANSI/ISO C standard. If | |
f12944ec | 1572 | you're using `gcc -ansi', the glibc includes which are specified in the |
fdacb17d | 1573 | standard follow the standard. The ANSI/ISO C standard defines what has to be |
f12944ec UD |
1574 | in the include files - and also states that nothing else should be in the |
1575 | include files (btw. you can still enable additional standards with feature | |
1576 | flags). | |
4775243a | 1577 | |
f12944ec UD |
1578 | The GNU C library is conforming to ANSI/ISO C - if and only if you're only |
1579 | using the headers and library functions defined in the standard. | |
4775243a | 1580 | |
a35cb74d UD |
1581 | |
1582 | 3.12. I can't access some functions anymore. nm shows that they do | |
1583 | exist but linking fails nevertheless. | |
1584 | ||
f12944ec UD |
1585 | {AJ} With the introduction of versioning in glibc 2.1 it is possible to |
1586 | export only those identifiers (functions, variables) that are really needed | |
1587 | by application programs and by other parts of glibc. This way a lot of | |
1588 | internal interfaces are now hidden. nm will still show those identifiers | |
1589 | but marking them as internal. ISO C states that identifiers beginning with | |
1590 | an underscore are internal to the libc. An application program normally | |
1591 | shouldn't use those internal interfaces (there are exceptions, | |
1592 | e.g. __ivaliduser). If a program uses these interfaces, it's broken. These | |
1593 | internal interfaces might change between glibc releases or dropped | |
1594 | completely. | |
a35cb74d | 1595 | |
a5f4e34a UD |
1596 | |
1597 | 3.13. When using the db-2 library which comes with glibc is used in | |
1598 | the Perl db modules the testsuite is not passed. This did not | |
1599 | happen with db-1, gdbm, or ndbm. | |
1600 | ||
037f8020 | 1601 | {} Removed. Does not apply anymore. |
a5f4e34a | 1602 | |
5148d49f UD |
1603 | |
1604 | 3.14. The pow() inline function I get when including <math.h> is broken. | |
1605 | I get segmentation faults when I run the program. | |
1606 | ||
1607 | {UD} Nope, the implementation is correct. The problem is with egcs version | |
1608 | prior to 1.1. I.e., egcs 1.0 to 1.0.3 are all broken (at least on Intel). | |
1609 | If you have to use this compiler you must define __NO_MATH_INLINES before | |
1610 | including <math.h> to prevent the inline functions from being used. egcs 1.1 | |
1611 | fixes the problem. I don't know about gcc 2.8 and 2.8.1. | |
1612 | ||
05f732b3 UD |
1613 | |
1614 | 3.15. The sys/sem.h file lacks the definition of `union semun'. | |
1615 | ||
1616 | {UD} Nope. This union has to be provided by the user program. Former glibc | |
1617 | versions defined this but it was an error since it does not make much sense | |
1618 | when thinking about it. The standards describing the System V IPC functions | |
1619 | define it this way and therefore programs must be adopted. | |
1620 | ||
33127459 UD |
1621 | |
1622 | 3.16. Why has <netinet/ip_fw.h> disappeared? | |
1623 | ||
1624 | {AJ} The corresponding Linux kernel data structures and constants are | |
b710a6e2 | 1625 | totally different in Linux 2.0 and Linux 2.2. This situation has to be |
33127459 UD |
1626 | taken care in user programs using the firewall structures and therefore |
1627 | those programs (ipfw is AFAIK the only one) should deal with this problem | |
1628 | themselves. | |
1629 | ||
28ab8526 UD |
1630 | |
1631 | 3.17. I get floods of warnings when I use -Wconversion and include | |
1632 | <string.h> or <math.h>. | |
1633 | ||
1634 | {ZW} <string.h> and <math.h> intentionally use prototypes to override | |
1635 | argument promotion. -Wconversion warns about all these. You can safely | |
1636 | ignore the warnings. | |
1637 | ||
1638 | -Wconversion isn't really intended for production use, only for shakedown | |
1639 | compiles after converting an old program to standard C. | |
1640 | ||
5ff1a70a UD |
1641 | |
1642 | 3.18. After upgrading to glibc 2.1, I receive errors about | |
1643 | unresolved symbols, like `_dl_initial_searchlist' and can not | |
1644 | execute any binaries. What went wrong? | |
1645 | ||
1646 | {AJ} This normally happens if your libc and ld (dynamic linker) are from | |
1647 | different releases of glibc. For example, the dynamic linker | |
1648 | /lib/ld-linux.so.2 comes from glibc 2.0.x, but the version of libc.so.6 is | |
1649 | from glibc 2.1. | |
1650 | ||
1651 | The path /lib/ld-linux.so.2 is hardcoded in every glibc2 binary but | |
1652 | libc.so.6 is searched via /etc/ld.so.cache and in some special directories | |
1653 | like /lib and /usr/lib. If you run configure with another prefix than /usr | |
1654 | and put this prefix before /lib in /etc/ld.so.conf, your system will break. | |
1655 | ||
1656 | So what can you do? Either of the following should work: | |
1657 | ||
1658 | * Run `configure' with the same prefix argument you've used for glibc 2.0.x | |
1659 | so that the same paths are used. | |
1660 | * Replace /lib/ld-linux.so.2 with a link to the dynamic linker from glibc | |
1661 | 2.1. | |
1662 | ||
1663 | You can even call the dynamic linker by hand if everything fails. You've | |
1664 | got to set LD_LIBRARY_PATH so that the corresponding libc is found and also | |
1665 | need to provide an absolute path to your binary: | |
1666 | ||
1667 | LD_LIBRARY_PATH=<path-where-libc.so.6-lives> \ | |
1668 | <path-where-corresponding-dynamic-linker-lives>/ld-linux.so.2 \ | |
1669 | <path-to-binary>/binary | |
1670 | ||
1671 | For example `LD_LIBRARY_PATH=/libold /libold/ld-linux.so.2 /bin/mv ...' | |
1672 | might be useful in fixing a broken system (if /libold contains dynamic | |
1673 | linker and corresponding libc). | |
1674 | ||
1675 | With that command line no path is used. To further debug problems with the | |
1676 | dynamic linker, use the LD_DEBUG environment variable, e.g. | |
1677 | `LD_DEBUG=help echo' for the help text. | |
1678 | ||
1679 | If you just want to test this release, don't put the lib directory in | |
1680 | /etc/ld.so.conf. You can call programs directly with full paths (as above). | |
1681 | When compiling new programs against glibc 2.1, you've got to specify the | |
1682 | correct paths to the compiler (option -I with gcc) and linker (options | |
1683 | --dynamic-linker, -L and --rpath). | |
1684 | ||
61952351 | 1685 | |
7d1de115 UD |
1686 | 3.19. bonnie reports that char i/o with glibc 2 is much slower than with |
1687 | libc5. What can be done? | |
1688 | ||
1689 | {AJ} The GNU C library uses thread safe functions by default and libc5 used | |
1690 | non thread safe versions. The non thread safe functions have in glibc the | |
1691 | suffix `_unlocked', for details check <stdio.h>. Using `putc_unlocked' etc. | |
1692 | instead of `putc' should give nearly the same speed with bonnie (bonnie is a | |
1693 | benchmark program for measuring disk access). | |
9f6b6d8d | 1694 | |
b93492aa UD |
1695 | |
1696 | 3.20. Programs compiled with glibc 2.1 can't read db files made with glibc | |
1697 | 2.0. What has changed that programs like rpm break? | |
1698 | ||
037f8020 | 1699 | {} Removed. Does not apply anymore. |
b93492aa | 1700 | |
b5a9efcd UD |
1701 | |
1702 | 3.21. Autoconf's AC_CHECK_FUNC macro reports that a function exists, but | |
1703 | when I try to use it, it always returns -1 and sets errno to ENOSYS. | |
1704 | ||
1705 | {ZW} You are using a 2.0 Linux kernel, and the function you are trying to | |
1706 | use is only implemented in 2.1/2.2. Libc considers this to be a function | |
1707 | which exists, because if you upgrade to a 2.2 kernel, it will work. One | |
1708 | such function is sigaltstack. | |
1709 | ||
1710 | Your program should check at runtime whether the function works, and | |
1711 | implement a fallback. Note that Autoconf cannot detect unimplemented | |
1712 | functions in other systems' C libraries, so you need to do this anyway. | |
1713 | ||
1714 | ||
1715 | 3.22. My program segfaults when I call fclose() on the FILE* returned | |
1716 | from setmntent(). Is this a glibc bug? | |
1717 | ||
1718 | {GK} No. Don't do this. Use endmntent(), that's what it's for. | |
1719 | ||
1720 | In general, you should use the correct deallocation routine. For instance, | |
1721 | if you open a file using fopen(), you should deallocate the FILE * using | |
1722 | fclose(), not free(), even though the FILE * is also a pointer. | |
1723 | ||
1724 | In the case of setmntent(), it may appear to work in most cases, but it | |
1725 | won't always work. Unfortunately, for compatibility reasons, we can't | |
1726 | change the return type of setmntent() to something other than FILE *. | |
1727 | ||
c891b2df UD |
1728 | |
1729 | 3.23. I get "undefined reference to `atexit'" | |
1730 | ||
1731 | {UD} This means that your installation is somehow broken. The situation is | |
1732 | the same as for 'stat', 'fstat', etc (see question 2.7). Investigate why the | |
1733 | linker does not pick up libc_nonshared.a. | |
1734 | ||
1735 | If a similar message is issued at runtime this means that the application or | |
1736 | DSO is not linked against libc. This can cause problems since 'atexit' is | |
1737 | not exported anymore. | |
1738 | ||
9f6b6d8d UD |
1739 | \f |
1740 | . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | |
1741 | ||
7d1de115 | 1742 | 4. Miscellaneous |
61952351 | 1743 | |
7d1de115 | 1744 | 4.1. After I changed configure.in I get `Autoconf version X.Y. |
61952351 UD |
1745 | or higher is required for this script'. What can I do? |
1746 | ||
1747 | {UD} You have to get the specified autoconf version (or a later one) | |
a35cb74d | 1748 | from your favorite mirror of ftp.gnu.org. |
61952351 | 1749 | |
04be94a8 | 1750 | |
7d1de115 | 1751 | 4.2. When I try to compile code which uses IPv6 headers and |
61952351 UD |
1752 | definitions on my Linux 2.x.y system I am in trouble. |
1753 | Nothing seems to work. | |
1754 | ||
f12944ec UD |
1755 | {UD} The problem is that IPv6 development still has not reached a point |
1756 | where the headers are stable. There are still lots of incompatible changes | |
1757 | made and the libc headers have to follow. | |
61952351 | 1758 | |
348ed515 UD |
1759 | {PB} The 2.1 release of GNU libc aims to comply with the current versions of |
1760 | all the relevant standards. The IPv6 support libraries for older Linux | |
1761 | systems used a different naming convention and so code written to work with | |
1762 | them may need to be modified. If the standards make incompatible changes in | |
1763 | the future then the libc may need to change again. | |
1764 | ||
1765 | IPv6 will not work with a 2.0.x kernel. When kernel 2.2 is released it | |
1766 | should contain all the necessary support; until then you should use the | |
1767 | latest 2.1.x release you can find. As of 98/11/26 the currently recommended | |
1768 | kernel for IPv6 is 2.1.129. | |
1769 | ||
1770 | Also, as of the 2.1 release the IPv6 API provided by GNU libc is not | |
b669ab02 | 1771 | 100% complete. |
04be94a8 | 1772 | |
ff44f2a5 | 1773 | |
7d1de115 | 1774 | 4.3. When I set the timezone by setting the TZ environment variable |
ff44f2a5 UD |
1775 | to EST5EDT things go wrong since glibc computes the wrong time |
1776 | from this information. | |
1777 | ||
f12944ec UD |
1778 | {UD} The problem is that people still use the braindamaged POSIX method to |
1779 | select the timezone using the TZ environment variable with a format EST5EDT | |
8b4a4715 UD |
1780 | or whatever. People, if you insist on using TZ instead of the timezone |
1781 | database (see below), read the POSIX standard, the implemented behaviour is | |
f12944ec UD |
1782 | correct! What you see is in fact the result of the decisions made while |
1783 | POSIX.1 was created. We've only implemented the handling of TZ this way to | |
1784 | be POSIX compliant. It is not really meant to be used. | |
1785 | ||
1786 | The alternative approach to handle timezones which is implemented is the | |
1787 | correct one to use: use the timezone database. This avoids all the problems | |
1788 | the POSIX method has plus it is much easier to use. Simply run the tzselect | |
1789 | shell script, answer the question and use the name printed in the end by | |
8b4a4715 UD |
1790 | making a symlink /etc/localtime pointing to /usr/share/zoneinfo/NAME (NAME |
1791 | is the returned value from tzselect). That's all. You never again have to | |
1792 | worry. | |
f12944ec UD |
1793 | |
1794 | So, please avoid sending bug reports about time related problems if you use | |
1795 | the POSIX method and you have not verified something is really broken by | |
1796 | reading the POSIX standards. | |
ff44f2a5 | 1797 | |
fdacb17d | 1798 | |
7d1de115 | 1799 | 4.4. What other sources of documentation about glibc are available? |
fdacb17d UD |
1800 | |
1801 | {AJ} The FSF has a page about the GNU C library at | |
1802 | <http://www.gnu.org/software/libc/>. The problem data base of open and | |
1803 | solved bugs in GNU libc is available at | |
1804 | <http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl>. Eric Green has written | |
9de4e203 | 1805 | a HowTo for converting from Linux libc5 to glibc2. The HowTo is accessible |
fdacb17d UD |
1806 | via the FSF page and at <http://www.imaxx.net/~thrytis/glibc>. Frodo |
1807 | Looijaard describes a different way installing glibc2 as secondary libc at | |
1808 | <http://huizen.dds.nl/~frodol/glibc>. | |
1809 | ||
1810 | Please note that this is not a complete list. | |
1811 | ||
348ed515 | 1812 | |
7d1de115 | 1813 | 4.5. The timezone string for Sydney/Australia is wrong since even when |
348ed515 UD |
1814 | daylight saving time is in effect the timezone string is EST. |
1815 | ||
1816 | {UD} The problem for some timezones is that the local authorities decided | |
1817 | to use the term "summer time" instead of "daylight saving time". In this | |
1818 | case the abbreviation character `S' is the same as the standard one. So, | |
1819 | for Sydney we have | |
1820 | ||
1821 | Eastern Standard Time = EST | |
1822 | Eastern Summer Time = EST | |
1823 | ||
1824 | Great! To get this bug fixed convince the authorities to change the laws | |
1825 | and regulations of the country this effects. glibc behaves correctly. | |
1826 | ||
eeabe877 | 1827 | |
7d1de115 | 1828 | 4.6. I've build make 3.77 against glibc 2.1 and now make gets |
eeabe877 UD |
1829 | segmentation faults. |
1830 | ||
037f8020 | 1831 | {} Removed. Does not apply anymore, use make 3.79 or newer. |
eeabe877 | 1832 | |
c63598bf UD |
1833 | |
1834 | 4.7. Why do so many programs using math functions fail on my AlphaStation? | |
1835 | ||
1836 | {AO} The functions floor() and floorf() use an instruction that is not | |
1837 | implemented in some old PALcodes of AlphaStations. This may cause | |
1838 | `Illegal Instruction' core dumps or endless loops in programs that | |
1839 | catch these signals. Updating the firmware to a 1999 release has | |
1840 | fixed the problem on an AlphaStation 200 4/166. | |
1841 | ||
8892c471 UD |
1842 | |
1843 | 4.8. The conversion table for character set XX does not match with | |
1844 | what I expect. | |
1845 | ||
1846 | {UD} I don't doubt for a minute that some of the conversion tables contain | |
1847 | errors. We tried the best we can and relied on automatic generation of the | |
1848 | data to prevent human-introduced errors but this still is no guarantee. If | |
1849 | you think you found a problem please send a bug report describing it and | |
1850 | give an authoritive reference. The latter is important since otherwise | |
1851 | the current behaviour is as good as the proposed one. | |
1852 | ||
1853 | Before doing this look through the list of known problem first: | |
1854 | ||
1855 | - the GBK (simplified Chinese) encoding is based on Unicode tables. This | |
1856 | is good. These tables, however, differ slightly from the tables used | |
1857 | by the M$ people. The differences are these [+ Unicode, - M$]: | |
1858 | ||
1859 | +0xA1AA 0x2015 | |
1860 | +0xA844 0x2014 | |
1861 | -0xA1AA 0x2014 | |
1862 | -0xA844 0x2015 | |
1863 | ||
1864 | In addition the Unicode tables contain mappings for the GBK characters | |
1865 | 0xA8BC, 0xA8BF, 0xA989 to 0xA995, and 0xFE50 to 0xFEA0. | |
1866 | ||
ffa156af UD |
1867 | - when mapping from EUC-CN to GBK and vice versa we ignore the fact that |
1868 | the coded character at position 0xA1A4 maps to different Unicode | |
1869 | characters. Since the iconv() implementation can do whatever it wants | |
1870 | if it cannot directly map a character this is a perfectly good solution | |
1871 | since the semantics and appearance of the character does not change. | |
1872 | ||
be76803a UD |
1873 | |
1874 | 4.9. How can I find out which version of glibc I am using in the moment? | |
1875 | ||
1876 | {UD} If you want to find out about the version from the command line simply | |
1877 | run the libc binary. This is probably not possible on all platforms but | |
1878 | where it is simply locate the libc DSO and start it as an application. On | |
1879 | Linux like | |
1880 | ||
1881 | /lib/libc.so.6 | |
1882 | ||
1883 | This will produce all the information you need. | |
1884 | ||
1885 | What always will work is to use the API glibc provides. Compile and run the | |
1886 | following little program to get the version information: | |
1887 | ||
1888 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
1889 | #include <stdio.h> | |
1890 | #include <gnu/libc-version.h> | |
1891 | int main (void) { puts (gnu_get_libc_version ()); return 0; } | |
1892 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
1893 | ||
1894 | This interface can also obviously be used to perform tests at runtime if | |
1895 | this should be necessary. | |
1896 | ||
5e014387 UD |
1897 | |
1898 | 4.10. Context switching with setcontext() does not work from within | |
1899 | signal handlers. | |
1900 | ||
1901 | {DMT} The Linux implementations (IA-64, S390 so far) of setcontext() | |
1902 | supports synchronous context switches only. There are several reasons for | |
1903 | this: | |
1904 | ||
02eca23b AJ |
1905 | - UNIX provides no other (portable) way of effecting a synchronous |
1906 | context switch (also known as co-routine switch). Some versions | |
1907 | support this via setjmp()/longjmp() but this does not work | |
1908 | universally. | |
1909 | ||
1910 | - As defined by the UNIX '98 standard, the only way setcontext() | |
1911 | could trigger an asychronous context switch is if this function | |
1912 | were invoked on the ucontext_t pointer passed as the third argument | |
1913 | to a signal handler. But according to draft 5, XPG6, XBD 2.4.3, | |
1914 | setcontext() is not among the set of routines that may be called | |
1915 | from a signal handler. | |
1916 | ||
1917 | - If setcontext() were to be used for asynchronous context switches, | |
1918 | all kinds of synchronization and re-entrancy issues could arise and | |
1919 | these problems have already been solved by real multi-threading | |
1920 | libraries (e.g., POSIX threads or Linux threads). | |
1921 | ||
1922 | - Synchronous context switching can be implemented entirely in | |
1923 | user-level and less state needs to be saved/restored than for an | |
1924 | asynchronous context switch. It is therefore useful to distinguish | |
1925 | between the two types of context switches. Indeed, some | |
1926 | application vendors are known to use setcontext() to implement | |
1927 | co-routines on top of normal (heavier-weight) pre-emptable threads. | |
5e014387 UD |
1928 | |
1929 | It should be noted that if someone was dead-bent on using setcontext() | |
1930 | on the third arg of a signal handler, then IA-64 Linux could support | |
1931 | this via a special version of sigaction() which arranges that all | |
1932 | signal handlers start executing in a shim function which takes care of | |
1933 | saving the preserved registers before calling the real signal handler | |
1934 | and restoring them afterwards. In other words, we could provide a | |
1935 | compatibility layer which would support setcontext() for asynchronous | |
1936 | context switches. However, given the arguments above, I don't think | |
1937 | that makes sense. setcontext() provides a decent co-routine interface | |
1938 | and we should just discourage any asynchronous use (which just calls | |
1939 | for trouble at any rate). | |
1940 | ||
f8cac037 | 1941 | \f |
61952351 UD |
1942 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
1943 | ||
f8cac037 | 1944 | Answers were given by: |
5e014387 UD |
1945 | {UD} Ulrich Drepper, <drepper@redhat.com> |
1946 | {DMT} David Mosberger-Tang, <davidm@hpl.hp.com> | |
dd7d45e8 | 1947 | {RM} Roland McGrath, <roland@gnu.org> |
9de4e203 | 1948 | {AJ} Andreas Jaeger, <aj@suse.de> |
22d57dd3 | 1949 | {EY} Eric Youngdale, <eric@andante.jic.com> |
a5a0310d | 1950 | {PB} Phil Blundell, <Philip.Blundell@pobox.com> |
af6f3906 | 1951 | {MK} Mark Kettenis, <kettenis@phys.uva.nl> |
f4017d20 | 1952 | {ZW} Zack Weinberg, <zack@rabi.phys.columbia.edu> |
612fdf25 | 1953 | {TK} Thorsten Kukuk, <kukuk@suse.de> |
5e014387 | 1954 | {GK} Geoffrey Keating, <geoffk@redhat.com> |
a35cb74d | 1955 | {HJ} H.J. Lu, <hjl@gnu.org> |
b710a6e2 | 1956 | {CG} Cristian Gafton, <gafton@redhat.com> |
5e014387 | 1957 | {AO} Alexandre Oliva, <aoliva@redhat.com> |
1324affa | 1958 | {BH} Bruno Haible, <haible@clisp.cons.org> |
dfc89273 | 1959 | {SM} Steven Munroe, <sjmunroe@us.ibm.com> |
f8cac037 RM |
1960 | \f |
1961 | Local Variables: | |
61952351 UD |
1962 | mode:outline |
1963 | outline-regexp:"\\?" | |
f12944ec | 1964 | fill-column:76 |
f8cac037 | 1965 | End: |