From: "Dora, Sunil Kumar" <SunilKumar.Dora@windriver.com>
To: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH v3] rust: Avoid passing host-specific information to crates Strict Version Hash
Date: Thu, 03 Sep 2026 11:40:22 -0700 [thread overview]
Message-ID: <3299883.1788460822003555425@lists.openembedded.org> (raw)
In-Reply-To: <78bca4cc9c3e7fd3014f22e1d1b9529480089a2a.camel@linuxfoundation.org>
[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]
I'm still working through the remaining Rust packages and will follow up on that separately.
While going through the reproducible-cross diffoscope output, though, I noticed something unrelated to Rust
that I think may explain the git/git-dbg entries, so sharing it here in case it's useful or helps narrow things down.
In the 2026-07-29 report from builder 120 [1], git's .rodata has:
-0x001b1780 6769742d 00000000 61617263 68363400 git-....aarch64.
+0x001b1780 6769742d 00000000 7838365f 36340000 git-....x86_64..
i.e. the build host's arch string, sitting right next to git's "cpu: %s" format string.
git's Makefile does:
ifeq (,$(HOST_CPU))
BASIC_CFLAGS += -DGIT_HOST_CPU="\"$(firstword $(subst -, ,$(uname_M)))\""
else
BASIC_CFLAGS += -DGIT_HOST_CPU="\"$(HOST_CPU)\""
endif
uname_M comes from `uname -m` on the build machine, and GIT_HOST_CPU
ends up in the "cpu:" line of `git version --build-options`.
Upstream even documents HOST_CPU as the thing to set when cross compiling,
but our recipe never sets it, so we always take the uname fallback.
Since "aarch64" and "x86_64" have different lengths, everything after that string shifts,
which is why the git diffs look much bigger than they really are (.text, .symtab and so on) -
the instructions themselves don't change. git/git-dbg show up in every run I've looked
at (119/120/121, before and after the SVH fix, on both x86 and arm hosts),
so it fits a build host leak rather than anything rust related.
The fix should just be:
EXTRA_OEMAKE += "HOST_CPU=${TARGET_ARCH}"
in git_2.55.0.bb. As far as I can tell TARGET_ARCH does the right
thing for native (= BUILD_ARCH) and nativesdk (= SDK_ARCH) as well, so
no class overrides needed.
I'm cross checking with a locally to make sure the resulting binary really says "aarch64", and will send the patch once
that's confirmed.
[1] https://valkyrie.yocto.io/pub/repro-fail/oe-reproducible-20260729-j6j_xpuw/packages/diff-html/
Thanks,
Sunil
[-- Attachment #2: Type: text/html, Size: 2399 bytes --]
prev parent reply other threads:[~2026-09-03 18:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-26 15:54 [PATCH v3] rust: Avoid passing host-specific information to crates Strict Version Hash Alejandro Hernandez
2026-08-26 18:25 ` Dora, Sunil Kumar
2026-08-26 19:17 ` [OE-core] " Richard Purdie
2026-08-26 20:08 ` Alejandro Hernandez
2026-08-26 20:47 ` Richard Purdie
[not found] ` <18CF75EE37DB8543.642712@lists.openembedded.org>
2026-08-27 7:53 ` Richard Purdie
2026-08-28 15:46 ` Alejandro Hernandez
2026-08-28 17:56 ` Richard Purdie
2026-09-03 18:40 ` Dora, Sunil Kumar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3299883.1788460822003555425@lists.openembedded.org \
--to=sunilkumar.dora@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox