This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Require and document using kernel headers from "make headers_install"
On Thu, 23 Feb 2012, Roland McGrath wrote:
> I haven't really considered the issues in detail. But I don't have any
> objection.
Thanks, does anyone else have any comments here?
> I don't really think we need to be concerned about people
> building the newest libc with extremely old kernel headers any more.
Indeed, even before this patch the instructions already said "Use the most
recent kernel you can get your hands on." (for headers).
> (We
> probably don't even really need to care about the newest libc being run
> with kernels before middling early 2.6 any more.)
Anything before 2.6.0 final is what's currently on the deprecation list
<http://sourceware.org/glibc/wiki/Deprecation>, given your suggestion in
<http://sourceware.org/ml/libc-alpha/2012-01/msg00007.html> to let it stew
for a bit before removal. (In any case I think it makes sense to do the
2.0-2.1, 2.2-2.3 and 2.4-2.5 support removals in separate patches, to keep
the patches smaller and so make it easier to spot any problems in them.)
If we required 2.6.9 or 2.6.12 or 2.6.16 that would allow removing a few
more __ASSUME_* conditionals; I don't know if we should go there after
removing the pre-2.6.0 support. (The README does say that 'All Linux
kernel versions prior to 2.6.16 are known to have some bugs that may cause
some of the tests related to pthreads in "make check" to fail.'.)
> Incidentally, as a style note for the manual (not that you're introducing
> the problem newly here), originally we judiciously always used "the GNU C
> library" instead of any abbreviations in the manual. We should restore
> that level of care in diction at some point. There remain fairly few
> departures from that convention, mostly in install.texi and all in text
> added after the period when the manual was getting serious attention and
> proof-reading. (Those portions have many other problems of poor grammar
> and awkward construction, understandably stemming from having been written
> by non-native English speakers and never properly edited or proofread.)
Thanks, noted for a future cleanup stage on install.texi (there are lots
of cleanups and updates still needed to this documentation - some
independent of others, some touching the same text as each other) and the
manual in general.
--
Joseph S. Myers
joseph@codesourcery.com