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