summaryrefslogtreecommitdiff
path: root/meta/files/toolchain-shar-relocate.sh
AgeCommit message (Collapse)AuthorFiles
2016-09-23toolchain-shar-relocate.sh: Fix typoRichard Purdie1
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-09-22toolchain-shar-relocate.sh: Add error-handlingMariano Lopez1
The relocation script of the SDK doesn't have enough error handling when replacing host perl with SDK perl or changing the symlinks. This will add those checks along with a sanity check of xargs. [YOCTO #10114] Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-03-11meta: toolchain-shar-relocate.sh: Fix for extracting SDK in the same ↵Zawadzki, Krzysztof (Nokia - PL/Wroclaw)1
directory as SDK script. If SDK will be extracted in the same folder as sdk shar script. The shar_relocate will substitute SDK.sh script SDKPATH with extract destination path. After that operation no one will be able use this sdk script as paths in it will be different. To fix this we need to filter out sdk script and relocate_sdk scripts from SDKPATH substitution Signed-off-by: Krzysztof Zawadzki <krzysztof.zawadzki@nokia.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-01-22meta/files/toolchain-shar-relocate.sh: Detect different python binaries and ↵Liam R. Howlett1
select one that exists. Although the relocate_sdk.sh supports python3, fc23 does not symlink /usr/bin/python3 to /usr/bin/python. Using exec instead of a call to the correct interpreter causes a failure on fc23 when python2 is not present. This uses 'which' to locate python, python2, then python3 and uses the first one that's found. Signed-off-by: Liam R. Howlett <Liam.Howlett@WindRiver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-12-08toolchain-shar-extract.sh: proper fix for additional env setup scriptsPaul Eggleton1
buildtools-tarball uses a custom env setup script, which isn't named the same as the default; thus unfortunately OE-Core revision a36469c97c9cb335de1e95dea5141038f337df95 broke installation of buildtools-tarball. Revert that and implement a more robust mechanism. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-12-01toolchain-shar-relocate: don't assume last state of env_setup_script is goodJean-Francois Dagenais1
In the case where many environment-setup-* files exist, the incorrect filename might be lastly set in env_setup_script, which leads to incorrect behaviour for the initialization of native_sysroot. The scenario I had was that our custom meta-toolchain-*.bb, which inherits populate_sdk, defined another environment-setup-* file to dump variable information for qt-creator. The file is named like so in order for the sdk shell script to pick it up and fix the SDK paths in the file. Since it (coincidentally) alphabetically comes after ...-core2, it was last set in env_setup_script and the grep OECORE_NATIVE_SYSROOT would simply be blank. The apparent symptom was "...relocate_sdk.py: Argument list too long" since the find command would not be searching in the right path. Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-09-29toolchain-shar-relocate.sh: make it fasterRobert Yang1
Make the extrating faster by: * Merge the two heavy "for .. find" loops into one * Move the commands out of for loop rather than inside, this can reduce the forking amount. As a result, when install: * buildtools-nativesdk-standalone: 14s -> 7s (50% saved) * core-image-minimal-core2-64-toolchain: 56s -> 47s (17% saved) [YOCTO #8404] Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-02-23toolchain-shar-template.sh: Make relocation optional.Randy Witt1
If the buildsystem is copied into the sdk and its toolchain is to be used, then the relocation provided in toolchain-shar-template.sh isn't needed and will actually fail. So break the relocation aspect out and essentially make it another SDK_POST_INSTALL_COMMAND script. Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>