When you install an SMP kernel, the non-SMP kernel headers are installed. This makes building a stand alone device driver impossible, as the module versions don't match the kernel.
*** Bug 3344 has been marked as a duplicate of this bug. *** $ rpm -qf /usr/include/linux/autoconf.h kernel-headers-2.2.5-22 $ grep SMP /usr/include/linux/autoconf.h #undef CONFIG_SMP Since I'm running an SMP kernel on my home system, this obviously makes it more difficult to compile kernel-modules to either play with myself or for products such as 4-Front's OSS sound drivers.
*** Bug 3072 has been marked as a duplicate of this bug. *** Building Daryll Strauss' 3dfx.o device on for an SMP kernel (2.2.5-15smp) creates a 3dfx.o with the version 2.2.5-15. I had previously configured the kernel with SMP. I got the device to build with the correct version by manually editing /usr/src/linux/include/linux/version.h and adding the 'smp' postfix to UTS_RELEASE. ------- Additional Comments From jturner 05/26/99 13:51 ------- I have seen this discrepancy in the test lab, but have not had trouble building modules. I am forwarding this issue to a developer for further review.
The default installed headers are for uniprocessor. The defaults have to be generic, because there is no way of telling what kernel the user is running. ------- Email Received From Daryll Strauss <daryll> 06/18/99 16:02 -------
Can't you at least provide your default SMTP headers in a separate package? That way people with SMP can install it if they need it. Otherwise they only way they can get valid headers is to do a full kernel compile and install. That seems like a reasonable compromise. - |Daryll
No, because when i generate the rpm I can only have one single file for eahc header. I can not have /usr/include/linux/foo.h as two different files in two different packages. That would be solved by having different .src.rpms for the smp and non smp kernels, and there is no way I am going back to that mess. ------- Additional Comments From 06/18/99 20:58 ------- I have a .spec file that creates additional packages for the generated headers. It has some problems that should be easy for a RPM expert to fix related to the symlink for /usr/include/linux. I do not believe that it is the correct solution, but I'm willing to email it to anyone who wants a copy. Why can't you put the generated header files as part of the kernel package? /usr/include/linux/modules-<foo>/ /usr/include/linux/versions.h-<foo> /usr/include/linux/autoconf.h-<foo> And as part of either the package install or the boot procedure symlink those to the non-foo names? You want me to try and come up with a .spec file for this as well? ------- Additional Comments From 06/18/99 22:50 ------- Are you really saying "yes, it is broken, but it is too much trouble to fix?" That's not a good answer. Realize that any stand-alone kernel module that tries to use module versions is effected by this. That means PCMCIA, serial drivers, etc will all have this problem if a user attempts to build them. I'm open to any suggestion for a work around. My current solution is to tell the users to reconfigure, recompile, and reinstall their kernel, because Red Hat ships a broken kernel configuration, but I would think we could come up with something better. - |Daryll