[nix23]

>it's very likely you won't be able to analyze the core..

You know that's the reproducible part, exact same library's same compiler same options.

>Compilers don't produce reproducible builds.

Sure they do, just compile two times the same and compare its hash, would be terrible if compilers makes something else every-time.

[giantrobot]

By default you're not guaranteed the exact same output in two compiled binaries. There's a lot of variable bits[1] that make into binaries from C and C++. Different languages/compilers have different levels of variable bits.

[1] https://blog.conan.io/2019/09/02/Deterministic-builds-with-C...

[nix23]

>Different languages/compilers have different levels of variable bits.

No that's the point! Exact same environment same binary, that's reproducibility.

[giantrobot]

Yes that would be reproducibility iff the environment is identical. However "identical environment" is a complicated issue.

Differing file paths, timestamps, and host date/time can all easily make their way into a binary through macros in several languages without explicit compiler/linker flags. If compiled artifacts are bundled into a container (like a jar file) their metadata need to deterministically set or else the container as an artifact won't be deterministic.

So yes doing all the work to make build deterministic enables reproducibility but it's not free or automatic. Then doing the work to ensure the build environment is deterministic is an additional task that's not free or automatic.

[nix23]

>make build deterministic enables reproducibility but it's not free or automatic

No one said that, Debian had a really hard time:

https://wiki.debian.org/ReproducibleBuilds/About