Bug 174366 - ES4 includes glibc-kernheaders which has the wrong values for the default kernel
Summary: ES4 includes glibc-kernheaders which has the wrong values for the default kernel
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: glibc-kernheaders
Version: 4.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: David Woodhouse
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-11-28 16:02 UTC by Samuel Oosterhuis
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-09-12 14:01:05 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Samuel Oosterhuis 2005-11-28 16:02:27 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921 Red Hat/1.0.7-1.4.1 Firefox/1.0.7

Description of problem:
Default install includes:
glibc-kernheaders-2.4-9.1.98.EL
kernel-2.6.9-22.EL

So there is a 2.6.9 kernel with old headers.  For example:
cat /usr/include/linux/version.h
#define UTS_RELEASE "2.4.20"
#define LINUX_VERSION_CODE 132116
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))

The implication is that locally compliled packages which depend on LINUX_VERSION_CODE either fail or compile incorrectly.

Version-Release number of selected component (if applicable):
glibc-kernheaders-2.4-9.1.98.EL

How reproducible:
Always

Steps to Reproduce:
1. cat /usr/include/linux/version.h


Actual Results:  Our product depends on this file being correct, as the internal structures in the linux kernel have changed since the 2.4 kernel.

Expected Results:  We should be able to depend on the files in glibc-kernheaders being the correct version.

Additional info:

Comment 1 David Woodhouse 2005-11-28 16:39:32 UTC
It should perhaps have been set to 2.6.something before shipping, but
unfortunately it's too late now -- we did try changing it as an experiment but
it broke too much other code.

Code which is depending on this is broken anyway; in RHEL5 we should probably
refrain from shipping linux/version.h altogether.

If you explain what you're trying to do, we can propose a better solution.


Note You need to log in before you can comment on or make changes to this bug.