Closed adiabatic closed 5 months ago
You’d need to at minimum compile with -e VIA_ENABLE=no -e COMMAND_ENABLE=no -e SKIP_VERSION=yes
in order to prevent any timestamps or other temporal information such as git revision from being included in the final binary.
you’d also need to ensure you’re building from the exact same environment — GHA has one version of GCC, your build env has another.
For reference, this script is what I use for validating like-for-like PRs: https://github.com/tzarc/qmk_userspace/blob/main/bin/pr-sha1-verification.sh
It intentionally disables all time/revision based mutations and performs builds, ensuring final binaries have matching SHA1s. Basically reproducible builds works fine so long as you have an identical environment — even the same version of GCC can output different binaries based on the configuration options given to it when building the toolchain itself.
You are really lucky to get such a small difference between the compiled binaries after using different versions of the toolchain. Basically, the compiler decided to do some operations in a different order when optimizing the code, which in the end gives the same result (this disassembly matches one of your binaries, while the other has the 2 first instructions moved after the next 3 ones):
00001e8c <.Loc.176>:
…/qmk_firmware/quantum/keyboard.c:560
1e8c: d0 2e mov r13, r16
1e8e: d8 26 eor r13, r24
00001e90 <.LBB25>:
…/qmk_firmware/quantum/keyboard.c:567
1e90: f1 2c mov r15, r1
00001e92 <.LBE25>:
…/qmk_firmware/quantum/keyboard.c:566
1e92: ee 24 eor r14, r14
1e94: e3 94 inc r14
If you use Docker to build, so that you would use the same container image as the GitHub workflow, you would have a higher chance to get an identical firmware image (but note that in some cases, like the ones mentioned in the previous comments, the firmware image actually embeds some timestamps on purpose, so even rebuilding the exact same code using the exact same toolchain may give different results).
Good to know that it's almost certainly nothing to raise an eyebrow about.
Thanks, everyone!
Describe the Bug
The computer I'm doing all this from is an Apple Silicon-based Mac mini running macOS 14.5.
I've set up a Git clone of
qmk_firmware
. Now that my keyboard layout is in a userspace repository, the only thing I do with theqmk_firmware
clone is rungit pull
on it and maybeqmk clean
.A couple of days ago, on a lark, I enabled the
build_binaries
workflow and then manually kicked off a build.Earlier today, I adjusted a couple keys on my keyboard's layout and then flashed them to my keyboard, and then pushed the changes to my
main
branch, kicking off a second build. You can see the generated artifacts for this second release on the relevant action's run's page. The download-firmware link is right there on the page. Downloading and extracting this.zip
file gave me a file calledergodox_ez_base_zweihander_macos 2.hex
(2
because I already have a file with that name downloaded earlier).Here's what I did just now:
qmk_firmware
, rungit pull
.qmk_firmware
, runqmk clean
.zweihander
, runrm ergodox_ez_base_zweihander_macos.hex
.zweihander
, runqmk userspace-compile
, (re)generatingergodox_ez_base_zweihander_macos.hex
.~/Downloads
, copyergodox_ez_base_zweihander_macos 2.hex
tozweihander
.diff -u ergodox_ez_base_zweihander_macos.hex ergodox_ez_base_zweihander_macos\ 2.hex
Here's the diff:
A bit more graphically, courtesy of
diff-so-fancy
:I don't expect to be The Guy Who Caught The Next Jia Tan, but I would expect these two generated .hex files to be identical. It's not like there's highly-optimized floating-point code in there, right?
Keyboard Used
ergodox_ez/base
Link to product page (if applicable)
No response
Operating System
macOS
qmk doctor Output