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