This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Clean up glibc version numbers in manual
On Mon, 20 Feb 2012, Marek Polacek wrote:
> Looks OK.
>
> > 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
>
> Yes, please, GCC 3.4 is really old these days. I'd volunteer for cleaning up
> those __GNUC_PREREQs.
>
> BTW, I'm seeing some __GNUC_PREREQ (2, *), I suppose they should the go?
__GNUC_PREREQ checks for old versions - and as appropriate references to
old versions in comments, etc. (which may be harder to find, but for
example the comment in sysdeps/x86_64/cacheinfo.c about how something can
be removed once 4.4 is the minimum version) - should generally only go
when they relate to compilers used to build glibc rather than used to
build user programs with glibc - that is, when in files that are not
installed. Installed headers may be used with any compiler (that supports
ISO C90).
In some cases you may know that a particular GCC version is the minimum
one that can be *used* with installed headers, because older versions
didn't support any system using the installed header. Generically that's
2.7 (older versions didn't have appropriately configured ELF targets for
current glibc). For some architectures it's more recent (e.g.
ports/sysdeps/arm/eabi/bits/huge_val.h; EABI support didn't exist even as
a backport before 3.3 so the conditions on different GCC versions are
irrelevant). But the __GNUC_PREREQ tests may still need to be replaced by
__GNUC__ conditionals rather than removed completely.
If a header or source file is *shared by gnulib* then conditionals may
still be relevant that are not relevant for direct use in glibc - so that
should also be checked before removing them.
--
Joseph S. Myers
joseph@codesourcery.com