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