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