-
-
Notifications
You must be signed in to change notification settings - Fork 37.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] GitHub-built .hex file doesn't quite match the one built by qmk userspace-compile
#23932
Comments
You’d need to at minimum compile with 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):
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
The text was updated successfully, but these errors were encountered: