This is my absolute last word on the subject. Let's please drop it. On Tue, 15 Jun 2004, Stas Sergeev wrote:
> What you said before was only "I don't run a distribution kernel...". Maybe, but that's not what I meant. Call it a communication problem. > "I don't use a distribution" - I don't think I understand what do you > mean by that. When I say I don't run a distribution, I mean exactly that. While the systems I'm running were originally Red Hat 5.2, nothing remains of the distribution apart from a few convenience scripts (and most of those have been heavily modified). > Apparently you haven't even looked into an URL I (and other people) > pointed you to :( I did. I even agree with Linus. The problem is that the "kernel" kernel headers and the "glibc" kernel headers (as maintained by the libc packagers) are different. Glibc doesn't provide "sanitized" headers for every occasion (nor can they if it's to remain, more or less, platform independent). With glibc 2.2.5, there are 22 libc headers that dip into the kernel source. Version 2.3 may be different: I intend to get the source and look into it. The result of all of this is that the burden of fixing kernel headers, which you have NO CHOICE but to use because libc uses them, has fallen squarely on the shoulders of libc builders. Ok, so I had /usr/include/linux symlinked into the 2.6.6 source tree. So what? That glibc was built against the 2.6.6 headers (BTW, I pulled the old glibc, which I built against 2.4, along with the appropriately versioned kernel headers, out of cold storage...at least things work now). > he himself doesn't want people to ever include the kernel headers I'm not including the kernel headers, libc is including the kernel headers. > Now you say distributors are not bothering to tell the kernel guys? > Sigh... Please RTFM. That was probably unfair. I've been corresponding with the kernel developers and they don't seem to understand what glibc is doing with the headers. > Kernel headers are fine. They're NOT fine if you, or some glibc packager, has to diddle with them to get applications which DON'T include kernel headers to compile. You can argue that the problem is with glibc, but I don't see what they can do about it. Maintain special sanitized headers for every conceivable platform? > ignoring whatever comes with the glibc Nothing in include/linux comes with glibc. The packagers may call it "glibc-kernelheaders" or somesuch, but the headers are straight out of the kernel source. Linus's argument was that include/linux should contain the kernel headers against which libc (and possibly other dynamic libraries) was built. I'm willing to concede that that's a very good idea, but not if it results in a willy-nilly profusion of divergent "kernel" headers. That's bedlam. > The best thing you'll hear is "don't include the kernel headers into > your program", You're right, of course. > but since that makes no sense to you, go ahead and try. Goddamnit, it makes perfect sense to me. The original problem cropped up because src/include/pci.h includes <sys/pci.h>. Not a kernel header, a glibc header. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
