This is the mail archive of the
libc-hacker@cygnus.com
mailing list for the glibc project.
FAQ patch
- To: libc-alpha@cygnus.com
- Subject: FAQ patch
- From: Daniel Jacobowitz <drow@false.org>
- Date: Sun, 31 Jan 1999 21:00:22 -0500
- Mail-Followup-To: libc-alpha@cygnus.com
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