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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165924):
https://lists.openembedded.org/g/openembedded-core/message/165924
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]
-=-=-=-=-=-=-=-=-=-=-=-
