From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.multimedia-labs.de ([82.149.226.172]) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1PswX7-0002JJ-01 for openembedded-devel@lists.openembedded.org; Fri, 25 Feb 2011 13:12:29 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.multimedia-labs.de (Postfix) with ESMTP id C4DE8314E12E for ; Fri, 25 Feb 2011 13:11:09 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.multimedia-labs.de Received: from mail.multimedia-labs.de ([127.0.0.1]) by localhost (mail.multimedia-labs.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hAQSfSCeh7jO for ; Fri, 25 Feb 2011 13:11:00 +0100 (CET) Received: from [172.22.22.61] (ip-94-79-168-47.unitymediagroup.de [94.79.168.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.multimedia-labs.de (Postfix) with ESMTPSA id B08B5314DDD8 for ; Fri, 25 Feb 2011 13:11:00 +0100 (CET) Message-ID: <4D679C54.9060202@opendreambox.org> Date: Fri, 25 Feb 2011 13:11:00 +0100 From: Andreas Oberritter User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: openembedded-devel@lists.openembedded.org References: <4D5A5871.7000005@dresearch.de> <4D5A89CD.803@opendreambox.org> <4D5A92BC.1010906@dresearch.de> <4D5E422B.3040703@dresearch.de> <4D665D92.7000100@dresearch.de> <4D6671C2.7060604@opendreambox.org> <4D675D08.6050301@dresearch.de> In-Reply-To: Subject: Re: linux-libc-headers version (reloaded) X-BeenThere: openembedded-devel@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: openembedded-devel@lists.openembedded.org List-Id: Using the OpenEmbedded metadata to build Distributions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 12:12:29 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 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. Regards, Andreas