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

[Khem Raj]

On Sat, Feb 26, 2011 at 4:47 AM, Andreas Oberritter
<obi at opendreambox.org> wrote:
> On 02/25/2011 06:28 PM, Khem Raj wrote:
>> On Fri, Feb 25, 2011 at 4:11 AM, Andreas Oberritter
>> <obi at opendreambox.org> wrote:
>>> On 02/25/2011 08:51 AM, Khem Raj wrote:
>>>> Well one way is to have kernel headers per machine which means you can
>>>> not share target packages anymore since they have to build per machine
>>>> but it would be much integrated solution and we could generate the
>>>> kernel headers from the kernel recipe itself so we are sure that the
>>>> .config of kernel headers match the .config of  kernel itself
>>>> downside is it will defeat the multimachine sharing packages a bit.
>>>
>>> The .config does not have any influence on the generated
>>
>> yes thats right
>>
>>> linux-libc-headers by definition. linux-libc-headers must not contain
>>> any CONFIG_* statements, because they are meant to be independent of it.
>>> The kernel config is not available to linux-libc-headers after all.
>>>
>>> The point I was trying to make is that feature detection at compile time
>>> is impossible, if the feature can be disabled by the kernel config
>>> (which is the case for epoll and inotify, which in turn were the
>>> examples discussed on the mailing list in May 2010). You need to do
>>> runtime tests in programs intended to be portable.
>>
>> which may not be easy to do for cross compiled packages unless they are patches
>> to make this test dynamic
>
> That doesn't make any sense. Runtime tests aren't affected by any cross
> compilation issues. Runtime tests are dynamic by nature.

I think we are talking different things. I was talking about e.g.
configure relying on
result of a runtime test to enable some feature during compile time

-Khem