linux/poky.git/meta/files/toolchain-shar-extract.sh, branch 2.7_M2

toolchain-shar-extract.sh: Preserve ICECC_PATH

2018-05-22T12:13:33+00:00

ICECC_PATH wasn't being preserved in the environment when it was reinitialized. This prevented toolchain installs from being able to use icecream by setting ICECC_PATH when icecc isn't in $PATH (From OE-Core rev: c245ab9bee536c7b6af026a5eda02ae0695567b3) Signed-off-by: Joshua Watt Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

toolchain-shar-extract: Add post-relocate scripts

2018-02-16T18:05:38+00:00

Recipes can now install post-relocation scripts which will be run when the SDK is installed. (From OE-Core rev: 93ec145f421a45077b40ae99ee6a96bc11f91f18) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

toolchain-shar-extract.sh: Ensure sbin directories are in PATH in clean environment

2017-03-10T14:50:11+00:00

For the PATH host tool whitelisting to work, the sbin directories need to be in PATH. In the cleaned SDK environment on some distros, this isn't the case and the SDK would then fail to setup there. This adds code to add such paths if they do happen to be missing, ugly, but unblocks the PATH whitelisting which I believe to be important. (From OE-Core rev: 8c49ab40c2ff2e60b717f479822d1a0021735429) Signed-off-by: Richard Purdie

toolchain-shar-extract: compare SDK and host gcc versions

2017-01-31T14:43:01+00:00

If ext sdk is built by gcc version higher than host gcc version and host gcc version is 4.8 or 4.9 the installation is known to fail due to the way uninative sstate package is built. It's a known issue and we don't have a way to fix it for above mentioned combinations of build and host gcc versions. Detected non-installable combinations of gcc versions and print an installation error. [YOCTO #10881] (From OE-Core rev: bfb9ea2604557804bd8c16adb57ccdd868a4020f) Signed-off-by: Ed Bartosh Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

sdk-installer: Fix unclear SDK installer message

2016-10-11T21:59:35+00:00

When the host and the SDK architectures are incompatible the SDK installer outputs an incomplete error message "Error: Installation machine not supported!". This commit adds a more verbose error message e.g "Error: Incompatible SDK installer! Your host is i686 and this SDK was built for x86_64 hosts." (From OE-Core rev: dc3964f1c3457cc1265d1ed0095c0c491a97b47f) Signed-off-by: Todor Minchev Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

classes/populate_sdk_ext: add some pre-install checks

2016-08-17T09:35:41+00:00

Check a number of things as early as possible in the eSDK installer script so that the user gets an error up front rather than waiting for the build system to be extracted and then have the error produced: * Check for missing utilities specified in SANITY_REQUIRED_UTILITIES (along with gcc and g++), taking into account that some of these are satisfied by buildtools which ships as part of the SDK. We use the newly added capability to list an SDK's contents to allow us to see exactly which binaries are inside the buildtools installer. * Check that Python is available (since the buildtools installer's relocate script is written in Python). * Check that locale value set by the script is actually available * Check that the install path is not on NFS This does duplicate some of the checks in sanity.bbclass but it's difficult to avoid that given that here they have to be written in shell and there they are written in Python, as well as the fact that we only need to run some of the checks here and not all (i.e. the ones that relate to the host system or install path, and not those that check the configuration or metadata). Given those issues and the fact that the amount of code is fairly small I elected to just re-implement the checks here. Fixes [YOCTO #8657]. (From OE-Core rev: 6e6999a920b913ad9fdd2751100219c07cd14e54) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

toolchain-shar-extract.sh: add option to list contents

2016-08-17T09:35:41+00:00

Add a -l command-line option for SDK installers to get a list of files that will be extracted by the SDK - internally this just runs "tar tv" on the embedded tarball. This can be used to look at which files the SDK provides without actually installing it. The initial user of this is the extensible SDK build process which needs to know what binaries are going to be installed by the buildtools installer without installing it. (From OE-Core rev: 1d3e874f191f011eb9d7b0e12e513433c126036e) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

toolchain-shar-extract.sh: allow TERM through into SDK installer env

2016-07-08T08:57:23+00:00

In order to show the task progress during the extensible SDK installation, knotty needs to know it is using a terminal it can support the "interactive" mode on (i.e. ncurses can be used), which means it needs access to the TERM variable value, so allow that through into the cleaned environment within the SDK installation script. Part of the implementation for [YOCTO #9613]. (From OE-Core rev: a8f11bc5ce07114b9ec7da7ad48da62e2026cd74) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake.conf/toolchain-shar-extract: Use en_US.UTF-8 as locale

2016-05-21T21:26:33+00:00

Under python 3, if we spawn python processes, we need to have a UTF-8 locale, else python's file access methods will use ascii. You can't change that mode once the interpreter is started so we have to ensure a locale is set. Ideally we'd use C.UTF-8 since OE already forces the C locale but not all distros support that and we need to set something so en_US.UTF-8 seems as standard we we can get. This matches the change in bitbake revision 8902c29638411d312e6fc4a197707e5742652e15 Also set this into the environment used when installing SDKs since python can be run and we need to ensure we use a standardised locale which is available from things like buildtools-tarball. (From OE-Core rev: 833d4c0fe804a1f7524b3d4b75cbcdd65c31ddac) Signed-off-by: Richard Purdie

toolchain-shar-extract.sh: ensure all_proxy is allowed through

2016-03-31T22:01:37+00:00

all_proxy is referred to by oe-git-proxy so ensure it is allowed through into the installer environment in case the extensible SDK install process needs to query a remote git repository. (From OE-Core rev: 65efec4cca9926b217b07c429a130088a9b8e2f6) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie