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