Thanks Alejandro. Your series did the hard part here, finding where the host details get into theCAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hopefully these fix reproducibility issue when built from different hosts. Unfortunately these go in a bit of a different way than my next version, so I will wait for the result before sending to avoid confusion, but I'm fine with these if they work, lets just add my sign off to the actual patches based off of mine instead of the "Patch from Alejandro + OE link".
Cheers AlejandroOn 9/15/2026 8:18 AM, Dora, Sunil Kumar via lists.openembedded.org wrote:
From: Sunil Dora <sunilkumar.dora@windriver.com> The reproducible selftest fails for rust on the arm workers ([YOCTO #16376]). This series fixes that. rust: drop the cc object-name reproducibility patch rust: hash cc object names relative to their source roots The patch we carried trimmed the build path by matching the string "rustc", and the shared-source rework broke that for one of the two sets of sources cc compiles. The replacement strips the roots the sources actually come from. The OUT_DIR part is proposed upstream as https://github.com/rust-lang/cc-rs/pull/1902. The RUST_COMPILER_RT_ROOT part is specific to rust's own build system, so it is not part of that pull request. rust: keep the build host triple out of cargo unit metadata From Alejandro Enedino Hernandez Samaniego's strict-version-hash series, carried with his sign-off: https://lists.openembedded.org/g/openembedded-core/topic/120939810 cargo mixes the "host:" line of "rustc -vV" into build script and proc-macro metadata, and target crates inherit it. Upstream report: https://github.com/rust-lang/cargo/issues/8140 rust: backport deterministic DocLinkResMap serialisation Upstream commit f9d9939 by jprochazk and mejrs. It is in rust 1.99, so this drops out at the next rust upgrade. rust: sort hygiene data before it is encoded Also from Alejandro's series. Upstream is fixing the same problem with a different approach in https://github.com/rust-lang/rust/pull/161450, which is still open. Alejandro's StableCrateId patch is not included: the value it pins is already host-independent in our builds, and it broke three rust test suite cases when the autobuilder tested it. Tested on the autobuilder: the x86 reproducible builder green with zero differing packages, the rust test suite green, and on both arm builders rust, rust-dbg, rust-rustdoc and libstd-rs-dev gone from the failing list. Sunil Dora (5): rust: drop the cc object-name reproducibility patch rust: hash cc object names relative to their source roots rust: keep the build host triple out of cargo unit metadata rust: backport deterministic DocLinkResMap serialisation rust: sort hygiene data before it is encoded ...-host-triple-from-unit-metadata-hash.patch | 62 ++++++++++ ...oc-link-metadata-order-deterministic.patch | 40 ++++++ ...hygiene-encoding-order-deterministic.patch | 58 +++++++++ ...ject-names-relative-to-source-roots.patch} | 116 +++++++++--------- meta/recipes-devtools/rust/rust-source.inc | 5 +- 5 files changed, 224 insertions(+), 57 deletions(-) create mode 100644 meta/recipes-devtools/rust/files/0007-cargo-omit-host-triple-from-unit-metadata-hash.patch create mode 100644 meta/recipes-devtools/rust/files/0008-rustc-hir-make-doc-link-metadata-order-deterministic.patch create mode 100644 meta/recipes-devtools/rust/files/0009-rustc-span-make-hygiene-encoding-order-deterministic.patch rename meta/recipes-devtools/rust/files/{repro-issue-fix-with-cc-crate-hashmap.patch => cc-hash-object-names-relative-to-source-roots.patch} (70%)
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#245843): https://lists.openembedded.org/g/openembedded-core/message/245843 Mute This Topic: https://lists.openembedded.org/mt/121261374/4354175 Group Owner: openembedded-core+owner@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alhe@linux.microsoft.com] -=-=-=-=-=-=-=-=-=-=-=-