Hacker News Reader

Comment by rhencke | Hacker News Reader

Debug information often is choc-full of environment specific goodies that can easily cause builds not to be reproducible.

For example, debug information for several languages I've worked with embed the full path to where the source code file was originally compiled. This can easily vary across two machines in a way that when debug information is turned on, the builds are different, but when turned off they are the same.

View on HN

You are correct, but to use a core file with debug info, the binaries don't have to be bit-perfectly identical. All that has to be equal is the offset of each function and statement and that is the case in reproducible builds. Debug info is only "tacked on"; you can strip a binary, generate a core dump and then use the original binary with debug information to debug the core dump.

While the reproducible builds efforts try to make builds path-independent, at the moment they often settle for reproducibility when built at the same common path. That's still enough that you can reproduce the build yourself.

Does path-independent mean what I think it means? One thing I hate about Linux is having to set prefix at build time. You can't tar up a software and move to your home directory on another machine. That and the lack of compatibility between base libraries/kernels means you can't hope to upgrade chrome for yourself easily like anyone on Windows or Mac can trivially do.

No, in this case it just means binaries won't contain / depend on the path you used to compile it in.

those kinds of differences are exactly part of what the reproducible builds project has worked on

however debug symbols and "debug mode" are two different things.. at least in debian packages are generally compiled with debug symbols on, then separated into a separate package automatically and stripped into the final package as a separate step.

more here: https://reproducible-builds.org/docs/build-path/

Reply on news.ycombinator.com