search

f0rmiga / gcc-toolchain

A fully-hermetic Bazel GCC toolchain for Linux.
Apache License 2.0
103 stars 24 forks source link

[Bug]: incompatible_sandbox_hermetic_tmp (on by default in bazel 7.0.0) breaks the gcc wrapper #161

Open novas0x2a opened 9 months ago

novas0x2a commented 9 months ago

What happened?

incompatible_sandbox_hermetic_tmp causes some relative paths to change, and results in this logic no longer pointing to the correct location (on my machine, it just ends up being /tmp)

This produces an error like:

external/gcc_toolchain_armv7/bin/gcc: line 45: /tmp/external/gcc_toolchain_armv7_files/bin/arm-linux-gcc: No such file or directory

Version

Development (host) and target OS/architectures: linux/amd64

Output of bazel --version: 7.0.0

Version of the Aspect rules, or other relevant rules from your WORKSPACE or MODULE.bazel file:

Language(s) and/or frameworks involved:

How to reproduce

from aspect/gcc-toolchain:

echo 7.0.0 > .bazelversion
bazel build --noenable_bzlmod //...
ERROR: $ROOT/aspect/gcc-toolchain/examples/hello_world_cpp/BUILD.bazel:19:10: Compiling examples/hello_world_cpp/main.cpp failed: (Exit 127): gcc failed: error executing CppCompile command (from target //examples/hello_world_cpp:hello_world_cpp) external/gcc_toolchain_armv7/bin/gcc -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer '-std=c++0x' -MD -MF ... (remaining 32 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
external/gcc_toolchain_armv7/bin/gcc: line 45: /tmp/external/gcc_toolchain_armv7_files/bin/arm-linux-gcc: No such file or directory

Any other information?

What seems to work is to pass the previously calculated execroot into _render_tool_paths and then further into the wrapper via a new __EXECROOT__ substitution but i'm not sure if that's an approach that would backfire in some way.

alexeagle commented 7 months ago

I find that logic also fails under rules_rust which sets PATH to a single entry that doesn't include dirname or realpath:

PATH="bazel-out/k8-opt-exec-ST-13d3ddad9198/bin/external/rust_linux_x86_64__x86_64-unknown-linux-gnu__stable_tools/rust_toolchain/lib/rustlib/x86_64-unknown-linux-gnu/bin" ...

Perhaps this is a rules_rust bug?

I think this line needs to be rewritten but I'm not sure how to verify the change works.