From 7233e359ddc50c80415c746449c33aa0fe83862d Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Mon, 21 Mar 2016 14:25:47 -0700 Subject: sdk-manual: Edits to add extensible SDK configuration sections. (From yocto-docs rev: 378bbceb8ea06c225c4758807e25a35521faa3a9) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/sdk-manual/sdk-intro.xml | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) (limited to 'documentation/sdk-manual/sdk-intro.xml') diff --git a/documentation/sdk-manual/sdk-intro.xml b/documentation/sdk-manual/sdk-intro.xml index 36d946459d..d71aafeba1 100644 --- a/documentation/sdk-manual/sdk-intro.xml +++ b/documentation/sdk-manual/sdk-intro.xml @@ -45,6 +45,34 @@ the Yocto Project build system. + + SDKs are completely self-contained. + The binaries are linked against their own copy of + libc, which results in no dependencies + on the target system. + To achieve this, the pointer to the dynamic loader is + configured at install time since that path cannot be dynamically + altered. + This is the reason for a wrapper around the + populate_sdk and + populate_sdk_ext archives. + + + + Another feature for the SDKs is that only one set of cross-canadian + toolchain binaries are produced per architecture. + This feature takes advantage of the fact that the target hardware can + be passed to gcc as a set of compiler options. + Those options are set up by the environment script and contained in + variables such as + CC + and + LD. + This reduces the space needed for the tools. + Understand, however, that a sysroot is still needed for every target + since those binaries are target-specific. + + Going beyond the actual SDK, the SDK development environment consists of the following: -- cgit v1.2.3-54-g00ecf