On Sat, Feb 26, 2011 at 4:47 AM, Andreas Oberritter <[email protected]> wrote: > On 02/25/2011 06:28 PM, Khem Raj wrote: >> On Fri, Feb 25, 2011 at 4:11 AM, Andreas Oberritter >> <[email protected]> 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 _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
