bcc dpmi ver1.2.0
Hello.
Quoted 2 lines · R.L. Horn
I stuck an "#ifdef
__KERNEL__" around it which seems to have done the trick. Of course, now when an upgrade patch eventually fails, I'll
Are you sure you are upgrading glibc
with patches?
Quoted 1 line
If it's not fixed in 2.6.7 I'll file a bugzilla report.
You probably have to do
diff -u /usr/include/linux/pci.h /usr/src/linux-2.6.6/include/linux/pci.h before filling such a report.
If you had an rpm-based distro, you could've
done also this:
$ rpm -qf /usr/include/linux/pci.h glibc-kernheaders-2.4-8.44
Quoted 1 line · Stas Sergeev
Are you sure you are upgrading glibc with patches?
The kernel. <linux/*> are kernel headers, not part of glibc, but the distributors appear to have muddied the waters considerably. (So, what else is new?)
Quoted 2 lines
diff -u
/usr/include/linux/pci.h/usr/src/linux-2.6.6/include/linux/pci.hbefore filling such a report.
My /usr/include/linux is a symlink into the kernel source.
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, but it seems like a horrendously bad idea to me. If nothing else, it occults kernel header problems, which might explain in part why they've been so long getting fixed.
At any rate, this is getting kind of far afield.
Quoted 7 lines · R.L. Horn
Quoted 1 line · Stas Sergeev
Are you sure you are upgrading glibc with patches?
The kernel. <linux/*> are kernel headers, not part of glibc, but the distributors appear to have muddied the waters considerably. (So, what else is new?)
[..]
Quoted 2 lines
It sounds as though the distributors are maintaining multiple, possibly disparate, copies of the kernel headers.
There's a good reason for this. Building userspace applications against kernel headers creates the very real possibility that a kernel upgrade may break binary compatibility, because the interfaces may change from kernel to kernel. The purpose of /usr/include/linux is to provide a stable set of headers for compiling applications that does not include things that might break as the structure of the kernel changes. It also means that the structure of the developer and user's machine with respect to compiling applications will be the same, which is obviously a good thing for QA and bug-reports.
The userspace headers are almost always behind the kernel ones in terms of what interfaces are supported, so if you have something that is building against the version 234 interface of ioctl xyz, you should probably add the header to the source of your application. #including a kernel header directly instead is a hack; not only will your binary potentially not work on a different kernel version, but that interface may not be available in that kernel header on the user's machine (if they even have a kernel source installed).
Think of the stable headers as a convenience measure; it is convenient to be able to run the same binary with any kernel and for a user to be able to compile your application no matter if he has a full kernel source installed or if he is running a different kernel version or not. They are not intended to be an annoyance or source of confusion (though they are frequently perceived as such by people who misunderstand the intent). It is fortunate that the bad old days of /usr/include/linux -> /usr/src/linux/include are mostly gone, but some systems still do that anyway (Slackware?).
Signature · 1 line
Ryan Underwood, <[email protected]>
Quoted 3 lines
intent). It is fortunate that the bad old days of
/usr/include/linux->/usr/src/linux/includeare mostly gone, but some systems still do that anyway (Slackware?).
FWIW - to be precise, Slackware isn't doing what's illustrated above, exactly. No symlink at all. Rather, /usr/include/linux, if populated at all, comes only from the kernel-headers package, and is a complete copy of the kernel headers that are packaged with the kernel source in that particular distribution.
I suspect the rationale for this would go along the lines of:
"If you want /usr/include/linux populated from this distribution, I'm going to populate it with the headers from the (stable) kernel version that I'm giving you. I do this with the assumption that when you change slackware versions, you're going to do a wholesale replacement of EVERYthing. I further assume that if you plan to chase the kernel and be building your own, you know enough to NOT install the kernel-specific headers here. So for these reasons, I give to the person who's going to keep a static configuration those elements that are internally self-consistent; and for the person who isn't, don't install the kernel-headers package - you know what you should be doing"
I'm not saying that this makes it right, or even ok; only that it's not the symlink situation. I'm inferring that a packaging decision was made deliberately to fit a theme: the distribution will go as far is it can to protect the novice from himself, but it's flexible enough to be used by a virtuoso without extra work, and if one is a virtuoso, s/he will know what to do with this anyway.
Reference: Slackware 9.1, and probably many earlier.
Just my 2c.
jbh
Quoted 5 lines
Quoted 5 lines
intent). It is fortunate that the bad old days of
/usr/include/linux->/usr/src/linux/includeare mostly gone, but some systems still do that anyway (Slackware?).
It's been years since Slackware has done that.
Quoted 7 lines
FWIW - to be precise, Slackware isn't doing what's illustrated above, exactly. No symlink at all. Rather,
/usr/include/linux, if populated at all, comes only from the kernel-headers package, and is a complete copy of the kernel headers that are packaged with the kernel source in that particular distribution.I suspect the rationale for this would go along the lines of:
The rationale is that the kernel headers in /usr/include should be closely matched to the ones that glibc was compiled against or you can run into trouble. Reference from Linus:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html
Take care,
Pat