Where to place the kernel source

jatho · n00b Joined: 09 Aug 2004 Posts: 5

I've got a question about the kernel source.
In the kernel documentation it says that you shouldn't place the source in /usr/src/linux because it can contain an incomplete set of header files that the system needs. This seems to imply that the symlink /usr/src/linux never should be changed to another directory than the current, which to me seems a little bit strange.

If so, why does portage place all sources in this directory by default? And why is it important to change the /usr/src/linux to the new kernel source directory? Are the files in this directory really needed after the kernel is compiled and in place? Or are they perhaps used when other applications are compiled?

Thanks in advance for any comments about this!

adaptr · Posted: Mon Aug 09, 2004 11:48 am Post subject:

That's just not how it works.

1. you do not decide where to place kernel files - portage does that for you, in a directory named after the kernel version, e.g. /usr/src/kernel-2.6.7-r11
2. Then, a link is made from that directory to /usr/src/linux - which is always a link, there is never any content in /usr/src/linux. Not. Ever.
Be aware that you have to change that link for every kernel after the first!
3. The header files are not part of the source tree - they're physically there, but used from /usr/include, which is linked to.. /usr/src/linux!
That's the main reason the build will only work from /usr/src/linux.

So, to answer your questions:

No, portage does not ever place anything in /usr/src/linux - nothing does.
It is important to change the symlink to the kernel you want to build, because things will fail mightily if you don't.
None of these files are used after the kernel is in place.
The headers used when applications are compiled are in /usr/include/*; these are chosen to correspond to the correct glibc libraries, which is what the system runs on (as opposed to the kernel).
_________________
>>> emerge (3 of 7) mcse/70-293 to /
Essential tools: gentoolkit eix profuse screen

jwj · Apprentice Joined: 07 May 2004 Posts: 240

jatho · n00b Joined: 09 Aug 2004 Posts: 5

Thank you for your quick responses!
Maybe I put it a little sloppy, I didn't mean that portage placed any files in the symlink linux, I meant in the directory that it points to. But you got my question right anyway!

So basically, what that comment about not using /usr/src/linux in the kernel documentation means is just that it would be very unwise to untar (if not using gentoo) the sources into the directory that /usr/src/linux points to?

adaptr · Posted: Mon Aug 09, 2004 9:09 pm Post subject:

wrc1944 · Posted: Tue Aug 10, 2004 5:32 am Post subject:

adaptr,
I read this thread with great interest. Are we only talking about kernels installed with portage and/or genkernel? Let me explain what I do, and perhaps you can help me understand why this works perfectly, and if I'm ever going to have problems I'm presently unaware of.

For two years, I've manually compiled and tested hundreds of kernels since 2.5.67 in my /home/wrc/kernels directory, both in Gentoo, Mandrake, and many other distros. I never use /usr/src/linux anymore, and never use an initrd, or System.map file. I never worry about changing kernel symlinks.

I just extract the kernel source in /home/wrc/kernels to linux-whatever, cd to that directory, and do my patches (if any), config, and compiling, as user. Then finally, I su to root, do make modules_install, mount /boot, and then:

copy arch/i386/boot/bzImage /boot/whatever kernel name

Then I edit grub, umount /boot, and I'm done. This procedure never fails, and I've never had any "header" related problems with anything, in any distro I've used, that are being talked about here. It doesn't seem to matter that the kernel source is not in /usr/src. It would seem to me if my procedure is incorrect, something would have gone wrong by now, as I've done this on at least 15 different boxes and different hardware. Maybe I'm just missing something, but at least for me, this method works perfectly.

Any advice or further enlightenment is appreciated,

wrc1944
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.40-r5, gcc-14
kernel-6.12.8 USE=experimental python3_12.7-final-0

adaptr · Posted: Tue Aug 10, 2004 10:18 am Post subject:

Well - I certainly won't try to claim anything like your experience... ;-)

What I think it means is that this is Gentoo - one specific implementation of how Linux can be used.

And I may be utterly wrong about te system headers, of course.
A little more thinking leads me to conclude that of course there can be symlinks to the kernel source if and only if the kernel headers used for the system are the same ones.

In that obvious case duplicating the kernel headers would be plain silly.

So they can - in the unique case of kernel headers == system headers.
But they don't have to.

And as for the /usr/src location - never tried it, never felt the need, I jus' follow that them there thing they tell me to do :oops:

Logic forces me to state that the only reason it could be mandatory to use /usr/src/linux is when something integral to the kernel build references that location from the outside in.

Of course it works if you get it working - cue theoretical scientist jokes here.
_________________
>>> emerge (3 of 7) mcse/70-293 to /
Essential tools: gentoolkit eix profuse screen

wrc1944 · Posted: Tue Aug 10, 2004 2:55 pm Post subject:

Hmmm.. I sure wish I understood all this "headers" business better. As it is, I'm pretty confused about the entire subject. IIRC, a while back I read something about that they are now included in glibc. I guess I'll google some, and search a few of the larger Linux forums for more info, and see if I can arrive at a better understanding of what's actually going on.

I just looked in /usr/include/linux, and all the C Header files and other folders (521 files, 10 folders) have the date 07-28-03, the date I installed Gentoo on this box. However, in /usr/include/, the C Header files/folders (360 files, 128 folders) have different and more recent dates (last few months), which seem to relate to when I either updated glibc, or compiled kernels in /home/wrc/kernels. I'm starting to think that kernels compiled as root in /usr/src/linux-whatever use these, and kernels compiled somewhere else as user, as I do, use their own headers in that specific source folder's /linux/include directory , wherever it is located. However, at this point, I just don't really know enough (or even understand what I do know) to come to a correct conclusion.
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.40-r5, gcc-14
kernel-6.12.8 USE=experimental python3_12.7-final-0

jatho · n00b Joined: 09 Aug 2004 Posts: 5

I've been googling around and reading a little bit here and a little bit there and I've found a few things.

It doesn't ever seem to be mandatory to install the sources in the /usr/src/ area. Apparently in early versions of the 2.4.* kernel many distributions used symlinks /usr/include/{asm,linux} to /usr/src/linux/include/{asm,include} instead of keeping the header files directly in directories under /usr/include. If you then upgraded the kernel and used /usr/src/linux for installing the source the symlinks would point to the newer kernel headers which weren't the header files you compiled glibc against. And that would surely create problems.

So I think the recommendation about not using /usr/src/linux is because of these historical(?) reasons.

As far as I know, Gentoo doesn't use these symlinks so then there won't be any problems. :roll:

The current "official" way of keeping the headerfiles in sync seems to be to distribute a linux-libc-header package along with glibc and that would seem to explain why the dates of your headerfiles differ wrc1944.

wrc1944 · Posted: Tue Aug 10, 2004 7:52 pm Post subject:

Hmmmm. Very interesting. If I understand this correctly, I guess that also explains why I've never had any problems, and everything regarding kernels, kernel source, headers, and glibc stays in sync?

How about that "emerge sync && emerge -uD system"!
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.40-r5, gcc-14
kernel-6.12.8 USE=experimental python3_12.7-final-0

Genone · Posted: Wed Aug 11, 2004 5:28 am Post subject:

http://uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html

wrc1944 · Posted: Wed Aug 11, 2004 6:17 am Post subject:

Thanks Genone,
Although I'm not sure I really understand this entire article, let me quote the conclusion at the bottom. Somehow, I luckily arrived at this (without really understanding why), for it is exactly what I've been doing for almost two years. I've always left the original kernel, kernel source, and /lib/modules/ intact, from any distro I've ever installed.

One question: Does the info quoted below mean that since those using Gentoo do once in a while compile their own glibc when they do emerge -u system, should they consciously update the /usr/include/linux tree? Or is emerge/portage taking care of that for us? Since I have no problems with all my 2.6.xx kernel testing, can I assume this is the case?

wrc1944

Genone · Posted: Wed Aug 11, 2004 6:51 am Post subject:

Well, if you ever update your linux-headers (or linux26-headers) package you should recompile your libc too, but you don't have to update your headers if you don't want to. In general you only update your headers if you want to use some specific new kernel features (like NPTL).