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

[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.

--Steven

[AlanBartlett]

[code]
[ajb@nova9 linux]$ uname -rmi
2.6.9-78.0.22.plus.c4 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]$
[/code]
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]

[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
'20414'

> #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.

[AlanBartlett]

[b]Steven[/b],

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=https://bugzilla.redhat.com/frontpage.cgi]upstream bug tracker[/url].

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