Could you please add an ebuild for klibc-1.5.12 to the tree? As indicated in comment 5 of bug #226107, this version fixes a problem that might be causing issues reported in bugs #212531 and #226107.
I'm join to the request. Please version bump dev-libs/klibc-1.5.11 to 1.5.12. Why klibc-1.5.11 installs kernel 2.6.23 (linux-2.6.23.tar.bz2)
Actually, it doesn't install kernel 2.6.23, it just uses headers straight from the tarball, instead of the installed ones. But the real question is: does it still need to to it, cause I managed to build klibc 1.5.11 on x86 without that and at least v86d does work (well, uvesafb seems to work, anyway).
Did you actually read the comments in the ebuild? On some systems, specifically those with 64-bit kernels but 32-bit userland, the linux-headers are not suitable. Also, the 2.6.23 ones needed patching to have the suitable stuff for uvesafb working. 1.5.12 and 1.5.12-r1 (w/ 2.6.26) are in the tree now
Those "comments", as you call them, only said that something is wrong. They didn't bother to specify what exactly is wrong and how to recognize it's no longer wrong.
galtgendo: klibc makes it's choices about pointer size and which compiler to try and call based on the kernel headers. On a ppc64-32ul system, the actual linux-headers package has 64-bit headers, because the kernel is 64-bit, however the userspace is 32-bit. See bug 190113 for the original error output. We also need to make sure that the headers that are used are sufficently new enough that uvesafb and v86d will build against them, which is why it used 2.6.24-rc7 before, because 2.6.23 wasn't up to date enough.
Thank you for your explanation. Neither ChangeLog nor ebuilds made it clear what exactly the problem was and I've seen ebuilds that carried strange hacks while they were no longer necessary (due to i.e. eclass changes). Well, the strange thing is that I have sys-kernel/linux-headers-2.6.23-r3 installed and uvesafb still works though klibc was built against them. Maybe it's simply much easier on x86.
Yeah, the x86/amd64 ones are much more tested than more exotic systems, so likely to have fixes in the kernel sooner rather than later.
