[1/4] libtool: strip build system triplet from installed libtool script

The installed /usr/bin/libtool script sourced by any recipe that
inherits libtool contains build_alias=, build= and build_os= lines
populated by config.status with the *build machine's* triplet
(e.g. build=x86_64-pc-linux-gnu, build_alias=x86_64-linux). Those
values vary between autobuilder workers whose config.guess reports
different vendors or OS strings, which makes libtool.rpm non-
reproducible across the autobuilder pool and shows up as a diff in
the reproducibility selftest.

Extend the sanitising sed in remove-buildpaths.inc to blank those
three lines the same way the existing rules blank sysroot and
build-path references.

Verified locally: before this change the installed libtool contained
`build_alias=x86_64-linux`, `build=x86_64-pc-linux-gnu` and
`build_os=linux-gnu`; after this change all three lines are empty.

Assisted-by: AI - OpenAI
Signed-off-by: Alejandro Hernandez <alhe@linux.microsoft.com>
---
 meta/recipes-devtools/libtool/remove-buildpaths.inc | 3 +++
 1 file changed, 3 insertions(+)

Apologies, I was planning on sending this particular one as RFC due to its intrusiveness and forgot.

Alejandro

On 8/4/2026 4:04 PM, Alejandro Hernandez Samaniego via 
lists.openembedded.org wrote:
> RUST_BUILD_SYS is currently listed in BB_BASEHASH_IGNORE_VARS, which
> tells bitbake that rust recipes should hash-match regardless of the
> build machine's triplet. In practice that is not true:
>
> rustc computes each crate's Strict Version Hash (SVH) using inputs
> that include the *stage0/stage1 bootstrap compiler* fingerprint, which
> in turn depends on the build host arch. That seed cascades through
> every dependent crate's mangled symbols and the packing order of
> rodata sections, so an sstate blob populated on one worker arch and
> reused on a differently-arched worker produces byte-different (but
> semantically identical) artifacts and fails the reproducibility
> selftest causing autobuilder intermittent issues when the sstate
> matches for the incorrect architecture.
>
> Remove RUST_BUILD_SYS from BB_BASEHASH_IGNORE_VARS so the task hash
> tracks the build triplet and mixed-arch autobuilder pools get an
> sstate miss instead of a silently-wrong hit. RUST_HOST_SYS and
> RUST_TARGET_SYS stay excluded because they're already covered by the
> target/host arch hash inputs.
>
> While this is not ideal, it should unblock the reproducible test case,
> another solution would be to patch rust sources manually and attempt
> to upstream that change.
>
> This also has the side-effect that multiple variants of the conflicting
> rust recipes sstate artifacts are created, but they'll be correctly used
> now in each architecture.
>
> Also add an explanatory comment next to the RUST_*_SYS[vardepvalue]
> declarations in rust-common.bbclass so future readers don't re-add
> the exclusion.
>
> Verified locally: Tier 1 sighash test toggling BUILD_ARCH now produces
> different task hashes for rust/libstd-rs/rpm-sequoia/python3-crypto-
> graphy/cargo/librsvg, where previously the hashes matched despite the
> build machine change.
>
> [YOCTO #15554]
>
> Assisted-by: AI - OpenAI
> Signed-off-by: Alejandro Hernandez<alhe@linux.microsoft.com>
> ---
>   meta/classes-recipe/rust-common.bbclass | 10 ++++++++++
>   meta/conf/bitbake.conf                  |  2 +-
>   2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes-recipe/rust-common.bbclass b/meta/classes-recipe/rust-common.bbclass
> index 6bc42016d1..98b46c4e3c 100644
> --- a/meta/classes-recipe/rust-common.bbclass
> +++ b/meta/classes-recipe/rust-common.bbclass
> @@ -114,6 +114,16 @@ RUST_HOST_SYS[vardepvalue] = "${RUST_HOST_SYS}"
>   RUST_TARGET_SYS = "${@rust_base_triple(d, 'TARGET')}"
>   RUST_TARGET_SYS[vardepvalue] = "${RUST_TARGET_SYS}"
>   
> +# Note: RUST_BUILD_SYS is intentionally NOT on BB_BASEHASH_IGNORE_VARS
> +# (see meta/conf/bitbake.conf). rustc's crate SVH (Strict Version Hash)
> +# is seeded by the stage0/stage1 bootstrap compiler whose fingerprint
> +# depends on the BUILD host arch; that seed cascades through every
> +# dependent crate's mangled symbols and rodata packing order. Excluding
> +# RUST_BUILD_SYS from task hashes let a mixed-arch autobuilder pool
> +# populate sstate on one worker arch and get a cache hit on a differently-
> +# arched worker, producing byte-different (but semantically identical)
> +# artifacts and failing reproducibility tests. See Yocto bug #15554.
> +
>   # wrappers to get around the fact that Rust needs a single
>   # binary but Yocto's compiler and linker commands have
>   # arguments. Technically the archiver is always one command but
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index bdf37d0da2..ee23459506 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -969,7 +969,7 @@ BB_HASHEXCLUDE_COMMON ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH BBSERVER DL_DI
>       SSTATE_HASHEQUIV_OWNER CCACHE_TOP_DIR BB_HASHSERVE GIT_CEILING_DIRECTORIES \
>       OMP_NUM_THREADS BB_CURRENTTASK"
>   BB_BASEHASH_IGNORE_VARS ?= "${BB_HASHEXCLUDE_COMMON} PSEUDO_INCLUDE_PATHS BUILDHISTORY_DIR \
> -    SSTATE_DIR SOURCE_DATE_EPOCH RUST_BUILD_SYS RUST_HOST_SYS RUST_TARGET_SYS"
> +    SSTATE_DIR SOURCE_DATE_EPOCH RUST_HOST_SYS RUST_TARGET_SYS"
>   BB_HASHCONFIG_IGNORE_VARS ?= "${BB_HASHEXCLUDE_COMMON} DATE TIME SSH_AGENT_PID \
>       SSH_AUTH_SOCK PSEUDO_BUILD BB_ENV_PASSTHROUGH_ADDITIONS DISABLE_SANITY_CHECKS \
>       PARALLEL_MAKE BB_NUMBER_THREADS BB_ORIGENV BB_INVALIDCONF BBINCLUDED \
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#242808):https://lists.openembedded.org/g/openembedded-core/message/242808
> Mute This Topic:https://lists.openembedded.org/mt/120602088/4354175
> Group Owner:openembedded-core+owner@lists.openembedded.org
> Unsubscribe:https://lists.openembedded.org/g/openembedded-core/unsub [alhe@linux.microsoft.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>