Need clarification on some terms

Need clarification on some terms

[Paul D. DeRocco]

I'm trying a second time to see if I can learn this system. Section 3.4
contains a short glossary which explains some things and seems to obscure
others. So perhaps someone can clear up a few simple things.

"Cross-Development Toolchain: A collection of software development tools and
utilities that allow you to develop software for targeted architectures." Is
that different from the toolchain that bitbake builds in the beginning, and
then uses to build the image? If so, what is it?

"Following is a list of toolchain recipes..." This is followed by
gcc-cross-initial, gcc-cross-intermediate, gcc-cross. All three of these
things say that the toolchain runs on the host and is used to build software
for the target. So why are there three of them? What are the differences
among them? It also says that each one is a "native" package. In my
experience, a "native" toolchain has always meant a toolchain that produces
code for the same machine that the toolchain runs on, while a "cross"
toolchain produces code for a different machine. That's obviously not what
"native" means in this context, so what does it mean?

The documentation makes frequent references to "the SDK" without ever
defining it. I know what it means generically, but what is it in the Yocto
context? And why does the SDK involve yet another set of three toolchains?
(Oh, and why is one of them called "canadian"?)

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com 
 

Re: Need clarification on some terms

[Rifenbark, Scott M]

Paul,

Thanks for pointing out these areas where it is confusing.  Maybe someone on the team can add some comments about the gcc-* recipe stuff.  I don't have that understanding but if I am giving more explanation I can update that entry.  I believe the term Cross-Development Toolchain" is the same that BitBake builds in the beginning.  If not, please someone from the team add some clarification for me and I will update.  I will look for the term "SDK" throughout and remedy that.  In the beginning of the development of the docs we used the term SDK liberally.  Then we decided to weed it out.  Seems I need to completely finish that task.

Scott

>-----Original Message-----
>From: yocto-bounces@yoctoproject.org [mailto:yocto-
>bounces@yoctoproject.org] On Behalf Of Paul D. DeRocco
>Sent: Tuesday, June 11, 2013 9:07 PM
>To: yocto@yoctoproject.org
>Subject: [yocto] Need clarification on some terms
>
>I'm trying a second time to see if I can learn this system. Section 3.4
>contains a short glossary which explains some things and seems to
>obscure
>others. So perhaps someone can clear up a few simple things.
>
>"Cross-Development Toolchain: A collection of software development tools
>and
>utilities that allow you to develop software for targeted
>architectures." Is
>that different from the toolchain that bitbake builds in the beginning,
>and
>then uses to build the image? If so, what is it?
>
>"Following is a list of toolchain recipes..." This is followed by
>gcc-cross-initial, gcc-cross-intermediate, gcc-cross. All three of these
>things say that the toolchain runs on the host and is used to build
>software
>for the target. So why are there three of them? What are the differences
>among them? It also says that each one is a "native" package. In my
>experience, a "native" toolchain has always meant a toolchain that
>produces
>code for the same machine that the toolchain runs on, while a "cross"
>toolchain produces code for a different machine. That's obviously not
>what
>"native" means in this context, so what does it mean?
>
>The documentation makes frequent references to "the SDK" without ever
>defining it. I know what it means generically, but what is it in the
>Yocto
>context? And why does the SDK involve yet another set of three
>toolchains?
>(Oh, and why is one of them called "canadian"?)
>
>--
>
>Ciao,               Paul D. DeRocco
>Paul                mailto:pderocco@ix.netcom.com
>
>
>_______________________________________________
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto

Re: Need clarification on some terms

[michael]

> "Cross-Development Toolchain: A collection of software development tools
> and
> utilities that allow you to develop software for targeted architectures."
> Is
> that different from the toolchain that bitbake builds in the beginning,
> and
> then uses to build the image? If so, what is it?

A "cross development toolchain" is a toolchain that runs on an
architecture (cpu+os+libc) that is different from the architecture it
generates code for. That can even be a toolchain running on an IA64-Linux
machine generating object-code for an IA32-Linux machine.

> "Following is a list of toolchain recipes..." This is followed by
> gcc-cross-initial, gcc-cross-intermediate, gcc-cross. All three of these
> things say that the toolchain runs on the host and is used to build
> software
> for the target. So why are there three of them? What are the differences
> among them?

The gcc must be build multiple times when you bootstrap it.
For building the gcc you need to build the libc and therefor you need to
build the linux kernel headers and therefor you need the gcc. Oops.

Thats why you first build a gcc only with c support and no libc first.
Use that to generate the kernel headers, then build the initial libc and
then another gcc with libc support and all the frontends you need
(c,c++,java,fortran,..). Why there is the gcc-cross-intermediate I am not
shure, but there will be a reason and another one can clarify that.

> It also says that each one is a "native" package. In my
> experience, a "native" toolchain has always meant a toolchain that
> produces
> code for the same machine that the toolchain runs on, while a "cross"
> toolchain produces code for a different machine. That's obviously not what
> "native" means in this context, so what does it mean?

In terms of openembedded a "native" package is a package that contains
code that is intended to run on the build machine (your workstation). The
cross-compiler runs on your build-machine to produce code for your
target-machine. Thats why it is a "native" package. And there are a lot
more "native" packages than only the compiler.

> The documentation makes frequent references to "the SDK" without ever
> defining it. I know what it means generically, but what is it in the Yocto
> context? And why does the SDK involve yet another set of three toolchains?
> (Oh, and why is one of them called "canadian"?)

A canadian-cross is a term from the compiler stuff, not specific to the
Yocto Project or Poky or Openembedded.
Building a canadian-cross is the process of build a toolchain on
architecture A that runs on architecture B and produces object-code for
architecture C. An example is building a gcc on an IA32 architecture, that
will run on an ARM, producing code for an M68K. Yes, that does make sence,
if the ARM machine does not have the resources to be able to bootstrap the
compiler by itself.

Hope that made some things clear.

Michael

Re: Need clarification on some terms

[Bill Traynor]

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

On Wed, Jun 12, 2013 at 7:16 AM, <michael@cubic.org> wrote:

> > "Cross-Development Toolchain: A collection of software development tools
> > and
> > utilities that allow you to develop software for targeted architectures."
> > Is
> > that different from the toolchain that bitbake builds in the beginning,
> > and
> > then uses to build the image? If so, what is it?
>
> A "cross development toolchain" is a toolchain that runs on an
> architecture (cpu+os+libc) that is different from the architecture it
> generates code for. That can even be a toolchain running on an IA64-Linux
> machine generating object-code for an IA32-Linux machine.
>
> > "Following is a list of toolchain recipes..." This is followed by
> > gcc-cross-initial, gcc-cross-intermediate, gcc-cross. All three of these
> > things say that the toolchain runs on the host and is used to build
> > software
> > for the target. So why are there three of them? What are the differences
> > among them?
>
> The gcc must be build multiple times when you bootstrap it.
> For building the gcc you need to build the libc and therefor you need to
> build the linux kernel headers and therefor you need the gcc. Oops.
>
> Thats why you first build a gcc only with c support and no libc first.
> Use that to generate the kernel headers, then build the initial libc and
> then another gcc with libc support and all the frontends you need
> (c,c++,java,fortran,..). Why there is the gcc-cross-intermediate I am not
> shure, but there will be a reason and another one can clarify that.
>
> > It also says that each one is a "native" package. In my
> > experience, a "native" toolchain has always meant a toolchain that
> > produces
> > code for the same machine that the toolchain runs on, while a "cross"
> > toolchain produces code for a different machine. That's obviously not
> what
> > "native" means in this context, so what does it mean?
>
> In terms of openembedded a "native" package is a package that contains
> code that is intended to run on the build machine (your workstation). The
> cross-compiler runs on your build-machine to produce code for your
> target-machine. Thats why it is a "native" package. And there are a lot
> more "native" packages than only the compiler.
>
> > The documentation makes frequent references to "the SDK" without ever
> > defining it. I know what it means generically, but what is it in the
> Yocto
> > context? And why does the SDK involve yet another set of three
> toolchains?
> > (Oh, and why is one of them called "canadian"?)
>
> A canadian-cross is a term from the compiler stuff, not specific to the
> Yocto Project or Poky or Openembedded.
> Building a canadian-cross is the process of build a toolchain on
> architecture A that runs on architecture B and produces object-code for
> architecture C. An example is building a gcc on an IA32 architecture, that
> will run on an ARM, producing code for an M68K. Yes, that does make sence,
> if the ARM machine does not have the resources to be able to bootstrap the
> compiler by itself.
>

And for what it's worth, the reason it's called "Canadian" is because at
the time of it's naming, Canada had 3 political parties.

http://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross


> Hope that made some things clear.
>
> Michael
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

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

Re: Need clarification on some terms

[Rifenbark, Scott M]

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

That little tidbit is interesting... Thanks Bill.  BTW - I am incorporating some of this information into "Terms" section to help clear up stuff.

Scott

From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Bill Traynor
Sent: Wednesday, June 12, 2013 4:33 AM
To: michael@cubic.org
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Need clarification on some terms



On Wed, Jun 12, 2013 at 7:16 AM, <michael@cubic.org<mailto:michael@cubic.org>> wrote:
> "Cross-Development Toolchain: A collection of software development tools
> and
> utilities that allow you to develop software for targeted architectures."
> Is
> that different from the toolchain that bitbake builds in the beginning,
> and
> then uses to build the image? If so, what is it?
A "cross development toolchain" is a toolchain that runs on an
architecture (cpu+os+libc) that is different from the architecture it
generates code for. That can even be a toolchain running on an IA64-Linux
machine generating object-code for an IA32-Linux machine.

> "Following is a list of toolchain recipes..." This is followed by
> gcc-cross-initial, gcc-cross-intermediate, gcc-cross. All three of these
> things say that the toolchain runs on the host and is used to build
> software
> for the target. So why are there three of them? What are the differences
> among them?
The gcc must be build multiple times when you bootstrap it.
For building the gcc you need to build the libc and therefor you need to
build the linux kernel headers and therefor you need the gcc. Oops.

Thats why you first build a gcc only with c support and no libc first.
Use that to generate the kernel headers, then build the initial libc and
then another gcc with libc support and all the frontends you need
(c,c++,java,fortran,..). Why there is the gcc-cross-intermediate I am not
shure, but there will be a reason and another one can clarify that.

> It also says that each one is a "native" package. In my
> experience, a "native" toolchain has always meant a toolchain that
> produces
> code for the same machine that the toolchain runs on, while a "cross"
> toolchain produces code for a different machine. That's obviously not what
> "native" means in this context, so what does it mean?
In terms of openembedded a "native" package is a package that contains
code that is intended to run on the build machine (your workstation). The
cross-compiler runs on your build-machine to produce code for your
target-machine. Thats why it is a "native" package. And there are a lot
more "native" packages than only the compiler.

> The documentation makes frequent references to "the SDK" without ever
> defining it. I know what it means generically, but what is it in the Yocto
> context? And why does the SDK involve yet another set of three toolchains?
> (Oh, and why is one of them called "canadian"?)
A canadian-cross is a term from the compiler stuff, not specific to the
Yocto Project or Poky or Openembedded.
Building a canadian-cross is the process of build a toolchain on
architecture A that runs on architecture B and produces object-code for
architecture C. An example is building a gcc on an IA32 architecture, that
will run on an ARM, producing code for an M68K. Yes, that does make sence,
if the ARM machine does not have the resources to be able to bootstrap the
compiler by itself.

And for what it's worth, the reason it's called "Canadian" is because at the time of it's naming, Canada had 3 political parties.

http://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross


Hope that made some things clear.

Michael
_______________________________________________
yocto mailing list
yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto


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

Re: Need clarification on some terms

[Paul Eggleton]

On Wednesday 12 June 2013 04:16:30 michael@cubic.org wrote:
> Paul D. DeRocco wrote on Tuesday, June 11, 2013 at 9:07 PM:
> > "Following is a list of toolchain recipes..." This is followed by
> > gcc-cross-initial, gcc-cross-intermediate, gcc-cross. All three of these
> > things say that the toolchain runs on the host and is used to build
> > software
> > for the target. So why are there three of them? What are the differences
> > among them?
> 
> The gcc must be build multiple times when you bootstrap it.
> For building the gcc you need to build the libc and therefor you need to
> build the linux kernel headers and therefor you need the gcc. Oops.
> 
> Thats why you first build a gcc only with c support and no libc first.
> Use that to generate the kernel headers, then build the initial libc and
> then another gcc with libc support and all the frontends you need
> (c,c++,java,fortran,..). Why there is the gcc-cross-intermediate I am not
> shure, but there will be a reason and another one can clarify that.

gcc-cross-intermediate is gone as of 1.3; as I understand it current versions 
of glibc can be compiled using gcc-cross-initial so the intermediate step is 
no longer required. We should remove mention of this from the documentation 
(other than in the migration section that is).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Need clarification on some terms

[Rifenbark, Scott M]

Ahh... thanks.  Just saw this after publishing some other changes.  

Thanks,
Scott

>-----Original Message-----
>From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]
>Sent: Wednesday, June 12, 2013 5:00 AM
>To: yocto@yoctoproject.org
>Cc: Rifenbark, Scott M
>Subject: Re: [yocto] Need clarification on some terms
>
>On Wednesday 12 June 2013 04:16:30 michael@cubic.org wrote:
>> Paul D. DeRocco wrote on Tuesday, June 11, 2013 at 9:07 PM:
>> > "Following is a list of toolchain recipes..." This is followed by
>> > gcc-cross-initial, gcc-cross-intermediate, gcc-cross. All three of
>these
>> > things say that the toolchain runs on the host and is used to build
>> > software
>> > for the target. So why are there three of them? What are the
>differences
>> > among them?
>>
>> The gcc must be build multiple times when you bootstrap it.
>> For building the gcc you need to build the libc and therefor you need
>to
>> build the linux kernel headers and therefor you need the gcc. Oops.
>>
>> Thats why you first build a gcc only with c support and no libc first.
>> Use that to generate the kernel headers, then build the initial libc
>and
>> then another gcc with libc support and all the frontends you need
>> (c,c++,java,fortran,..). Why there is the gcc-cross-intermediate I am
>not
>> shure, but there will be a reason and another one can clarify that.
>
>gcc-cross-intermediate is gone as of 1.3; as I understand it current
>versions
>of glibc can be compiled using gcc-cross-initial so the intermediate
>step is
>no longer required. We should remove mention of this from the
>documentation
>(other than in the migration section that is).
>
>Cheers,
>Paul
>
>--
>
>Paul Eggleton
>Intel Open Source Technology Centre

Re: Need clarification on some terms

[Rifenbark, Scott M]

This begs the question for gcc-crosssdk-intermediate...  Is that gone as well?

>-----Original Message-----
>From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]
>Sent: Wednesday, June 12, 2013 5:00 AM
>To: yocto@yoctoproject.org
>Cc: Rifenbark, Scott M
>Subject: Re: [yocto] Need clarification on some terms
>
>On Wednesday 12 June 2013 04:16:30 michael@cubic.org wrote:
>> Paul D. DeRocco wrote on Tuesday, June 11, 2013 at 9:07 PM:
>> > "Following is a list of toolchain recipes..." This is followed by
>> > gcc-cross-initial, gcc-cross-intermediate, gcc-cross. All three of
>these
>> > things say that the toolchain runs on the host and is used to build
>> > software
>> > for the target. So why are there three of them? What are the
>differences
>> > among them?
>>
>> The gcc must be build multiple times when you bootstrap it.
>> For building the gcc you need to build the libc and therefor you need
>to
>> build the linux kernel headers and therefor you need the gcc. Oops.
>>
>> Thats why you first build a gcc only with c support and no libc first.
>> Use that to generate the kernel headers, then build the initial libc
>and
>> then another gcc with libc support and all the frontends you need
>> (c,c++,java,fortran,..). Why there is the gcc-cross-intermediate I am
>not
>> shure, but there will be a reason and another one can clarify that.
>
>gcc-cross-intermediate is gone as of 1.3; as I understand it current
>versions
>of glibc can be compiled using gcc-cross-initial so the intermediate
>step is
>no longer required. We should remove mention of this from the
>documentation
>(other than in the migration section that is).
>
>Cheers,
>Paul
>
>--
>
>Paul Eggleton
>Intel Open Source Technology Centre

Re: Need clarification on some terms

[Paul Eggleton]

On Wednesday 12 June 2013 12:27:16 Rifenbark, Scott M wrote:
> This begs the question for gcc-crosssdk-intermediate...  Is that gone as
> well?

Yes.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Need clarification on some terms

[Paul D. DeRocco]

> From: Paul Eggleton
> 
> gcc-cross-intermediate is gone as of 1.3; as I understand it 
> current versions 
> of glibc can be compiled using gcc-cross-initial so the 
> intermediate step is 
> no longer required. We should remove mention of this from the 
> documentation 
> (other than in the migration section that is).

Okay, so now there are two stages to each cross-compilation, so there's
gcc-cross-initial producing gcc-cross, and also gcc-crosssdk-initial
producing gcc-crosssdk. But is the difference between those two pairs that
the first pair ultimately produces a cross-compiler that runs on the host,
and the second pair ultimately produces a native compiler that runs on the
target? From what I can gather about the various references to "SDK", it
sounds like it's supposed to be a set of native tools that runs on the
target and produces output for the target. If that's true, then the new
descriptions are still wrong. Shouldn't gcc-cross be described as a "cross"
package rather than a "native", and shouldn't gcc-crosssdk be described as a
"native" binary that runs on the target? Or am I still fundamentally
misinterpreting these things?

For now, I really just need to know if I'm interested in the SDK, since I
have no intention of ever running compilations on my target system.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com 

Re: Need clarification on some terms

[Rifenbark, Scott M]

I need this clarified as well.  I am taking some "guesses" here and hoping for input.

Scott

>-----Original Message-----
>From: Paul D. DeRocco [mailto:pderocco@ix.netcom.com]
>Sent: Wednesday, June 12, 2013 12:51 PM
>To: 'Paul Eggleton'; Rifenbark, Scott M
>Cc: yocto@yoctoproject.org
>Subject: RE: [yocto] Need clarification on some terms
>
>> From: Paul Eggleton
>>
>> gcc-cross-intermediate is gone as of 1.3; as I understand it
>> current versions
>> of glibc can be compiled using gcc-cross-initial so the
>> intermediate step is
>> no longer required. We should remove mention of this from the
>> documentation
>> (other than in the migration section that is).
>
>Okay, so now there are two stages to each cross-compilation, so there's
>gcc-cross-initial producing gcc-cross, and also gcc-crosssdk-initial
>producing gcc-crosssdk. But is the difference between those two pairs
>that
>the first pair ultimately produces a cross-compiler that runs on the
>host,
>and the second pair ultimately produces a native compiler that runs on
>the
>target? From what I can gather about the various references to "SDK", it
>sounds like it's supposed to be a set of native tools that runs on the
>target and produces output for the target. If that's true, then the new
>descriptions are still wrong. Shouldn't gcc-cross be described as a
>"cross"
>package rather than a "native", and shouldn't gcc-crosssdk be described
>as a
>"native" binary that runs on the target? Or am I still fundamentally
>misinterpreting these things?
>
>For now, I really just need to know if I'm interested in the SDK, since
>I
>have no intention of ever running compilations on my target system.
>
>--
>
>Ciao,               Paul D. DeRocco
>Paul                mailto:pderocco@ix.netcom.com

Re: Need clarification on some terms

[Trevor Woerner]

On Wed, Jun 12, 2013 at 3:51 PM, Paul D. DeRocco <pderocco@ix.netcom.com> wrote:
> Shouldn't gcc-cross be described as a "cross"
> package rather than a "native", and shouldn't gcc-crosssdk be described as a
> "native" binary that runs on the target? Or am I still fundamentally
> misinterpreting these things?

Your understanding is quite good, actually. But I think you're mixing
up your contexts :-)


If you were at GCC or LLVM conference talking to a bunch of compiler
geeks about compilers, they would use the term "native" to refer to a
compiler which produces executables for the same machine on which the
compile was taking place. As opposed to a cross-compiler which
produces executables meant to run on some other architecture.

If you were on the Yocto/OE mailing lists talking to people about
"native" packages or output, you would be differentiating between
packages which are meant to run on the build machine rather than on
the (embedded) target.



So in the Yocto world, any package meant to run on the build machine
is a "native" package. Even if that package is a cross-compiling
compiler (i.e. a non-native compiler).

:-D

Re: Need clarification on some terms

[Trevor Woerner]

On Wed, Jun 12, 2013 at 3:51 PM, Paul D. DeRocco <pderocco@ix.netcom.com> wrote:
> For now, I really just need to know if I'm interested in the SDK, since I
> have no intention of ever running compilations on my target system.

Imagine a company which produces embedded devices running Linux. There
are hardware engineers, and software people. Within the software group
there will always be that person (or group) which is responsible for
creating the Linux filesystem which runs on the device, i.e. the
"base" system, and there is the person or group responsible for
writing the "special sauce", the program which (or programs that) make
the device do the special thing that sets this device apart (i.e. the
application developer group).

Sometimes these people are the one and the same person, other times
they are separate people/groups.

Only the person/group responsible for the base filesystem need to know
about Yocto/OE. The "special sauce" people don't need to know anything
about packages, kernels, udev, /etc, or any of that other stuff. But
what they do need is a "compiler"[1] so they can build the software
for their target device.

The "compiler" they need has to be tied to the base filesystem. They
shouldn't be using a "compiler" that isn't aware of what libraries
(and therefore also be using the correct header files) that are going
to be available on the target, and they shouldn't be using a compiler
that isn't aware of the version of the kernel that will be available
on the target.

In order to help get the Yocto/OE group and the application group in
sync, Yocto/OE has this neat target which allows the platform team to
generate an "compiler" (i.e. the SDK) that the application group can
use which is, through the magic of the Yocto system, perfectly tuned
for the image the platform team is creating. In other words, the
application team doesn't need to perform Yocto builds in order to
write their software, they just need the Yocto people to generate an
SDK for them and produce a new SDK anytime anything on the target
image changes. The Yocto people can generate this SDK using a very
simple one-liner.

For a little more information, please have a look at item 19 of
https://github.com/twoerner/meta-trevor/blob/master/misc/notes


[1] When I say "compiler" here (in quotes) I really mean the
cross-compiler, the necessary header files, the cross-linker, etc,
etc...

Re: Need clarification on some terms

[Paul D. DeRocco]

> From: Trevor Woerner
> 
> Imagine a company which produces embedded devices running Linux. There
> are hardware engineers, and software people. Within the software group
> there will always be that person (or group) which is responsible for
> creating the Linux filesystem which runs on the device, i.e. the
> "base" system, and there is the person or group responsible for
> writing the "special sauce", the program which (or programs that) make
> the device do the special thing that sets this device apart (i.e. the
> application developer group).
> 
> Sometimes these people are the one and the same person, other times
> they are separate people/groups.
> 
> Only the person/group responsible for the base filesystem need to know
> about Yocto/OE. The "special sauce" people don't need to know anything
> about packages, kernels, udev, /etc, or any of that other stuff. But
> what they do need is a "compiler"[1] so they can build the software
> for their target device.
> 
> The "compiler" they need has to be tied to the base filesystem. They
> shouldn't be using a "compiler" that isn't aware of what libraries
> (and therefore also be using the correct header files) that are going
> to be available on the target, and they shouldn't be using a compiler
> that isn't aware of the version of the kernel that will be available
> on the target.
> 
> In order to help get the Yocto/OE group and the application group in
> sync, Yocto/OE has this neat target which allows the platform team to
> generate an "compiler" (i.e. the SDK) that the application group can
> use which is, through the magic of the Yocto system, perfectly tuned
> for the image the platform team is creating. In other words, the
> application team doesn't need to perform Yocto builds in order to
> write their software, they just need the Yocto people to generate an
> SDK for them and produce a new SDK anytime anything on the target
> image changes. The Yocto people can generate this SDK using a very
> simple one-liner.
> 
> For a little more information, please have a look at item 19 of
> https://github.com/twoerner/meta-trevor/blob/master/misc/notes

Okay, so I'm wrong about the SDK being a toolchain that runs on the target.
It does indeed run on the host, right? So why is the toolchain that builds
the target application on the host different from the toolchain that builds
the target OS image on the host?

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com 

Re: Need clarification on some terms

[Paul D. DeRocco]

Or, looking at your notes, is it that "bitbake -c populate_sdk <image>"
takes the toolchain that was used to build the image, and packages it up as
an SDK for the benefit of application developers (the normal case), while
"bitbake meta-toolchain" builds a new SDK that may be different in some
ways, including maybe running on a third intermediate machine (the special
case)?

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com 

Re: Need clarification on some terms

[Zhang, Jessica]

Hi Paul,

Both of them will generate the cross toolchain which will be used by application developer on their development host for generate binaries for their target embedded devices, this cross toolchain includes the cross compiler, cross linker, etc.  But to allow for cross development, the application developer also needs development packages that contains target headers and libraries that they can develop application against.  These development packages are included in the sysroot that cross toolchain is compiling and linking against.  This sysroot is typically base on the target devices' image rootfs.  The first command "bitbae -c populate_sdk <image>" will generate the full SDK that includes toolchain and a target image matching sysroot, while the command bitbake meta_toolchain only generate the cross toolchain and a minimum sysroot that you shouldn't use to develop against.  For the latter case, we suggest people to setup their sysroot using a target image rootfs.

Cheers,
Jessica

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Paul D. DeRocco
Sent: Wednesday, June 12, 2013 3:10 PM
To: 'Trevor Woerner'
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Need clarification on some terms

Or, looking at your notes, is it that "bitbake -c populate_sdk <image>"
takes the toolchain that was used to build the image, and packages it up as an SDK for the benefit of application developers (the normal case), while "bitbake meta-toolchain" builds a new SDK that may be different in some ways, including maybe running on a third intermediate machine (the special case)?

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com

_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: Need clarification on some terms

[William Mills]

On 06/12/2013 03:51 PM, Paul D. DeRocco wrote:
> For now, I really just need to know if I'm interested in the SDK, since I
> have no intention of ever running compilations on my target system.
>

Trevor's answer has a lot of great background.

My short answer is gcc-cross is for use inside bitbake (in the host) and 
gcc-crosssdk is for use outside of bitbake (still on the host).  This 
outside bitbake use case is the SDK Trevor described.

Why does gcc need to get built differently between these two use cases? 
  I gave up asking this many years ago and accepted it as "something I 
can not change" for my own serenity.  I am sure Paul or Khem could give 
the detail.  The sdk version does have extra stuff to make it 
relocatable etc that is not needed inside of bitbake.  However I don't 
know why we don't always build the sdk-able version.

Re: Need clarification on some terms

[Khem Raj]

On Jun 12, 2013, at 12:51 PM, Paul D. DeRocco <pderocco@ix.netcom.com> wrote:

> Okay, so now there are two stages to each cross-compilation, so there's
> gcc-cross-initial producing gcc-cross, and also gcc-crosssdk-initial
> producing gcc-crosssdk. But is the difference between those two pairs that
> the first pair ultimately produces a cross-compiler that runs on the host,
> and the second pair ultimately produces a native compiler that runs on the
> target? From what I can gather about the various references to "SDK", it
> sounds like it's supposed to be a set of native tools that runs on the
> target and produces output for the target. If that's true, then the new
> descriptions are still wrong. Shouldn't gcc-cross be described as a "cross"
> package rather than a "native", and shouldn't gcc-crosssdk be described as a
> "native" binary that runs on the target? Or am I still fundamentally
> misinterpreting these things?
> 
> For now, I really just need to know if I'm interested in the SDK, since I
> have no intention of ever running compilations on my target system.

OK here it is. When bootstrapping the cross toolchain there are circular dependencies
like gcc-cross wants to have C library to be staged but you need cross compiler to build
C library therefore building cross toolchains we have to bootstrap it in stages where
the initial recipes are temporary tools that are just means to an end.  gcc-cross-initial builds
enough of gcc which can build C library for us and once we have C library then we build the
real cross compiler. We also cheat to make gcc-cross-initial think there are some C library
components available e.g. libc.so which it just needs so that it can configure itself to generate
shared objects. 

So there is a toolchain build sequence that is followed.

binutils-cross -> gcc-cross-initial -> kernel-headers -> libc-initial - > libc -> cross gcc


Now the above sequence is base of it all. Then SDK has different variants there are 3 

Target/on-device SDK - This will install the dev env in the images such that you will be able to build stuff on the device itself
you would add tools-sdk to IMAGE_FEATURES and it will get added to your images

Cross SDK - like meta-toolchain or -c populate_sdk will generate a relocatable self installer that can be installed outside OE/Yocto build env
and used to develop software. You can install it anywhere and also on different linux systems as long as SDKMACHINE architecture is same
(x86 or x86_64)

Internal toolchain - This is what is used when you are using the OE build system to build images. This toolchain is used on build host and in theory
you can use this toolchain outside OE too as long as you specify right options to compilers but this toolchain is not relocatable and is meant for
the build host only.

OE uses the terms a bit differently

lets say you have thee systems 

build host - The machine you are using the build OE and generate SDK
SDKMACHINE - The machine that will run SDK, its a x86/x86_64 machine it may be different than your build host above 
target = Your target device

native - is used for programs that run on the build system ( say we want to use same captive perl version on any build host) then we will build perl-native
nativesdk - The same as above but meant for SDK which means it would run on SDKMACHINE host ( built on build host -> will run on SDKMACHINE )
cross - runs on build host but generates code for target ( its loosely like a native package built on build host -> runs on build host -> generates code for target)
crosssdk - cross tool meant to build apps for into SDKMACHINE ( built on build host -> runs on build host -> generates code for SDKMACHINE )
cross-canadian - Cross compilers hosted to run on SDKMACHINE ( we build on the buildhost -> it will run on SDKMACHINE -> generate code for target)
thats why its called cross-candian

Hope that helps

-Khem

Re: Need clarification on some terms

[Paul D. DeRocco]

> From: Khem Raj
> 
<snip>
> 
> Hope that helps

Yes, it does. That's an e-mail that will not be deleted. Thanks.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com 

Re: Need clarification on some terms

[Rifenbark, Scott M]

See http://www.yoctoproject.org/docs/1.5/dev-manual/dev-manual.html#cross-development-toolchain for the changes that I have made to the "Cross-Development Toolchain" term description.  Let me know if this helps.  Also let me know if I have botched anything.

Thanks, 
Scott

>-----Original Message-----
>From: yocto-bounces@yoctoproject.org [mailto:yocto-
>bounces@yoctoproject.org] On Behalf Of michael@cubic.org
>Sent: Wednesday, June 12, 2013 4:17 AM
>To: yocto@yoctoproject.org
>Subject: Re: [yocto] Need clarification on some terms
>
>> "Cross-Development Toolchain: A collection of software development
>tools
>> and
>> utilities that allow you to develop software for targeted
>architectures."
>> Is
>> that different from the toolchain that bitbake builds in the
>beginning,
>> and
>> then uses to build the image? If so, what is it?
>
>A "cross development toolchain" is a toolchain that runs on an
>architecture (cpu+os+libc) that is different from the architecture it
>generates code for. That can even be a toolchain running on an IA64-
>Linux
>machine generating object-code for an IA32-Linux machine.
>
>> "Following is a list of toolchain recipes..." This is followed by
>> gcc-cross-initial, gcc-cross-intermediate, gcc-cross. All three of
>these
>> things say that the toolchain runs on the host and is used to build
>> software
>> for the target. So why are there three of them? What are the
>differences
>> among them?
>
>The gcc must be build multiple times when you bootstrap it.
>For building the gcc you need to build the libc and therefor you need to
>build the linux kernel headers and therefor you need the gcc. Oops.
>
>Thats why you first build a gcc only with c support and no libc first.
>Use that to generate the kernel headers, then build the initial libc and
>then another gcc with libc support and all the frontends you need
>(c,c++,java,fortran,..). Why there is the gcc-cross-intermediate I am
>not
>shure, but there will be a reason and another one can clarify that.
>
>> It also says that each one is a "native" package. In my
>> experience, a "native" toolchain has always meant a toolchain that
>> produces
>> code for the same machine that the toolchain runs on, while a "cross"
>> toolchain produces code for a different machine. That's obviously not
>what
>> "native" means in this context, so what does it mean?
>
>In terms of openembedded a "native" package is a package that contains
>code that is intended to run on the build machine (your workstation).
>The
>cross-compiler runs on your build-machine to produce code for your
>target-machine. Thats why it is a "native" package. And there are a lot
>more "native" packages than only the compiler.
>
>> The documentation makes frequent references to "the SDK" without ever
>> defining it. I know what it means generically, but what is it in the
>Yocto
>> context? And why does the SDK involve yet another set of three
>toolchains?
>> (Oh, and why is one of them called "canadian"?)
>
>A canadian-cross is a term from the compiler stuff, not specific to the
>Yocto Project or Poky or Openembedded.
>Building a canadian-cross is the process of build a toolchain on
>architecture A that runs on architecture B and produces object-code for
>architecture C. An example is building a gcc on an IA32 architecture,
>that
>will run on an ARM, producing code for an M68K. Yes, that does make
>sence,
>if the ARM machine does not have the resources to be able to bootstrap
>the
>compiler by itself.
>
>Hope that made some things clear.
>
>Michael
>_______________________________________________
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto