This is the mail archive of the libc-hacker@cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

FAQ patch


I went over the first piece of FAQ.in tonight, and fixed a few minor
grammatical nits.  Take this patch with a grain of salt.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|     CMU, CS class of 2002      |
|   Debian GNU/Linux Developer    __   Part-Time Systems Programmer  |
|         dan@debian.org         |  |        drow@cs.cmu.edu         |
\--------------------------------/  \--------------------------------/
Index: FAQ.in
===================================================================
RCS file: /glibc/cvsfiles/libc/FAQ.in,v
retrieving revision 1.59
diff -u -r1.59 FAQ.in
--- FAQ.in	1999/01/29 07:55:33	1.59
+++ FAQ.in	1999/02/01 01:52:46
@@ -69,7 +69,7 @@
 ??	When I try to compile glibc I get only error messages.
 	What's wrong?
 
-{UD} You definitely need GNU make to translate GNU libc.  No other make
+{UD} You definitely need GNU make to build GNU libc.  No other make
 program has the needed functionality.
 
 We recommend version GNU make version 3.75 or 3.77.  Versions before 3.75
@@ -168,7 +168,7 @@
 problems on kernels that are older than the kernel headers used.  The other
 way round (compiling the GNU C library with old kernel headers and running
 on a recent kernel) does not necessarily work.  For example you can't use
-new kernel features when using old kernel headers for compiling the GNU C
+new kernel features if you used old kernel headers to compile the GNU C
 library.
 
 {ZW} Even if you are using a 2.0 kernel on your machine, we recommend you
@@ -282,18 +282,18 @@
 without --enable-omitfp.  If the problem vanishes consider tracking the
 problem down and report it as compiler failure.
 
-Since a library build with --enable-omitfp is undebuggable on most systems,
-debuggable libraries are also built - you can use it by appending "_g" to
+Since a library built with --enable-omitfp is undebuggable on most systems,
+debuggable libraries are also built - you can use them by appending "_g" to
 the library names.
 
 The compilation of these extra libraries and the compiler optimizations slow
 down the build process and need more disk space.
 
-??	I get failures during `make check'.  What shall I do?
+??	I get failures during `make check'.  What should I do?
 
-{AJ} The testsuite should compile and run cleanly on your system, every
-failure should be looked into.  Depending on the failure I wouldn't advise
-installing the library at all.
+{AJ} The testsuite should compile and run cleanly on your system; every
+failure should be looked into.  Depending on the failures, you probably
+should not install the library at all.
 
 You should consider using the `glibcbug' script to report the failure,
 providing as much detail as possible.  If you run a test directly, please
@@ -303,9 +303,9 @@
 test in the sources.
 
 There are some failures which are not directly related to the GNU libc:
-- Some compiler produce buggy code.  The egcs 1.1 release should be ok.  gcc
-  2.8.1 might cause some failures, gcc 2.7.2.x is so buggy, that explicit
-  checks have been used so that you can't build with it.
+- Some compilers produce buggy code.  The egcs 1.1 release should be ok. 
+  gcc 2.8.1 might cause some failures, and gcc 2.7.2.x is so buggy, that
+  explicit checks have been used so that you can't build with it.
 - The kernel might have bugs.  For example on Linux/Alpha 2.0.34 the
   floating point handling has quite a number of bugs and therefore most of
   the test cases in the math subdirectory will fail.  Linux 2.2 has
@@ -318,15 +318,15 @@
 previous version of the GNU C library but the interface or the semantics of
 the function has been changed in the meantime.  For binary compatibility
 with the old library, a newer library needs to still have the old interface
-for old programs.  On the other hand new programs should use the new
+for old programs.  On the other hand, new programs should use the new
 interface.  Symbol versioning is the solution for this problem.  The GNU
-libc version 2.1 uses by default symbol versioning if the binutils support
-it.
+libc version 2.1 uses symbol versioning by default if the installed binutils
+supports it.
 
-We don't advise to build without symbol versioning since you lose binary
-compatibility if you do - for ever!  The binary compatibility you lose is
-not only against the previous version of the GNU libc (version 2.0) but also
-against future versions.
+We don't advise building without symbol versioning, since you lose binary
+compatibility - forever!  The binary compatibility you lose is not only
+against the previous version of the GNU libc (version 2.0) but also against
+all future versions.
 
 
 ? Installation and configuration issues

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]