Update.
[kopensolaris-gnu/glibc.git] / FAQ
1                 Frequently Asked Question on GNU C Library
2
3 As every FAQ this one also tries to answer questions the user might have
4 when using the package.  Please make sure you read this before sending
5 questions or bug reports to the maintainers.
6
7 The GNU C Library is very complex.  The building process exploits the
8 features available in tools generally available.  But many things can
9 only be done using GNU tools.  Also the code is sometimes hard to
10 understand because it has to be portable but on the other hand must be
11 fast.  But you need not understand the details to use GNU C Library.
12 This will only be necessary if you intend to contribute or change it.
13
14 If you have any questions you think should be answered in this document,
15 please let me know.
16
17                                                   --drepper@cygnus.com
18 \f
19 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
20 [Q1]    ``What systems does the GNU C Library run on?''
21
22 [Q2]    ``What compiler do I need to build GNU libc?''
23
24 [Q3]    ``When starting make I get only error messages.
25           What's wrong?''
26
27 [Q4]    ``After I changed configure.in I get `Autoconf version X.Y.
28           or higher is required for this script'.  What can I do?''
29
30 [Q5]    ``Do I need a special linker or archiver?''
31
32 [Q6]    ``Do I need some more things to compile GNU C Library?''
33
34 [Q7]    ``When I run `nm -u libc.so' on the produced library I still
35           find unresolved symbols?  Can this be ok?''
36
37 [Q8]    ``Can I replace the libc on my Linux system with GNU libc?''
38
39 [Q9]    ``I expect GNU libc to be 100% source code compatible with
40           the old Linux based GNU libc.  Why isn't it like this?''
41
42 [Q10]   ``Why does getlogin() always return NULL on my Linux box?''
43
44 [Q11]   ``Where are the DST_* constants found in <sys/time.h> on many
45           systems?''
46
47 [Q12]   ``The `gencat' utility cannot process the input which are
48           successfully used on my Linux libc based system.  Why?''
49
50 [Q13]   ``How do I configure GNU libc so that the essential libraries
51           like libc.so go into /lib and the other into /usr/lib?''
52
53 [Q14]   ``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
57 [Q15]   ``What are these `add-ons'?''
58
59 [Q16]   ``When I use GNU libc on my Linux system by linking against
60           to libc.so which comes with glibc all I get is a core dump.''
61
62 [Q17]   ``Looking through the shared libc file I haven't found the
63           functions `stat', `lstat', `fstat', and `mknod' and while
64           linking on my Linux system I get error messages.  How is
65           this supposed to work?''
66
67 [Q18]   ``The prototypes for `connect', `accept', `getsockopt',
68           `setsockopt', `getsockname', `getpeername', `send',
69           `sendto', and `recvfrom' are different in GNU libc than
70           on any other system I saw.  This is a bug, isn't it?''
71
72 [Q19]   ``My XXX kernel emulates a floating-point coprocessor for me.
73           Should I enable --with-fp?''
74
75 [Q20]   ``How can I compile gcc 2.7.2.1 from the gcc source code using
76           glibc 2.x?
77
78 [Q21]    ``On Linux I've got problems with the declarations in Linux
79            kernel headers.''
80
81 [Q22]   ``When I try to compile code which uses IPv6 header and
82           definitions on my Linux 2.x.y system I am in trouble.
83           Nothing seems to work.''
84
85 [Q23]   ``When compiling GNU libc I get lots of errors saying functions
86           in glibc are duplicated in libgcc.''
87
88 [Q24]   ``I have set up /etc/nis.conf, and the Linux libc 5 with NYS
89           works great.  But the glibc NIS+ doesn't seem to work.''
90
91 [Q25]   ``After installing glibc name resolving doesn't work properly.''
92
93
94 [Q26]   ``I have /usr/include/net and /usr/include/scsi as symlinks
95           into my Linux source tree.  Is that wrong?''
96
97 [Q27]   ``Programs like `logname', `top', `uptime' `users', `w' and
98           `who', show incorrect information about the (number of)
99           users on my system.  Why?''
100
101 [Q28]   ``After upgrading to a glibc 2.1 with symbol versioning I get
102           errors about undefined symbols.  What went wrong?''
103
104 [Q29]   ``I don't include any kernel header myself but still the
105           compiler complains about type redeclarations of types in the
106           kernel headers.''
107
108 [Q30]   ``When I start the program XXX after upgrading the library
109           I get
110             XXX: Symbol `_sys_errlist' has different size in shared object, consider re-linking
111           Why?  What to do?''
112
113 [Q31]   ``What's the problem with configure --enable-omitfp?''
114
115 [Q32]   ``Why don't signals interrupt system calls anymore?''
116
117 [Q33]   ``I've got errors compiling code that uses certain string
118           functions.  Why?''
119 \f
120 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
121 [Q1]    ``What systems does the GNU C Library run on?''
122
123 [A1] {UD} This is difficult to answer.  The file `README' lists the
124 architectures GNU libc is known to run *at some time*.  This does not
125 mean that it still can be compiled and run on them in the moment.
126
127 The systems glibc is known to work on in the moment and most probably
128 in the future are:
129
130         *-*-gnu                 GNU Hurd
131         i[3456]86-*-linux-gnu   Linux-2.0 on Intel
132         m68k-*-linux-gnu        Linux-2.0 on Motorola 680x0
133         alpha-*-linux-gnu       Linux-2.0 on DEC Alpha
134         powerpc-*-linux-gnu     Linux and MkLinux on PowerPC systems
135         sparc-*-linux-gnu       Linux-2.0 on SPARC
136         sparc64-*-linux-gnu     Linux-2.0 on UltraSPARC
137
138 Other Linux platforms are also on the way to be supported but I need
139 some success reports first.
140
141 If you have a system not listed above (or in the `README' file) and
142 you are really interested in porting it, contact
143
144         <bug-glibc@prep.ai.mit.edu>
145
146
147 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
148 [Q2]    ``What compiler do I need to build GNU libc?''
149
150 [A2] {UD} It is (almost) impossible to compile GNU C Library using a
151 different compiler than GNU CC.  A lot of extensions of GNU CC are
152 used to increase the portability and speed.
153
154 But this does not mean you have to use GNU CC for using the GNU C
155 Library.  In fact you should be able to use the native C compiler
156 because the success only depends on the binutils: the linker and
157 archiver.
158
159 The GNU CC is found like all other GNU packages on
160         ftp://prep.ai.mit.edu/pub/gnu
161 or better one of the many mirror sites.
162
163 You always should try to use the latest official release.  Older
164 versions might not have all the features GNU libc could use.  It is
165 known that on most platforms compilers earlier than 2.7.2.3 fail so
166 at least use this version.
167
168
169 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
170 [Q3]    ``When starting `make' I get only errors messages.
171           What's wrong?''
172
173 [A3] {UD} You definitely need GNU make to translate GNU libc.  No
174 other make program has the needed functionality.
175
176 Versions before 3.74 have bugs which prevent correct execution so you
177 should upgrade to the latest version before starting the compilation.
178
179
180 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
181 [Q4]    ``After I changed configure.in I get `Autoconf version X.Y.
182           or higher is required for this script'.  What can I do?''
183
184 [A4] {UD} You have to get the specified autoconf version (or a later)
185 from your favourite mirror of prep.ai.mit.edu.
186
187
188 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
189 [Q5]    ``Do I need a special linker or archiver?''
190
191 [A5] {UD} If your native versions are not too buggy you can probably
192 work with them.  But GNU libc works best with GNU binutils.
193
194 On systems where the native linker does not support weak symbols you
195 will not get a really ISO C compliant C library.  Generally speaking
196 you should use the GNU binutils if they provide at least the same
197 functionality as your system's tools.
198
199 Always get the newest release of GNU binutils available.
200 Older releases are known to have bugs that affect building the GNU C
201 Library.
202
203
204 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
205 [Q6]    ``Do I need some more things to compile GNU C Library?''
206
207 [A6] {UD} Yes, there are some more :-).
208
209 * GNU gettext; the GNU libc is internationalized and partly localized.
210   For bringing the messages for the different languages in the needed
211   form the tools from the GNU gettext package are necessary.  See
212   ftp://prep.ai.mit.edu/pub/gnu or better any mirror site.
213
214 * lots of diskspace (for i?86-linux this means, e.g., ~170MB; for ppc-linux
215   even ~200MB).
216
217   You should avoid compiling on a NFS mounted device.  This is very
218   slow.
219
220 * plenty of time (approx 1h for i?86-linux on i586@133 or 2.5h on
221   i486@66 or 4.5h on i486@33), both for shared and static only).
222   Multiply this by 1.5 or 2.0 if you build profiling and/or the highly
223   optimized version as well.  For Hurd systems times are much higher.
224
225   For Atari Falcon (Motorola 68030 @ 16 Mhz, 14 Mb memory) James Troup
226   <J.J.Troup@comp.brad.ac.uk> reports for a full build (shared, static,
227   and profiled) a compile time of 45h34m.
228
229   For Atari TT030 (Motorola 68030 @ 32 Mhz, 34 Mb memory) (full build)
230   a compile time of 22h48m.
231
232   If you have some more measurements let me know.
233
234 * When compiling for Linux:
235
236   + the header files of the Linux kernel must be available in the
237     search path of the CPP as <linux/*.h> and <asm/*.h>.
238
239 * Some files depend on special tools.  E.g., files ending in .gperf
240   need a `gperf' program.  The GNU version (part of libg++) is known
241   to work while some vendor versions do not.
242
243   You should not need these tools unless you change the source files.
244
245 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
246 [Q7]    ``When I run `nm -u libc.so' on the produced library I still
247           find unresolved symbols?  Can this be ok?''
248
249 [A7] {UD} Yes, this is ok.  There can be several kinds of unresolved
250 symbols:
251
252 * magic symbols automatically generated by the linker.  Names are
253   often like __start_* and __stop_*
254
255 * symbols starting with _dl_* come from the dynamic linker
256
257 * symbols resolved by using libgcc.a
258   (__udivdi3, __umoddi3, or similar)
259
260 * weak symbols, which need not be resolved at all
261   (currently fabs among others; this gets resolved if the program
262    is linked against libm, too.)
263
264 Generally, you should make sure you find a real program which produces
265 errors while linking before deciding there is a problem.
266
267
268 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
269 [Q8]    ``Can I replace the libc on my Linux system with GNU libc?''
270
271 [A8] {UD} You cannot replace any existing libc for Linux with GNU
272 libc.  There are different versions of C libraries and you can run
273 libcs with different major version independently.
274
275 For Linux there are today two libc versions:
276         libc-4          old a.out libc
277         libc-5          current ELF libc
278
279 GNU libc will have the major number 6 and therefore you can have this
280 additionally installed.  For more information consult documentation for
281 shared library handling.  The Makefiles of GNU libc will automatically
282 generate the needed symbolic links which the linker will use.
283
284
285 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
286 [Q9]    ``I expect GNU libc to be 100% source code compatible with
287           the old Linux based GNU libc.  Why isn't it like this?''
288
289 [A9] {DMT,UD} Not every extension in Linux libc's history was well
290 thought-out.  In fact it had a lot of problems with standards compliance
291 and with cleanliness.  With the introduction of a new version number these
292 errors now can be corrected.  Here is a list of the known source code
293 incompatibilities:
294
295 * _GNU_SOURCE: glibc does not automatically define _GNU_SOURCE.  Thus,
296   if a program depends on GNU extensions or some other non-standard
297   functionality, it is necessary to compile it with C compiler option
298   -D_GNU_SOURCE, or better, to put `#define _GNU_SOURCE' at the beginning
299   of your source files, before any C library header files are included.
300   This difference normally manifests itself in the form of missing
301   prototypes and/or data type definitions.  Thus, if you get such errors,
302   the first thing you should do is try defining _GNU_SOURCE and see if
303   that makes the problem go away.
304
305   For more information consult the file `NOTES' part of the GNU C
306   library sources.
307
308 * reboot(): GNU libc sanitizes the interface of reboot() to be more
309   compatible with the interface used on other OSes.  In particular,
310   reboot() as implemented in glibc takes just one argument.  This argument
311   corresponds to the third argument of the Linux reboot system call.
312   That is, a call of the form reboot(a, b, c) needs to be changed into
313   reboot(c).
314      Beside this the header <sys/reboot.h> defines the needed constants
315   for the argument.  These RB_* constants should be used instead of the
316   cryptic magic numbers.
317
318 * swapon(): the interface of this function didn't changed, but the
319   prototype is in a separate header file <sys/swap.h>.  For the additional
320   argument of swapon() you should use the SWAP_* constants from
321   <linux/swap.h>, which get defined when <sys/swap.h> is included.
322
323 * errno: If a program uses variable "errno", then it _must_ include header
324   file <errno.h>.  The old libc often (erroneously) declared this variable
325   implicitly as a side-effect of including other libc header files.  glibc
326   is careful to avoid such namespace pollution, which, in turn, means that
327   you really need to include the header files that you depend on.  This
328   difference normally manifests itself in the form of the compiler
329   complaining about the references of the undeclared symbol "errno".
330
331 * Linux-specific syscalls: All Linux system calls now have appropriate
332   library wrappers and corresponding declarations in various header files.
333   This is because the syscall() macro that was traditionally used to
334   work around missing syscall wrappers are inherently non-portable and
335   error-prone.  The following tables lists all the new syscall stubs,
336   the header-file declaring their interface and the system call name.
337
338        syscall name:    wrapper name:   declaring header file:
339        -------------    -------------   ----------------------
340        bdflush          bdflush         <sys/kdaemon.h>
341        create_module    create_module   <sys/module.h>
342        delete_module    delete_module   <sys/module.h>
343        get_kernel_syms  get_kernel_syms <sys/module.h>
344        init_module      init_module     <sys/module.h>
345        syslog           ksyslog_ctl     <sys/klog.h>
346
347 * lpd: Older versions of lpd depend on a routine called _validuser().
348   The library does not provide this function, but instead provides
349   __ivaliduser() which has a slightly different interfaces.  Simply
350   upgrading to a newer lpd should fix this problem (e.g., the 4.4BSD
351   lpd is known to be working).
352
353 * resolver functions/BIND: like on many other systems the functions of
354   the resolver library are not included in the libc itself.  There is
355   a separate library libresolv.  If you find some symbols starting with
356   `res_*' undefined simply add -lresolv to your call of the linker.
357
358 * the `signal' function's behaviour corresponds to the BSD semantic and
359   not the SysV semantic as it was in libc-5.  The interface on all GNU
360   systems shall be the same and BSD is the semantic of choice.  To use
361   the SysV behaviour simply use `sysv_signal', or define _XOPEN_SOURCE.
362   See question 32 for details.
363
364
365 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
366 [Q10]   ``Why does getlogin() always return NULL on my Linux box?''
367
368 [A10] {UD} The GNU C library has a format for the UTMP and WTMP file
369 which differs from what your system currently has.  It was extended to
370 fulfill the needs of the next years when IPv6 is introduced.  So the
371 record size is different, fields might have a different position and
372 so reading the files written by functions from the one library cannot
373 be read by functions from the other library.  Sorry, but this is what
374 a major release is for.  It's better to have a cut now than having no
375 means to support the new techniques later.
376
377 {MK} There is however a (partial) solution for this problem.  Please
378 take a look at the file `README.utmpd'.
379
380
381 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
382 [Q11]   ``Where are the DST_* constants found in <sys/time.h> on many
383           systems?''
384
385 [A11] {UD} These constants come from the old BSD days and are not used
386 today anymore (even the Linux based glibc does not implement the handling
387 although the constants are defined).
388
389 Instead GNU libc contains the zone database handling and compatibility
390 code for POSIX TZ environment variable handling.
391
392
393 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
394 [Q12]   ``The `gencat' utility cannot process the input which are
395           successfully used on my Linux libc based system.  Why?''
396
397 [A12] {UD} Unlike the author of the `gencat' program which is distributed
398 with Linux libc I have read the underlying standards before writing the
399 code.  It is completely compatible with the specification given in
400 X/Open Portability Guide.
401
402 To ease the transition from the Linux version some of the non-standard
403 features are also present in the `gencat' program of GNU libc.  This
404 mainly includes the use of symbols for the message number and the automatic
405 generation of header files which contain the needed #defines to map the
406 symbols to integers.
407
408 Here is a simple SED script to convert at least some Linux specific
409 catalog files to the XPG4 form:
410
411 -----------------------------------------------------------------------
412 # Change catalog source in Linux specific format to standard XPG format.
413 # Ulrich Drepper <drepper@cygnus.com>, 1996.
414 #
415 /^\$ #/ {
416   h
417   s/\$ #\([^ ]*\).*/\1/
418   x
419   s/\$ #[^ ]* *\(.*\)/\$ \1/
420 }
421
422 /^# / {
423   s/^# \(.*\)/\1/
424   G
425   s/\(.*\)\n\(.*\)/\2 \1/
426 }
427 -----------------------------------------------------------------------
428
429
430 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
431 [Q13]   ``How do I configure GNU libc so that the essential libraries
432           like libc.so go into /lib and the other into /usr/lib?''
433
434 [A13] {UD,AJ} Like all other GNU packages GNU libc is configured to
435 use a base directory and install all files relative to this.  If you
436 intend to really use GNU libc on your system this base directory is
437 /usr.  I.e., you run
438         configure --prefix=/usr <other_options>
439
440 Some systems like Linux have a filesystem standard which makes a
441 difference between essential libraries and others.  Essential
442 libraries are placed in /lib because this directory is required to be
443 located on the same disk partition as /.  The /usr subtree might be
444 found on another partition/disk.
445
446 To install the essential libraries which come with GNU libc in /lib
447 one must explicitly tell this (except on Linux, see below).  Autoconf
448 has no option for this so you have to use the file where all user
449 supplied additional information should go in: `configparms' (see the
450 `INSTALL' file).  Therefore the `configparms' file should contain:
451
452 slibdir=/lib
453 sysconfdir=/etc
454
455 The first line specifies the directory for the essential libraries,
456 the second line the directory for file which are by tradition placed
457 in a directory named /etc.
458
459 No rule without an exception: If you configure for Linux with
460 --prefix=/usr, then slibdir and sysconfdir will automatically be
461 defined as stated above.
462
463
464 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
465 [Q14]   ``When linking with the new libc I get unresolved symbols
466           `crypt' and `setkey'.  Why aren't these functions in the
467           libc anymore?''
468
469 [A14] {UD} Remember the US restrictions of exporting cryptographic
470 programs and source code.  Until this law gets abolished we cannot
471 ship the cryptographic function together with the libc.
472
473 But of course we provide the code and there is an very easy way to use
474 this code.  First get the extra package.  People in the US may get it
475 from the same place they got the GNU libc from.  People outside the US
476 should get the code from ftp://ftp.ifi.uio.no/pub/gnu, or another
477 archive site outside the USA.  The README explains how to install the
478 sources.
479
480 If you already have the crypt code on your system the reason for the
481 failure is probably that you failed to link with -lcrypt.  The crypto
482 functions are in a separate library to make it possible to export GNU
483 libc binaries from the US.
484
485
486 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
487 [Q15]   ``What are these `add-ons'?''
488
489 [A15] {UD} To avoid complications with export rules or external source
490 code some optional parts of the libc are distributed as separate
491 packages (e.g., the crypt package, see Q14).
492
493 To ease the use as part of GNU libc the installer just has to unpack
494 the package and tell the configuration script about these additional
495 subdirectories using the --enable-add-ons option.  When you add the
496 crypt add-on you just have to use
497
498         configure --enable-add-ons=crypt,XXX ...
499
500 where XXX are possible other add-ons and ... means the rest of the
501 normal option list.
502
503 You can use add-ons also to overwrite some files in glibc.  The add-on
504 system dependent subdirs are search first.  It is also possible to add
505 banner files (use a file named `Banner') or create shared libraries.
506
507 Using add-ons has the big advantage that the makefiles of the GNU libc
508 can be used.  Only some few stub rules must be written to get
509 everything running.  Even handling of architecture dependent
510 compilation is provided.  The GNU libc's sysdeps/ directory shows how
511 to use this feature.
512
513
514 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
515 [Q16]   ``When I use GNU libc on my Linux system by linking against
516           to libc.so which comes with glibc all I get is a core dump.''
517
518 [A16] {UD} It is not enough to simply link against the GNU libc
519 library itself.  The GNU C library comes with its own dynamic linker
520 which really conforms to the ELF API standard.  This dynamic linker
521 must be used.
522
523 Normally this is done by the compiler.  The gcc will use
524
525         -dynamic-linker /lib/ld-linux.so.1
526
527 unless the user specifies her/himself a -dynamic-linker argument.  But
528 this is not the correct name for the GNU dynamic linker.  The correct
529 name is /lib/ld.so.1 which is the name specified in the SVr4 ABi.
530
531 To change your environment to use GNU libc for compiling you need to
532 change the `specs' file of your gcc.  This file is normally found at
533
534         /usr/lib/gcc-lib/<arch>/<version>/specs
535
536 In this file you have to change a few things:
537
538 - change `ld-linux.so.1' to `ld.so.1' (or to ld-linux.so.2, see below)
539
540 - remove all expression `%{...:-lgmon}';  there is no libgmon in glibc
541
542 - fix a minor bug by changing %{pipe:-} to %|
543
544
545 Things are getting a bit more complicated if you have GNU libc
546 installed in some other place than /usr, i.e., if you do not want to
547 use it instead of the old libc.  In this case the needed startup files
548 and libraries are not found in the regular places.  So the specs file
549 must tell the compiler and linker exactly what to use.  Here is what
550 the gcc-2.7.2 specs file should look like when GNU libc is installed at
551 /usr:
552
553 -----------------------------------------------------------------------
554 *asm:
555 %{V} %{v:%{!V:-V}} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*}
556
557 *asm_final:
558 %|
559
560 *cpp:
561 %{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} %{!m386:-D__i486__} %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
562
563 *cc1:
564 %{profile:-p}
565
566 *cc1plus:
567
568
569 *endfile:
570 %{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s
571
572 *link:
573 -m elf_i386 %{shared:-shared}   %{!shared:     %{!ibcs:       %{!static:        %{rdynamic:-export-dynamic}     %{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2}}  %{static:-static}}}
574
575 *lib:
576 %{!shared: %{pthread:-lpthread}         %{profile:-lc_p} %{!profile: -lc}}
577
578 *libgcc:
579 -lgcc
580
581 *startfile:
582 %{!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}
583
584 *switches_need_spaces:
585
586
587 *signed_char:
588 %{funsigned-char:-D__CHAR_UNSIGNED__}
589
590 *predefines:
591 -D__ELF__ -Dunix -Di386 -Dlinux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386)
592
593 *cross_compile:
594 0
595
596 *multilib:
597 . ;
598
599 -----------------------------------------------------------------------
600
601 The above is currently correct for ix86/Linux.  Because of
602 compatibility issues on this platform the dynamic linker must have
603 a different name: ld-linux.so.2.  So you have to replace
604
605         %{!dynamic-linker:-dynamic-linker=/home/gnu/lib/ld-linux.so.2}
606 by
607         %{!dynamic-linker:-dynamic-linker=/home/gnu/lib/ld.so.1}
608
609 in the above example specs file to make it work for other systems.
610
611 Version 2.7.2.3 does and future versions of GCC will automatically
612 provide the correct specs.
613
614
615 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
616 [Q17]   ``Looking through the shared libc file I haven't found the
617           functions `stat', `lstat', `fstat', and `mknod' and while
618           linking on my Linux system I get error messages.  How is
619           this supposed to work?''
620
621 [A17] {RM} Believe it or not, stat and lstat (and fstat, and mknod)
622 are supposed to be undefined references in libc.so.6!  Your problem is
623 probably a missing or incorrect /usr/lib/libc.so file; note that this
624 is a small text file now, not a symlink to libc.so.6.  It should look
625 something like this:
626
627 GROUP ( libc.so.6 ld.so.1 libc.a )
628
629 or in ix86/Linux and alpha/Linux:
630
631 GROUP ( libc.so.6 ld-linux.so.2 libc.a )
632
633
634 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
635 [Q18]   ``The prototypes for `connect', `accept', `getsockopt',
636           `setsockopt', `getsockname', `getpeername', `send',
637           `sendto', and `recvfrom' are different in GNU libc from
638           any other system I saw.  This is a bug, isn't it?''
639
640 [A18] {UD} No, this is no bug.  This version of the GNU libc already
641 follows the Single Unix specifications (and I think the POSIX.1g
642 draft which adopted the solution).  The type for parameter describing
643 a size is now `socklen_t', a new type.
644
645
646 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
647 [Q19]   ``My XXX kernel emulates a floating-point coprocessor for me.
648           Should I enable --with-fp?''
649
650 [A19] {UD} As `configure --help' shows the default value is `yes' and
651 this should not be changed unless the FPU instructions would be
652 invalid.  I.e., an emulated FPU is for the libc as good as a real one.
653
654
655 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
656 [Q20]   ``How can I compile gcc 2.7.2.1 from the gcc source code using
657           glibc 2.x?
658
659 [A20] {AJ} There's only correct support for glibc 2.0.x in gcc 2.7.2.3
660 or later.  You should get at least gcc 2.7.2.3.  All previous versions
661 had problems with glibc support.
662
663
664 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
665 [Q21]    ``On Linux I've got problems with the declarations in Linux
666            kernel headers.''
667
668 [A21] {UD,AJ} On Linux, the use of kernel headers is reduced to a very
669 minimum.  Besides giving Linus the possibility to change the headers
670 more freely it has another reason: user level programs now do not
671 always use the same types like the kernel does.
672
673 I.e., the libc abstracts the use of types.  E.g., the sigset_t type is
674 in the kernel 32 or 64 bits wide.  In glibc it is 1024 bits wide, in
675 preparation for future development.  The reasons are obvious: we don't
676 want to have a new major release when the Linux kernel gets these
677 functionality. Consult the headers for more information about the changes.
678
679 Therefore you shouldn't include Linux kernel header files directly if
680 glibc has defined a replacement. Otherwise you might get undefined
681 results because of type conflicts.
682
683
684 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
685 [Q22]   ``When I try to compile code which uses IPv6 header and
686           definitions on my Linux 2.x.y system I am in trouble.
687           Nothing seems to work.''
688
689 [A22] {UD} The problem is that the IPv6 development still has not reached
690 a point where it is stable.  There are still lots of incompatible changes
691 made and the libc headers have to follow.
692
693 Currently (as of 970401) according to Philip Blundell <philb@gnu.ai.mit.edu>
694 the required kernel version is 2.1.30.
695
696
697 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
698 [Q23]   ``When compiling GNU libc I get lots of errors saying functions
699           in glibc are duplicated in libgcc.''
700
701 [A23] {EY} This is *exactly* the same problem that I was having.  The
702 problem was due to the fact that the autoconfigure didn't correctly
703 detect that linker flag --no-whole-archive was supported in my linker.
704 In my case it was because I had run ./configure with bogus CFLAGS, and
705 the test failed.
706
707 One thing that is particularly annoying about this problem is that
708 once this is misdetected, running configure again won't fix it unless
709 you first delete config.cache.
710
711 {UD} Starting with glibc-2.0.3 there should be a better test to avoid
712 some problems of this kind.  The setting of CFLAGS is checked at the
713 very beginning and if it is not usable `configure' will bark.
714
715
716
717 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
718 [Q24]   ``I have set up /etc/nis.conf, and the Linux libc 5 with NYS
719           works great.  But the glibc NIS+ doesn't seem to work.''
720
721 [A24] The glibc NIS+ implementation uses a /var/nis/NIS_COLD_START
722 file for storing information about the NIS+ server and their public
723 keys, because the nis.conf file do not contain all necessary
724 information.  You have to copy a NIS_COLD_START file from a Solaris
725 client (the NIS_COLD_START file is byte order independend) or generate
726 it new with nisinit from the nis-tools (look at
727 http://www-vt.uni-paderborn.de/~kukuk/linux/nisplus.html).
728
729
730 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
731 [Q25]   ``After installing glibc name resolving doesn't work properly.''
732
733 [A25] {AJ} You  probable should read the manual section describing
734 ``nsswitch.conf'' (just type `info libc "NSS Configuration File"').
735 The NSS configuration file is usually the culprit.
736
737
738 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
739 [Q26]   ``I have /usr/include/net and /usr/include/scsi as symlinks
740           into my Linux source tree.  Is that wrong?''
741
742 [A26] {PB} This was necessary for libc5, but is not correct when using
743 glibc.  Including the kernel header files directly in user programs
744 usually does not work (see Q21).  glibc provides its own <net/*> and
745 <scsi/*> header files to replace them, and you may have to remove any
746 symlink that you have in place before you install glibc.  However,
747 /usr/include/asm and /usr/include/linux should remain as they were.
748
749
750 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
751 [Q27]   ``Programs like `logname', `top', `uptime' `users', `w' and
752           `who', show incorrect information about the (number of)
753           users on my system.  Why?''
754
755 [A27] {MK} See Q10.
756
757
758 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
759 [Q28]   ``After upgrading to a glibc 2.1 with symbol versioning I get
760           errors about undefined symbols.  What went wrong?''
761
762 [A28] {AJ} In a versioned libc a lot of symbols are now local that
763 have been global symbols in previous versions. When defining a extern
764 variable both in a user program and extern in the libc the links
765 resolves this to only one reference - the one in the library. The
766 problem is caused by either wrong program code or tools. In no case
767 the global variables from libc should be used by any program. Since
768 these reference are now local, you might see a message like:
769
770 "msgfmt: error in loading shared libraries: : undefined symbol: _nl_domain_bindings"
771
772 The only way to fix this is to recompile your program. Sorry, that's
773 the price you might have to pay once for quite a number of advantages
774 with symbol versioning.
775
776
777 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
778 [Q29]   ``I don't include any kernel header myself but still the
779           compiler complains about type redeclarations of types in the
780           kernel headers.''
781
782 [A29] {UD} The kernel headers before Linux 2.1.61 don't work correctly with
783 glibc since they pollute the name space in a not acceptable way.  Compiling
784 C programs is possible in most cases but especially C++ programs have (due
785 to the change of the name lookups for `struct's) problem.  One prominent
786 example is `struct fd_set'.
787
788 There might be some more problems left but 2.1.61 fixes some of the known
789 ones.  See the BUGS file for other known problems.
790
791
792 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
793 [Q30]   ``When I start the program XXX after upgrading the library
794           I get
795             XXX: Symbol `_sys_errlist' has different size in shared object, consider re-linking
796           Why?  What to do?''
797
798 [A30] {UD} As the message says, relink the binary.  The problem is that
799 very few symbols from the library can change in size and there is no way
800 to avoid this.  _sys_errlist is a good example.  Occasionally there are
801 new error numbers added to the kernel and this must be reflected at user
802 level.
803
804 But this does not mean all programs are doomed once such a change is
805 necessary.  Such symbols should normally not be used at all.  There are
806 mechanisms to avoid using them.  In the case of _sys_errlist, there is the
807 strerror() function which should _always_ be used instead.  So the correct
808 fix is to rewrite that part of the application.
809
810 In some situations (especially when testing a new library release) it might
811 be possible that such a symbol size change slipped in though it must not
812 happen.  So in case of doubt report such a warning message as a problem.
813
814
815 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
816 [Q31]   ``What's the problem with configure --enable-omitfp?''
817
818 [A31] {AJ} When configuring with --enable-omitfp the libraries are build
819 without frame pointers. Some compilers produce in this situation buggy
820 code and therefore we don't advise using it at the moment.
821
822 If you use --enable-omitfp, you're on your own. If you encounter
823 problems with a library that was build this way, I'll advise you to
824 rebuild the library without --enable-omitfp.  If the problem vanishes
825 consider tracking the problem down and report it as compiler failure.
826
827 Since a library build with --enable-omitfp is undebuggable, a
828 debuggable library is also build - you can recognize it by the suffix
829 "_g" to the library names.
830
831 The compilation of this extra libraries and the compiler optimizations
832 slow down the build process and need more disk space.
833
834
835 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
836 [Q32]   ``Why don't signals interrupt system calls anymore?''
837
838 [A32] {ZW} By default GNU libc uses the BSD semantics for signal(),
839 unlike Linux libc 5 which used System V semantics.  This is partially
840 for compatibility with other systems and partially because the BSD
841 semantics tend to make programming with signals easier.
842
843 There are three differences:
844
845 * BSD-style signals that occur in the middle of a system call do not
846   affect the system call; System V signals cause the system call to
847   fail and set errno to EINTR.
848
849 * BSD signal handlers remain installed once triggered.  System V signal
850   handlers work only once, so one must reinstall them each time.
851
852 * A BSD signal is blocked during the execution of its handler.  In other
853   words, a handler for SIGCHLD (for example) does not need to worry about
854   being interrupted by another SIGCHLD.  It may, however, be interrrupted
855   by other signals.
856
857 There is general consensus that for `casual' programming with signals, the
858 BSD semantics are preferable.  You don't need to worry about system calls
859 returning EINTR, and you don't need to worry about the race conditions
860 associated with one-shot signal handlers.
861
862 If you are porting an old program that relies on the old semantics, you can
863 quickly fix the problem by changing signal() to sysv_signal() throughout.
864 Alternatively, define _XOPEN_SOURCE before including <signal.h>.
865
866 For new programs, the sigaction() function allows you to specify precisely
867 how you want your signals to behave.  All three differences listed above are
868 individually switchable on a per-signal basis with this function.
869
870 If all you want is for one specific signal to cause system calls to fail
871 and return EINTR (for example, to implement a timeout) you can do this with
872 siginterrupt().
873
874
875 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
876 [Q33]   ``I've got errors compiling code that uses certain string
877           functions.  Why?''
878
879 [A33] {AJ} glibc 2.1 has the much asked for optimized string
880 functions that are faster than the normal library functions. Some of
881 the functions are implemented as inline functions and others as
882 macros.
883 The optimized string functions are only used when compiling with
884 optimizations (-O1 or higher). The behaviour can be changed with two
885 feature macros:
886 * __NO_STRING_INLINES: Don't use string optimizations.
887 * __USE_STRING_INLINES: Use also assembler inline functions (might
888   increase code use dramatically).
889
890 Since some of these string functions are now additionally defined as
891 macros, code like "char *strncpy();" doesn't work anymore (and is even
892 unneccessary since <string.h> has the necessary declarations). Either
893 change your code or define __NO_STRING_INLINES.
894
895 {UD} Another problem in this area is that the gcc still has problems on
896 machines with very few registers (e.g., ix86).  The inline assembler
897 code sometimes requires many/all registers and the register allocator
898 cannot handle these situation in all cases.
899
900 If a function is also defined as a macro in the libc headers one can prevent
901 the use of the macro easily.  E.g., instead of
902
903         cp = strcpy (foo, "lkj");
904
905 one can write
906
907         cp = (strcpy) (foo, "lkj");
908
909 Using this method one can avoid using the optimizations for selected
910 function calls.
911
912
913 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
914 \f
915 Answers were given by:
916 {UD} Ulrich Drepper, <drepper@cygnus.com>
917 {DMT} David Mosberger-Tang, <davidm@AZStarNet.com>
918 {RM} Roland McGrath, <roland@gnu.org>
919 {HJL} H.J. Lu, <hjl@gnu.org>
920 {AJ} Andreas Jaeger, <aj@arthur.rhein-neckar.de>
921 {EY} Eric Youngdale, <eric@andante.jic.com>
922 {PB} Phil Blundell, <Philip.Blundell@pobox.com>
923 {MK} Mark Kettenis, <kettenis@phys.uva.nl>
924 {ZW} Zack Weinberg, <zack@rabi.phys.columbia.edu>
925 \f
926 Local Variables:
927  mode:text
928 End: