Re: [OE-core] [PATCH V4] meta: rust - Bug fix for target definitions returning 'NoneType' for arm

[richard.purdie@linuxfoundation.org]

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