cross-canadian: fix do_configure failure when switching machine and multilib

The following changes since commit d012a9acdc3dce014705224a1261145628e75931:

scripts/test-dependencies.sh: remove (2018-04-13 16:58:07 +0100)

are available in the git repository at:

git://git.pokylinux.org/poky-contrib ChenQi/cross-canadian-mlprefix
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/cross-canadian-mlprefix

Chen Qi (1):
cross-canadian: fix do_configure failure when switching machine and
multilib

 meta/classes/cross-canadian.bbclass | 10 ++++++++++
 1 file changed, 10 insertions(+)

1.9.1

This patch fixes a corner case, where in the same build directory, we change MACHINE and MULTILIBS but the resulting TUNE_ARCH remains the same.

This situation is encountered when we switch build from 'qemuarm' to 'lib32 qemuarm64'.

And we have the following problem for cross-canadian recipes at do_configure.

configure: error: C compiler cannot create executable.

The problem could be reproduced by two steps.
step1:
MACHINE = "qemuarm"
require conf/multilib.conf
MULTILIBS = ""
bitbake binutils-cross-canadian-arm

step2:
MACHINE = "qemuarm64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "armv7vethf" bitbake binutils-cross-canadian-arm

The problem occured because its lib32-recipe-sysroot is not constructed correctly, reusulting in missing of necessary components like crt1.o.

Why this happens? Because for such cross-canadian recipes, their dependency tasks are nativesdk recipes, whose MLPREFIX are set to 'nativesdk-'. Hence, even if RECIPE_SYSROOT has changed from 'recipe-sysroot' to 'lib32-recipe-sysroot', it's possible that the checksums of these dependency tasks remain the same. This happens when variables like TUNE_ARCH remain the same between the switch. e.g.
TUNE_ARCH remain to be 'arm' when switching from qemuarm to lib32 qemuarm64.

OE supports changing MACHINE and multilib in the same build directory. So when changing from 'qemuarm' to 'lib32 qemuarm64', things should build out correctly.

So we need to ensure the do_prepare_recipe_sysroot task is rerun when switching multilib.

Adding MLPREFIX to vardeps of do_prepare_recipe_sysroot could ensure the task to rerun in such case.

Besides, when this task is rerun, which invokes extend_recipe_sysroot, we need to make sure the recipe sysroot is constructed correctly.

So we need to set RECIPE_SYSROOT_NATIVE to contain MLPREFIX. Otherwise, as the checksums of the dependency tasks are the same and they are stored in recipe-sysroot-native/intalleddeps, no component would be installed.

After this change, when switching from 'qemuarm' to 'lib32 qemuarm64', we could ensure that the two builds are not using the same native recipe sysroot, and they are not using the same recipe sysroot.

---
 meta/classes/cross-canadian.bbclass | 10 ++++++++++
 1 file changed, 10 insertions(+)

index ee8aa61..9a4d021 100644
@@ -165,6 +165,16 @@ USE_NLS = "${SDKUSE_NLS}"
 # and not any particular tune that is enabled.
 TARGET_ARCH[vardepsexclude] = "TUNE_ARCH"
 
+# Make sure prepare_recipe_sysroot is rerun when changing multilib
+# where TUNE_ARCH remains the same
+# e.g. switch from qemuarm to lib32 qemuarm64
+do_prepare_recipe_sysroot[vardeps] += "MLPREFIX"
+
+# Make sure recipe_sysroot is correctly constructed when changing multilib
+# where TUNE_ARCH remains the same
+# e.g. switch from qemuarm to lib32 qemuarm64
+RECIPE_SYSROOT_NATIVE = "${WORKDIR}/${MLPREFIX}recipe-sysroot-native"
+
 PKGDATA_DIR = "${TMPDIR}/pkgdata/${SDK_SYS}"
 # If MLPREFIX is set by multilib code, shlibs
 # points to the wrong place so force it

1.9.1

ping

I've used this patch locally for a few weeks. It works well and does not cause any new problem.

Best Regards,
Chen Qi