bcc dpmi ver1.2.0
Hello.
Quoted 2 lines · R.L. Horn
The kernel. <linux/*> are kernel headers, not part of glibc, but the distributors appear to have muddied the waters considerably.
No, this is not the decision of distributors any more.
Quoted 4 lines
It sounds as though the distributors are maintaining multiple, possibly disparate, copies of the kernel headers. Whether this is to ease installations without kernel sources or because 2.6 is so thoroughly buggered up I don't know
Linux-related FAQs contains the precise explanation for this:
http://www.linuxmafia.com/faq/Kernel/usr-src-linux-symlink.html
Quoted 1 line
If nothing else, it occults kernel header problems, which might explain in part why they've been so long getting fixed.
AFAIK everything is fixed. There was the problem with debian distro, but not any more I think.
You erased and symlinked /usr/include/linux on your own. Why do you expect the programs to still compile or work correctly? I think the above URL explains why you should not.
Quoted 1 line · Stas Sergeev
You erased and symlinked
/usr/include/linuxon your own.
I did no such thing. As I've explained before, I DON'T USE A DISTRIBUTION. Perhaps I'm a bit behind the times, but my argument is still valid. The kernel developers aren't hearing about bugs (and I'm talking about gross compile errors here, not nitpicky stuff about structures and unions) because the distributors are fixing them on their own and not bothering to tell the kernel guys. The <sys/pci.h>/ <linux/pci.h> thing was fixed months ago...but the bug is still there in kernel 2.6.6.
Now, let's get off this topic and talk about dosemu, ok?
Hello.
Quoted 3 lines · R.L. Horn
Quoted 1 line
You erased and symlinked
/usr/include/linuxon your own.I did no such thing. As I've explained before, I DON'T USE A DISTRIBUTION.
What you said before was only
"I don't run a distribution kernel...". Most of us do not run a distribution kernel. And as for "I don't use a distribution" - I don't think I understand what do you mean by that. LFS?
Quoted 3 lines
Perhaps I'm a bit behind the times, but my argument is still valid. The kernel developers aren't hearing about bugs (and I'm talking about gross compile errors here, not nitpicky stuff about
Apparently you haven't even looked into an URL I (and other people) pointed you to :(
Quoted 2 lines
structures and unions) because the distributors are fixing them on their own and not bothering to tell the kernel guys. The <sys/pci.h>/
If you at least made a quick glance at an URL, you'll probably notice that it was the quote from Linus, and he himself doesn't want people to ever include the kernel headers and don't want glibc maintainers to symlink the /usr/include/linux to /usr/src because that no longer work and not going to work ever again. Now you say distributors are not bothering to tell the kernel guys? Sigh... Please RTFM.
Quoted 2 lines
<
linux/pci.h> thing was fixed months ago...but the bug is still there in kernel 2.6.6.
Kernel headers are fine. Their only purpose is to compile with the kernel, and for that they suit very well. If someone thinks he can include the kernel headers everywhere, ignoring whatever comes with the glibc, it is another problem. If the same person doesn't even bother to read the documents that were pointed to him, that's also a completely different problem.
Quoted 1 line
Now, let's get off this topic and talk about dosemu, ok?
Right, such a discussion leads us nowhere. Go ahead an fill the bug report for kernel as you intended to do before. The best thing you'll hear is "don't include the kernel headers into your program", but since that makes no sense to you, go ahead and try. Maybe that will even work, who knows...
This is my absolute last word on the subject. Let's please drop it.
Quoted 1 line · Stas Sergeev
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.
Quoted 2 lines
"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).
Quoted 2 lines
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).
Quoted 1 line
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.
Quoted 2 lines
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.
Quoted 1 line
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?
Quoted 1 line
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.
Quoted 2 lines
The best thing you'll hear is "don't include the kernel headers into your program",
You're right, of course.
Quoted 1 line
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.