I'm looking at some software I have to build at work, and I'm trying to work with RedHat 8.0, even though I don't have it yet. I'm curious about a particulare "binary" package: kernel-source-2.4.18-14.i386.rpm and similarly: glibc-kernheaders-2.4-7.20.i386.rpm These are clearly source files. How do they compare with: kernel-2.4.18-14.src.rpm ???? In particular, I'd like to try building my package (targeting 8.0) on my 7.2 box. (Maybe that's unrealistic. It's a fibre HBA driver module.) At any rate, why the mixup with the "sources"? And, why would header files be non-relocatable on the install? (At least the kernel headers are with 7.2. TIA, Bill
On Thu, Oct 03, 2002 at 05:25:24PM -0400, Bill Mills-Curran wrote: subssn594> I'm looking at some software I have to build at work, and I'm trying subssn594> to work with RedHat 8.0, even though I don't have it yet. I'm curious subssn594> about a particulare "binary" package: subssn594> subssn594> kernel-source-2.4.18-14.i386.rpm This contains the expanded and RH-patched kernel source code in /usr/src/linux-2.4.18-14, along with supporting files, such as config files. It is used if you want to build a custom kernel right in /usr/src/linux, without packaging it up as an RPM. It is also needed for compiling your own kernel modules. In that case, you should always use the include files in /lib/modules/2.4.18-14/build/include (build is a symlink into /usr/src/linux-2.4.18-14) so you compile against the current kernel version's include files. subssn594> glibc-kernheaders-2.4-7.20.i386.rpm This is a totally separate package that contains stable, unchanging kernel headers for use with all user-space program compilation. The files are contained in /usr/include/asm and /usr/include/linux, and this package should always be used instead of symlinking those directories to /usr/src/linux/include/{asm,linux}. subssn594> kernel-2.4.18-14.src.rpm This contains the kernel tarball + patches + configs + an RPM spec file. It is used to build all kernel-*.i{3,5,6}86.rpm files. If you want to make custom kernel RPM packages, then you need to use this. subssn594> In particular, I'd like to try building my package (targeting 8.0) on subssn594> my 7.2 box. (Maybe that's unrealistic. It's a fibre HBA driver subssn594> module.) Yes, that is unrealistic. RH 8.0 uses GCC 3.2, which compiles code that is fundamentally incompatible with kernel code compiled with RH's GCC 2.96 in 7.2. Not only that, but kernel modules should always be compiled against the same kernel version they will be used with, using the headers in /lib/modules/2.4.x-y/build/include. subssn594> At any rate, why the mixup with the "sources"? And, why would header subssn594> files be non-relocatable on the install? (At least the kernel headers subssn594> are with 7.2. Because you should never need to use the kernel headers of a specific kernel version for *userspace* programs, and you should use /lib/modules/2.4.x-y/build/include for *kernelspace* programs. These changes are the first steps in separating out the kernel ABI/API from the userspace ABI/API. -- Charles R. Anderson <cra@wpi.edu> / http://angus.ind.wpi.edu/~cra/ PGP Key ID: 49BB5886 Fingerprint: EBA3 A106 7C93 FA07 8E15 3AC2 C367 A0F9 49BB 5886
participants (2)
-
Bill Mills-Curran
-
Charles R. Anderson