Zig binaries contain absolute paths
aherrmann opened this issue · comments
Follow-up issue to #77.
Zig binaries built in debug mode on MacOS will still contain an absolute path to Bazel's output-base directory, even when the Zig library directory is set to a relative path.
To reproduce:
$ bazel build //zig/tests/simple-binary:binary
$ objdump --syms bazel-bin/zig/tests/simple-binary/binary | grep _bazel
000000006481751e d *UND* /private/var/tmp/_bazel_runner/36a8d349c49d2cd2257479c9c92eadb8/sandbox/darwin-sandbox/4/execroot/rules_zig/bazel-out/darwin-fastbuild/bin/zig/tests/simple-binary/binary.o
Surrounding hex dump, via xxd:
000cab30: 3800 5f63 6f6d 7069 6c65 725f 7274 2e66 8._compiler_rt.f
000cab40: 6d61 2e61 6464 5f61 6e64 5f64 656e 6f72 ma.add_and_denor
000cab50: 6d31 3238 005f 636f 6d70 696c 6572 5f72 m128._compiler_r
000cab60: 742e 7564 6976 6d6f 642e 7564 6976 6d6f t.udivmod.udivmo
000cab70: 645f 5f61 6e6f 6e5f 3336 3636 005f 636f d__anon_3666._co
000cab80: 6d70 696c 6572 5f72 742e 7265 6d5f 7069 mpiler_rt.rem_pi
000cab90: 6f32 5f6c 6172 6765 2e72 656d 5f70 696f o2_large.rem_pio
000caba0: 325f 6c61 7267 6500 5f6d 6174 682e 6672 2_large._math.fr
000cabb0: 6578 702e 6672 6578 7036 3400 5f6d 6174 exp.frexp64._mat
000cabc0: 682e 6672 6578 702e 6672 6578 7031 3238 h.frexp.frexp128
000cabd0: 005f 636f 6d70 696c 6572 5f72 742e 6174 ._compiler_rt.at
000cabe0: 6f6d 6963 732e 7370 696e 6c6f 636b 7300 omics.spinlocks.
000cabf0: 2e00 6d61 696e 002f 7072 6976 6174 652f ..main./private/
000cac00: 7661 722f 746d 702f 5f62 617a 656c 5f72 var/tmp/_bazel_r
000cac10: 756e 6e65 722f 3336 6138 6433 3439 6334 unner/36a8d349c4
000cac20: 3964 3263 6432 3235 3734 3739 6339 6339 9d2cd2257479c9c9
000cac30: 3265 6164 6238 2f73 616e 6462 6f78 2f64 2eadb8/sandbox/d
000cac40: 6172 7769 6e2d 7361 6e64 626f 782f 312f arwin-sandbox/1/
000cac50: 6578 6563 726f 6f74 2f72 756c 6573 5f7a execroot/rules_z
000cac60: 6967 2f62 617a 656c 2d6f 7574 2f64 6172 ig/bazel-out/dar
000cac70: 7769 6e2d 6661 7374 6275 696c 642f 6269 win-fastbuild/bi
000cac80: 6e2f 7a69 672f 7465 7374 732f 7369 6d70 n/zig/tests/simp
000cac90: 6c65 2d62 696e 6172 792f 6269 6e61 7279 le-binary/binary
000caca0: 2e6f 005f 6d61 696e 005f 5f5f 7a69 675f .o._main.___zig_
000cacb0: 7072 6f62 655f 7374 6163 6b00 5f6d 656d probe_stack._mem
000cacc0: 6370 7900 5f6d 656d 7365 7400 5f5f 5f61 cpy._memset.___a
000cacd0: 746f 6d69 635f 6c6f 6164 005f 5f5f 6174 tomic_load.___at
000cace0: 6f6d 6963 5f73 746f 7265 005f 5f5f 6174 omic_store.___at
000cacf0: 6f6d 6963 5f65 7863 6861 6e67 6500 5f5f omic_exchange.__
000cad00: 5f61 746f 6d69 635f 636f 6d70 6172 655f _atomic_compare_
000cad10: 6578 6368 616e 6765 005f 5f5f 6174 6f6d exchange.___atom
Upstream issue: ziglang/zig#16028
As of Zig 0.11.0 debug outputs also contain the output base on Linux. Additionally, the output base is included in release fast and release size mode outputs. Only release small builds did not include it. In other words, the behavior reported in ziglang/zig#16028 for MacOS is now also observed on Linux.
The corresponding upstream issuse ziglang/zig#16028 was closed as "nofix" because
I am closing this issue as not applicable since we only guarantee build reproducibility for release builds and with debug info stripped.
This issue here is about the reproducibility concern of embedding non-deterministic absolute paths in the generated binaries. Closely related is issue #207 about enabling debuggers to find the relevant sources.