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