Compiling

Brian Densmore DensmoreB at ctbsonline.com
Mon Mar 4 20:23:37 CST 2002


----Original Message-----
From: Duston, Hal
Sent: Mon 3/4/2002 12:56 PM
To: 'kclug'
Cc: 
Subject: RE: Compiling

>Jonathan Hutchins [mailto:hutchins at opus1.com] wrote:
>--snip--
>> 
>> One thing that's not at all clear is that if you change 
>> kernels too much, your modules and library links change 
>> too, and unless you have more than one complete trees, 
>> you could end up unable to go back because your new 
>> modules won't work with your old kernel, or the new 
>> kernel wanted new libraries which over-wrote the old 
>> ones.  Developers deal with this by having the whole 
>> kernel/boot/module/library/compile tree in more than 
>> one place and version, but there are places where this 
>> has to be managed by manually switching links.
>
>Some notes here.  The kernel is not dependent on any 
>libraries in order to run.  I also never move the 
>symlink in /usr/src to point to an newly built kernel 
>tree.  Those symlinks and include files belong to glibc,
>and _not_ the kernel.  I _always_ build my kernels in 

Yes, this is very true. You should never change the symlink in /usr/src
unless you install a new glibc tat is based on a different kernel. This
is the official word from Linus. I always create new directories,
/usr/src/linux-version, for each kernel version I have. If I'm patching,
I create a new directory and copy the old code there and patch from that
directory. glibc needs a clean, unmodified /usr/src/linux/ directory.
Messing with this directory will almost certainly sooner or later break
your system.

Trust me I know what I'm talking about, ;')
Brian

Brian





More information about the Kclug mailing list