Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
On Tue, Jan 27, 2004 at 09:01:56AM -0500, Ambrose Li wrote:
> Back "in the former times" (I started using GNU/Linux back
> when the only distros were SLS and Slackware), apps assumed
> that the kernel header files are in a "linux" directory in the
> system include path (the /usr/include/linux symlink, unless the
> user has a very strange setup). They need not assume there is
> anything in /usr/src/linux, though /usr/include/linux is likely
> a symlink to /usr/src/linux/include/linux.
True -- *but*, it must be pointed out that this is historic! In a
modern GNU/Linux distribution, /usr/include/linux should *not* be
a symlink to anything at all. It should be a plain directory containing
the kernel header files with which the GNU libc was built.
Every once in a while, someone comes along with a seriously broken
Debian system because they followed the advice in some old Slackware
HOWTO document from 1997, and made /usr/include/{linux,asm} symlinks
to some kernel source tree they happened to find somewhere. The
only fix for it is to remove the symlinks they made by hand, and
reinstall the libc6-dev package. (And in unstable now, the
linux-kernel-headers package.)
> And I have never
> heard of anyone hard-coding /usr/src/sys (nor have I heard of
> such a directory at all) in their makefiles.
That's where BSD keeps its kernel source tree. BSD is dramatically
more consistent than GNU/Linux.
> I have never encountered any app that has such an elaborate
> setup to detect where the kernel include files are; I would tend
> to say that such elaborate setup is unnecessary.
Not quite true. As has already been pointed out in this discussion,
there are different kinds of applications, and they need to use
different kinds of header files.
Most applications (like "hello, world") just use #include <stdio.h>
and so on. These headers come from the libc development package. This
case is easy.
Kernel modules need kernel headers -- specifically, they need the exact
kernel headers for the kernel that the module is going to be loaded into.
But there's no way of knowing exactly *where* the correct set of kernel
headers can be found, unless the sysadmin takes action when compiling
the module. With Linux 2.4.x, there's a "build" symlink under the
/lib/modules tree which (theoretically) points back to /usr/src/linux-2.4.x
or wherever the kernel source tree was configured. Failing that, the
kernel headers may be in a package (e.g. kernel-headers-2.4.18-bf2.4 in
Debian), which when installed will put them in a directory such as
/usr/src/kernel-headers-2.4.18-bf2.4/. Or they may be in /usr/src/linux/.
Or they may be in /home/fred/kernels/. There's no way to be sure,
so in the worst case the sysadmin who's building the module *WILL*
have to supply a -I flag to gcc.
Then there's a funky kind of application which seems to be in both user
space (like "hello, world") *and* kernel space at the same time. It
uses normal libc headers, but it also uses kernel headers. cdrecord
seems to be one of these kinds of applications. I don't know *what*
the right way to build these kinds of applications is -- and I don't
think there's any concensus among the various developers either.
Reply to: