Summary: | wavemon 0.4.0b and kernel 2.6 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Petric Frank <pfrank> |
Component: | New packages | Assignee: | Mobile Herd (OBSOLETE) <mobile+disabled> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Petric Frank
2004-03-30 08:45:44 UTC
Yup, this problem is a nasty one that won't really go away until 2.6 kernel headers are used in /usr/include/linux... We could edit the ebuild to use /usr/src/linux/include, but then when someone moves back to 2.4, it dies, etc, etc. Ultimately it's a headers vs. running kernel issue, that's nasty regardless. I suppose you could have a versioned binary depending on the kernel version detected, and have /usr/bin/wavemon -> /usr/bin/wavemon-v2.6 or -> /usr/bin/wavemon-2.4, but this is still not a good solution. Let me ponder this more, any input from you would be great. I placed a suggestion inside the bug report. As /lib/modules/'uname -r'/build points always (?) to the actual kernel source tree - why not use/add -I/lib/modules/'uname -r'/build/include as compile option. This should solve the problem in either case of kernel version. There's many problems with that approach. First, gentoo's policy is to use the kernel found at /usr/src/linux to determine the version, NOT what uname -r returns. THis is because many times things are compiled on hosts other than the final destination, etc. Beyond that, this does nothing to solve the problem where someone has a machine that uses both a 2.4 and a 2.6 kernel. Either one is broken, or the other is. For now, i supposed we can change the include to use /usr/src/linux/include so it at least works on a 2.6 only system, but utlimately there needs to be a better solution. Okay. Marking WONTFIX as there are easy to use 2.6 kernel headers that work fine now for this. |