Sandbox makes build non-deterministic when building with debug symbols

[aaron-michaux]

The sandbox has a unique incrementing number in its path, which in turn finds its way into the debug symbols. This means that binary targets are non-deterministic. For example, when I build @zlib//:zlib with debug symbols, the bit-pattern of libz.a depends on sandbox path, which changes from build to build. Thus, anything that links to libz.a is also non-deterministic.

Gcc has an option -fdebug-prefix-map=old=new, which can mitigate against this; however, to set this option, you'd have to a priori know the path to the sandbox. That is, we want to have a flag that looks like: -fdebug-prefix-map=$SANDBOX_PATH=., where the bazel rule fills in $SANDBOX_PATH for you.

In my mind, this is an issue with the bazel sandbox itself; however, the issue can be mitigated in rules_foreign_cc.

Thanks to @fmeum for prompting me to create this ticket.

[fmeum]

In my mind, this is an issue with the bazel sandbox itself; however, the issue can be mitigated in rules_foreign_cc.

It's not an issue with the sandbox itself if you follow its golden rule: exclusively use relative paths. If you do that, then compilers would generally emit relative paths into debug output. But rules_foreign_cc may not be able to ensure this as it forks out to external build systems.