[oe] linux-libc-headers version (reloaded)

Khem Raj raj.khem at gmail.com
Fri Feb 18 15:30:16 UTC 2011


On Fri, Feb 18, 2011 at 1:55 AM, Steffen Sledz <sledz at dresearch.de> 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




More information about the Openembedded-devel mailing list