Red Hat Bugzilla – Bug 64647
glibc-kernelhearder headers inconsistent with kernel-source
Last modified: 2007-04-18 12:42:29 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020408 Description of problem: Header files in /usr/include/asm from glibc-kernheaders are completely different from header files in /usr/src/linux-2.4/include/asm-i386 from kernel-source. Applications requiring the use of these headers don't compile if they use headers from glibc-kernheaders. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. ls -l /usr/src/linux-2.4/include/asm-i386 > /tmp/ks.dir 2. ls -l /usr/include/asm > /tmp/gkh.dir 3. diff /tmp/ks.dir /tmp/gkh.dir Actual Results: diff shows that the directories' contents is very different. Expected Results: diff should show no difference, as in previous versions of Red Hat Linux. Additional info:
* /usr/include/linux/version.h defines UTS_RELEASE 2.4.9-9. Are these really the right glibc kernel headers for Valhalla's 2.4.18-3 kernel? * Also, most files in /usr/include/linux have a time stamp of Oct 21 2001 while the kernel headers in /usr/src/linux-2.4/include/linux are different and up to Apr 18 2002. When creating the glibc-kernheaders package, cp -a should have been used to preserve timestamps.
Please ignore my comment if headers from kernel 2.4.9 are 100% compatible with kernel 2.4.18.
The kernel ABI to userspace is stable and doesn't change in an incompatible way. (It only gets extended and the extensions are put in the glibc headers just fine) The glibc headers are a SUBSET of the kernel headers, in that most of the internal kernel parts are removed and only the parts that describe the stable kernel ABI are present. Yes "diff" shows big differences, since all #ifdef __KERNEL__ parts are removed for one. This is *NOT* a problem since userspace programs (eg the programs that use glibc) can't use those bits anyway.
Reporter could close this report if he agrees. No further questions from me regarding compatibility.
closing, no comments in > 1 year and the issue isn't a bug.