On Jun 12, 2013, at 12:51 PM, Paul D. DeRocco <pdero...@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 _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
