SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Originally posted by monz
If the links pointing to the currently used kernelversion are set correctly in /usr/src, the right set of headers will be used.
wich links are you referring to ?
Quote:
Originally posted by monz
If some obscure program is specifically designed to -want- some other (2.4.x) headers, it's time to upgrade that program anyway, IMHO.
any program that uses glibc will probally need 2.4 headers to compile AFAIK.
but as said, using 2.6 headers *might* give problems, it's not allways the case i guess.
For some understanding on linking kernel headers, and where to build,
check the README file from Linus that comes with EVERY kernel source:
Quote:
INSTALLING the kernel:
- If you install the full sources, put the kernel tarball in a
directory where you have permissions (eg. your home directory) and
unpack it:
gzip -cd linux-2.6.XX.tar.gz | tar xvf -
Replace "XX" with the version number of the latest kernel.
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 asked glibc maintainers to stop the symlink insanity for the last
few years now, but it doesn't seem to happen.
Basically, that symlink should not be a symlink. It's a symlink for
historical reasons, none of them very good any more (and haven't been
for a long time), and it's a disaster unless you want to be a C library
developer. Which not very many people want to be.
The fact is, that the header files should match the library you link
against, not the kernel you run on.
Think about it a bit.. Imagine that the kernel introduces a new "struct
X", and maintains binary backwards compatibility by having an old system
call in the old place that gets passed a pointer to "struct old_X".
It's all compatible, because binaries compiled for the old kernel will
still continue to run - they'll use the same old interfaces they are
still used to, and they obviously do not know about the new ones.
Now, if you start mixing a new kernel header file with an old binary
"glibc", you get into trouble. The new kernel header file will use the
_new_ "struct X", because it will assume that anybody compiling against
it is after the new-and-improved interfaces that the new kernel
provides.
But then you link that program (with the new "struct X") to the binary
library object archives that were compiled with the old header files,
that use the old "struct old_X" (which _used_ to be X), and that use the
old system call entry-points that have the compatibility stuff to take
"struct old_X".
Boom! Do you see the disconnect?
In short, the _only_ people who should update their /usr/include/linux
tree are the people who actually make library releases and compile their
own glibc, because if they want to take advantaged of new kernel
features they need those new definitions. That way there is never any
conflict between the library and the headers, and you never get warnings
like the above..
>Mr. Ulrich Drepper (one of the glibc/gcc guys) gave me a standard
>"don't use kernel headers directly" answer. But neither gcc.c,
>neither the above small program use kernel headers. I suppose he
>referred to /usr/include/linux/* as (I think) he did not understand me.
No. He really meant that you should not use the kernel headers: you
should use the headers that glibc came with. It is probably a redhat bug
that those headers were a symbolic link.
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
it.
- 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 ;)
Linus
So you see why people have trouble in this area, but I don't understand
why these Johnny-come-lately-guys still post their kernel build guides with
the instructions incorrect. I guess they've never bothered to read what the
author of the kernel wrote.
It's rumored that Pat will come out with a 10.2 in August, still with a 2.4.x
kernel, and 11.0 will be the end of this year or the first of 2006 with 2.6.x
Time will tell...
Thats true. I've heard it many times, and since all the applications that need the kernel source check /lib/modules/<kernel-version>/build for the kernel source directory, there is no problem with having the kernel somewhere else.
Kala! that's a first for me. Yes i do read documentations, but i guess all of what i read regarding kernel compiling was mostly from the forums and tutorials posted here...
Well, time to try out the *propper* method of compilng with 2.6.12.2 now
If you'll look under /usr/src/linux-2.4.29/ you'll find your kernel source,
and that is what you should have there, not the kernel of the day. It
should be somewhere like this:
Where you would find out is reading the INSTALL and README files which
usually come with the apps before you compile. That's what I did...I had
compiled once with the DaOne guide and it didn't work, so I read Linus'
README file. Compiled again the correct way, didn't have to edit any other
files (such as the Makefile or whatever), and it just works. You only need
a few steps to compile a 2.6.x kernel...they're in the README file.
It might be wise to change the symlink /usr/src/linux back to whatever
came with your Linux distro, then compile a new kernel under /home but
it might not be necessary. That just depends upon if you later compile
something that needs the headers that glibc was compiled with.
Just remember that anyone can post whatever they want on the internet,
and as the LQ disclaimer says:
Quote:
We would like to stress that you should fully understand what a recommended change may do to your system. You should not give anyone you do not know login information to your system. LinuxQuestions.org cannot be held liable for for anything you do as a result of information obtained at this site.
I doubt most people mean us any harm, they're just posting what they've
been doing that seems to work.
From this I gather that it is smarter to get instructions from the people who made the app in the first place, rather than searching for some hack that just so happends to work.
Now, about the symlink linux---->
Linus says
Code:
Basically, that symlink should not be a symlink. It's a symlink for
historical reasons, none of them very good any more (and haven't been
for a long time), and it's a disaster unless you want to be a C library
developer. Which not very many people want to be.
Some things seem to work, and might never create a problem for most
systems. That /usr/src/linux business isn't really a hack, but it can jump
up and bite you later on. I'm almost certain I'll get flamed by someone
saying something like, "It always works for me..." but as you say here,
I follow the directions of the guys who write the apps. We must also
remember, it's a Personal Computer and we're all free to run them
however we want...
Originally posted by mianve From this I gather that it is smarter to get instructions from the people who made the app in the first place, rather than searching for some hack that just so happends to work.
Now, about the symlink linux---->
Linus says
Code:
Basically, that symlink should not be a symlink. It's a symlink for
historical reasons, none of them very good any more (and haven't been
for a long time), and it's a disaster unless you want to be a C library
developer. Which not very many people want to be.
That's just the point. It's not broken...people symlinking the kernel
sources to /usr/src/linux is what can break it. Just leave that link
alone like Linus says, and build your kernels somewhere under /home
and you'll be fine. That's where your new kernel sources will be, and
the ones that the libraries that your distro was built with will still be
under /usr/src/linux
For instance, I create a directory just for building from source:
That's apps that I've built from source...most of them using SlackBuild scripts, and
a few with checkinstall...all made into nice Slackpacks except the kernels. There
are others that I've built on other boxen and moved the Slackpacks into another
directory, ~/tarballs/
it's a Personal Computer and we're all free to run them
I understand that but....
I would prefer to do things as they should be and I belive that Linus would know more about the kernel than anyone else that comes to mind.
I would rather not want to take that rare chance that something would come back to bite me.
While we are talking. I have another question somewhat related to the subject. Someone posted yesterday that Patrick said that Slackware 11 would have a 2.6.x kernel as a default kernel. Wether that's true or not, I imagine somewhere down the road he may go to a kernel other than 2.4.x. be it a 2.6.x or a 2.8.x kernel. I would assume then he would also use new kernel header files.
I would think then he would have to recompile glibc and everything else to work correctly. That being said, I wonder if even though I continue to keep updated to Slackware current, one day I will have to do a complete reinstall when he decides to use the new kernel and header files. It seems that would be the thing to do.
it's a Personal Computer and we're all free to run them
I understand that but....
I would prefer to do things as they should be and I belive that Linus would know more about the kernel than anyone else that comes to mind.
I would rather not want to take that rare chance that something would come back to bite me.
I agree with you on that point.
Quote:
While we are talking. I have another question somewhat related to the subject. Someone posted yesterday that Patrick said that Slackware 11 would have a 2.6.x kernel as a default kernel. Wether that's true or not, I imagine somewhere down the road he may go to a kernel other than 2.4.x. be it a 2.6.x or a 2.8.x kernel. I would assume then he would also use new kernel header files.
I would think then he would have to recompile glibc and everything else to work correctly. That being said, I wonder if even though I continue to keep updated to Slackware current, one day I will have to do a complete reinstall when he decides to use the new kernel and header files. It seems that would be the thing to do.
If you're running -current, then you'll be upgrading glibc when Patrick does, and if you need to do anything differently, Pat will have included it in the Slackware -current ChangeLog. When he releases Slack-10.2 or
Slack-11.0, you can use the kernel he uses and put it in /usr/src/linux at that time. I think we're going to
see another release of Slackware with a 2.4.x kernel before Slack-11.0 with a 2.6.x ... just my opinion.
You should read the present Slackeare -current ChangeLog thoroughly, cause Pat does keep us pretty
much up-to-date in there.
Hey, I'm not the brightest star on the planet...I grew up in the backwoods of
Mississippi ;)
I do, however, want to do things The Slackware Way (TM) with my systems, and
run my kernel the Linus Torvalds Way (TM). I've still got a whole lot to learn, and
these 5 Slackware boxen here in China are evidence. Sometimes they are in
different states of disarray. I'm glad this has helped you is some small way.
Sorry to have hijacked xushi's thread, but I don't think he'll mind...especially while
he's in the States and has good news about his heart. ;)
Last edited by Bruce Hill; 07-01-2005 at 09:25 AM.
For the record, I've always compiled new kernels under /usr/src, never had a problem, and don't expect to. But that's no surprise, since I've never used and never will use a distro with a broken /usr/include/linux tree...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
