I have a build directory I've reused heavily. After the rust 163->1.64 upgrade, I'm seeing librsvg compile failures which are long lists of errors but boils down to: | error[E0464]: multiple matching crates for `core` | | | = note: candidates: | crate `core`: /media/build1/poky/build/tmp/work/core2-64-poky-linux/librsvg/2.54.5-r0/recipe-sysroot/usr/lib/rustlib/x86_64-poky-linux-gnu/lib/libcore-5c7322bf8f654199.rmeta | crate `core`: /media/build1/poky/build/tmp/work/core2-64-poky-linux/librsvg/2.54.5-r0/recipe-sysroot/usr/lib/rustlib/x86_64-poky-linux-gnu/lib/libcore-c5fc82c620226960.rmeta i.e. there are two copies of core and rust isn't happy about it. These are both listed in manifest-core2-64-libstd-rs.populate_sysroot in sstate-control, i.e. libstd-rs is corrupted by the rebuild and is including files it should not. Cleaning librsvg doesn't help since the corruption is in libstd-rs. We need to ensure rebuilds in an existing build directory are clean.
Updated the Rust from 1.63 to 1.64 Git checkout b72193a602 Bitbake core-image-minimal Edited the conf/local.conf SDK_TOOLCHAIN_LANGS += "rust” CORE_IMAGE_EXTRA_INSTALL += "rust" IMAGE_INSTALL:append = " librsvg" Ran the build and again updated it to Rust 1.65 git pull origin master And triggered the build. Manually added 2 .rmeta files and ran the build. Copied the sstate cache from one directory to another and vice versa and built. The issue was still not reproducible.
Sundeep isn't able to reproduce this. Richard said that he'd try again at some point.
I confirmed that manifest-core2-64-libstd-rs.populate_sysroot:/media/build/poky2/build/tmp/sysroots-components/core2-64/libstd-rs/usr/lib/rustlib/x86_64-poky-linux-gnu/lib/libcore-5c7322bf8f654199.rmeta comes from rust 1.64, commit b72193a602c9f58be37d5591b83324ab86311477 I still haven't found which revision produces the other hash. I did try building the commit before 1.64, the building the commit above and that didn't reproduce the bug.
I saw this when collapsing all the piecemeal patching into rust-source.inc - that wasn't changing any of the versions, only the sources. I wonder if this problem is something along the lines of rebuilding a version with different components so you get an underlying hash change, which leads to this?
I was able to reproduce this: a) clone a fresh poky repository at revision b72193a602c9f58be37d5591b83324ab8631147 b) set DL_DIR to a common location but not SSTATE_DIR or any sstate mirrorc c) "bitbake librsvg". d) update the git checkout to c6d8d49167f069b792ac4a76d90170073ba9ba49 e) "bitbake librsvg" then it will fail as described originally. These are commits immediately after the upgrade to 1.64. The question is why the libstd-rs build is corrupted like this, it shouldn't be. Sundeep: Could you see if you could reproduce this now and if so, look and see if anything can be improved to avoid it please?
(In reply to comment #4) > I saw this when collapsing all the piecemeal patching into rust-source.inc - > that wasn't changing any of the versions, only the sources. I wonder if this > problem is something along the lines of rebuilding a version with different > components so you get an underlying hash change, which leads to this? I think that is entirely possible. So far I've worked to create a reproducible test case. Hopefully once we have that we'll be able to analyse things and work out if that is the case.
We analyzed the sigdata of the librsvg & libstd-rs artifacts and found sstate hash differences is causing by the changes riscv32 -> riscv32gc & riscv64 -> riscv64gc with commit id #6608c076f64. Along with this the python bbclass also changed with another commit. I suspect 6608c076f64 causing this issue. Since the rust version is identical the rebuild is not cleaning the old rmeta files and creating a new rmeta with different hash id. We will analyze these changes further and update here.
This issue is occuring because of the below commit. e33afcd0dc rust-common.bbclass: use built-in rust targets for -native builds This commit is causing to generate the 2nd rmeta file 'libcore-c5fc82c620226960.rmeta'. It is suspected that the 'host' tag change from 'x86_64-linux-gnu' -> 'x86_64-unknown-linux-gnu' causing this other rmeta file generation ('host' tag found in .rustc_info.json file). But, to confirm that we've analyzed the sigdata & *.d files of librsvg/libstd-rs modules but those are not showing any differences. Refer the detailed discussion is in below link. https://lists.openembedded.org/g/openembedded-core/topic/96811314
When updating from 5.0.6 to 5.0.7 using a build directory populated with 5.0.6, a patch in binutils ( 1e47fd8e4427f9d84048139804f75b83471bab28 ) causes a rebuild of libstd-rs. This seems to trigger this bug: libstd-rs then installs a second version of the rust standard library into e.g. tmp/work/armv8a-poky-linux/libstd-rs/1.75.0/sysroot-destdir/usr/lib/rustlib/aarch64-poky-linux-gnu/lib/ The work-around is to cleansstate libstd-rs
Bug review: with the data from Etienne's data, Sundeep with see if someone can reproduce this bug.
Waiting on Richard to review Sundeep's analysis.