Re: linux-libc-headers version (reloaded)

[Andreas Oberritter <obi@opendreambox.org>]

On 02/25/2011 06:28 PM, Khem Raj wrote:
> On Fri, Feb 25, 2011 at 4:11 AM, Andreas Oberritter
> <obi@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.

Regards,
Andreas