* [PATCH 1/1] cross-canadian: fix do_configure failure when switching machine and multilib
2018-04-20 2:05 [PATCH 0/1] cross-canadian: fix do_configure failure when switching machine and multilib Chen Qi
@ 2018-04-20 2:06 ` Chen Qi
2018-05-10 1:53 ` [PATCH 0/1] " ChenQi
1 sibling, 0 replies; 3+ messages in thread
From: Chen Qi @ 2018-04-20 2:06 UTC (permalink / raw)
To: openembedded-core
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.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
meta/classes/cross-canadian.bbclass | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/meta/classes/cross-canadian.bbclass b/meta/classes/cross-canadian.bbclass
index ee8aa61..9a4d021 100644
--- a/meta/classes/cross-canadian.bbclass
+++ b/meta/classes/cross-canadian.bbclass
@@ -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
^ permalink raw reply related [flat|nested] 3+ messages in thread