Difference between target, cross, native and nativesdk.

Difference between target, cross, native and nativesdk.

[Raphael Philipe]

Hi,

I'm working on a set of recipes that must be configurable to be baked
in native, nativesdk, cross and target.

I have a bunch of questions concerning this terms. I searched the
documentation and wasn't able to find a definitive explanation for
these terms.

I will write some statements bellow about my understanding on these
terms, and I will ask you to please correct me if I'm wrong or add any
additional information:

- By default, recipes bake binaries for the target architecture that
is described in the MACHINE variable in the local.conf

- One can use BBCLASSEXTEND = "native nativesdk" to bake binaries for
the host architecture (native) and for target sdk architecture. The
target sdk architecture is described in the SDKMACHINE variable and
the host architecture is the architecture of the machine executing
bitbake. BBCLASSEXTEND = "native nativesdk" will alow you to bake
recipes that are "virtual" using the suffix native ( so ${PN}-native)
and the prefix nativesdk (so nativesdk-${PN}).

- Recipes that are cross need to inherit cross.bbclass. They are used for  ????

I'm looking for the reason why there is a u-boot-fw-utils and a
u-boot-fw-utils-cross. One produces a binary for the target and the
other for???

thank you.

Re: Difference between target, cross, native and nativesdk.

[Paul Eggleton]

Hi Raphael,

On Tuesday 20 January 2015 09:17:49 Raphael Philipe wrote:
> I'm working on a set of recipes that must be configurable to be baked
> in native, nativesdk, cross and target.
> 
> I have a bunch of questions concerning this terms. I searched the
> documentation and wasn't able to find a definitive explanation for
> these terms.
> 
> I will write some statements bellow about my understanding on these
> terms, and I will ask you to please correct me if I'm wrong or add any
> additional information:
> 
> - By default, recipes bake binaries for the target architecture that
> is described in the MACHINE variable in the local.conf

Correct.

> - One can use BBCLASSEXTEND = "native nativesdk" to bake binaries for
> the host architecture (native) and for target sdk architecture. The
> target sdk architecture is described in the SDKMACHINE variable and
> the host architecture is the architecture of the machine executing
> bitbake. BBCLASSEXTEND = "native nativesdk" will alow you to bake
> recipes that are "virtual" using the suffix native ( so ${PN}-native)
> and the prefix nativesdk (so nativesdk-${PN}).

Correct. FYI alternatively you can also "inherit native" or "inherit
nativesdk" to make a recipe specific to either of those classes (in which case
the recipe itself should be named <something>-native or nativesdk-
<something>), however BBCLASSEXTEND is preferred these days.

> - Recipes that are cross need to inherit cross.bbclass. They are used for 
> ????

Cross tools, i.e. tools that need to run in the native context and produce
some binary output for the target.
 
> I'm looking for the reason why there is a u-boot-fw-utils and a
> u-boot-fw-utils-cross. One produces a binary for the target and the
> other for???

Here's the start of the discussion that precipitated this move:

  http://lists.openembedded.org/pipermail/openembedded-core/2013-September/084280.html

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Difference between target, cross, native and nativesdk.

[Raphael Philipe]

Thank you Paul,

On Tue, Jan 20, 2015 at 10:23 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> Hi Raphael,
>
> On Tuesday 20 January 2015 09:17:49 Raphael Philipe wrote:
>> I'm working on a set of recipes that must be configurable to be baked
>> in native, nativesdk, cross and target.
>>
>> I have a bunch of questions concerning this terms. I searched the
>> documentation and wasn't able to find a definitive explanation for
>> these terms.
>>
>> I will write some statements bellow about my understanding on these
>> terms, and I will ask you to please correct me if I'm wrong or add any
>> additional information:
>>
>> - By default, recipes bake binaries for the target architecture that
>> is described in the MACHINE variable in the local.conf
>
> Correct.
>
>> - One can use BBCLASSEXTEND = "native nativesdk" to bake binaries for
>> the host architecture (native) and for target sdk architecture. The
>> target sdk architecture is described in the SDKMACHINE variable and
>> the host architecture is the architecture of the machine executing
>> bitbake. BBCLASSEXTEND = "native nativesdk" will alow you to bake
>> recipes that are "virtual" using the suffix native ( so ${PN}-native)
>> and the prefix nativesdk (so nativesdk-${PN}).
>
> Correct. FYI alternatively you can also "inherit native" or "inherit
> nativesdk" to make a recipe specific to either of those classes (in which case
> the recipe itself should be named <something>-native or nativesdk-
> <something>), however BBCLASSEXTEND is preferred these days.
>
>> - Recipes that are cross need to inherit cross.bbclass. They are used for
>> ????
>
> Cross tools, i.e. tools that need to run in the native context and produce
> some binary output for the target.

For u-boot-fw-utils-cross, the binary that you refer is the enviroment
variables file of u-boot? In this case, the difference between cross
and native is not clear for me.

>
>> I'm looking for the reason why there is a u-boot-fw-utils and a
>> u-boot-fw-utils-cross. One produces a binary for the target and the
>> other for???
>
> Here's the start of the discussion that precipitated this move:
>
>   http://lists.openembedded.org/pipermail/openembedded-core/2013-September/084280.html
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre

Re: Difference between target, cross, native and nativesdk.

[Paul Eggleton]

On Tuesday 20 January 2015 12:39:16 Raphael Philipe wrote:
> On Tue, Jan 20, 2015 at 10:23 AM, Paul Eggleton
> <paul.eggleton@linux.intel.com> wrote:
> > On Tuesday 20 January 2015 09:17:49 Raphael Philipe wrote:
> >> I'm working on a set of recipes that must be configurable to be baked
> >> in native, nativesdk, cross and target.
> >> 
> >> I have a bunch of questions concerning this terms. I searched the
> >> documentation and wasn't able to find a definitive explanation for
> >> these terms.
> >> 
> >> I will write some statements bellow about my understanding on these
> >> terms, and I will ask you to please correct me if I'm wrong or add any
> >> additional information:
> >> 
> >> - By default, recipes bake binaries for the target architecture that
> >> is described in the MACHINE variable in the local.conf
> > 
> > Correct.
> > 
> >> - One can use BBCLASSEXTEND = "native nativesdk" to bake binaries for
> >> the host architecture (native) and for target sdk architecture. The
> >> target sdk architecture is described in the SDKMACHINE variable and
> >> the host architecture is the architecture of the machine executing
> >> bitbake. BBCLASSEXTEND = "native nativesdk" will alow you to bake
> >> recipes that are "virtual" using the suffix native ( so ${PN}-native)
> >> and the prefix nativesdk (so nativesdk-${PN}).
> > 
> > Correct. FYI alternatively you can also "inherit native" or "inherit
> > nativesdk" to make a recipe specific to either of those classes (in which
> > case the recipe itself should be named <something>-native or nativesdk-
> > <something>), however BBCLASSEXTEND is preferred these days.
> > 
> >> - Recipes that are cross need to inherit cross.bbclass. They are used for
> >> ????
> > 
> > Cross tools, i.e. tools that need to run in the native context and produce
> > some binary output for the target.
> 
> For u-boot-fw-utils-cross, the binary that you refer is the enviroment
> variables file of u-boot? In this case, the difference between cross
> and native is not clear for me.

I'm not sure of the details for this recipe specifically. Perhaps one of the 
people on CC can answer.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Difference between target, cross, native and nativesdk.

[Raphael Philipe]

I was explained about the difference in a different way.

cross generates binary for the host architecture. But the way this
binary is generated depends of the target architecture. Native
generated binaries that do not depend of the target architecture.

Regards,



On Tue, Jan 20, 2015 at 12:44 PM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Tuesday 20 January 2015 12:39:16 Raphael Philipe wrote:
>> On Tue, Jan 20, 2015 at 10:23 AM, Paul Eggleton
>> <paul.eggleton@linux.intel.com> wrote:
>> > On Tuesday 20 January 2015 09:17:49 Raphael Philipe wrote:
>> >> I'm working on a set of recipes that must be configurable to be baked
>> >> in native, nativesdk, cross and target.
>> >>
>> >> I have a bunch of questions concerning this terms. I searched the
>> >> documentation and wasn't able to find a definitive explanation for
>> >> these terms.
>> >>
>> >> I will write some statements bellow about my understanding on these
>> >> terms, and I will ask you to please correct me if I'm wrong or add any
>> >> additional information:
>> >>
>> >> - By default, recipes bake binaries for the target architecture that
>> >> is described in the MACHINE variable in the local.conf
>> >
>> > Correct.
>> >
>> >> - One can use BBCLASSEXTEND = "native nativesdk" to bake binaries for
>> >> the host architecture (native) and for target sdk architecture. The
>> >> target sdk architecture is described in the SDKMACHINE variable and
>> >> the host architecture is the architecture of the machine executing
>> >> bitbake. BBCLASSEXTEND = "native nativesdk" will alow you to bake
>> >> recipes that are "virtual" using the suffix native ( so ${PN}-native)
>> >> and the prefix nativesdk (so nativesdk-${PN}).
>> >
>> > Correct. FYI alternatively you can also "inherit native" or "inherit
>> > nativesdk" to make a recipe specific to either of those classes (in which
>> > case the recipe itself should be named <something>-native or nativesdk-
>> > <something>), however BBCLASSEXTEND is preferred these days.
>> >
>> >> - Recipes that are cross need to inherit cross.bbclass. They are used for
>> >> ????
>> >
>> > Cross tools, i.e. tools that need to run in the native context and produce
>> > some binary output for the target.
>>
>> For u-boot-fw-utils-cross, the binary that you refer is the enviroment
>> variables file of u-boot? In this case, the difference between cross
>> and native is not clear for me.
>
> I'm not sure of the details for this recipe specifically. Perhaps one of the
> people on CC can answer.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre

Re: Difference between target, cross, native and nativesdk.

[Otavio Salvador]

On Wed, Jan 21, 2015 at 11:23 AM, Raphael Philipe <rapphil@gmail.com> wrote:
> I was explained about the difference in a different way.
>
> cross generates binary for the host architecture. But the way this
> binary is generated depends of the target architecture. Native
> generated binaries that do not depend of the target architecture.

Yes; basically:

cross: generates a binary to run in the host system but dependant of
the target (e.g: binutils)
crosssdk: generates a binary to run in SDK host system but dependant
of the target (e.g: binutils)

native: generates a binary to run in the host system and has no direct
dependant information of the target
nativesdk: generates a binary to run in SDK host system and has no
direct dependant information of the target

The cross use is not very common because most of stuff fits in native
or target cases. However some specific utilities ends on this group.

The fw tools inside of U-Boot qualifies for both target and cross use
cases. When used in cross or crosssdk, it can be used to change things
in the generated image (sdcard for example) while in the target case
it can be used in the runtime system.

I hope it is clear now. If someone can add more info here, please do.

-- 
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: Difference between target, cross, native and nativesdk.

[Dominic Sacré]

On 2015-01-21 14:37, Otavio Salvador wrote:
> The fw tools inside of U-Boot qualifies for both target and cross use
> cases. When used in cross or crosssdk, it can be used to change things
> in the generated image (sdcard for example) while in the target case
> it can be used in the runtime system.

I've been wondering about the "u-boot-fw-utils-cross" recipe myself.
When I build the recipe I get what appear to be the correct binaries for
the host architecture, located in the target-specific work directory
(e.g. tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-fw-utils-cross).
However, these binaries don't get installed anywhere other recipes (like
my sdcard image) would be able to find them.

My workaround so far has been to build a native package instead (by
simply adding BBCLASSEXTEND = "native" to the regular "u-boot-fw-utils"
recipe).
This way the binaries get installed to the host's sysroot and are found
just fine, but I feel like I'm missing something about how the cross
recipe should be used properly for this purpose.

Can anyone shed some light on this?


Cheers,

Dominic

Re: Difference between target, cross, native and nativesdk.

[Otavio Salvador]

On Thu, Jan 22, 2015 at 8:31 PM, Dominic Sacré <dominic.sacre@gmx.de> wrote:
> On 2015-01-21 14:37, Otavio Salvador wrote:
>> The fw tools inside of U-Boot qualifies for both target and cross use
>> cases. When used in cross or crosssdk, it can be used to change things
>> in the generated image (sdcard for example) while in the target case
>> it can be used in the runtime system.
>
> I've been wondering about the "u-boot-fw-utils-cross" recipe myself.
> When I build the recipe I get what appear to be the correct binaries for
> the host architecture, located in the target-specific work directory
> (e.g. tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-fw-utils-cross).
> However, these binaries don't get installed anywhere other recipes (like
> my sdcard image) would be able to find them.
>
> My workaround so far has been to build a native package instead (by
> simply adding BBCLASSEXTEND = "native" to the regular "u-boot-fw-utils"
> recipe).
> This way the binaries get installed to the host's sysroot and are found
> just fine, but I feel like I'm missing something about how the cross
> recipe should be used properly for this purpose.
>
> Can anyone shed some light on this?

I sent a patch and seems to do the right thing. Can you test it?

-- 
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: Difference between target, cross, native and nativesdk.

[Dominic Sacré]

On 2015-01-23 13:54, Otavio Salvador wrote:
> On Thu, Jan 22, 2015 at 8:31 PM, Dominic Sacré <dominic.sacre@gmx.de> wrote:
>> When I build the recipe I get what appear to be the correct binaries for
>> the host architecture, located in the target-specific work directory
>> (e.g. tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-fw-utils-cross).
>> However, these binaries don't get installed anywhere other recipes (like
>> my sdcard image) would be able to find them.
> 
> I sent a patch and seems to do the right thing. Can you test it?

I tried your patch, but it doesn't seem to solve the issue I described
above.
The recipe builds ok (in master it didn't before), but I still don't see
the binaries installed in a sysroot or any other directory in $PATH.

Which directory should these binaries be installed in anyway?


Dominic

Re: Difference between target, cross, native and nativesdk.

[Denys Dmytriyenko]

On Fri, Jan 23, 2015 at 10:54:39AM -0200, Otavio Salvador wrote:
> On Thu, Jan 22, 2015 at 8:31 PM, Dominic Sacré <dominic.sacre@gmx.de> wrote:
> > On 2015-01-21 14:37, Otavio Salvador wrote:
> >> The fw tools inside of U-Boot qualifies for both target and cross use
> >> cases. When used in cross or crosssdk, it can be used to change things
> >> in the generated image (sdcard for example) while in the target case
> >> it can be used in the runtime system.
> >
> > I've been wondering about the "u-boot-fw-utils-cross" recipe myself.
> > When I build the recipe I get what appear to be the correct binaries for
> > the host architecture, located in the target-specific work directory
> > (e.g. tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-fw-utils-cross).
> > However, these binaries don't get installed anywhere other recipes (like
> > my sdcard image) would be able to find them.
> >
> > My workaround so far has been to build a native package instead (by
> > simply adding BBCLASSEXTEND = "native" to the regular "u-boot-fw-utils"
> > recipe).
> > This way the binaries get installed to the host's sysroot and are found
> > just fine, but I feel like I'm missing something about how the cross
> > recipe should be used properly for this purpose.
> >
> > Can anyone shed some light on this?
> 
> I sent a patch and seems to do the right thing. Can you test it?

Well, again, you didn't really answer the question...

The question wasn't about the breakage, but rather about the process. How do 
you mean to use the u-boot-fw-utils-cross "package"?

In other words, SYSROOT_PREPROCESS_FUNCS doesn't seem to work, as no binaries 
are being deployed or staged in sysroots. Moreover, if you use rm_work class, 
the only binary in the tmp/work directory gets deleted right away and you 
can't use the output of this recipe in any way.

-- 
Denys

Re: Difference between target, cross, native and nativesdk.

[Denys Dmytriyenko]

On Wed, Jan 21, 2015 at 11:23:38AM -0200, Raphael Philipe wrote:
> I was explained about the difference in a different way.
> 
> cross generates binary for the host architecture. But the way this
> binary is generated depends of the target architecture. Native
> generated binaries that do not depend of the target architecture.

Pretty much.

But another big difference is that -native packages do not generate IPK, RPM 
or DEB, while -nativesdk, -cross, -crosssdk and -cross-canadian do.

-- 
Denys


> On Tue, Jan 20, 2015 at 12:44 PM, Paul Eggleton
> <paul.eggleton@linux.intel.com> wrote:
> > On Tuesday 20 January 2015 12:39:16 Raphael Philipe wrote:
> >> On Tue, Jan 20, 2015 at 10:23 AM, Paul Eggleton
> >> <paul.eggleton@linux.intel.com> wrote:
> >> > On Tuesday 20 January 2015 09:17:49 Raphael Philipe wrote:
> >> >> I'm working on a set of recipes that must be configurable to be baked
> >> >> in native, nativesdk, cross and target.
> >> >>
> >> >> I have a bunch of questions concerning this terms. I searched the
> >> >> documentation and wasn't able to find a definitive explanation for
> >> >> these terms.
> >> >>
> >> >> I will write some statements bellow about my understanding on these
> >> >> terms, and I will ask you to please correct me if I'm wrong or add any
> >> >> additional information:
> >> >>
> >> >> - By default, recipes bake binaries for the target architecture that
> >> >> is described in the MACHINE variable in the local.conf
> >> >
> >> > Correct.
> >> >
> >> >> - One can use BBCLASSEXTEND = "native nativesdk" to bake binaries for
> >> >> the host architecture (native) and for target sdk architecture. The
> >> >> target sdk architecture is described in the SDKMACHINE variable and
> >> >> the host architecture is the architecture of the machine executing
> >> >> bitbake. BBCLASSEXTEND = "native nativesdk" will alow you to bake
> >> >> recipes that are "virtual" using the suffix native ( so ${PN}-native)
> >> >> and the prefix nativesdk (so nativesdk-${PN}).
> >> >
> >> > Correct. FYI alternatively you can also "inherit native" or "inherit
> >> > nativesdk" to make a recipe specific to either of those classes (in which
> >> > case the recipe itself should be named <something>-native or nativesdk-
> >> > <something>), however BBCLASSEXTEND is preferred these days.
> >> >
> >> >> - Recipes that are cross need to inherit cross.bbclass. They are used for
> >> >> ????
> >> >
> >> > Cross tools, i.e. tools that need to run in the native context and produce
> >> > some binary output for the target.
> >>
> >> For u-boot-fw-utils-cross, the binary that you refer is the enviroment
> >> variables file of u-boot? In this case, the difference between cross
> >> and native is not clear for me.
> >
> > I'm not sure of the details for this recipe specifically. Perhaps one of the
> > people on CC can answer.
> >
> > Cheers,
> > Paul
> >
> > --
> >
> > Paul Eggleton
> > Intel Open Source Technology Centre
> -- 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Difference between target, cross, native and nativesdk.

[Richard Purdie]

On Wed, 2015-01-21 at 14:27 -0500, Denys Dmytriyenko wrote:
> On Wed, Jan 21, 2015 at 11:23:38AM -0200, Raphael Philipe wrote:
> > I was explained about the difference in a different way.
> > 
> > cross generates binary for the host architecture. But the way this
> > binary is generated depends of the target architecture. Native
> > generated binaries that do not depend of the target architecture.
> 
> Pretty much.
> 
> But another big difference is that -native packages do not generate IPK, RPM 
> or DEB, while -nativesdk, -cross, -crosssdk and -cross-canadian do.

-cross and -crosssdk do not generate packages.

Another way to think of this is:

"native" build once

"cross" build once per target, run on native, output code for target

"crosssdk" build once per sdk, run on native, output code for sdk

"cross-canadian" build once per sdk, run on sdk, output code for target

Whilst native.bbclass and nativesdk.bbclass are useful generally,
cross.bbclass is only useful for GNU tool projects like
binutils/gcc/gdb.

Cheers,

Richard

Re: Difference between target, cross, native and nativesdk.

[Denys Dmytriyenko]

On Wed, Jan 21, 2015 at 09:23:35PM +0000, Richard Purdie wrote:
> On Wed, 2015-01-21 at 14:27 -0500, Denys Dmytriyenko wrote:
> > On Wed, Jan 21, 2015 at 11:23:38AM -0200, Raphael Philipe wrote:
> > > I was explained about the difference in a different way.
> > > 
> > > cross generates binary for the host architecture. But the way this
> > > binary is generated depends of the target architecture. Native
> > > generated binaries that do not depend of the target architecture.
> > 
> > Pretty much.
> > 
> > But another big difference is that -native packages do not generate IPK, RPM 
> > or DEB, while -nativesdk, -cross, -crosssdk and -cross-canadian do.
> 
> -cross and -crosssdk do not generate packages.

Yeah, I thought so initially, but then I found depmodwrapper-cross and 
qemuwrapper-cross packages in my deploy/ipk, which got me confused... They 
seem to be special cases and only have scripts and not binaries. I wonder if 
the name is misleading...


> Another way to think of this is:
> 
> "native" build once
> 
> "cross" build once per target, run on native, output code for target
> 
> "crosssdk" build once per sdk, run on native, output code for sdk
> 
> "cross-canadian" build once per sdk, run on sdk, output code for target
> 
> Whilst native.bbclass and nativesdk.bbclass are useful generally,
> cross.bbclass is only useful for GNU tool projects like
> binutils/gcc/gdb.
> 
> Cheers,
> 
> Richard
> 

Re: Difference between target, cross, native and nativesdk.

[Richard Purdie]

On Wed, 2015-01-21 at 16:31 -0500, Denys Dmytriyenko wrote:
> On Wed, Jan 21, 2015 at 09:23:35PM +0000, Richard Purdie wrote:
> > On Wed, 2015-01-21 at 14:27 -0500, Denys Dmytriyenko wrote:
> > > On Wed, Jan 21, 2015 at 11:23:38AM -0200, Raphael Philipe wrote:
> > > > I was explained about the difference in a different way.
> > > > 
> > > > cross generates binary for the host architecture. But the way this
> > > > binary is generated depends of the target architecture. Native
> > > > generated binaries that do not depend of the target architecture.
> > > 
> > > Pretty much.
> > > 
> > > But another big difference is that -native packages do not generate IPK, RPM 
> > > or DEB, while -nativesdk, -cross, -crosssdk and -cross-canadian do.
> > 
> > -cross and -crosssdk do not generate packages.
> 
> Yeah, I thought so initially, but then I found depmodwrapper-cross and 
> qemuwrapper-cross packages in my deploy/ipk, which got me confused... They 
> seem to be special cases and only have scripts and not binaries. I wonder if 
> the name is misleading...

More like they shouldn't be getting packaged...

Cheers,

Richard