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>.

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: