Description of problem: Building kernel either manually (or through the build system of drivers that have to be installed separately) gives an error. /usr/src/kernels/2.6.35.11-83.fc14.i686]$ make CHK include/linux/version.h CHK include/generated/utsrelease.h make[1]: *** No rule to make target `missing-syscalls'. Stop. make: *** [prepare0] Error 2 When building and installing Realtek wireless LAN 8191se drivers from the manufacturer (currently not supported by even the latest FC14 kernels), one runs into make -C /lib/modules/2.6.35.11-83.fc14.i686/build M= CC=gcc modules make[2]: Entering directory `/usr/src/kernels/2.6.35.11-83.fc14.i686' CHK include/linux/version.h CHK include/generated/utsrelease.h HOSTCC scripts/selinux/genheaders/genheaders scripts/selinux/genheaders/genheaders.c:13:22: fatal error: classmap.h: No such file or directory compilation terminated. make[5]: *** [scripts/selinux/genheaders/genheaders] Error 1 make[4]: *** [scripts/selinux/genheaders] Error 2 make[3]: *** [scripts/selinux] Error 2 make[2]: *** [scripts] Error 2 make[2]: Leaving directory `/usr/src/kernels/2.6.35.11-83.fc14.i686' make[1]: *** [modules] Error 2 Not being able to get wireless working with these cards will affect a lot of users as these cards are currently on several ThinkPads including X201, and FC14 kernels don't support them; hence the need to be able to install these drivers easily. Where exactly should the missing syscalls target be? Version-Release number of selected component (if applicable): 2.6.35.11-83.fc14.i686 $ rpm -q kernel-devel kernel-headers kernel-devel-2.6.35.11-83.fc14.i686 kernel-headers-2.6.35.11-83.fc14.i686 How reproducible: Always Steps to Reproduce: In the kernel source dir, 1. make oldconfig 2. make or make menconfig make Actual results: Expected results: Additional info:
I have the exact same problem. Im trying to compile a module for, lspci -v | grep audio 04:07.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10) which was supported under sl 5.5 but now is not supported. Is there any solution...
oops btw, Im using SL. 6
You're trying to compile something that isn't a source tree (it's a headers tree from kernel-devel). Building a kernel requires that you install the srpm.
> You're trying to compile something that isn't a source tree (it's a headers > tree from kernel-devel). Building a kernel requires that you install the srpm. If it's no longer a source tree, do you know why it's still under /usr/src/kernels/2.6.35.11-83.fc14.i686/? The directory name fully hints at it being a source tree. Was a switch made at some point from a full-fledged source tree to just a headers tree, and presumably due to various legacy/compatibility reasons, the name was retained? As far as I remember, I was able to do a 'make oldconfig/menconfig; make' directly in that dir or a similarly named one -- that was several years ago though.
In addition, several drivers/kernel module developers somehow expect that to be a source tree. Is there a strong reason for that such as several other linux distributions using the same/similar name for their source tree? In any case, do you also think it's correct for /lib/modules/`uname -r`/build to point to something that's not really a source tree? Since that is how an external build process gets to this dir.
(In reply to comment #3) > You're trying to compile something that isn't a source tree (it's a headers > tree from kernel-devel). Building a kernel requires that you install the srpm. It's not us, but the build process of (presumably) well-written/tested and widely used drivers that is trying to do that.
the build process of those drivers would probably work fine if you install a kernel tree, and not just a headers tree. again, you haven't installed the right package. It's not a bug. a well written external driver would be able to compile against a headers package, as many already do. For whatever reason, the realtek one doesn't.
(In reply to comment #7) > the build process of those drivers would probably work fine if you install a > kernel tree, and not just a headers tree. > > again, you haven't installed the right package. It's not a bug. While we are at this, can I ask if there's a way to install the kernel tree directly via yum? > > a well written external driver would be able to compile against a headers > package, as many already do. For whatever reason, the realtek one doesn't. What you say definitely makes sense, but again, shouldn't '/lib/modules/`uname -r`/build' point to something that actually builds or something from which something else was built and can be rebuilt?
"install a kernel tree". What exactly is the command for that? At the moment I'm trying "yum -y install kernel*" as a Hail-Mary pass.
(In reply to comment #9) > "install a kernel tree". What exactly is the command for that? > > At the moment I'm trying "yum -y install kernel*" as a Hail-Mary pass. Yes, I have the same question. Is there a way to install the kernel source tree directly via yum instead of getting srpm, etc.?