f9v2c4qi <w9d.gura.bl83dhcxvz@antichef.com> wrote:

> http://www.freewebs.com/specfiles/help/kernel-compiling

It's amazing how all these howtos are written by people who haven't
even read the directions that come with the kernel itself. This one,
similar to other links, states:

<quote>
The linux symlink should always point to your current linux kernel tree.
It's best to have a symlink of "linux" pointing to "linux-x.x.x".
Whenever you get a a new kernel, you then remove "linux", which is the
symlink, unpack the new kernel into /usr/src, mv the new "linux" directory
to "linux-x.x.x" (where x.x.x is the new kernel), and link linux to the new
kernel tree. 'ln -s linux-x.x.x linux'.
</quote>

Which is simply wrong. As the kernel README states:

<quote>
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.
</quote>

- Kurt

On Sun, 17 Aug 2003, it was written:
> William Hunt wrote:
>> ??? and so just how is that -not- RTFM ?
>
> I did not make that up.
> First result searching google for "kernel compile no rtfm".
> Try it.

yes indeed. and, not suprisingly, the information given in
that FM is also incorrect, same as Kurt points out about the
other "no RTFM" link posted today. oh well. it's a common
problem. Linus hisself posted a rant about the issue recently.


>> can one somehow absorb the information therein -without- reading it?
>
> I agree.

cool. I tried it by sleeping with Stevens under my pillow, but all
i got for my effort was a crick in the neck.


--
William Hunt, Portland Oregon USA

AverageJoe <AverageJoe@.> wrote:
>
> Thanks. Geeh, thats how I updated to 2.4.21. Hmmm, oh well, looks like more
> RTFM for me.

It's not an issue if you are recompiling the stock kernel, and probably
won't be a problem with small version changes. Most people don't seem
to run into any problems. But why take a chance.

The only issue I am not completely sure of is what to do when compiling
modules that are not part of the kernel - say the Nvidia driver modules.
I figure it's best to compile such modules using the kernel headers of the
kernel they are to be used with and not the stock headers.

- Kurt

Kurt wrote:
>
> The only issue I am not completely sure of is what to do when compiling
> modules that are not part of the kernel - say the Nvidia driver modules.
> I figure it's best to compile such modules using the kernel headers of the
> kernel they are to be used with and not the stock headers.

The Nvidia drivers can be built for the running kernel with the
following before installing them.

sh ./NVIDIA-Linux-x86-1.0-4496-pkg1.run --add-this-kernel

This will unpack compile and make a new package and append
"-custom" to the name of the package.

But it sounds like you didn't RTFM for the Nvidia drivers.

--
Confucius: He who play in root, eventually kill tree.
Registered with The Linux Counter. http://counter.li.org/
Slackware 9.0 Kernel 2.4.21 i686 (GCC) 3.3
Uptime: 22:18, 1 user, load average: 1.19, 1.14, 1.10

well the only kernel headers on my system are in /usr/src/linux >
linux-x.x.x,
the only headers are the ones in the actual kernel tree I'm using.
That statement in the README has always confused me, cause there is
nothing
else there. I have compiled umpteen kernels this way for years, and
have compiled about a million and a half programs. If I'm wrong
I sure would like to know wtf I'm doing wrong. After installing
slackware
there was tree which had the same version as the kernel, so if you
upgrade the
kernel, why keep old headers from a previous kernel?

> <quote>
> The linux symlink should always point to your current linux kernel tree.
> It's best to have a symlink of "linux" pointing to "linux-x.x.x".
> Whenever you get a a new kernel, you then remove "linux", which is the
> symlink, unpack the new kernel into /usr/src, mv the new "linux" directory
> to "linux-x.x.x" (where x.x.x is the new kernel), and link linux to the new
> kernel tree. 'ln -s linux-x.x.x linux'.
> </quote>
>
> Which is simply wrong. As the kernel README states:
>
> <quote>
> 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.
> </quote>
>
> - Kurt

f9v2c4qi <w9d.gura.bl83dhcxvz@antichef.com> wrote:
> well the only kernel headers on my system are in /usr/src/linux >
> linux-x.x.x,

Check out "/usr/modules/2.4.whatever/build/include"

That will have kernel headers for each specific kernel.

/usr/include also appears to have kernel headers (somewhat incomplete),
plus many other headers not related to the kernel. These header files
do not seem to match those in the stock kernel (/usr/src/linux).

> That statement in the README has always confused me, cause there is

It confuses me too. I've installed some distros where there is nothing
in /usr/src/linux.

> there was tree which had the same version as the kernel, so if you
> upgrade the
> kernel, why keep old headers from a previous kernel?

Because these headers should match what the library installed on
your system was compiled against.

I'm guessing people don't tend to run into problems because the headers
are mostly backwards compatible? I was screwing around with adding
support for my south bridge chip to 2.4.18 some time back and found
this is not always the case though.

My question is this. Where should the kernel headers that correspond
to the system libraries be installed? "/usr/include" or
"/usr/src/linux/include"? I guess this isn't as much of an issue as
knowing where a certain Makefile will look. If you don't want to worry
about this issue, it's probably good to make sure you don't mess
with /usr/src/linux. However, I'm still confused as to why the kernel
header files in /usr/include don't match the stock kernel. The asm
files match, but some of the other directories have a lot of differences.

I hate to waste his time, but I'm thinking I might just write Pat and
see what he as to say. Everything I can find on the net about this is
written by someone with just as much of a clue as I have, which isn't
much.

- Kurt

David <thunderbolt01@netscape.net> wrote:
>
> I would say they belong in /usr/include which is where Pat puts
> them as well as most if not all of the distro's including LFS.
>

LFS - excellent - you reminded me to go back and re-read some of that
documentation. Finally, I resolved my last bit of confusion.
"/usr/include" is where the kernel header files that glibc were compiled
against reside. The problem was that most distributions used to make
symlinks between the "/usr/include" directories, and the
"/usr/src/linux/include" directories.

This means as long as sym links from "/usr/include" to
"/usr/src/linux/include" are not being used, there is actually no problem
dumping the latest kernel source that you want to play with in
"/usr/src/linux".

- Kurt

I just asked a SIMPLE QUESTION to be answered with A REASONABLE response,
But SOME on YOU people would rather talk about the SORTCOMINGS. now I'm not
an everyday user of linux but i would like to be, IF i could get a little
help from some people who might be able to help a biginger out once in a
while. The People who say RTFM then point you to a REDHAT site would be
better off not summinint anything to MY questions. I was looking for a stait
forward aproch at linux help only..


--------This Don't aply to any one who tryed to help and I thank them for
that.----
The other need to SEE A SHRINK about the ANGER issuse.


"widgetcomputers" <widgetcomputers1@comcast.net> wrote in message
news:QKL%a.166796$o%2.68046@sccrnsc02...
> This might be an easy question to answer for some one about how to you
make
> and new kernel in the Slackware 9.0 I need a step by step instruction to
> help me config my new kernel in SLACK
>
> Thanks
>
>

widgetcomputers wrote:
> I just asked a SIMPLE QUESTION to be answered with A
> REASONABLE response, But SOME on YOU people would rather talk
> about the SORTCOMINGS. now I'm not an everyday user of linux
> but i would like to be, IF i could get a little help from some
> people who might be able to help a biginger out once in a
> while. The People who say RTFM then point you to a REDHAT site
> would be better off not summinint anything to MY questions. I
> was looking for a stait forward aproch at linux help only..

unpack kernel sources in /usr/src
cd into kernel source directory

If you are re-compiling the same kernel version that you are
running then you need to: Edit Makefile and add something to the
EXTRAVERSION line to differentiate new kernel from the old.

make mrproper
make menuconfig

configure kernel for your system here and save config to
alternate file. This will be helpful if you have to re-compile it
again for some reason.

make dep
make clean
make bzImage
make modules
make modules_install
cp arch/i386/boot/bzImage /boot/vmlinuz-x.x.xx-x
cp System.map /boot/System.map-x.x.xx-x

Edit /etc/lilo.conf and add a section for the new kernel using
the correct image for the new kernel.

run "lilo -v" and check for any errors

All this needs to be done as "root".
DO NOT remove the old kernel until you know the new kernel works.

--
Confucius: He who play in root, eventually kill tree.
Registered with The Linux Counter. http://counter.li.org/
Slackware 9.0 Kernel 2.4.21 i686 (GCC) 3.3
Uptime: 2 days, 18:34, 1 user, load average: 1.16, 1.21, 1.24

In article <soA0b.203142$Ho3.26169@sccrnsc03>, David wrote:
> All this needs to be done as "root".

Actually it's preferable to have kernel sources owned by a non-root
user. Only "make modules_install" and beyond need root privileges. And
for those who appreciate economy, multiple make targets can be listed on
the same command line, in sequence:
make menuconfig clean dep bzImage modules
--
/dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
or put "not-spam" or "/dev/rob0" in Subject header to reply