/usr/src/linux & /usr/src/linux-2.4.20 directories

Dagmar d'Surreal dagmar.wants at nospam.com
Tue Jan 28 08:50:05 PST 2003

On Tue, 2003-01-28 at 04:03, Tushar Teredesai wrote:
> Ian Molton wrote:
> >On Tue, 28 Jan 2003 07:08:34 +0000 (UTC)
> >tushar at linuxfromscratch.org (Tushar Teredesai) wrote:
> >  
> >
> >>In some systems /usr/include/linux and /usr/include/asm are symlinks
> >>to the corresponding dirs in /usr/src/linux
> >>    
> >>
> >/usr/src/linux/include, actually. anyway:
> >
> Sorry typo.
> >This is WRONG WRONG WRONG. any system set up like this is broken.
> >
> Nope. Its not. The important thing is that the headers that are 
> accessible via /usr/include/linux and /usr/include/asm should *always* 
> be the ones that glibc is compiled against. It doesn't matter whether 
> /usr/include/linux is a directory or a symlink to somewhere else (say 
> /usr/src/linux or /opt/kernel-sources).

Symlinks from /usr/include/linux make the Baby Torvalds(*) cry.  Didn't
you see the email that's cited in the book?  Linus has said that
/usr/include/{linux|asm} should not be symlinks.

(* - "Baby Torvalds" is not me calling Linus a baby.)

> The package is definitely broken. Given the fact that the kernel 
> developers have given a nearly failsafe mechanism for finding the 
> relevant kernel source, why should a package pick a location that _may_ 
> not be correct. It is ok to use /usr/src/linux as a fallback mechanism 
> (in case the build symlink is invalid) but not as the default.

Umm... that's not why that directory is version-granular.   It's
versioned so that new kernels won't be dropping incompatible modules
into the same directory as the old kernels' modules, which would break
the ability to reinstall an old kernel quickly if something in a new one
turnes out to be fubar.
The email address above is just as phony as it looks, and for obvious reasons.
Instant messaging contact nfo: AIM: evilDagmar  Jabber: evilDagmar at jabber.org

Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list