FAQ

   1                 Frequently Asked Question on GNU C Library
   2
   3 As every FAQ this one also tries to answer the questions the user
   4 might when using the pacakge.  Please make sure you read this before
   5 sending questions/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 question which you think might be worth answered in
  15 this document let me know.
  16
  17                                                   --drepper@cygnus.com
  18 \f
  19 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
  20 [Q1]    ``What systems the GNU C Library runs on?''
  21
  22 [A1] {UD} This is difficult to answer.  The file `README' lists the
  23 architectures GNU libc is known to run *at some time*.  This does not
  24 mean that it still can be compiled and run on them in the moment.
  25
  26 The systems glibc is known to work on in the moment and most probably
  27 in the future are:
  28
  29         *-*-gnu                 GNU Hurd
  30         i[3456]86-*-linux       Linux-2.0 on Intel
  31
  32 Other Linux platforms are also on the way to be supported but I need
  33 some success reports first.
  34
  35 If you have a system not listed above (or in the `README' file) and
  36 you are really interested in porting it, contact
  37
  38         Roland McGrath          <roland@gnu.ai.mit.edu>
  39 or      Ulrich Drepper          <drepper@cygnus.com>
  40
  41
  42 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
  43 [Q2]    ``What compiler do I need to translate GNU libc?''
  44
  45 [A2] {UD} It is (almost) impossible to compile GNU C Library using a
  46 different compiler than GNU CC.  A lot of extensions of GNU CC are
  47 used to increase the portability and speed.
  48
  49 But this does not mean you have to use GNU CC for using the GNU C
  50 Library.  In fact you should be able to use the native C compiler
  51 because the success only depends on the binutils: the linker and
  52 archiver.
  53
  54 The GNU CC is found like all other GNU packages on
  55         ftp://prep.ai.mit.edu/pub/gnu
  56 or better one of the many mirrors.
  57
  58 You always should try to use the latest official release.  Older
  59 versions might not have all the features GNU libc could use.
  60
  61
  62 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
  63 [Q3]    ``When starting make I get only errors messages.
  64           What's wrong?''
  65
  66 [A3] {UD} You definitely need GNU make to translate GNU libc.  No
  67 other make program has the needed functionality.
  68
  69 Versions before 3.74 have bugs which prevent correct execution so you
  70 should upgrade to the latest version before starting the compilation.
  71
  72
  73 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
  74 [Q4]    ``After I changed configure.in I get `Autoconf version X.Y.
  75           or higher is required for this script'.  What can I do?''
  76
  77 [A4] {UD} You have to get the specified autoconf version (or a later)
  78 from your favourite mirror of prep.ai.mit.edu.
  79
  80
  81 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
  82 [Q5]    ``Do I need a special linker or archiver?''
  83
  84 [A5] {UD} If your native versions are not too buggy you can work with
  85 them.  But GNU libc works best with GNU binutils.
  86
  87 On systems where the native linker does not support weak symbols you
  88 will not get a really ISO C compliant C library.  Generally speaking
  89 you should use the GNU binutils if they provide at least the same
  90 functionality as your system's tools.
  91
  92
  93 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
  94 [Q6]    ``Do I need some more things to compile GNU C Library?''
  95
  96 [A6] {UD} Yes, there are some more :-).
  97
  98 * lots of diskspace (for i386-linux this means, e.g., ~70MB)
  99
 100   You should avoid compiling on a NFS mounted device.  This is very
 101   slow.
 102
 103 * plenty of time (approx 1h for i386-linux on i586@133 or 2.5h or
 104   i486@66).
 105
 106   If you have some more interested measurements let me know.
 107
 108
 109 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
 110 [Q7]    ``When I run `nm libc.so|grep " U "' on the produced library
 111           I still find unresolved symbols?  Can this be ok?''
 112
 113 [A7] {UD} Yes, this is ok.  There can be several kinds of unresolved
 114 symbols:
 115
 116 * magic symbols automatically generated by the linker.  Names are
 117   often like __start_* and __stop_*-
 118
 119 * symbols resolved by using libgcc.a
 120   (__udivdi3, __umoddi3, or similar)
 121
 122 * weak symbols, which need not be resolved at all
 123   (currently fabs among others; this gets resolved if the program
 124    is linked against libm, too.)
 125
 126 Generally, you should make sure you find a real program which produces
 127 errors while linking.
 128
 129
 130 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
 131
 132
 133 \f
 134 Answers were given by:
 135 {UD} Ulrich Drepper, <drepper@cygnus.com>
 136
 137 \f
 138 Local Variables:
 139  mode:text
 140 End: