linux/poky.git/meta/classes/populate_sdk_ext.bbclass, branch pyro-enea

populate_sdk: install UTF-8 locales in SDKs

2018-04-02T16:06:24+00:00

As glibc 2.27 can't read older locale-archives, SDKs using glibc 2.27 on hosts using glibc earlier than 2.27 won't be able to find any locales, so bitbake won't start and Python can't use UTF-8. So by default install all locales into the SDK. Special-case Extensible SDKs by installing no locales as they ship glibc in a buildtools, and that will have the locales. Locale installation requires cross-localedef, so add that to DEPENDS. Also remove the explicit en_US addition in buildtools-tarball as it is now redundant. (From OE-Core rev: 96896568d197cd06302713c24c0f7d91bfaea6c1) (From OE-Core rev: af9eb2ef36cb5bfd87ea61ff3390949810097c9b) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

populate_sdk_ext: Set cleandirs correctly

2018-01-22T10:40:08+00:00

The current conflicting use of SDKDEPLOYDIR causes a race between do_populate_sdk and do_populate_sdk_ext potentially causing the SDK to either go missing or the build to fail. (From OE-Core rev: 2c61e60cc5fe635774e88c1e34646a32a9ad918b) Signed-off-by: Richard Purdie

populate_sdk_ext: Use prebuilt uninative tarball

2017-12-11T21:47:34+00:00

For uninative to work, it relies on it being updated to new versions as newer glibcs are built. This means the uninative generated by the current build may not be as recent as the uninative that is being downloaded by uninative.bbclass. If this occurs, we can get symbol mismatch errors. Ultimately, the sstate and the uninative versions need to match so we should use the same tarball as uninative.bbclass is using, not the one we built. [YOCTO #12405] (From OE-Core rev: 1bde969058f7e832db0e7eb9c6f7ef00f027628c) Signed-off-by: Richard Purdie

classes/populate_sdk_ext: work around runqemu behaviour within the eSDK

2017-04-19T09:38:37+00:00

Currently, in order to figure out variable values when run within the eSDK, runqemu does not use the standard SDK method nor is it able to run bitbake (since the eSDK environment isn't initialised like the normal OE build environment). runqemu really ought to be fixed, but the quick workaround is to set DEPLOY_DIR_IMAGE in the environment so that runqemu can find image files. Fixes [YOCTO #10447]. (From OE-Core rev: 1ef833b6393366a10f4bb65df89725ad65761386) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

populate_sdk_ext: Add do_addto_recipe_sysroot to BB_SETSCENE_ENFORCE_WHITELIST

2017-04-14T08:47:09+00:00

Without this, eSDK builds are failing due to qemu-helper-native's dependency on this task. It makes sense to allow this to execute in eSDK contexts (its a non-sstate task intentionally). (From OE-Core rev: 3e8ade8c0772c4492efd93824f78cb043281d235) Signed-off-by: Richard Purdie

classes/populate_sdk_ext: reset TCLIBCAPPEND to get consistent TMPDIR

2017-04-14T08:47:08+00:00

populate_sdk_ext sets TMPDIR to a known static value with '/tmp' directory name and that name is hard coded in a few places (e.g., in meta-environment-extsdk.bb that writes the eSDK environment variables). Distros that do not reset TCLIBCAPPEND (poky does) end up getting TMPDIR = /tmp-${TCLIBCAPPEND} via defaultsetup.conf and that breaks the functionality in eSDK that expects everything is in /tmp. To get TMPDIR consistent, we also need to reset TCLIBCAPPEND in populate_sdk_ext.bbclass. Fixes: [YOCTO #11298] (From OE-Core rev: 9ec29153f279bb9e1dbcddc2c66e00fdbe3fd6e9) Signed-off-by: Mikko Ylinen Signed-off-by: Richard Purdie

populate_sdk_ext.bbclass: enhance compatibility with rm_work.bbclass

2017-03-31T09:10:29+00:00

"bitbake -c populate_dsk_ext" must not trigger do_rm_work, because it is impossible to declare that the additional tasks activated by "-c populate_dsk_ext" must run before do_rm_work. When do_populate_dsk_ext and do_rm_work are both active, the resulting race condition breaks do_populate_dsk_ext. The existing bitbake dependencies can't be used for that, because "addtask populate_dsk_ext before do_rm_work" would then always execute populate_dsk_ext also in normal builds. do_populate_dsk_ext triggers do_rm_work indirectly through the dependency on do_build of the SDK_TARGETs. Using the new do_build_without_rm_work instead (when available, with do_build as before if not) avoids the problem. However, one has to be careful to not trigger do_rm_work in the same build in some other way. "bitbake core-image-sato:do_populate_sdk_ext core-image-sato:do_build" still fails, for example. Doing one after the other works. Fixes: [YOCTO 11042] (From OE-Core rev: 00b1911c65fa1b21c3dedec40170998573b62178) Signed-off-by: Patrick Ohly Signed-off-by: Richard Purdie

populate_ext_sdk: Merge auto.conf into local.conf

2017-03-03T11:16:12+00:00

auto.conf is included before local.conf. Instead of keeping them separate, merge them into the extsdk local.conf. As it happens we can do this quite neatly, more neatly than the current code IMO and it makes the configuration easier for the end user to understand too. This means auto.conf is then available for the testsdk code to use for testing purposes. (From OE-Core rev: fb625e555707478d5b4931c6bc83ab06b17a8ca9) Signed-off-by: Richard Purdie

populate_ext_sdk: Append to SSTATE_MIRRORS

2017-03-03T11:16:12+00:00

We need to appent to SSTATE_MIRRORS in case other areas of code are also setting the variable. (From OE-Core rev: 9cab832b1e85822fa9be5ea9fa0415f48fba86f2) Signed-off-by: Richard Purdie

populate_sdk_ext: Allow generation of meta-extsdk-toolchain even for minimal SDKs

2017-03-01T23:27:11+00:00

If you build a minimal eSDK currently, you don't build meta-extesdk-toolchain even if you will have built most of its dependencies. This means when you try and install a toolchain into the eSDK, it fails, breaking our automated testing of the eSDK. Therefore add the dependency unconditionally even when a minimal eSDK is being built and allow the automated testing to work. (From OE-Core rev: 6e4ae81d76c5a61e7603ff4ca94452a6e724c244) Signed-off-by: Richard Purdie