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