> [email protected] (Jesse Pollard) wrote:
> > That way the "uname -r" command could be used to set a symbolic link
> > to point to the correct include files at boot time (or install time).
Kai Henningsen wrote:
> Correct for what?
correct for building kernel modules for /lib/include/$KERNEL_VER.
that's how i've used /lib/include for some time,
when needing to generate oodles of different versions of a kernel
module under active development, without necessarily having oodles of
/usr/src/linux-$KERNEL_VER trees.
i just propagate /boot/*$KERNEL_VER* and
/lib/{modules,include}/$KERNEL_VER as one tarball fully describing the
environment, to anything i'm even thinking of building on.
i do admit to maintaining boot-time /usr/include/{linux,asm} --->
/lib/include/$(uname -r)/{linux,asm} symlinks to get a consistent
usermode include tree, but it's always worried me.
The interesting parts of /usr/include are always the bleeding
edge which *hasn't* made it into glibc-blessed namespace yet.
I'm hoping some clear methodology will arise out of this bickering which
will allow stable apps to build against a static tree, with
gcc-bleeding-edge resorted to as a fallback.
[exec gcc -I/lib/include/${KERNEL_VER:-$(uname -r)} "$@"]
Ideally, binaries produced in this way would be tagged with their
dependance on version>=xx.yy.zz obvious, so they're not confused
with the stable builds, and can be ported to glibc-blessed-namespace
when new features propagate there.
^..^
(oo)