On Fri, 2022-05-20 at 12:04 +0100, Richard Purdie via
lists.openembedded.org wrote:
> On Fri, 2022-05-20 at 10:56 +0100, Richard Purdie via
> lists.openembedded.org wrote:
> > Let me jump in and explain a bit about what I think we need to do here
> > to move forward.
> >
> > With the patch in this series applied, "oe-selftest -r
> > sstatetests.SStateTests.test_sstate_allarch_samesigs" fails. Looking at
> > the test, it sets two different MACHINE values, "qemuarm" and "qemux86-
> > 64". Lets see if we can get more information about what is going on.
> >
> > With MACHINE = "qemux86-64", I run:
> >
> > bitbake adwaita-icon-theme rust-native cargo-native -S none
> >
> > (since adwaita-icon-theme is what is changing when it shouldn't and we
> > suspect a problem with rust-native and cargo-native).
> >
> > This generates a locked-sigs.inc, lets move that to a different
> > location:
> >
> > mv locked-sigs.inc locked-sigs2.inc
> >
> > Now with MACHINE = "qemuarm", I run:
> >
> > bitbake adwaita-icon-theme rust-native cargo-native -S none
> >
> > and we get another locked-sigs.inc.
> >
> > Comparing locked-sigs.inc with locked-sigs2.inc is revealing. I like:
> >
> > meld locked-sigs.inc locked-sigs2.inc
> >
> > but you could use diff too or whatever way you prefer to view
> > differences.
> >
> > adwaita-icon-theme is changing, there are a load of changes from
> > SIGGEN_LOCKEDSIGS_t-core2-64 to SIGGEN_LOCKEDSIGS_t-cortexa15t2hf-neon
> > which isn't surprising. You can see binutils-cross-arm becoming
> > binutils-cross-x86_64 which again, isn't surprising. cargo-native
> > changes which is a worry. rust-native also changes and is the likely
> > cause of our issues, it is furthest down the dependency stack. The
> > tasks which change are:
> >
> > rust-native:do_build
> > rust-native:do_compile
> > rust-native:do_install
> > rust-native:do_populate_sysroot
> > rust-native:do_rust_gen_targets
> >
> > and since the patch is changing do_rust_gen_targets, that is likely our
> > problem.
> >
> > Now we've proven that the signature of that task changes between these
> > two different configs, we need to investigate what the issue is there
> > and bitbake-diffsigs can likely help with that. The idea is that the
> > native recipes should be independent of the target machine choice so
> > that is the issue which now needs to be fixed.
> >
> > I did notice that if you compare qemux86-64 with qemuarm64, you don't
> > see this issue, it only happens with qemuarm. This probably means that
> > some 32 vs 64 bit issue is happening in rust-native.
> >
> > Note I did all of this without actually building anything, just some
> > recipe parses to dump the signatures.
> >
> > Does that help move things forward with the issue?
>
> Since I now had the environment, I help but complete this (taking the
> hashes from the difference between the locked-sigs diff):
>
> $ bitbake-diffsigs
> tmp/stamps/x86_64-linux/rust-native/1.60.0-r0.do_rust_gen_targets.sigdata.63*
> tmp/stamps/x86_64-linux/rust-native/1.60.0-r0.do_rust_gen_targets.sigdata.34*
> NOTE: Starting bitbake server...
> basehash changed from
> 860b8f11b10182dc5b2737f62cdb697477f714adb63eeb4d4b932d67cac8eec2 to
> 9379e8b9df9696e8056fec7d1534661f34dda073f6d816e241b09a2dff76ae2d
> Variable rust_base_triple value changed:
> @@ -36,4 +36,4 @@
>
>
> # In some cases uname and the toolchain differ on their idea of the arch name
> -TUNE_FEATURES{callconvention-hard} = Set
> +TUNE_FEATURES{callconvention-hard} = Unset
>
> The question now becomes how to fix that since I doubt rust-native
> really does depend on that.
The fix is probably this:
diff --git a/meta/classes/rust-common.bbclass b/meta/classes/rust-common.bbclass
index 02a538258af..cb811ac5da7 100644
--- a/meta/classes/rust-common.bbclass
+++ b/meta/classes/rust-common.bbclass
@@ -117,8 +117,11 @@ RUST_BUILD_ARCH =
"${@oe.rust.arch_to_rust_arch(d.getVar('BUILD_ARCH'))}"
# its likely best to not use the triple suffix due to potential confusion.
RUST_BUILD_SYS = "${@rust_base_triple(d, 'BUILD')}"
+RUST_BUILD_SYS[vardepvalue] = "${RUST_BUILD_SYS}"
RUST_HOST_SYS = "${@rust_base_triple(d, 'HOST')}"
+RUST_HOST_SYS[vardepvalue] = "${RUST_HOST_SYS}"
RUST_TARGET_SYS = "${@rust_base_triple(d, 'TARGET')}"
+RUST_TARGET_SYS[vardepvalue] = "${RUST_TARGET_SYS}"
# wrappers to get around the fact that Rust needs a single
# binary but Yocto's compiler and linker commands have
which makes the sstate signatures depend on the determined values
rather than the ingredients in them (which is usually what we want but
not here).
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165954):
https://lists.openembedded.org/g/openembedded-core/message/165954
Mute This Topic: https://lists.openembedded.org/mt/91074788/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
