aboutsummaryrefslogtreecommitdiff
path: root/FAQ
diff options
context:
space:
mode:
authorRoland McGrath <roland@gnu.org>1996-05-10 22:55:26 +0000
committerRoland McGrath <roland@gnu.org>1996-05-10 22:55:26 +0000
commitf8cac037eea3e928b0d5e0c17990b6996159eec8 (patch)
tree6a974750b859b185818d8f8b0763907f66fc8954 /FAQ
parent7cfb2d8be3d4ee24fbba14df7176fd13e7052205 (diff)
downloadglibc-f8cac037eea3e928b0d5e0c17990b6996159eec8.zip
glibc-f8cac037eea3e928b0d5e0c17990b6996159eec8.tar.gz
glibc-f8cac037eea3e928b0d5e0c17990b6996159eec8.tar.bz2
Fri May 10 18:36:14 1996 Roland McGrath <roland@delasyd.gnu.ai.mit.edu>
* FAQ: New file contributed by drepper. * time/Makefile (headers): Add timebits.h. * sysdeps/unix/sysv/linux/timebits.h: New file. * sysdeps/stub/timebits.h: New file. * time/time.h (CLK_TCK): Define to CLOCKS_PER_SEC. (CLOCKS_PER_SEC): Remove this macro. Instead #include <timebits.h>.
Diffstat (limited to 'FAQ')
-rw-r--r--FAQ140
1 files changed, 140 insertions, 0 deletions
diff --git a/FAQ b/FAQ
new file mode 100644
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
+
+~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
+[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: