On 2002.09.20 Charles A Edwards wrote: >On Fri, 20 Sep 2002 11:34:18 -0400 >David Walluck <[EMAIL PROTECTED]> wrote: > >> Given this, I don't understand why the build would not fail due to >> missing headers if only kernel-headers is installed. How is it that >> the kernel-source headers automatically 'override' the kernel-headers >> if kernel-source is installed? >> >> In other words, kernel-headers file '/usr/include/[sys]/<header>.h' >> includes 'linux/<header>.h', but if kernel-source is not installed, >> then 'linux/<header>.h' does not exist, yet the build does not fail. > >I agree it can be confusing and it even caused me to miss-speak.
It is not confusing, it is wrong. See below. This has been told tons of times, but I will try one more, just to see if I can sort things. >Pkgs such as NVIDIA_kernel require you have installed kernel-source.rpm >but Not the kernel-headers.rpm. >If it were a normal pkg then the kernel-source.rpm would be >kernel-devel.rpm. >It contains the header and other files necessary for building pkg that >are kernel dependent. > >If you want answers about the reasoning behind the the kernel-headers >pkg change you may have to ask the kernel or glibc people because I >can't tell you. > glibc has functions for dealing with hardware (ioctl) or filesystems (fcntl). glibc has to interact with kernel, so needs info about kernel internal structures. So you see a glibc function 'fcntl' that calls a kernel syscal 'fcntl' with a constant named 'F_DUPFD' (hypothetical case). F_DUPFD is defined in kernel headers. So glibc-devel has to include that definition. And you do not want to duplicate it, so you just take the kernel header. Ideally, kernel headers should be splitted in public and private parts, so public parts are borrowed by glibc (the F_DUPFD), and private ones are not taken outside the kernel (for example, the exact struct definition of a scsi device...). but I do not trust that will ever be. So you have to ship kernel-headers with glibc-devel. And _IDEALLY_ you should _REBUILD_ your glibc whenever you kernel changes. But it is not always needed. Usually kernel external interfaces do not change so much. But internals do. So you build your glibc on 2.4.10, and now you want to build 2.4.20. You need headers from 2.4.10 to have the definition of things like glibc 'thinks they are', and you need you new kernel tree, including the headers, to build it. And if you build a user-space program, you will interact with the kernel through glibc, so you need the defs of 2.4.10, that are the ones glibc understands. But if you build a module that needs to know internals of the kernel, you can't build against 2.4.10 headers, because internals have changed. You have to build against 2.4.20. So, usually you install (for this example), 2.4.10 headers under /usr/include/linux, for user-space programs, and 2.4.20 headers are with the rest of the kernel source tree under /usr/src/linux. And there appear all the problems when a not-very-careful build of a kernel module forgets to include headers from /usr/src/linux and ends up using those from /usr/include/linux, that can be wrong for the kernel you are running or want to build. (uh, too much typing ;) Hope this helps to clarify the mess) /by -- J.A. Magallon <[EMAIL PROTECTED]> \ Software is like sex: werewolf.able.es \ It's better when it's free Mandrake Linux release 9.0 (Cooker) for i586 Linux 2.4.20-pre7-jam0 (gcc 3.2 (Mandrake Linux 9.0 3.2-1mdk))
