@dsc, I haven’t been able to reproduce your release builds. I did, however, find that the result varies depending on the build machine’s CPU family.
These are Linux x86_64 binaries compiled using the “reproducible” Docker-based build instructions, each time restarting from a fresh OS image. I’ve tested across different VM configs and distros, and the only difference seems to come varying the CPU.
What CPU did you use? Either I haven’t hit your exact CPU model, or dependencies have drifted enough for the builds to no longer match.
Or I might be missing something silly.
The only thing I changed was the Boost download URL in
Dockerfile, which had moved due to Bintray shutting down. Instead of https://dl.bintray.com/boostorg/release/1.73.0/source/boost_1_73_0.tar.gz, it’s now https://boostorg.jfrog.io/artifactory/main/release/1.73.0/source/boost_1_73_0.tar.gz.
For everyone trying to replicate, there are a couple of build steps which can cause problems if run from behind a pesky firewall or proxy that chokes on anything but vanilla HTTP or HTTPS:
- The Qt build step downloads code via the
git:// protocol. Try
https://code.qt.io/ instead of
- The same goes for GnuPG–try
https://dev.gnupg.org/source/ instead of
These changes have no effect on the resulting binaries.
Running 6 jobs in parallel eats up RAM fast. Have about 10 GB free (about 6 GB physical, swap is fine for the rest), or reduce the parallelism.