Fri May 10 18:36:14 1996 Roland McGrath <roland@delasyd.gnu.ai.mit.edu>
[kopensolaris-gnu/glibc.git] / 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: