diff options
Diffstat (limited to 'manual')
| -rw-r--r-- | manual/install.texi | 57 |
1 files changed, 29 insertions, 28 deletions
diff --git a/manual/install.texi b/manual/install.texi index a05114d..bfd1ca6 100644 --- a/manual/install.texi +++ b/manual/install.texi @@ -279,11 +279,12 @@ Version 3.76.1 seems OK but some people have reported problems. EGCS 1.1.1, 1.1 or 1.0.3 The GNU C library can only be compiled with the GNU C compiler family. -We recommend EGCS 1.0.3 or higher. GCC 2.8.1 and older versions of EGCS -may have problems, particularly on non-Intel architectures. GCC 2.7.x -has catastrophic bugs and cannot be used at all. (You can use GCC 2.7.x -to compile programs that use GNU libc, but you may have problems, -particularly with the math functions.) +As of the 2.1 release, EGCS 1.0.3 or higher is required. GCC 2.8.1 cannot +be used due to an incompatible implementation of some internal compiler +support routines; see the FAQ for details. GCC 2.7.x is simply too +buggy. You can use whatever compiler you like to compile programs that +use GNU libc, but be aware that both GCC 2.7 and 2.8 have bugs in their +floating-point support that may be triggered by the math library. On Alpha machines you need at least EGCS 1.1.1. Earlier versions don't work reliably. @@ -292,17 +293,17 @@ For PPC you might need some patches even on top of the last EGCS version. See the FAQ. @item -GNU @code{binutils} 2.9.1, or 2.9.1.0.16 +GNU @code{binutils} 2.9.1, 2.9.1.0.16, or later 2.9.1.0.x release You must use GNU binutils (as and ld) if you want to build a shared library. Even if you don't, we recommend you use them anyway. No one has tested compilation with non-GNU binutils in a long time. The quality of binutils releases has varied a bit recently. The bugs -are in obscure features, but glibc uses quite a few of those. -2.9.1 and 2.9.1.0.16 are known to work. Versions after -2.8.1.0.23 may or may not work. Older versions definitely don't. -2.9.1.0.16 is required on some platforms, like PPC and Arm. +are in obscure features, but glibc uses quite a few of those. 2.9.1, +2.9.1.0.16, and later 2.9.1.0.x releases are known to work. Versions +after 2.8.1.0.23 may or may not work. Older versions definitely don't. +2.9.1.0.16 or higher is required on some platforms, like PPC and Arm. For PPC you might need some patches even on top of the last binutils version. See the FAQ. @@ -335,7 +336,7 @@ If you change any of the @file{configure.in} files you will also need @itemize @bullet @item -GNU @code{autoconf} 2.12 +GNU @code{autoconf} 2.12 or higher @end itemize @noindent @@ -417,23 +418,23 @@ switches via @var{CFLAGS}. @cindex upgrading from libc5 @cindex kernel header files -If you are installing GNU libc on a Linux system, you need to have the -header files from a development kernel around for reference. You do not -need to use the development kernel, just have its headers where glibc -can get at them. The easiest way to do this is to unpack a development -kernel in a directory such as @file{/usr/src/linux-dev}. In that -directory, run @samp{make config} and accept all the defaults. Then -configure glibc with the option -@samp{--with-headers=/usr/src/linux-dev/include}. Use the latest -development kernel you can get your hands on. - -An alternate tactic is to unpack the development kernel and run -@samp{make config} as above. Then rename or delete @file{/usr/include}, -create a new @file{/usr/include}, and make the usual symbolic links of -@file{/usr/include/linux} and @file{/usr/include/asm} into the -development kernel sources. You can then configure glibc with no -special options. This tactic is recommended if you are upgrading from -libc5, since you need to get rid of the old header files anyway. +If you are installing GNU libc on a Linux system, you need to have +the header files from a 2.2 kernel around for reference. You do not +need to use the 2.2 kernel, just have its headers where glibc can get +at them. The easiest way to do this is to unpack it in a directory +such as @file{/usr/src/linux-2.2.1}. In that directory, run +@samp{make config} and accept all the defaults. Then run @samp{make +include/linux/version.h}. Finally, configure glibc with the option +@samp{--with-headers=/usr/src/linux-2.2.1/include}. Use the most recent +kernel you can get your hands on. + +An alternate tactic is to unpack the 2.2 kernel and run @samp{make +config} as above. Then rename or delete @file{/usr/include}, create +a new @file{/usr/include}, and make the usual symbolic links of +@file{/usr/include/linux} and @file{/usr/include/asm} into the 2.2 +kernel sources. You can then configure glibc with no special options. +This tactic is recommended if you are upgrading from libc5, since you +need to get rid of the old header files anyway. Note that @file{/usr/include/net} and @file{/usr/include/scsi} should @strong{not} be symlinks into the kernel sources. GNU libc provides its |