Re: RLIM_INFINITY inconsistency between archs

[peter swain <swine@pobox.com>]

> pollard@tomcat.admin.navo.hpc.mil (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)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/