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
Why does /usr/include/linux/version.h define the kernel version as 2.4.20?
-
- Posts: 2
- Joined: 2009/08/20 18:16:00
- Contact:
- AlanBartlett
- Forum Moderator
- Posts: 9326
- Joined: 2007/10/22 11:30:09
- Location: ~/Earth/UK/England/Suffolk
- Contact:
Why does /usr/include/linux/version.h define the kernel vers
[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]
[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]
-
- Posts: 2
- Joined: 2009/08/20 18:16:00
- Contact:
Re: Why does /usr/include/linux/version.h define the kernel version as 2.4.20?
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.
> #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
- Forum Moderator
- Posts: 9326
- Joined: 2007/10/22 11:30:09
- Location: ~/Earth/UK/England/Suffolk
- Contact:
Re: Why does /usr/include/linux/version.h define the kernel version as 2.4.20?
[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.
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.