On Fri, Feb 18, 2011 at 1:55 AM, Steffen Sledz <[email protected]> wrote: > Am 15.02.2011 15:50, schrieb Steffen Sledz: >> Am 15.02.2011 15:12, schrieb Andreas Oberritter: >>> On 02/15/2011 11:41 AM, Steffen Sledz wrote: >>>> "Kernel headers are backwards compatible, but not forwards compatible. >>>> This >>>> means that a program built against a C library using older kernel headers >>>> should run on a newer kernel (although it may not have access to new >>>> features), but a program built against newer kernel headers may not work >>>> on an >>>> older kernel."[2] >>> >>> Isn't this what the variable OLDEST_KERNEL is good for, when compiling >>> glibc? >> >> If i'm right this goes to the --enable-kernel=VERSION configure option of >> glibc just to optimize the library. >> >> "the configure option --enable-kernel=X.Y.Z allows to strip out >> compatibility for kernel versions before X.Y.Z." >> >> Imho it is not legitimately to follow that glibc has compatibility code for >> all kernels greater or equal X.Y.Z. >> >> Another question is the handling in other libc implementations. >> >> And finally there are a lot of programs using userland kernel headers >> directly. > > Ping! > > If i interpret responses from Tom and Phil right they agree with me (or at > least do not disagree). ;-) > > But i miss reactions from the distro maintainers (especially Ångström). >
I think we should make sure that linux version chosen for a build is equal or newer than linux-libc-headers for that build. Another option is that linux-libc-headers are driven out of selected virtual/kernel too but this may be a bit clunky since it would mean that every machine will have them different and we share sysroots e.g. two armv5te may use same sysroot _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
