Hi,

I put my new kernel source in /usr/src. Do I make the symbolic link /usr/src/linux point to the new kernel tree, or leave it pointing to the old one.

I've seen it answered online both ways. Some distros answer one way, other distros answer another. And usually the answer is emphatic. I haven't seen it answered by a Slackware wizard.

Specifically for my current question, I have Slackware 12.0 with installed kernel 2.6.21.5-smp and I'm upgrading to kernel 2.6.22.4-smp. This upgrade is kinda critical for me as I'm writing software that use the ivtv drivers and they've been migrating those drivers gradually into the kernel, and 2.6.22 is the version where it's been completed. This means I don't have to keep re-writing my ivtv software to reflect these changes.

Thanks,

Inside the Slackware forum there is a stickied thread about compiling the kernel (specifically a 2.6 kernel).

Very good information for first- (and second- and third-) time kernel compilers, of any distro (IMO).

I point the linux symlink to the new tree every time; it is from there that new programs look for the source to compile against, iirc.

Ok, thanks. I'm going to roll with it. I saw both the stickies, but wasn't sure if the authors were aware of the potential issues. I'm not actually a noob linux or slackware user, and have run into some odd INCLUDE_DIR anomalies when compiling my programs. I have definitely seen posts on the internet from apparently knowledgeable sources that say DO NOT use /usr/src/linux as the path to the new kernel tree. Anyway, thanks for posting.

Take a look at AlienBob's website

Same, here's mine:
One of the great things about Slackware is:
http://slackware.com/info/
Enjoy

No no no...

Slackware came with the kernel source in /usr/src/linux ... let it be . don't touch that.

Seriously, leave it alone.

Get the new src (latest and greatest) and save it anywhere (preferrably your home directory etc.)

configure and compile it. as a NORMAL user. Compiling as a root is a strict no no..

then su..
make modules_install
cp arch/.../bzImage /boot/vmlinuz-something

These 2 things are the only place where you should be root. Nowhere else.

see http://linuxmafia.com/faq/Kernel/usr...x-symlink.html

for why ... it is a post by Linus himself ...

basically /usr/src/linux is for the one with which glibc has been compiled (2.6.21.5 in case of Slack12) . Any correct program will use /lib/modules/'uname -r'/source anyways to get the src.

The post by Linus that you are referring to is seven years old and several people don't agree with it (anymore), certainly for Slackware.
Alien Bob made a statement about it. Who also made a very good howto on kernel compiling (saved my ass a couple of times...), like mannyslack already mentioned.

Ok.
From "Linux Kernel Development Second Edition" By Robert Love

Published in 2005/2006 something for kernel version 2.6.10. This guy is a major linux hacker. Greg Kroah in his book "linux kernel in a nutshell" mentions the same thing . Especially about not being a root, they had bug reports where the user compiled it as a root and as all linux hackers compiled as normal users they never could reproduce it.

I tried AlienBob's guide. Believe me , the linux kernel in a nutshell is a much much better guide /book. Available free online,.

Wow, thanks a lot to all contributors to this thread. I've run into both sides of this issue for years now.

After the first couple of posts, I went ahead and sym linked to the new kernel tree. It doesn't actually matter during the build and install process.

But after reading Linus' article, I'm switching it back. I don't think it matters that the new tree is in /usr/src, but the sym link definitely is going back to the old kernel tree. His description in there may be 7 years old, but his explanation makes perfect sense and explains problems I've had compiling programs. The libraries on my system were compiled against the "old" kernel tree, not the new one and therefore when compiling programs, discrepancies can develop that can cause nasty bugs (which I've run into). I also don't see any compelling reason to disregard his advice about not compiling as root and only using su to install. Personally I've been doing that for years.

But again, thanks to the guys on both sides of the question for posting. Reviewing the info both ways was has allowed me to come to my own conclusion.

Mike

I take it back. It probably matters a lot when you compile the new kernel. with /usr/src/linux linked to the original kernel tree I re-compiled and re-installed my new kernel. I think Linus is a pretty smart guy, and I'm doing what he says, even if it was seven years ago.

Apparently it doesn't matter for Slackware (as already stated) -- I think there's a good explanation in the stickied kernel compiling thread. That being said, I always compile my kernels as a normal user inside my HOME directory just so I don't have to be root for very long.

This is an edit of a previous post I wrote back in February 2007: http://www.linuxquestions.org/questi...04&postcount=6
I won't claim to be completely correct here, but based on a conversation with Eric, Pat, and others, I think it's more or less accurate. Eric, I know you were following this thread, so please jump in if I miss something... :-)

The whole "leave /usr/src/linux alone" is largely a remnant from the days when the kernel headers weren't shipped as a separate package. In those days, the distribution maintainer either copied or symlinked the kernel headers in /usr/src/linux-$VERSION/include/{linux,asm} to /usr/include/{linux,asm}. From what I've read, the symlink was more popular; essentially, the maintainers symlinked /usr/src/linux to /usr/src/linux-$VERSION, then made the include symlinks to /usr/src/linux. After the distro shipped, if the user installed a newer kernel and changed the /usr/src/linux symlink to point to the running kernel sources, then problems could (and often did) occur. In fact, see Linus Torvalds' explanation of what can happen: http://uwsg.iu.edu/hypermail/linux/k...07.3/0587.html


If I remember correctly, Slackware was one of the first (if not the first) distributions to start shipping a separate package of the kernel headers that were used to compile glibc, thereby making the symlink to /usr/src/linux completely irrelevant. Essentially, you should not remove or replace the contents of the kernel-headers package with the includes from a new kernel *unless* you plan to recompile glibc against those headers, and that's not something you need to do. Moral of the story: DO NOT try to use the kernel headers from the kernel version that you're running; the kernel headers should match those that were present when glibc was compiled.

To my knowledge, the only reason for the continuing presence of the /usr/src/linux symlink to the running kernel sources is due to the fact that some external software that builds kernel modules looks there. The proper place to look now is /lib/modules/$(uname -r)/source, and *most* applications do that now, but there are still a few non-compliant ones out there. If you run across these, please contact the author and kindly ask them to fix it.

Anyway, to sum up, it really doesn't matter whether you build kernels in /usr/src/ or /home/wherever - the proper links to the source directory will be created by the 'make modules_install' run (just make sure you don't delete that source directory).

Robby I bow to thee ... I can't argue with you ... but anyways some additions ...

The reason I was supporting not using /usr/src was that most ppl then compile linux as root which is not only wrong but a pain as many a times make xconfig doesn't work. Also, many a times ppl like me have multiple kernel versions running so not using /usr/src/linux is nice.

Other than that you are totally right ...

And also , if you get used to not compiling kernel in /usr/src/linux then you can easily move to distros that are not as nice as Slackware. (I assume there are still some of them as most of the newer kernels book note this problem).

Once again, thanks for the posts, guys. They've definitely shined some light on a murky area for me.

It goes a bit far to say that compiling as root is "wrong" - there's nothing wrong with it, but it's not necessary either. Being that it's not necessary, and since the general rule is to only use the root account when it is necessary, many people choose to compile kernels as normal users. As I see it, either approach is just as valid as the other. If you compile as a normal user, then you've got to be in a directory that's writable by your user, and then you have to leave the kernel source directory in the same location - in other words, you need a special location for kernel source that's writable by a normal user account. If you compile as root, you already have a special location for kernel source, and it's not writable by anyone but root. If you're concerned about compiling malicious code, well, get over that -- you're building a kernel, remember? If you don't trust the code enough to compile it as root, then you probably shouldn't compile it at all.

On the subject of /usr/src/linux, I was not suggesting that a person would actually use the 'linux' directory (or symlink) - instead, I was thinking along the lines of /usr/src/linux-2.6.21.5, /usr/src/linux-2.6.22.5, and so on.

On the subject of 'make xconfig' - well, I don't use it, and to be honest, I find it much more hassle to use than 'make menuconfig'
I personally prefer to use the keyboard as much as possible, so the ncurses menu is much friendlier (and faster) for me.

The only problem is that, as it pertains to Slackware, that is not correct.
Slackware does not (and has not in a *long* time) left the kernel headers that glibc was compiled against in /usr/src/linux, so this is a complete non-issue for us.