kernel package building

Ken Moffat ken at linuxfromscratch.org
Tue Jul 10 09:28:49 PDT 2007


On Tue, Jul 10, 2007 at 12:47:29PM -0300, ICMP Request wrote:

 Just to query some of this -
> 
> 2. Extract it to a dir, usually under /usr/src:
> 

 Why ?  Apart from when I'm in chroot, I always build in ~/ as a
normal user.  If you run into kernel errors when building as root
(seen that twice, I think) you will find that upstream doesn't
really care.  For the book, the kernel version has been tested, so
it shouldn't be a problem.

> bash# cd /usr/src
> bash# tar -zxf linux-x.y.z.tar.gz
> 
> (if it's a .tar.bz2, use 'tar -jxf')
> 

 And if you are using a semi-recent LFS, just tar -xf will do it.
> OPTIONAL: Make a Symlink to "Linux" and remove any other previously created:
> 
> bash# rm -f linux
> bash# ln -s linux-x.y.z linux
> 

 Again, why ?  This used to be the way to build external modules,
but shouldn't be required for 2.6.

> 7. Copy the kernel headers to /usr/include:
> 

 NO!  The headers in /usr/include are what glibc was compiled
against.
> 7.1 Using raw kernel headers (I do not recommend):
> 
> bash# cp -rp include/{asm-generic,asm-[your_arch],linux,mtd,scsci,sound} 
> /usr/include/
> 

 If your use of 'raw' is the same as mine ("the kernel's own
headers, not sanitised for userspace"), this is definitely a very
bad idea for 2.6.  Fortunately, the kernel can now sanitise its own
headers, which is what we do when we build LFS (fedora uses this,
distros will undoubtedly move to this, at least for the main
architectures).  But only the other day somebody had problems caused
by repeating the book's instructions on a running system.
> 
> 7.2 Using CLFS Headers (I recommend):
> 
> So far, the raw kernel headers are known for not being stable. There's a 
> lot of discussion about this. CLFS is known for making sane headers so I 
> recommend you to check the linux-headers-xyz package from:
> 
> http://cross-lfs.org/files/packages/svn/
> 
> It's RECOMMENDED that you do use the same headers-xyz version as your 
> kernel version. See why I wanted you to read this before downloading the 
> kernel? ;)
> 
 For building glibc, kernel headers should be no newer than the
kernel you are going to run, or as Dan pointed out in a different
thread yesterday, some apps may try to use non-existent interfaces.
Most people will want to retain an old kernel until they are
confident that the new kernel works adequately.

 To repeat myself, do not bother upgrading the kernel headers when
you upgrade the kernel - only do it if you upgrade glibc: and that
is not recommended - build a new system.  Yes, I know some people do
it for point releases of glibc, but AFAIK the last point release was
on 2.3, and you will need good backups.

 Going O/T for this list, when you build glibc I recommend the
kernel's own sanitised headers for all the platforms I have (x86,
x86_64, powerpc).  OK, on pure64 x86_64 that means I have redundant
32-bit headers, but it does no harm.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce



More information about the lfs-support mailing list