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