Re: Native package building

[Gary Thomas <gary@mlbassoc.com>]

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 <aliberal@arroweurope.com> 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-<virtual> 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
------------------------------------------------------------