search

bazel-contrib / rules_foreign_cc

Build rules for interfacing with "foreign" (non-Bazel) build systems (CMake, configure-make, GNU Make, boost, ninja, Meson)
https://bazel-contrib.github.io/rules_foreign_cc
Apache License 2.0
673 stars 248 forks source link

Sandbox makes build non-deterministic when building with debug symbols #1271

Closed aaron-michaux closed 1 month ago

aaron-michaux commented 2 months ago

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 commented 2 months ago

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.