fix build error on musl libc (linux/cdrom.h namespace clash).
since the libc defines some of the same symbol as the kernel headers, there is a clash.
using linux headers directly in userspace is almost always a bad idea, so i ripped the handful of required declarations out of the cdrom.h header and supplied it in a standalone file.
this also removes the need of having the kernel headers installed at all.
inline version of the patch for quick review without dealing with downloads to harddisk, browsing around, and opening files in an editor:
note that in the above text the "lower than" character got mistreated
so it basically removes include linux/cdrom.h and instead provides linux_cdrom.h
I am confused as to why dosbox would need patching ?
Isn't this just a bug in musl libc ?
DOSBox interfaces with devices directly, so using kernel headers makes sense to me.
If musl libc can't handle a kernel header, than that is their problem imho.
Feel free to point out some reasons to convince me otherwise.
is there something that disturbs you about the patch ?
basically it only takes out 4 magic numbers (from iso9660 standard) and 2 structs (kernel abi) (note: none of these will ever change), and removes the need to the have the linux headers installed.
isn't that a good thing?
the reason it works with glibc is that glibc deliberately includes the kernel headers for their own structs. so in order to compile gibc you have to have one of the few working kernel-header versions installed (in most linux releases the userspace kernel headers are broken).
musl otoh strives to be a complete implementation without any dependencies, thus it has to declare the types and macros dictated by the C standard and POSIX.
it's not the libc's job to work around incompatibilites with kernel headers (you simply should not use them from userspace, but if you do your translation unit must not be including other userspace headers.
nevermind, the bug was actually in the version of kernel headers i got installed (3.8.6). this bug does not appear with over kernel header version.
http://sprunge.us/BDCF
but still, since userspace kernel headers are often broken (as in my case), you may want to consider applying the patch none the less.