Re: RLIM_INFINITY inconsistency between archs

peter swain
2000-08-02T17:58:23Z

> 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)