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
*** Bug 3344 has been marked as a duplicate of this bug. ***
$ rpm -qf /usr/include/linux/autoconf.h
$ grep SMP /usr/include/linux/autoconf.h
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 email@example.com 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
The default installed headers are for uniprocessor. The defaults have
to be generic, because there is no way of telling what kernel the user
------- Email Received From Daryll Strauss <firstname.lastname@example.org> 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.
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
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.