Reproducible builds outputting differing .elf and .bin files (IDFGH-12690)

[mianowill]

Answers checklist.

• [x] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• [X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• [X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.2.1

Operating System used.

macOS

How did you build your project?

Command line with idf.py

If you are using Windows, please specify command line type.

None

What is the expected behavior?

Building with CONFIG_APP_REPRODUCIBLE_BUILD should build the same binary regardless of the machine it's built on, provided the same IDF version is used.

What is the actual behavior?

Full paths are removed from the .bin file, but the .elf file contains the full toolchain path—something like /Users/mia/.espressif/tools/xtensa-esp-elf rather than /ESPRESSIF_TOOLS_DIR/xtensa-esp-elf. Paths for the project file and IDF components are correctly replaced; it's just the xtensa-esp-elf files in the tools dir that keep the full path. This means that the elf files will differ when built on different machines, and so the app.bin file will have a different elf SHA.

Steps to reproduce.

• idf.py build
• sha256sum build/app.bin build/app.elf

Example sdkconfig: sdkconfig.txt. Built with a clean IDF 5.2.1 on MacOS.

Build or installation Logs.

No response

More Information.

No response

[dobairoland]

The beginning of https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/reproducible-builds.html states conditions under which the binaries remain the same. Your highlighted case is not amongst them. So I mark this a feature request.

There might be a workaround for you (I haven't tried it): to install the tools under the same directory in each machine, e.g. a global /opt/espressif/ directory.

[igrr]

@mianowill We've merged the fix for this bug internally, this issue will be closed automatically when the commit is synced to Github. We will backport the fix to release/v5.3 and release/v5.2 branches, as well.