SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I've been trying to compile klibc for a Slackware64-14.0 system, to enable the use of uvesafb.
I'm running a home-built kernel (3.6.3), and the compile fails because klibc looks for the kernel headers in /usr/include/linux rather than in the /usr/src/linux/ tree. It appears the structure in the kernel source tree is different to that in the /usr/include tree. For example, there is no symlink between asm-x86 and asm in the kernel tree, so the program fails to find the headers it wants!
The klibc maintainers insist that I should replace the Slackware kernel headers with the ones from my home-built kernel, but the Slackware documentation is equally emphatic that this should not be done!
So now I have to conflicting opinions! Advice, anyone?
Thanks for that link, but I'm already using that script! And I've tried it with both 2.0.1 and 2.0.2 as well as older versions.
The problem is that the klibc developers insist on linking to the standard kernel headers, instead of the ones in the kernel source. The Slackware documentation says don't replace the standard headers. The klibc developers say it won't compile unless you do! Stalemate!
Yes, I wondered about that, but it looks as if the kernel has to have uvesafb enabled when klibc is compiled. The stock kernel doesn't have that!
(Bangs head against brick wall!)
One other possibility has occurred to me, but it will be a day or two before I can try it. The idea is to do a "make headers_install" to a specific directory (somewhere in my home?) and then point the klibc make at that directory. Doing it that way should create the right directory structure, if not in the usual place, leaving the standard Slackware kernel headers intact and in place.
But it will be the week-end before I get chance to try it.....!
Looking more closely at the SlackBuild it passes the path for the kernel source via the /lib/modules/* path make sure that is setup correctly and has the symlink present to the source for your new kernel.
ie Default Slack 14.0 setup has
with a symlink in that directory called source which points to /usr/src/linux-3.2.29
The problem seems to be that the directory structure in the kernel source is somewhat different from that which gets installed in the "proper" headers directory (/usr/include/linux from memory - I'm at work at the moment, and not sat in front of the machine!)
In particular, in the "proper" headers directory, there are symlinks from the asm subdirectory to the appropriate processor specific directory (asm-x86) which simply don't exist in the kernel source. And that's just one example!
I tried making the necessary symlink, but then it failed with another incorrect path, and after trying to locate a couple more "missing links", I gave up - I could see me still being sat there 5 years from now still making symlinks.....!
This really is a badly written piece of software! It appears that it is only possible to build it against the default headers (which we are told we must not change). And if the default headers don't have the necessary options, you are stuffed!
I've been on to the klibc mailing list, and they just say that to make it work you have to install the new headers from the new kernel. I've pointed them at the documentation saying that this is a no-no, and since then they've gone silent!
Every other piece of software that I've compiled that requires access to a configured kernel source looks in the kernel source directory! Why this one insists on looking in completely the wrong place is a mystery, and indicates to me that the developers are very much making a one-trick pony - not fit for general purpose!
Over the week-end I'll try my trick of making a specific header location, tucked somewhere safely out of the way. If that doesn't work, I'll give up on klibc, and never let it darken my doorstep again!
I've read the exchange on the mailing list and I think you have misunderstood the developer. The developer did not at any time say to replace the kernel headers installed at /usr/include/linux. What the developer did say was that you need to use a different set of headers.
Go into /usr/src/linux-3.6.3 and use
it should install headers to /usr/src/linux-3.6.3/usr. Then edit the slackbuild so that
KLIBCKERNELSRC=/lib/modules/$KERNEL/source HOSTCFLAGS=$SLKCFLAGS make
KLIBCKERNELSRC=/lib/modules/$KERNEL/source make install INSTALLROOT=$PKG
is changed to
KLIBCKERNELSRC=/lib/modules/$KERNEL/source/usr HOSTCFLAGS=$SLKCFLAGS make
KLIBCKERNELSRC=/lib/modules/$KERNEL/source/usr make install INSTALLROOT=$PKG
Turteli: Thanks for that! If you are right, I owe him an apology! I understood that make headers_install put the headers in /usr/include/linux - in fact, I had a look inside the script, and I thought that's where it put it by default! Indeed, the kernel documentation on kernel.org states:
make headers_install ARCH=i386 INSTALL_HDR_PATH=/usr/include
<snip irrelevant stuff about architecture>
INSTALL_HDR_PATH indicates where to install the headers. It defaults to
Just noticed that leading . ! I must have missed that (should've gone to Specsavers - but that probably only means anything to UK residents!)
That implies (to me, anyway) that if I run it from the top level of the kernel source directory (/usr/src/linux-3.6.3), it will indeed put it in linux-3.6.3/usr
At least, I sincerely hope it does!
That is sort of what I was trying to achieve by passing a harmless destination to INSTALL_HDR_PATH, so I was on the right track!
Now before I try it for real, can you positively confirm that the default location won't over-write my existing headers in /usr/include/linux ?
OK, well I've now made the suggested amendments and installed the kernel headers, and yes, they did install into the kernel source tree rather than over-writing the system headers, which is what I had feared.
The changes to KLIBCKERNELSRC finally got it pointing at something that appears to work, but only up to a point! It now appears to fail at the install stage with the following error:
INSTALL headers + man pages to /tmp/SBo/package-klibc/usr/lib64/klibc
make: *** No rule to make target `headers_install'. Stop.
make: *** [header] Error 2
make: *** [install] Error 2
Now what is it complaining about?
I've also tried building 2.0.1, but that fails at the first hurdle:
In file included from /tmp/SBo/klibc-2.0.1/usr/klibc/../include/signal.h:12:0,
/tmp/SBo/klibc-2.0.1/usr/klibc/../include/sys/types.h:28:1: error: unknown type name '__kernel_nlink_t'
It seems this is a known problem and fixed in 2.0.2 - so anything before that is a no-no for recent kernels like mine.