Thorsten Glaser
2013-Dec-27 00:24 UTC
[klibc] [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
Robin H. Johnson
2013-Dec-27 03:27 UTC
[klibc] [PATCH] Update header locations for uapi & generated
(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
H. Peter Anvin
2013-Dec-27 04:31 UTC
[klibc] [PATCH] Update header locations for uapi & generated
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
Possibly Parallel Threads
- [PATCH] Update header locations for uapi & generated
- [PATCH] Update header locations for uapi & generated
- Patch: Kbuild.install: *** No rule to make target `headers_install'.
- Build problems: klibc with Linux 3.10.7
- [PATCH] Update header locations for uapi & generated