diff options
Diffstat (limited to 'FAQ')
| -rw-r--r-- | FAQ | 140 |
1 files changed, 140 insertions, 0 deletions
diff --git a/FAQ b/FAQ new file mode 100644 index 0000000000..9334108afa --- /dev/null +++ b/FAQ @@ -0,0 +1,140 @@ + Frequently Asked Question on GNU C Library + +As every FAQ this one also tries to answer the questions the user +might when using the pacakge. Please make sure you read this before +sending questions/bug reports to the maintainers. + +The GNU C Library is very complex. The building process exploits the +features available in tools generally available. But many things can +only be done using GNU tools. Also the code is sometimes hard to +understand because it has to be portable but on the other hand must be +fast. But you need not understand the details to use GNU C Library. +This will only be necessary if you intend to contribute or change it. + +If you have any question which you think might be worth answered in +this document let me know. + + --drepper@cygnus.com + +~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ +[Q1] ``What systems the GNU C Library runs on?'' + +[A1] {UD} This is difficult to answer. The file `README' lists the +architectures GNU libc is known to run *at some time*. This does not +mean that it still can be compiled and run on them in the moment. + +The systems glibc is known to work on in the moment and most probably +in the future are: + + *-*-gnu GNU Hurd + i[3456]86-*-linux Linux-2.0 on Intel + +Other Linux platforms are also on the way to be supported but I need +some success reports first. + +If you have a system not listed above (or in the `README' file) and +you are really interested in porting it, contact + + Roland McGrath <roland@gnu.ai.mit.edu> +or Ulrich Drepper <drepper@cygnus.com> + + +~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ +[Q2] ``What compiler do I need to translate GNU libc?'' + +[A2] {UD} It is (almost) impossible to compile GNU C Library using a +different compiler than GNU CC. A lot of extensions of GNU CC are +used to increase the portability and speed. + +But this does not mean you have to use GNU CC for using the GNU C +Library. In fact you should be able to use the native C compiler +because the success only depends on the binutils: the linker and +archiver. + +The GNU CC is found like all other GNU packages on + ftp://prep.ai.mit.edu/pub/gnu +or better one of the many mirrors. + +You always should try to use the latest official release. Older +versions might not have all the features GNU libc could use. + + +~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ +[Q3] ``When starting make I get only errors messages. + What's wrong?'' + +[A3] {UD} You definitely need GNU make to translate GNU libc. No +other make program has the needed functionality. + +Versions before 3.74 have bugs which prevent correct execution so you +should upgrade to the latest version before starting the compilation. + + +~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ +[Q4] ``After I changed configure.in I get `Autoconf version X.Y. + or higher is required for this script'. What can I do?'' + +[A4] {UD} You have to get the specified autoconf version (or a later) +from your favourite mirror of prep.ai.mit.edu. + + +~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ +[Q5] ``Do I need a special linker or archiver?'' + +[A5] {UD} If your native versions are not too buggy you can work with +them. But GNU libc works best with GNU binutils. + +On systems where the native linker does not support weak symbols you +will not get a really ISO C compliant C library. Generally speaking +you should use the GNU binutils if they provide at least the same +functionality as your system's tools. + + +~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ +[Q6] ``Do I need some more things to compile GNU C Library?'' + +[A6] {UD} Yes, there are some more :-). + +* lots of diskspace (for i386-linux this means, e.g., ~70MB) + + You should avoid compiling on a NFS mounted device. This is very + slow. + +* plenty of time (approx 1h for i386-linux on i586@133 or 2.5h or + i486@66). + + If you have some more interested measurements let me know. + + +~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ +[Q7] ``When I run `nm libc.so|grep " U "' on the produced library + I still find unresolved symbols? Can this be ok?'' + +[A7] {UD} Yes, this is ok. There can be several kinds of unresolved +symbols: + +* magic symbols automatically generated by the linker. Names are + often like __start_* and __stop_*- + +* symbols resolved by using libgcc.a + (__udivdi3, __umoddi3, or similar) + +* weak symbols, which need not be resolved at all + (currently fabs among others; this gets resolved if the program + is linked against libm, too.) + +Generally, you should make sure you find a real program which produces +errors while linking. + + +~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ + + + +Answers were given by: +{UD} Ulrich Drepper, <drepper@cygnus.com> + + +Local Variables: + mode:text +End: |