From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.chez-thomas.org (mail.mlbassoc.com [65.100.170.105]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id B9F59E017EE for ; Tue, 12 Nov 2013 08:52:39 -0800 (PST) Received: by mail.chez-thomas.org (Postfix, from userid 1998) id 30923F811EB; Tue, 12 Nov 2013 09:52:38 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hermes.chez-thomas.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=4.0 tests=ALL_TRUSTED,BAYES_00 autolearn=unavailable version=3.3.2 Received: from [192.168.1.114] (zeus [192.168.1.114]) by mail.chez-thomas.org (Postfix) with ESMTP id D61C7F811EA; Tue, 12 Nov 2013 09:52:36 -0700 (MST) Message-ID: <52825CEA.4020401@mlbassoc.com> Date: Tue, 12 Nov 2013 09:52:58 -0700 From: Gary Thomas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: meta-freescale@yoctoproject.org References: <665fcc507acf439ea64bb3ddd99e7b05@BLUPR04MB023.namprd04.prod.outlook.com> In-Reply-To: <665fcc507acf439ea64bb3ddd99e7b05@BLUPR04MB023.namprd04.prod.outlook.com> Subject: Re: Native package building X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:52:43 -0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 2013-11-12 09:43, Alberto Liberal de los Rios wrote: > Thanks Octavio, > > But I have not clear my main question yet, although you maybe have answered it to me. Do you know why is it needed to add BBCLASSEXTEND = "native nativesdk" in ZLIB recipe? I am using the arm poky toolchain outside bitbake to build the library (generated with bitbake meta-toolchain), and it builds without any problem. Why is it needed to generate a native version of the ZLIB? The act of having BBCLASSEXTEND="native" doesn't build zlib-native by itself. The zlib-native [pseudo] recipe will be built because many other recipes need native zlib support, e.g. building GCC needs zlib-native. > -----Mensaje original----- > De: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] En nombre de Otavio Salvador > Enviado el: martes, 12 de noviembre de 2013 17:28 > Para: Alberto Liberal de los Rios > CC: meta-freescale@yoctoproject.org > Asunto: Re: RE: [meta-freescale] Native package building > > On Tue, Nov 12, 2013 at 2:19 PM, Alberto Liberal de los Rios wrote: >> Thanks Octavio, >> >> I checked removing BBCLASSEXTEND = "native nativesdk" and adding >> "inherit autotools" but I got an error, the reason can be the next >> >> >> "About ZLIB, by looking at the configure script, we see that this >> configure script has not been generated by autoconf (otherwise it would contain a sentence like Generated by GNU Autoconf 2.62). >> Moreover, the project doesn't use automake since there are no >> Makefile.am files. So zlib uses a custom build system, not a build system based on the classical autotools" > > Makes sense but it is unfortunate. > >> Anyway I donīt understand yet why it is needed to add BBCLASSEXTEND = "native nativesdk" in ZLIB and why it is not working removing it from the recipe. Could you give more details about the meaning of "when no class- variant is provided, the defaults are used" > > When bitbake sees the extend, it generates a new recipe which uses the tasks as the same provided by the original .bb file. When it has a 'class-nativesdk' override of a task, this one is used, the same is valid for class-native. > > You can grep 'class-nativesdk' in Poky/OE-Core for some examples of this. > -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------