On Mon, 22 Jan 2001, Ken D'Ambrosio wrote:
> /usr/include/bits/errno.h:25: linux/errno.h: No such file or directory
>
> And there is *too* a file, errno.h, in /usr/src/linux/include/linux/. Is
> some pesky environmental variable awry? Or... I dunno?
There is apparently some confusion over how things like kernel headers
should be included into other source files.
$LINUX_SOURCE/include/{linux,asm,scsi} are three directories used by Linux
for C header files intended to be included by other kernel source files.
Some of these files may change between kernel revisions, but that shouldn't
matter, because the changes will be crafted such that the kernel will present
a consistent binary interface to userland programs.
However, it turns out that not just the kernel wants the kernel headers.
Two other classes of programs need access to these headers:
(1) The C library (glibc), which needs access to the kernel headers so it
can provide an API to them.
(2) Certain programs which, while executing in userland, manipulate
low-level system information. A good example is cdrecord, which makes
use of all sorts of arcane bus interface routines and constants.
To make things *really* interesting, the glibc designers made a poor choice
when they were first deciding how to present kernel values to userland. They
decided that userland programs should simply include the kernel headers
directly. Since glibc makes use of these values internally as well, it means
that glibc (and userland programs which use glibc) depend on the kernel
headers which *glibc was compiled against* and not necessarily the headers
*for the currently running kernel*.
Programs like cdrecord, on the other hand, generally want to use the headers
from the currently running kernel, because those most closely match the
interfaces they are using.
Just to confuse things further, it was (and perhaps still is) a common
practice to symlink /usr/include/{linux,asm,scsi} to the actual kernel source
directories in the /usr/src/linux/include/ directory. Meanwhile, it is very
common to muck around with the kernel installed in /usr/src/linux for various
reasons (rebuilds, hacking, new kernel, etc.).
Combine that with the fact that /usr/include/{linux,asm,scsi} are typically
in the compiler's default include path, and you've got one big mess.
If you remove /usr/include/{linux,asm,scsi}, you may break builds of glibc
and/or programs which use it (i.e., everything). If you do not remove them,
then kernel builds may get screwed up, because the compiler will find those
before it finds $LINUX_SOURCE/include/{linux,asm,scsi}, and cause errors like
what you are seeing.
I'm not really sure what the Right Thing to do is in this case. I suspect
it is something along the lines of "change the compiler include path when
compiling a kernel", but I'm fuzzy on the details.
What I typically do is simply remove or rename /usr/include/{linux,asm,scsi}
to build the kernel, and hope userland programs still compile.
> I guess I could hand-edit the makefile, but it's gotta be something more
> obvious than that, no?
Heh. Heh. Heh.
--
Ben Scott <[EMAIL PROTECTED]>
Net Technologies, Inc. <http://www.ntisys.com>
Voice: (800)905-3049 x18 Fax: (978)499-7839
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
