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

[Robin H. Johnson]

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

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead
E-Mail     : robbat2 at gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85