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 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.

Cheers,

Richard