klibc - Dec 2013 - [PATCH] Update header locations for uapi & generated

H. Peter Anvin dixit:
>You should be using the output of "make headers_install" to build
klibc.
Hm. Can we catch that somehow? Like?

#ifdef using_uninstalled_kernel_headers
# error Go RTFM!
#endif

? in the klibc sources, centrally somewhere? Ideally, a klibc
header that?d also be included when using klcc to build some?
thing, so that both klibc-build time and klibc-use time would
be caught.

bye,
//mirabilos
-- 
> Wish I had pine to hand :-( I'll give lynx a try, thanks.
Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k.a. {news.gmane.org/nntp}#news.gmane.linux.debian.ports.68k in pine

(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

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.

	-hpa