diff options
author | Andrew Geissler <geissonator@yahoo.com> | 2020-10-16 18:22:50 +0300 |
---|---|---|
committer | Andrew Geissler <geissonator@yahoo.com> | 2020-10-19 20:45:27 +0300 |
commit | af5e4ef732faedf66c6dc1756432e9de2ac72988 (patch) | |
tree | 8f49154a7382b1beb2c3a2b50a6e7c632484fa25 /poky/documentation/sdk-manual/sdk-using.xml | |
parent | 36fe5df200a94e3ce82ba2dcad16c0a4127f6d46 (diff) | |
download | openbmc-af5e4ef732faedf66c6dc1756432e9de2ac72988.tar.xz |
poky: subtree update:b23aa6b753..ad30a6d470
Armin Kuster (1):
timezone: update to 2020b
Bruce Ashfield (7):
linux-yocto/5.4: fix kprobes build warning
linux-yocto/5.4: update to v5.4.67
linux-yocto/5.8: update to v5.8.11
linux-yocto/5.4: update to v5.4.68
linux-yocto/5.8: update to v5.8.12
linux-yocto/5.4: update to v5.4.69
linux-yocto/5.8: update to v5.8.13
Fabio Berton (1):
weston-init: Add environment file support for systemd unit file
Jon Mason (5):
armv8/tunes: Move TUNECONFLICTS
armv8/tunes: reference parent's TUNE_FEATURES
armv8/tunes: Add tunes for supported ARMv8a cores
armv8/tunes: Add tunes for supported ARMv8.2a cores
tune-cortexa32: fix cortexa32 tune
Joshua Watt (2):
classes/sanity: Bump minimum python version to 3.5
classes/waf: Add build and install arguments
Khem Raj (3):
systemd: Use ROOTPREFIX without suffixed slash in systemd.pc.in
musl: Update to master
strace: Fix value of IPPROTO_MAX
Martin Jansa (3):
base.bbclass: use os.path.normpath instead of just comparing WORKDIR and S as strings
mtd-utils: don't use trailing slash in S
base.bbclass: warn when there is trailing slash in S or B variables
Michael Thalmeier (1):
IMAGE_LOCALES_ARCHIVE: add option to prevent locale archive creation
Naoki Hayama (3):
uninative: Fix typo in error message
local.conf.sample: Fix comment typo
local.conf.sample.extended: Fix comment typo
Naveen Saini (2):
linux-yocto: update genericx86* SRCREV for 5.4
linux-yocto: update genericx86* SRCREV for 5.8
Nicolas Dechesne (8):
bitbake: docs: ref-variables: add links to terms in glossary
bitbake: docs: sphinx: replace special quotes with double quotes
bitbake: docs: update README file after migrationg to Sphinx
bitbake: docs: sphinx: report errors when dependencies are not met
bitbake: sphinx: remove DocBook files
bitbake: sphinx: rename Makefile.sphinx
sphinx: remove DocBook files
sphinx: rename Makefile.sphinx
Peter Kjellerstedt (1):
tune-cortexa65.inc: Correct TUNE_FEATURES_tune-cortexa65
Quentin Schulz (4):
docs: ref-manual: ref-variables: fix one-letter pointer links in glossary
docs: ref-manual: ref-variables: fix alphabetical order in glossary
docs: ref-manual: ref-variables: add links to terms in glossary
bitbake: docs: static: theme_overrides.css: fix responsive design on <640px screens
Richard Purdie (25):
glibc: do_stash_locale must not delete files from ${D}
libtools-cross/shadow-sysroot: Use nopackages inherit
pseudo: Ignore mismatched inodes from the db
pseudo: Add support for ignoring paths from the pseudo DB
pseudo: Abort on mismatch patch
psuedo: Add tracking of linked files for fds
pseudo: Fix xattr segfault
pseudo: Add may unlink patch
pseudo: Add pathfix patch
base/bitbake.conf: Enable pseudo path filtering
wic: Handle new PSEUDO_IGNORE_PATHS variable
pseudo: Fix statx function usage
bitbake.conf: Extend PSEUDO_IGNORE_PATHS to ${COREBASE}/meta
docs: Fix license CC-BY-2.0-UK -> CC-BY-SA-2.0-UK
abi_version,sanity: Tell users TMPDIR must be clean after pseudo changes
pseudo: Update to account for patches merged on branch
pseudo: Upgrade to include mkostemp64 wrapper
poky.conf: Drop OELAYOUT_ABI poking
bitbake: command: Ensure exceptions inheriting from BBHandledException are visible
bitbake: tinfoil: When sending commands we need to process events
scripts/oe-build-perf-report: Allow operation with no buildstats
oe-build-perf-report: Ensure correct data is shown for multiple branch options
skeleton/baremetal-helloworld: Fix trailing slash
oeqa/selftest/runtime_test: Exclude gpg directory from pseudo database
bitbake: process: Show command exceptions in the server log as well
Ross Burton (10):
bjam-native: don't do debug builds
coreutils: improve coreutils-ptest RDEPENDS
parted: improve ptest
devtool: remove unused variable
selftest: skip npm tests if nodejs-native isn't available
selftest: add test for recipes with patches in overrides
devtool: fix modify with patches in override directories
boost: build a standalone boost.build
boost: don't specify gcc version
boost: consolidate and update library list
Usama Arif (1):
kernel-fitimage: generate openssl RSA keys for signing fitimage
Victor Kamensky (2):
qemu: add 34Kf-64tlb fictitious cpu type
qemumips: use 34Kf-64tlb CPU emulation
Yann Dirson (1):
rngd: fix --debug to also filter syslog() calls
Yoann Congal (1):
bitbake-bblayers/create: Make the example recipe print its message
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I7139cb04b43f722a2118df5346a7a22a13c6a240
Diffstat (limited to 'poky/documentation/sdk-manual/sdk-using.xml')
-rw-r--r-- | poky/documentation/sdk-manual/sdk-using.xml | 201 |
1 files changed, 0 insertions, 201 deletions
diff --git a/poky/documentation/sdk-manual/sdk-using.xml b/poky/documentation/sdk-manual/sdk-using.xml deleted file mode 100644 index 28ee50d0b..000000000 --- a/poky/documentation/sdk-manual/sdk-using.xml +++ /dev/null @@ -1,201 +0,0 @@ -<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" -[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > -<!--SPDX-License-Identifier: CC-BY-2.0-UK--> - -<chapter id='sdk-using-the-standard-sdk'> - <title>Using the Standard SDK</title> - - <para> - This chapter describes the standard SDK and how to install it. - Information includes unique installation and setup aspects for the - standard SDK. - <note> - For a side-by-side comparison of main features supported for a - standard SDK as compared to an extensible SDK, see the - "<link linkend='sdk-manual-intro'>Introduction</link>" - section. - </note> - </para> - - <para> - You can use a standard SDK to work on Makefile and Autotools-based - projects. - See the - "<link linkend='sdk-working-projects'>Using the SDK Toolchain Directly</link>" - chapter for more information. - </para> - - <section id='sdk-standard-sdk-intro'> - <title>Why use the Standard SDK and What is in It?</title> - - <para> - The Standard SDK provides a cross-development toolchain and - libraries tailored to the contents of a specific image. - You would use the Standard SDK if you want a more traditional - toolchain experience as compared to the extensible SDK, which - provides an internal build system and the - <filename>devtool</filename> functionality. - </para> - - <para> - The installed Standard SDK consists of several files and - directories. - Basically, it contains an SDK environment setup script, some - configuration files, and host and target root filesystems to - support usage. - You can see the directory structure in the - "<link linkend='sdk-installed-standard-sdk-directory-structure'>Installed Standard SDK Directory Structure</link>" - section. - </para> - </section> - - <section id='sdk-installing-the-sdk'> - <title>Installing the SDK</title> - - <para> - The first thing you need to do is install the SDK on your - <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>Build Host</ulink> - by running the <filename>*.sh</filename> installation script. - </para> - - <para> - You can download a tarball installer, which includes the - pre-built toolchain, the <filename>runqemu</filename> - script, and support files from the appropriate - <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'>toolchain</ulink> - directory within the Index of Releases. - Toolchains are available for several 32-bit and 64-bit - architectures with the <filename>x86_64</filename> directories, - respectively. - The toolchains the Yocto Project provides are based off the - <filename>core-image-sato</filename> and - <filename>core-image-minimal</filename> images and contain - libraries appropriate for developing against that image. - </para> - - <para> - The names of the tarball installer scripts are such that a - string representing the host system appears first in the - filename and then is immediately followed by a string - representing the target architecture. - <literallayout class='monospaced'> - poky-glibc-<replaceable>host_system</replaceable>-<replaceable>image_type</replaceable>-<replaceable>arch</replaceable>-toolchain-<replaceable>release_version</replaceable>.sh - - Where: - <replaceable>host_system</replaceable> is a string representing your development system: - - i686 or x86_64. - - <replaceable>image_type</replaceable> is the image for which the SDK was built: - - core-image-minimal or core-image-sato. - - <replaceable>arch</replaceable> is a string representing the tuned target architecture: - - aarch64, armv5e, core2-64, i586, mips32r2, mips64, ppc7400, or cortexa8hf-neon. - - <replaceable>release_version</replaceable> is a string representing the release number of the Yocto Project: - - &DISTRO;, &DISTRO;+snapshot - </literallayout> - For example, the following SDK installer is for a 64-bit - development host system and a i586-tuned target architecture - based off the SDK for <filename>core-image-sato</filename> and - using the current &DISTRO; snapshot: - <literallayout class='monospaced'> - poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh - </literallayout> - <note> - As an alternative to downloading an SDK, you can build the - SDK installer. - For information on building the installer, see the - "<link linkend='sdk-building-an-sdk-installer'>Building an SDK Installer</link>" - section. - </note> - </para> - - <para> - The SDK and toolchains are self-contained and by default are - installed into the <filename>poky_sdk</filename> folder in your - home directory. - You can choose to install the extensible SDK in any location when - you run the installer. - However, because files need to be written under that directory - during the normal course of operation, the location you choose - for installation must be writable for whichever - users need to use the SDK. - </para> - - <para> - The following command shows how to run the installer given a - toolchain tarball for a 64-bit x86 development host system and - a 64-bit x86 target architecture. - The example assumes the SDK installer is located in - <filename>~/Downloads/</filename> and has execution rights. - <note> - If you do not have write permissions for the directory - into which you are installing the SDK, the installer - notifies you and exits. - For that case, set up the proper permissions in the directory - and run the installer again. - </note> - <literallayout class='monospaced'> - $ ./Downloads/poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh - Poky (Yocto Project Reference Distro) SDK installer version &DISTRO; - =============================================================== - Enter target directory for SDK (default: /opt/poky/&DISTRO;): - You are about to install the SDK to "/opt/poky/&DISTRO;". Proceed [Y/n]? Y - Extracting SDK........................................ ..............................done - Setting it up...done - SDK has been successfully set up and is ready to be used. - Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g. - $ . /opt/poky/&DISTRO;/environment-setup-i586-poky-linux - </literallayout> - </para> - - <para> - Again, reference the - "<link linkend='sdk-installed-standard-sdk-directory-structure'>Installed Standard SDK Directory Structure</link>" - section for more details on the resulting directory structure of - the installed SDK. - </para> - </section> - - <section id='sdk-running-the-sdk-environment-setup-script'> - <title>Running the SDK Environment Setup Script</title> - - <para> - Once you have the SDK installed, you must run the SDK environment - setup script before you can actually use the SDK. - This setup script resides in the directory you chose when you - installed the SDK, which is either the default - <filename>/opt/poky/&DISTRO;</filename> directory or the directory - you chose during installation. - </para> - - <para> - Before running the script, be sure it is the one that matches the - architecture for which you are developing. - Environment setup scripts begin with the string - "<filename>environment-setup</filename>" and include as part of - their name the tuned target architecture. - As an example, the following commands set the working directory - to where the SDK was installed and then source the environment - setup script. - In this example, the setup script is for an IA-based - target machine using i586 tuning: - <literallayout class='monospaced'> - $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux - </literallayout> - When you run the setup script, the same environment variables are - defined as are when you run the setup script for an extensible SDK. - See the - "<link linkend='sdk-running-the-extensible-sdk-environment-setup-script'>Running the Extensible SDK Environment Setup Script</link>" - section for more information. - </para> - </section> -</chapter> -<!-- -vim: expandtab tw=80 ts=4 ---> |