This article is amazing. I also face the problem of reproducibility every day, I’m also an embedded firmware developer. I avoid using macros like __TIME__, use relative paths on the gcc command line, etc.
But I can see that you’re emphasizing certain aspects that I hadn’t considered and that I don’t fully understand.
What matters to me is the binary, not so much the elf it comes from. It’s the binary that’s written in the microncontroller flash. So I’m wondering why you want elf reproducibility, too. If from two different directories you compile different elf, but the binaries are the same, then what’s the problem?
About the second patch: I tried to replace the ROOT_DIR := $(abspath .) assignment with ROOT_DIR := . and not to apply patch 03. I would have expected it to work instead it doesn’t but I don’t understand why.
Finally, I ask you how risky it is to embed the GNU build ID into the binary, since it also depends on the debug sections.
So even changing just one gcc parameter to drive debugging (like -g3 or -g2) would change the SHA1 without changing the binary functionally.
In my opinion, it is risky to introduce a dependence on information (debugging information) that is not present in the binary itself.
best regards
Max