In the kernel update issued in RHSA-2001:013-05 the kernel-headers rpm is missing. The headers are in the kernel-source rpm instead. Was this change made intentionally? I really liked the the old way of separating the headers and the rest of the source.
*** Bug 26889 has been marked as a duplicate of this bug. ***
*** Bug 26976 has been marked as a duplicate of this bug. ***
Just so its not missed: from bug 26889: The symbolic links /usr/include/ {linux,asm} are missing from the package, too.
Sorry, missed that. Thanx for the addition.
The change was intentional, but the wrong idea, and will be changed in a future errata kernel back to having a kernel-headers package. The links are no longer part of the package; they are made in the post-install script.
Just what does "will be changed in a future errata kernel" mean? Can we expect a new set of RPMs soon (as in days), or do I need to extract the headers from include/linux and include/asm-* by hand?
You shouldn't need to extract anything by hand -- just install the kernel-source rpm.
Yes, I could do that. However, that means installing a 45Mb RPM to get 7.5Mb of include files. I've got a bunch of "small" machines that I put on student desks that just don't have the space to spare. :/ I could leave it out completely, but that just doesn't work in the College of Computing. My users tend to get anoyed when they can't compile programs. :) In short, I've got special requirements that make me dependant on the kernel-headers package being seperate from the kernel-source package. I can do a work around if needed, but was hoping for an updated set of RPMs so I didn't have to.
Until we release the new version, there is in the spec file a %define headersinsource 1 that you can can change to %define headersinsource 0 and rebuild. That will take care of your special requirements in the meantime. They were moved in so that we could use 2.4 headers even on a 2.2-based system for building (with) a glibc that could take advantage of 2.4 functionality. But that's not an issue for 6.x, so we'll move that back in the next errata release.
*** Bug 27996 has been marked as a duplicate of this bug. ***
Note that just %define headersinsource 0 won't probably be enough to build an headers rpm, see bug 18868
johnsonm, The linux and asm symlinks aren't created in the post-install script either. They'll be created only when %headersinsource -eq 0. [wenzhuo@marvin wenzhuo]$ rpm --scripts -q kernel-source postinstall script (through /bin/sh): cd /usr/src rm -f linux ln -snf linux-2.2.17 linux if [ 1 -eq 0 ] ; then cd /usr/include rm -f linux asm ln -snf ../src/linux/include/linux linux ln -snf ../src/linux/include/asm asm fi cd /boot rm -f kernel.h ln -snf kernel.h-2.2.17 kernel.h exit 0
No, that's correct. headersinsource is done specifically so that another package can provide headers unrelated to that kernel version. So if headersinsource is 1, none of those links should be created; they will be provided by a different package. In Red Hat Linux 7.0, this allows us to provide 2.4 kernel headers so that users can build applications that can work with either the 2.4 or 2.2 kernel; part of our attempt to be 2.4-kernel-ready in Red Hat Linux 7.0 If headersinsource is 0, then we have a separate kernel-headers package created as a subpackage of the kernel package and we should create those links. I know, it's hard to follow, but it really isn't a bug. However, I *did* see bug 18868.
If this isn't a bug then why can't I compile masquerading in a bzImage on my i586 anymore? make[2]: Entering directory `/usr/src/linux-2.2.17/net/ipv4' make all_targets make[3]: Entering directory `/usr/src/linux-2.2.17/net/ipv4' gcc -D__KERNEL__ -I/usr/src/linux-2.2.17/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -DEXPORT_SYMTAB -c ip_masq.c ip_masq.c:578: `ip_masq_hash' undeclared here (not in a function) ip_masq.c:578: initializer element for `__ksymtab_ip_masq_hash.value' is not constant ip_masq.c:579: `ip_masq_unhash' undeclared here (not in a function) ip_masq.c:579: initializer element for `__ksymtab_ip_masq_unhash.value' is not constant ip_masq.c:518: warning: `masq_port_lock' defined but not used make[3]: *** [ip_masq.o] Error 1 make[3]: Leaving directory `/usr/src/linux-2.2.17/net/ipv4' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux-2.2.17/net/ipv4' make[1]: *** [_subdir_ipv4] Error 2 make[1]: Leaving directory `/usr/src/linux-2.2.17/net' make: *** [_dir_net] Error 2 I suppose I should uninstall kernel-headers-2.2.16-3??? [root@wiz linux-2.2.17]# rpm -qa | grep kernel kernel-utils-2.2.17-14 kernelcfg-0.5-5 kernel-doc-2.2.17-14 kernel-headers-2.2.16-3 kernel-2.2.17-14 kernel-source-2.2.17-14 But then, how could I compile anything root@wiz linux-2.2.17]# rpm -ev kernel-headers-2.2.16-3 error: removing these packages would break dependencies: kernel-headers is needed by glibc-devel-2.1.3-22 kernel-headers >= 2.2.1 is needed by glibc-devel-2.1.3-22 kernel-headers is needed by glibc-devel-2.1.3-22 kernel-headers >= 2.2.1 is needed by glibc-devel-2.1.3-22
All these bug reports could have been avoided if the kernel update document was updated with all this info. Sounds to me Q&A was not working at peak efficiency. The question remains: Will removing the following procedure work and keep the system sound and capable of compiling kernels and other software? rpm -e kernel-headers kernel-source rpm -Uvh kernel-source-2.2.17-14.sparc.rpm
I realize you're getting multiple bugs in this report, but I have a comment related to hugh.bragg's error (and this is the only bugzilla entry mentioning it so far). I had to modify net/ipv4/ip_masq.c before my kernel would compile (upgrading stock RH6.2 with kernel 2.2.17-14). I moved EXPORT_SYMBOL (ip_masq_hash) and EXPORT_SYMBOL(ip_masq_unhash) to a point after those two functions were defined.
Hugo says rpm -e kernel-headers kernel-source Nice if it were that simple, but the compiler depends on these. Perhaps rpm -e kernel-headers kernel-source glibc-devel egcs egcs-c++ egcs-objc rpm -U kernel-source-2.2.17-14.i386.rpm rpm -i --nodeps glibc-devel-2.1.3-22.i386.rpm egcs-1.1.2-30.i386.rpm egcs-c++-1.1.2-30.i386.rpm egcs-objc-1.1.2-30.i386.rpm If I don't do it with --nodeps it won't work. Is this OK? Maybe I would be better off looking for a 2.2.18 kernel with a kernel-headers?
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/