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 7701DE017BE for ; Tue, 12 Nov 2013 09:20:48 -0800 (PST) Received: by mail.chez-thomas.org (Postfix, from userid 1998) id D7F06F811EB; Tue, 12 Nov 2013 10:20:47 -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 96CFBF811EA; Tue, 12 Nov 2013 10:20:46 -0700 (MST) Message-ID: <52826383.7030601@mlbassoc.com> Date: Tue, 12 Nov 2013 10:21:07 -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: Alberto Liberal de los Rios , "meta-freescale@yoctoproject.org" References: <7ccaa2eef01a469aa31532418673a217@BLUPR04MB023.namprd04.prod.outlook.com> In-Reply-To: <7ccaa2eef01a469aa31532418673a217@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 17:20:49 -0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 2013-11-12 10:01, Alberto Liberal de los Rios wrote: > Thanks Gary, > > It has sense, but if I remove BBCLASSEXTEND = "native nativesdk" in the recipe and do "bitbake zlib" why I got an error? Is there another recipe used during the building of ZLIB that needs zlib-native? Many of them, including GCC. In order to build zlib, you need a toolchain (GCC, etc) and bitbake will look at the recipes to make sure that the GCC you may already have is up to date, etc. It will then find that the GCC recipe needs zlib-native but there is no way to build that any more, so the process will fail. Why are you interested in removing the build of zlib-native? Maybe you don't understand its purpose? zlib-native will be built so that other tools that run on your build host will have access to the zlib functions. Those tools will always require that functionality, hence the need to build zlib-native. If you are trying to avoid building zlib-native (for whatever reason), and your build host has the correct (up to date) zlib development package installed, you can use that instead by adding ASSUME_PROVIDED += " zlib-native" to your local.conf. This will tell bitbake to use the host's zlib tools instead of building them from the recipe (but only instead of zlib-native). In general though, this is discouraged. > -----Mensaje original----- > De: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-bounces@yoctoproject.org] En nombre de Gary Thomas > Enviado el: martes, 12 de noviembre de 2013 17:53 > Para: meta-freescale@yoctoproject.org > Asunto: Re: [meta-freescale] Native package building > > 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 > ------------------------------------------------------------ > _______________________________________________ > meta-freescale mailing list > meta-freescale@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-freescale > -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------