Messages in this thread | | | Date | Wed, 02 Aug 2000 11:16:25 -0700 | From | peter swain <> | Subject | Re: RLIM_INFINITY inconsistency between archs |
| |
> 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/
| |