[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: compiling (or rather, failing to compile) a kernel

On Tue, Nov 13, 2012 at 2:41 AM, Tom Furie <tom@furie.org.uk> wrote:
> On Tue, Nov 13, 2012 at 01:59:41AM -0500, Tom H wrote:
>> The documentation says
>>  - If you install the full sources, put the kernel tarball in a
>>    directory where you have permissions (eg. your home directory)
>> which basically means "don't use /usr/src" since a regular user
>> doesn't have write access to it by default.
> Which is fine for an essentially single-user system such as a home
> desktop machine, but if you have a group of people who will be building
> software for the system, it might make sense to have the sources in a
> central location and have those people be members of a group that has
> access there.

I'd say the opposite. On a single-user system, using "/usr/src" to
check out code or unpack a source-code tarball's OK if that's what you
want to do but on a multi-user system, no way (even if this was SOP a
century or two ago)!

I've been pointed to this email of Linus's:



I would suggest that people who compile new kernels should:

 - NOT do so in /usr/src. Leave whatever kernel (probably only the
   header files) that the distribution came with there, but don't touch

 - compile the kernel in their own home directory, as their very own
   selves. No need to be root to compile the kernel. You need to be root
   to _install_ the kernel, but that's different.

 - not have a single symbolic link in sight (except the one that the
   kernel build itself sets up, namely the "linux/include/asm" symlink
   that is only used for the internal kernel compile itself)

And yes, this is what I do. My /usr/src/linux still has the old 2.2.13
header files, even though I haven't run a 2.2.13 kernel in a _loong_
time. But those headers were what glibc was compiled against, so those
headers are what matches the library object files.

And this is actually what has been the suggested environment for at
least the last five years.  I don't know why the symlink business keeps
on living on, like a bad zombie.  Pretty much every distribution still
has that broken symlink, and people still remember that the linux
sources should go into "/usr/src/linux" even though that hasn't been
true in a _loong_ time.

Is there some documentation file that I've not updated and that people
are slavishly following outdated information in? I don't read the
documentation myself, so I'd never notice ;)


Reply to: