[vox-tech] Module build

[Richard Harke]

On Sat September 3 2005 09:24, Rick Moen wrote:
> Quoting Jeff Newmiller (jdnewmil at dcn.davis.ca.us):
> > /usr/include/linux:
>
> [...]
>
> > /usr/src/linux/include/linux:
>
> The two were, for a long time across a broad range of distributions,
> symlinked, which caused huge amounts of trouble for Linux's first
> decade, during the latter half of which, Linus was pleading with
> everyone to "stop the symlink madness".  Near as I can tell, someone
> early on thought:
>
>  "Well, I'm going to keep a full kernel source tree unpacked at
> /usr/src/linux anyway, so I can economise on disk space used by system
> headers in /usr/include, by creating these symlinks:
>
> /usr/include/linux -> /usr/src/linux/include/linux
> /usr/include/asm -> /usr/src/linux/include/asm
> /usr/include/scsi -> /usr/src/linux/include/scsi "
>
> ...and that's the way people tried to maintain their systems for a long
> time.  In fact, for a while, the kernel build instructions included in
> kernel.org kernels even included a directive to create the above
> symlinks, if they didn't yet exist.  The problem came because the
> _system_ headers (the ones in /usr/include) need to be in sync with your
> installed glibc library.  That would probably be true at the time of
> initial system build, because your unpacked kernel source tree probably
> _was_ the one that furnished your system header files.
>
> But then, you would tend over time to start installing newer kernels,
> going from 2.0.33 to 2.1.x betas, say.  Suddenly, the headers in your
> new /usr/src/linux/include/ trees started referencing structs that
> didn't exist in your glibc, and compiles started to mysteriously fail.
>
> It took a long time, but the distribution people finally _did_ "end the
> symlink madness", and distro maintainers have managed to discourage
> casual mucking about in /usr/include (including but not limited to
> ripping out entire subtrees and replacing them with symlinks to
> elsewhere).  These days, your /usr/include system headers come with your
> glibc package, and get replaced only when it does.
>
> The one part of that old nightmare that keeps persisting, and nobody has
> yet managed to put a stake through its heart, is the misconception that
> kernel compiles should be performed in /usr/src/linux, and should be
> carried out by root.  I keep hearing that, and neither claim is true.
>
> (Except, for example, some third-party build scripts for software fail
> if /usr/src/linux doesn't exist and point to a full kernel source tree,
> which means that those people haven't yet gotten the message.)
>
> Fortunately, because essentially no modern system has
> /usr/include/{linux|asm|scsi} symlinked to /usr/src/linux/ locations,
> the habit of compiling kernels in the latter subtree is at least
> _harmless_ if a bit bizarre, but it would be nice if people indulging
> that habit would at least "chown -R myusername /usr/src/linux", so that
> they cease needing to do their compiles with unnecessarily elevated
> privilege.
>
> (But then, too, why not compile your kernels somewhere more convenient,
> like your home directory or /tmp?  And you can always have a symlink at
> /usr/src/linux that points into there.)
>
Neither answer (this one and the one from Jeff) really answered what I
thought I asked. I realized that these are potentially different sets of
headers but the question was how to have a module build find the correct
ones. For modules that are a part of the kernel tarball, this has already
been taken care of. The problem comes up when you have module
source which is not in the kernel source tree. Part of the answer is that
the gcc command line has -I <prefix>/include where <prefix> is the
location of the kernel source tree, /usr/src/linux in the traditional case.
This directory will be searched first and /usr/include will only be searched
if the header file wasn't found. I was trying to build a version of rtlinux
and their instructions required putting the kernel source in /usr/src/linux
because they needed to build a lot of out-of-the-tree modules and
they needed to know where the includes would be located.

By the way, I just checked, all of the kernels I have in /usr/src
belong to me, not root.

Richard