LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Klibc and kernel headers (http://www.linuxquestions.org/questions/slackware-14/klibc-and-kernel-headers-4175436909/)

pchristy 11-13-2012 04:47 AM

Klibc and kernel headers
 
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?

--
Pete

wildwizard 11-13-2012 06:15 AM

Does this help :-

http://slackbuilds.org/repository/14.0/misc/klibc/

pchristy 11-13-2012 09:40 AM

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!

:(

--
Pete

ponce 11-13-2012 10:12 AM

that's strange, it builds fine here http://pastebin.com/raw.php?i=QnkMuu25

pchristy 11-13-2012 12:40 PM

Quote:

Originally Posted by ponce (Post 4828494)
that's strange, it builds fine here http://pastebin.com/raw.php?i=QnkMuu25

Yes, but you seem to be building against the stock Slackware kernel! The problem arises when you try and build it against a different kernel. I'm running 3.6.3!

--
Pete

ponce 11-13-2012 02:31 PM

maybe the fastest solution is to boot with the standard kernel (huge or generic should make no difference), build klibc and reboot with your custom one.

pchristy 11-14-2012 07:20 AM

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.....!

--
Pete

wildwizard 11-14-2012 09:43 PM

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

/lib/modules/3.2.29

with a symlink in that directory called source which points to /usr/src/linux-3.2.29

Code:

root@indigo:/lib/modules/3.2.29# ls -l
lrwxrwxrwx  1 root root    21 Sep 29 17:07 source -> /usr/src/linux-3.2.29/


pchristy 11-15-2012 10:07 AM

Yes, I've been around that route, thanks!

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!

Grrr!

--
Pete

ponce 11-15-2012 11:24 AM

Quote:

Originally Posted by pchristy (Post 4829137)
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!

I'm just guessing, no experience at all with uvesa/klibc, but I think you can also rebuild the stock kernel with CONFIG_FB_UVESA enabled, boot with that and then build klibc.

turtleli 11-15-2012 11:54 AM

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
Code:

make headers_install
it should install headers to /usr/src/linux-3.6.3/usr. Then edit the slackbuild so that
Code:

KLIBCKERNELSRC=/lib/modules/$KERNEL/source HOSTCFLAGS=$SLKCFLAGS make
KLIBCKERNELSRC=/lib/modules/$KERNEL/source make install INSTALLROOT=$PKG

is changed to
Code:

KLIBCKERNELSRC=/lib/modules/$KERNEL/source/usr HOSTCFLAGS=$SLKCFLAGS make
KLIBCKERNELSRC=/lib/modules/$KERNEL/source/usr make install INSTALLROOT=$PKG

See if that works.

pchristy 11-15-2012 12:31 PM

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
"./usr/include".
-----------------------------------------------------------------------------

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 ?

Cheers!

turtleli 11-15-2012 12:40 PM

Quote:

Originally Posted by pchristy (Post 4830191)
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 ?

Yes. I've tried it with my kernel sources at /usr/src/linux-3.4.13 and it generated an include directory at /usr/src/linux-3.4.13/usr.

pchristy 11-15-2012 01:16 PM

Bingo! Thank you for supplying the bit of knowledge I was missing!

I'll try it over the week-end!

Many thanks! And when I get home, I'll put a message up on the mailing list apologising for my misunderstanding!

--
Pete

pchristy 11-17-2012 05:16 AM

Turtleli

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:

KLIBCLD usr/gzip/gzip
LN usr/gzip/gunzip
LN usr/gzip/zcat
INSTALL headers + man pages to /tmp/SBo/package-klibc/usr/lib64/klibc
make[2]: *** No rule to make target `headers_install'. Stop.
make[1]: *** [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:

KLIBCCC usr/klibc/syscalls/typesize.o
In file included from /tmp/SBo/klibc-2.0.1/usr/klibc/../include/signal.h:12:0,
from usr/klibc/syscalls/syscommon.h:9,
from usr/klibc/syscalls/typesize.c:1:
/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.


All times are GMT -5. The time now is 06:38 PM.