You are not logged in.
So, in my latest pacman -Syu, I finally got Linux 2.6.25. However, kernel-headers is still at 2.6.24, and there is no 2.6.25 package in [testing] that I can grab. Shouldn't these packages be updated at the same time?
"Gentlemen! You can't fight in here! This is the war room!"
--President Merkin Muffley
Offline
No, they dont need to match, they have nothing to do with each other.
Offline
I like to use a lot of virtual machines (VMware), and have Arch in one of them. How am I supposed to compile VMware Tools against my current kernel if the kernel headers are for a different kernel?
Anyways, I'm glad to see that someone flagged kernel-headers as out of date, hopefully it will be updated sometime soon.
"Gentlemen! You can't fight in here! This is the war room!"
--President Merkin Muffley
Offline
You installed your kernel and then tried to rebuild your stuff? Of course you have to run the new kernel, it isn't enough to simply have it installed.
Offline
I like to use a lot of virtual machines (VMware), and have Arch in one of them. How am I supposed to compile VMware Tools against my current kernel if the kernel headers are for a different kernel?
Anyways, I'm glad to see that someone flagged kernel-headers as out of date, hopefully it will be updated sometime soon.
You are mistaken, the kernel-headers package is a different beast.
Description : Kernel headers sanitized for use in userspace
Don't flag it out of date for no reason when you don't even know what it is for.
The kernel26 package already includes all necessary headers for building modules. Just check pacman -Ql kernel26. Everything is in /usr/src/linux-<version>-ARCH/
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
See http://www.uwsg.iu.edu/hypermail/linux/ … /0587.html for more information:
by Linus Torvalds
The fact is, that the header files should match the library you link
against, not the kernel you run on.Think about it a bit.. Imagine that the kernel introduces a new "struct
X", and maintains binary backwards compatibility by having an old system
call in the old place that gets passed a pointer to "struct old_X".
It's all compatible, because binaries compiled for the old kernel will
still continue to run - they'll use the same old interfaces they are
still used to, and they obviously do not know about the new ones.Now, if you start mixing a new kernel header file with an old binary
"glibc", you get into trouble. The new kernel header file will use the
_new_ "struct X", because it will assume that anybody compiling against
it is after the new-and-improved interfaces that the new kernel
provides.But then you link that program (with the new "struct X") to the binary
library object archives that were compiled with the old header files,
that use the old "struct old_X" (which _used_ to be X), and that use the
old system call entry-points that have the compatibility stuff to take
"struct old_X".
Offline