Fri May 10 18:36:14 1996 Roland McGrath <roland@delasyd.gnu.ai.mit.edu>
authorroland <roland>
Fri, 10 May 1996 22:55:08 +0000 (22:55 +0000)
committerroland <roland>
Fri, 10 May 1996 22:55:08 +0000 (22:55 +0000)
* FAQ: New file contributed by drepper.

FAQ [new file with mode: 0644]

diff --git a/FAQ b/FAQ
new file mode 100644 (file)
index 0000000..9334108
--- /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
+\f
+~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
+[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.
+
+
+~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
+
+
+\f
+Answers were given by:
+{UD} Ulrich Drepper, <drepper@cygnus.com>
+
+\f
+Local Variables:
+ mode:text
+End: