The version of the kernel headers is supposed to match the version of the kernel that compiled glibc.
I don't exactly see the problem here. The kernel headers in your /usr/src/... directory should match the kernel you are building, and the headers in /usr/include should ideally match those you built glibc with. There is no link between the two.
perhaps he's asking about the fact that the headers were updated with -r1 that added a virtual/os-headers to the build?
AFAIK [according to Seemant], os-headers is _currently_ just a meta definition of linux-headers. It was brought in from the GNU/Herd stuff, where os-headers would be used for OS headers, and not linux headers. Currently, it's just a meta definition.
I've been wondering about the headers for a little while too. I have linux-headers-2.4.18 installed and emerge -pu world shows linux-headers-2.4.19-r1 to be installed. Is this safe? Everyone says not to change the headers that glibc was compiled with but this will change mine. If my headers shouldn't be updated then the default-1.0 profile should be changed.
Say you compile glibc using 2.4.22. The 2.4.22 kernel headers should then be installed for the remainder of the time that glibc is installed. If you upgrade to a 2.4.23 kernel in the future, you shouldn't update your kernel headers. It may cause problems, even unexplainable bugs. However, if you decide to recompile your glibc while using 2.4.23, the 2.4.23 kernel headers should be installed. Linus Torvalds has stressed this repeatedly in the past.
Thats all well and good but portage wants to update my headers, not me. I don't do blind emerge -pu worlds but many people do and could be in trouble with this. Maybe the linux-headers ebuild should remerge glibc, or at least have an einfo that says you should.
Not quite, but close. When one emerges libc, the kernel headers should be remerged if the installed version does not match the running kernel version.
Oh I see what you're saying...I'm using gentoo-sources-2.4.20-r6, and if I emerge glibc I should be using linux-headers-2.4-20, but the newest x86 headers is 2.4.19, so it's not right. But if I leave my glibc that I installed when I was running a 2.4.19 kernel then it's fine with mismatched headers/kernel. I thought that the kernel and headers didn't have to match at all, just that the headers shouldn't change underneath glibc.
AFAIK, this is incorrect. It is apparently considered safe to run any version of a kernel with a glibc compiled against headers older than the version of the kernel running. That glibc just won't make use of any new features the newer kernel may implement. Thus, if you're glibc is built against liunux-headers-2.4.21, and you run a 2.4.22 or 2.4.23 kernel, you should be fine. These are the *exact* circumstances many users are going to be using once the 2.6 kernel goes final -- that is running 2.6.x with a glibc built against 2.4 headers. I believe the only time the issue becomes an issue is when glibc is compiled against headers that are newer than the version of kernel being run. However, I ran linux-2.4.20 on my sparc64 machine for near 6 months, with about half that time using 2.4.21 headers and noticed no odd side effects of doing so. I'll also add that gentoo is likely to be stuck on linux-headers-2.4.21 for awhile, as a core package, iputils, attempts to use linux header files, and files miserably on 2.4.22 headers. iputils is that huggable little package that provides utilities like ping and all, making it a bit annoying. The same issue also occurs with 2.6 headers. Anyways, from my understanding, part of what allows this odd mix of kernel versions and header versions is the fact that /usr/include/linux and /usr/include/asm are not symlinks to their respective directories in /usr/src/linux/include*, but that /usr/include/{linux,asm} are real directories with copies of the headers in them. I believe we are one of the few distributions to implement this specific setup (correct me if wrong), so it's safe to have any random version of a kernel in /usr/src/linux, or not even have a /usr/src/linux symlink, as glibc will readily find it's desired header files already in /usr/include.
Ditto Joshua. I am pretty sure I did comment on this before bugzilla went down, and If there are any other issues left explaining, let me know.
An solution is the CDEPEND (or was that PDEPEND) that was supposed to remerge whatever even if it was already merged ... Anybody can remember the status of this ?
I'm closing this as INVALID, I think we have a good explanation in comment #9 and many other bugs - if you do actually come across into trouble when using a non-matched glibc, please reopen this bug.
