[yocto] Need clarification on some terms

Khem Raj raj.khem at gmail.com
Thu Jun 13 00:10:33 PDT 2013


On Jun 12, 2013, at 12:51 PM, Paul D. DeRocco <pderocco at 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





More information about the yocto mailing list