Greg Schafer wrote: > The bottom line is that you absolutely want your Glibc to be aware of > new kernel syscalls otherwise there isn't a hope in hell of them ever > being called by Glibc, even if you upgrade your kernel or user apps > at a later date.
Yes. However, do you necessarily need to have the kernel headers with
support for those syscalls in /usr/include/{linux,asm} after you finish
building glibc?
I don't know; I haven't tested it. But if glibc "sanitizes" and copies
all the relevant declarations into /usr/include/sys/ (or bits/) already,
then it seems to me that the Linux kernel headers shouldn't be required.
(Unless the program is Linux-specific and low-level, like iptables or
perhaps some of util-linux.)
I'm thinking something like /usr/include/libc-headers/{linux,asm}: stick
the kernel headers in there, point glibc to that directory, and then
leave everything alone after that (except in the few places where that
directory is required by a package). But like I said, I haven't tested
it.
But I do see problems with it: several headers from glibc-2.3.4 include
files in linux/. For instance, sys/kd.h effectively only has an
#include <linux/kd.h> as its body; that would break if we didn't install
some form of kd.h into /usr/include/linux. So maybe the idea's dead
already. Dang; it was conceptually clean, at least to me. ;-)
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
