Re: Clean up glibc version numbers in manual

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Mon, 20 Feb 2012, Jeff Bailey wrote:

> Is it important to indicate minimum versions of GCC that are old?  Could
> that paragraph be replaced with "GCC and Glibc are developed in concert
> with one another, and it is a good idea to have a relatively current
> toolchain when compiling Glibc.  The configure script will check to make
> sure you have a sufficiently recent version and give you a minimum version
> if you need to update." ?

I think it's useful for the manual to say what versions of GCC work rather 
than only having that information in the configure script.  Certainly the 
configure script *should* detect too-old versions (and I suspect 3.4 is 
too-old by now; certainly x86 and x86_64 require at least 4.3 because they 
require cpuid.h); having the build fail because of a problem configure 
didn't detect is bad.

Apart from increasing the minimum version (to 4.3, probably) I'd be 
inclined to change the recommended version to 4.6 instead of 4.4.  But 
this patch isn't touching the GCC versions - it's purely about glibc 
version numbers.  There are many things that need updating in the 
installation documentation, and it seems best to fix them one at a time in 
case any concerns arise about individual patches.  My previous 
install.texi patch removed documentation about upgrading from libc5.  
This one deals with glibc version numbers.  A subsequent one may deal with 
kernel versions (remove relics of support for pre-2.4 kernels; I would say 
pre-2.6, but there were concerns about that so that's probably been 
postponed until after glibc 2.16; in any case, require the *headers* to be 
from "make headers_install" from 2.6.19.1 or later).  Tool versions may 
come in at some point.  Quite a few of these changes will involve both 
configure or other code and the manual (and the README, etc.).

-- 
Joseph S. Myers
joseph@codesourcery.com