| Summary: | fix /usr/include/{asm,linux} to properly support different kernel versions | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | mlmoser |
| Component: | [OLD] Core system | Assignee: | Martin Schlemmer (RETIRED) <azarah> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | critical | CC: | dev-portage, docs-team, kumba, x86-kernel |
| Priority: | Highest | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
mlmoser
2003-09-06 23:27:14 UTC
yes we know and we've been working on a solution ... there's a few threads on LKML you might want to read If you want to be perfectly straight with what is in the Documentation of the kernel sources, you shouldn't even have the sources inside /usr/src/linux :/ I've had a similar discussion some time ago with lolo. I've asked him this: """ > In Gentoo Linux, the kernel sourcecode is installed in /usr/src/linux-version > and /usr/linux is a symlink to that directory. > > However, the Linux kernel README clearly states: > > [...] > Do NOT use the /usr/src/linux area! This area has a (usually > incomplete) set of kernel headers that are used by the library header > files. They should match the library, and not get messed up by > whatever the kernel-du-jour happens to be. > [...] > > I've found the following document concerning this problem: > http://www.linuxgazette.com/issue62/tag/4.html > > This is a discussion with a person familiar with kernel developing. > > Can you shed any lights on this, and if Gentoo's "breaking" this with unknown > consequences, can you fix this? """ I've had the following reply: Actually we solve this concern in a very different way. Most linux distributions use a symlink to /usr/src/linux/include/asm and /usr/src/linux/include/linux for the linux kernel headers for the C library. We do not. We physically install headers during system installation directly to /usr/src/include/linux and /usr/src/include/asm so it is then perfectly acceptable to use /usr/src/linux for whatever kernel the system happens to be running. Just letting you know :) > Actually we solve this concern in a very different way. Most linux
> distributions use a symlink to /usr/src/linux/include/asm and
> /usr/src/linux/include/linux for the linux kernel headers for the C library.
> We do not. We physically install headers during system installation
> directly to /usr/src/include/linux and /usr/src/include/asm so it is then
> perfectly acceptable to use /usr/src/linux for whatever kernel the system
> happens to be running.
This is how we have been handling it from day one. The only places where I know
of breakage is if you user symlink his live kernel to /usr/include/{asm,linux},
or if he does not maintain his /usr/src/linux symlink (but this is more for
things like svgalib, etc that needs the live kernel headers).
Isn't this documented anymore ? It used to be in big red (ok, not that bad ;):
Do not remove /usr/include/{asm,linux} or replace them with a diff version!
If not, we should get the docs fixed, and not try to 'fix' it with a fix that
will complicate everything. We might even have portage check the
/usr/include/{asm,linux} to be directories, and not symlinks, and also if
/usr/src/linux symlink is valid .. Nick?
Alright, so if you all have the kernel headers installed to /usr/src/linux and /usr/src/asm, why is it that I don't see these directories, and that the linux-headers ebuild installs files to /usr/include/linux and /usr/include/asm ?
The problem is that the kernel breaks unless /usr/include/{linux|asm} are symlinked into the current kernel tree; but if they are, many compiles will break because the library doesn't like those headers. This means that under your current scheme, you need to have these directories have different contents at different times, depending on what you are doing.
I can't believe I'm the only one that has compiled a kernel and had depmod -ae spit out every symbol in every module as being unresolved. Try a 2.4.22-openMosix or otherwise heavily patched kernel with /usr/include/{linux|asm} containing the 2.4.19 vanilla's. The depmod -ae -F System.map that gets run on make modules_install is fine, but if you don't give it the System.map, it doesn't work. modprobe doesn't work either.
It seems this problem is somewhat an enigma. The kernel build system really is supposed to use the headers in ${TOPDIR}/include, NOT /usr/include, but for some reason it doesn't seem to work that way. Those of us using older versions of the kernel for various reasons (available patches, broken h/w, etc) can't really rely on a new, fixed build system either. Looks like you've all painted eachother into your corners. Who's got a mop?
I think you are a bit confused. Default apps, etc should use /usr/include/.. for 'kernel' headers. Things like nvidia-kernel, etc in *Gentoo* by default is (or should be) fixed to use headers in /usr/src/linux/include, which should point to your current, or new kernel that you want to use (meaning it is possible to compile a new kernel, then merge nvidia-kernel, and then reboot having nvidia.o ready to be loaded with the new kernel). The kernel should by default use like you said, the headers in $TOPDIR/include, and in newer kernels '-nostdinc -iwithprefix include' is added to CFLAGS to make sure of this (have a look at bug #8132). If it breaks for 2.4.20 and later, it might be a kernel/gcc problem. It might also be as in #8132 a wrapper (such as those from gcc-config, ccache or distcc) that could cause breakage. Have you tried another kernel than 2.4.22-openmosix? Lastly be nice =) The om prepatch for .22 was the last I tried. I've had problems with various. I still do the movement by hand based on situation. I don't use a wrapper though . . . just `make menuconfig clean dep bzImage modules && rm -rf /lib/modules/{kernver} && make modules_install && cp arch/i386/boot/bzImage /boot/bzImage-{kernver}`. And I AM being nice, so shut up :-p
Could you try the fix in: http://bugs.gentoo.org/show_bug.cgi?id=8132#c21 and see if that fixes. If so, we know it is similar issues ... Works this side. Please reopen if you have more to add. |
