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