[klibc] [PATCH] Update header locations for uapi & generated

H. Peter Anvin hpa at zytor.com
Thu Dec 26 20:31:48 PST 2013

On 12/26/2013 07:27 PM, Robin H. Johnson wrote:
> (please CC me, I'm not on the klibc list, and I didn't get HPA's
> response to my post).
> On Fri, Dec 27, 2013 at 12:24:34AM +0000, Thorsten Glaser wrote:
>> H. Peter Anvin dixit:
>>> You should be using the output of "make headers_install" to build klibc.
> That makes easy cross-building a pain in the arse, and if that's the
> case, why do you even have variables referring to the kernel source at
> all? KLIBCKERNELSRC is a local copy of the kernel for our build
> purposes.
> Aside from the build spewing:
> #warning "Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders"
> There is nothing wrong with the build, and it passes all of your
> testcases (we block some of them as they would fail in the non-root
> restricted environment, but they pass outside that).
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/klibc/klibc-2.0.3-r1.ebuild?revision=1.1&view=markup
> I'm perfectly happy to use the result of headers_install, but there is
> no way to specify where that output is. I do NOT want the /usr/include
> location used, we'd be doing a pass of headers_install with
> INSTALL_HDR_PATH="${S}"/linux-headers/ and wanting to point klibc to
> that location for the build.
> In the end, demanding that I use a copy of the installed kernel headers,
> when I'm passing a specific kernel source to the klibc build and that
> kernel source is most probably not the same as the kernel that's running
> seems like a bad idea. I want to build against a known kernel source,
> and not expose klibc to the crazy kernels used by some gentoo users.

Please read the *current* version of usr/klibc/README.klibc and come back.


More information about the klibc mailing list