Page 1 of 1

Why does /usr/include/linux/version.h define the kernel version as 2.4.20?

Posted: 2009/08/20 18:26:14
by steven_rvbd
This is causing issues building some packages. For instance boost::asio uses the kernel version defined in this file to choose between using select and epoll.


Why does /usr/include/linux/version.h define the kernel vers

Posted: 2009/08/21 10:56:15
by AlanBartlett
[ajb@nova9 linux]$ uname -rmi x86_64 x86_64
[ajb@nova9 linux]$ cat version.h
#define UTS_RELEASE "2.4.20"
#define LINUX_VERSION_CODE 132116
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
[ajb@nova9 linux]$
I see [i]UTS_RELEASE[/i], not [i]KERNEL_VERSION[/i], defined as [i]2.4.20[/i].

As [i]CentOS 4[/i] is binary compatible with [i]RHEL 4[/i] I can say, with confidence, that the [i]/usr/include/linux/version.h[/i] file displayed above is identical to that distributed by [i]TUV[/i].

It might be worth looking to see exactly which parameter is being checked by the code you are compiling.

Three possible courses of action:

(1) edit the file so that [i]UTS_RELEASE[/i] is defined to be the string "2.6.9" for the duration of your code compilation
(2) ask the provider of the code that you are attempting to compile why it uses [i]UTS_RELEASE[/i]
(3) ask [i]TUV[/i]

Re: Why does /usr/include/linux/version.h define the kernel version as 2.4.20?

Posted: 2009/08/21 21:08:36
by steven_rvbd
Boost is looking at LINUX_VERSION_CODE (not UTS_RELEASE), which indicates that the kernel is 2.4.20;

> #define LINUX_VERSION_CODE 132116

>>> "%x" % 132116

> #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))

Changing version.h does not seem like a good idea without knowing why it does not match the kernel that is running.

Re: Why does /usr/include/linux/version.h define the kernel version as 2.4.20?

Posted: 2009/08/22 13:50:58
by AlanBartlett

I'll reiterate -- [i]CentOS[/i] is binary equivalent to [i]RHEL[/i]. Any decision made by [i]TUV[/i] is reproduced in [i]CentOS[/i].

As you require an answer to a question that only [i]TUV[/i] can answer, I'll advise that you first check and then raise this query on the [url=]upstream bug tracker[/url].

For future reference, please post the bz reference number you obtain here.