Re: Native package building

Re: Native package building

[Alberto Liberal de los Rios]

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?





-----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

Re: Native package building

[Gary Thomas]

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
------------------------------------------------------------

Re: Native package building

[Alberto Liberal de los Rios]

Thanks Gary for your explanation,
It is clear now!

________________________________________
From: Gary Thomas <gary@mlbassoc.com>
Sent: Tuesday, November 12, 2013 6:21:07 PM
To: Alberto Liberal de los Rios; meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] Native package building

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
------------------------------------------------------------

Re: Native package building

[Alberto Liberal de los Rios]

Do you refer that the ARM poky toolchain outside bitbake is generating the zlib-nativesdk? How do I drop the extend? Is it a compiler flag of the toolchain?

-----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:49
Para: Alberto Liberal de los Rios
CC: meta-freescale@yoctoproject.org
Asunto: Re: RE: RE: [meta-freescale] Native package building

On Tue, Nov 12, 2013 at 2:43 PM, Alberto Liberal de los Rios <aliberal@arroweurope.com> 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 toolchain is including it for you, so it is building zlib-nativesdk. If you drop the extend, it won't be available.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Native package building

[Gary Thomas]

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
------------------------------------------------------------

Re: Native package building

[Otavio Salvador]

On Tue, Nov 12, 2013 at 2:43 PM, Alberto Liberal de los Rios
<aliberal@arroweurope.com> 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 toolchain is including it for you, so it is building
zlib-nativesdk. If you drop the extend, it won't be available.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Native package building

[Alberto Liberal de los Rios]

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?

Best Regards
Alberto

-----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.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Native package building

[Otavio Salvador]

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.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Native package building

[Alberto Liberal de los Rios]

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"


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"

Thanks a lot for your help

Alberto

-----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 16:57
Para: Alberto Liberal de los Rios
CC: meta-freescale@yoctoproject.org
Asunto: Re: [meta-freescale] Native package building

On Tue, Nov 12, 2013 at 12:38 PM, Alberto Liberal de los Rios <aliberal@arroweurope.com> wrote:
> Maybe someone of you can help me with one question (I have searched a 
> lot of info, but nothing that clarifies it to me). I am compiling zlib 
> 1.2.7 with the next recipe:
>
>
>
> SUMMARY = "Zlib Compression Library"
>
> DESCRIPTION = "Zlib is a general-purpose, patent-free, lossless data 
> compression \ library which is used by many different programs."
>
> HOMEPAGE = "http://zlib.net/"
>
> SECTION = "libs"
>
> LICENSE = "Zlib"
>
> LIC_FILES_CHKSUM =
> "file://zlib.h;beginline=4;endline=23;md5=94d1b5a40dadd127f3351471727e66a9"
>
>
>
> SRC_URI = "http://www.zlib.net/${BPN}-${PV}.tar.bz2 \
>
>            file://remove.ldconfig.call.patch \
>
>            "
>
> SRC_URI[md5sum] = "2ab442d169156f34c379c968f3f482dd"
>
> SRC_URI[sha256sum] =
> "49e2e9658dfb036900da6ea0267a737fa3c4eee6666776d378c79d52e9334934"
>
>
>
> do_configure (){
>
>                 ./configure --prefix=${prefix} --shared 
> --libdir=${libdir} }
>
>
>
> do_compile (){
>
>                 oe_runmake
>
> }
>
>
>
> do_install() {
>
>                 oe_runmake DESTDIR=${D} install
>
> }

This should work with the defaults provided by 'autotools' class.

> BBCLASSEXTEND = "native nativesdk"

Read below...

> I have a doubt about the need of "native nativesdk" If I understand 
> well the building of this package depends of a zlib native building on 
> the host, therefore the "native".  Is it needed to build the package 
> on the host? If I build zlib using the meta-toolchain outside of yocto 
> is not needed any host building of the library. If I remove 
> BBCLASSEXTEND of the recipe, I have errors during Yocto building 
> What´s the difference between native & nativesdk?

External toolchain uses the nativesdk variant.

The BBCLASSEXTEND is equivalent of providing a zlib-native and zlib-nativesdk recipes; when no class-<virtual> variant is provided, the defaults are used. This allow for easy maintenance and avoid useless code duplication.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Native package building

[Otavio Salvador]

On Tue, Nov 12, 2013 at 12:38 PM, Alberto Liberal de los Rios
<aliberal@arroweurope.com> wrote:
> Maybe someone of you can help me with one question (I have searched a lot of
> info, but nothing that clarifies it to me). I am compiling zlib 1.2.7 with
> the next recipe:
>
>
>
> SUMMARY = "Zlib Compression Library"
>
> DESCRIPTION = "Zlib is a general-purpose, patent-free, lossless data
> compression \ library which is used by many different programs."
>
> HOMEPAGE = "http://zlib.net/"
>
> SECTION = "libs"
>
> LICENSE = "Zlib"
>
> LIC_FILES_CHKSUM =
> "file://zlib.h;beginline=4;endline=23;md5=94d1b5a40dadd127f3351471727e66a9"
>
>
>
> SRC_URI = "http://www.zlib.net/${BPN}-${PV}.tar.bz2 \
>
>            file://remove.ldconfig.call.patch \
>
>            "
>
> SRC_URI[md5sum] = "2ab442d169156f34c379c968f3f482dd"
>
> SRC_URI[sha256sum] =
> "49e2e9658dfb036900da6ea0267a737fa3c4eee6666776d378c79d52e9334934"
>
>
>
> do_configure (){
>
>                 ./configure --prefix=${prefix} --shared --libdir=${libdir} }
>
>
>
> do_compile (){
>
>                 oe_runmake
>
> }
>
>
>
> do_install() {
>
>                 oe_runmake DESTDIR=${D} install
>
> }

This should work with the defaults provided by 'autotools' class.

> BBCLASSEXTEND = "native nativesdk"

Read below...

> I have a doubt about the need of "native nativesdk" If I understand well the
> building of this package depends of a zlib native building on the host,
> therefore the "native".  Is it needed to build the package on the host? If I
> build zlib using the meta-toolchain outside of yocto is not needed any host
> building of the library. If I remove BBCLASSEXTEND of the recipe, I have
> errors during Yocto building What´s the difference between native &
> nativesdk?

External toolchain uses the nativesdk variant.

The BBCLASSEXTEND is equivalent of providing a zlib-native and
zlib-nativesdk recipes; when no class-<virtual> variant is provided,
the defaults are used. This allow for easy maintenance and avoid
useless code duplication.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Native package building

[Alberto Liberal de los Rios]

[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]

Hi



Maybe someone of you can help me with one question (I have searched a lot of info, but nothing that clarifies it to me). I am compiling zlib 1.2.7 with the next recipe:



SUMMARY = "Zlib Compression Library"

DESCRIPTION = "Zlib is a general-purpose, patent-free, lossless data compression \ library which is used by many different programs."

HOMEPAGE = "http://zlib.net/"

SECTION = "libs"

LICENSE = "Zlib"

LIC_FILES_CHKSUM = "file://zlib.h;beginline=4;endline=23;md5=94d1b5a40dadd127f3351471727e66a9<file:///\\zlib.h;beginline=4;endline=23;md5=94d1b5a40dadd127f3351471727e66a9>"



SRC_URI = "http://www.zlib.net/${BPN}-${PV}.tar.bz2 \

           file://remove.ldconfig.call.patch<file:///\\remove.ldconfig.call.patch> \

           "

SRC_URI[md5sum] = "2ab442d169156f34c379c968f3f482dd"

SRC_URI[sha256sum] = "49e2e9658dfb036900da6ea0267a737fa3c4eee6666776d378c79d52e9334934"



do_configure (){

                ./configure --prefix=${prefix} --shared --libdir=${libdir} }



do_compile (){

                oe_runmake

}



do_install() {

                oe_runmake DESTDIR=${D} install

}



BBCLASSEXTEND = "native nativesdk"





I have a doubt about the need of "native nativesdk" If I understand well the building of this package depends of a zlib native building on the host, therefore the "native".  Is it needed to build the package on the host? If I build zlib using the meta-toolchain outside of yocto is not needed any host building of the library. If I remove BBCLASSEXTEND of the recipe, I have errors during Yocto building What´s the difference between native & nativesdk?



Many thanks in advance



Alberto


[-- Attachment #2: Type: text/html, Size: 5698 bytes --]