Bug 690773 - No rule to make target `missing-syscalls'
Summary: No rule to make target `missing-syscalls'
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 14
Hardware: i686
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-25 11:15 UTC by udayb
Modified: 2011-05-05 08:06 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-03-28 17:22:02 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description udayb 2011-03-25 11:15:23 UTC
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:

Comment 1 craig 2011-03-28 12:34:19 UTC
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...

Comment 2 craig 2011-03-28 12:48:16 UTC
oops btw, Im using SL. 6

Comment 3 Dave Jones 2011-03-28 16:15:47 UTC
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.

Comment 4 udayb 2011-03-28 16:30:10 UTC
> 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.

Comment 5 udayb 2011-03-28 16:37:03 UTC
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.

Comment 6 udayb 2011-03-28 17:04:01 UTC
(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.

Comment 7 Dave Jones 2011-03-28 17:22:02 UTC
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.

Comment 8 udayb 2011-03-28 17:31:56 UTC
(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?

Comment 9 Penelope Fudd 2011-04-12 22:15:06 UTC
"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.

Comment 10 udayb 2011-05-05 08:06:43 UTC
(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.?


Note You need to log in before you can comment on or make changes to this bug.