l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2005 Sep 04 01:47

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Module build
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Module build

Quoting Jeff Newmiller (jdnewmil@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

(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.)

vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.