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