Bump rules_cc to 0.1.4

[UebelAndre]

No description provided.

[UebelAndre]

Looks like macos doesn't work after updating to >=0.1.2
https://buildkite.com/bazel/rules-rust-rustlang/builds/15189/steps/canvas?sid=019858d4-277e-42c2-a1ce-b567a0d6a8e7

(02:58:02) ERROR: /Users/buildkite/builds/bk-macos-arm64-pz85/bazel/rules-rust-rustlang/util/process_wrapper/BUILD.bazel:31:36: Compiling Rust (without process_wrapper) bin process_wrapper (6 files) failed: (Exit 1): bootstrap_process_wrapper.sh failed: error executing Rustc command (from target //util/process_wrapper:process_wrapper)
  (cd /private/var/tmp/_bazel_buildkite/a86460401be5422e0ecc75a08e74f9e3/sandbox/darwin-sandbox/75/execroot/_main && \
  exec env - \
    CARGO_CFG_TARGET_ARCH=aarch64 \
    CARGO_CFG_TARGET_OS=macos \
    CARGO_CRATE_NAME=process_wrapper \
    CARGO_MANIFEST_DIR='${pwd}/util/process_wrapper' \
    CARGO_PKG_AUTHORS='' \
    CARGO_PKG_DESCRIPTION='' \
    CARGO_PKG_HOMEPAGE='' \
    CARGO_PKG_NAME=process_wrapper \
    CARGO_PKG_VERSION=0.0.0 \
    CARGO_PKG_VERSION_MAJOR=0 \
    CARGO_PKG_VERSION_MINOR=0 \
    CARGO_PKG_VERSION_PATCH=0 \
    CARGO_PKG_VERSION_PRE='' \
    REPOSITORY_NAME='' \
    ZERO_AR_DATE=1 \
  bazel-out/darwin_arm64-opt-exec-ST-d57f47055a04/bin/util/process_wrapper/bootstrap_process_wrapper.sh -- bazel-out/darwin_arm64-fastbuild/bin/external/+rust+rust_macos_aarch64__aarch64-apple-darwin__stable_tools/rust_toolchain/bin/rustc util/process_wrapper/main.rs '--crate-name=process_wrapper' '--crate-type=bin' '--error-format=human' '--out-dir=bazel-out/darwin_arm64-fastbuild/bin/util/process_wrapper' '--codegen=opt-level=0' '--codegen=debuginfo=0' '--codegen=strip=none' '--remap-path-prefix=${pwd}=.' '--emit=link=bazel-out/darwin_arm64-fastbuild/bin/util/process_wrapper/process_wrapper' '--emit=dep-info' '--color=always' '--target=aarch64-apple-darwin' -L bazel-out/darwin_arm64-fastbuild/bin/external/+rust+rust_macos_aarch64__aarch64-apple-darwin__stable_tools/rust_toolchain/lib/rustlib/aarch64-apple-darwin/lib '--edition=2018' '-Cembed-bitcode=no' '--codegen=linker=external/rules_cc++cc_configure_extension+local_config_cc/cc_wrapper.sh' '--codegen=link-arg=-mmacosx-version-min=15.2' '--codegen=link-arg=-no-canonical-prefixes' '--codegen=link-arg=-fobjc-link-runtime' '--codegen=link-arg=-headerpad_max_install_names' '--codegen=link-arg=-lc++' '--codegen=link-arg=-lm' '--extern=tinyjson=bazel-out/darwin_arm64-fastbuild/bin/external/+i+rules_rust_tinyjson/libtinyjson-2730294943.rlib' '-Ldependency=bazel-out/darwin_arm64-fastbuild/bin/external/+i+rules_rust_tinyjson' '--sysroot=bazel-out/darwin_arm64-fastbuild/bin/external/+rust+rust_macos_aarch64__aarch64-apple-darwin__stable_tools/rust_toolchain')
# Configuration: 44d823af471c00a0f331560f31c47d7492ea88dc35aa83e5331e5aab8731d666
# Execution platform: @@platforms//host:host
Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
error: linking with `external/rules_cc++cc_configure_extension+local_config_cc/cc_wrapper.sh` failed: exit status: 127
  |
  = note:  "external/rules_cc++cc_configure_extension+local_config_cc/cc_wrapper.sh" "/tmp/rustcYxWIZ7/symbols.o" "<17 object files omitted>" "/private/var/tmp/_bazel_buildkite/a86460401be5422e0ecc75a08e74f9e3/execroot/_main/bazel-out/darwin_arm64-fastbuild/bin/external/+i+rules_rust_tinyjson/{libtinyjson-2730294943.rlib}.rlib" "/private/var/tmp/_bazel_buildkite/a86460401be5422e0ecc75a08e74f9e3/external/+rust+rust_macos_aarch64__aarch64-apple-darwin__stable_tools/lib/rustlib/aarch64-apple-darwin/lib/{libstd-b14eaf39f161baba.rlib,libpanic_unwind-e9afca0624de13f2.rlib,libobject-f4f25c763c07e1da.rlib,libmemchr-f5821a4757eb4967.rlib,libaddr2line-e2075fd42f8fdfe6.rlib,libgimli-08932eb7054dd262.rlib,librustc_demangle-ed8c67e97825d1a5.rlib,libstd_detect-1047965a55c74dd5.rlib,libhashbrown-a128e33792b49d56.rlib,librustc_std_workspace_alloc-9d142a7fc6a557ed.rlib,libminiz_oxide-b5c8cae15aefe652.rlib,libadler2-458be00c7580c8fb.rlib,libunwind-ebf825f8faf836bb.rlib,libcfg_if-c920e7cfad4eac40.rlib,liblibc-b046c3bdd2263ebf.rlib,liballoc-4320d4958ec5f4d4.rlib,librustc_std_workspace_core-8e246dbdcfd33251.rlib,libcore-c8c2fe5a80a1416e.rlib,libcompiler_builtins-78f29445e315e03f.rlib}.rlib" "-lSystem" "-lc" "-lm" "-arch" "arm64" "-mmacosx-version-min=11.0.0" "-L" "<sysroot>/lib/rustlib/aarch64-apple-darwin/lib" "-o" "bazel-out/darwin_arm64-fastbuild/bin/util/process_wrapper/process_wrapper" "-Wl,-dead_strip" "-nodefaultlibs" "-mmacosx-version-min=15.2" "-no-canonical-prefixes" "-fobjc-link-runtime" "-headerpad_max_install_names" "-lc++" "-lm"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: env: bash: No such file or directory
error: aborting due to 1 previous error

@keith does that ring any bells? I saw you made a ton of changes to rules_cc in 0.1.2 and you're also a known expert on Apple systems.

[keith]

note: env: bash: No such file or directory

🤔 any idea which file this is referring to? is this using the latest apple_support too?

[UebelAndre]

note: env: bash: No such file or directory

🤔 any idea which file this is referring to? is this using the latest apple_support too?

I first saw this in #3534 where I was bumping everything.

And isn't this referring to https://github.com/bazelbuild/rules_cc/blob/0769eb3cec5ae57b02c1f34709643f7cc872af21/cc/private/toolchain/osx_cc_wrapper.sh.tpl#L1 ?

[UebelAndre]

@keith By the time cc_wrapper.sh is called there is no PATH in the environment

 CARGO_CFG_TARGET_ARCH=aarch64
CARGO_CFG_TARGET_OS=macos
CARGO_CRATE_NAME=process_wrapper
CARGO_MANIFEST_DIR=${pwd}/util/process_wrapper
CARGO_PKG_AUTHORS=
CARGO_PKG_DESCRIPTION=
CARGO_PKG_HOMEPAGE=
CARGO_PKG_NAME=process_wrapper
CARGO_PKG_VERSION=0.0.0
CARGO_PKG_VERSION_MAJOR=0
CARGO_PKG_VERSION_MINOR=0
CARGO_PKG_VERSION_PATCH=0
CARGO_PKG_VERSION_PRE=
PWD=/private/var/tmp/_bazel_user/76282c66b0dfe3c5cb9a230bdc913a52/sandbox/darwin-sandbox/91/execroot/_main
REPOSITORY_NAME=
RULES_RUST_PROCESS_WRAPPER_DEBUG=1
SHLVL=1
TMPDIR=/var/folders/h4/_xm41cq11v90znmm9dz87wdc0000gn/T/
ZERO_AR_DATE=1
_=/usr/bin/env
__CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0

Thus, the #!/usr/bin/env bash shebang fails. Can this be an absolute path on MacOS (#!/bin/bash)?

[keith]

i think some folks did a pass to avoid /bin/bash for portability bazelbuild/rules_cc@d749150

should that action be setting use_default_shell_env=True?

[UebelAndre]

i think some folks did a pass to avoid /bin/bash for portability bazelbuild/rules_cc@d749150

should that action be setting use_default_shell_env=True?

I would rather avoid inconsistencies from things injected into PATH on various users machines for these actions. As far as I know that flag is convenient but otherwise degrades caching. If there's some magic I'm not aware of to avoid the consequences I'd be happy to turn it on.

[keith]

that respects --incompatible_strict_action_env so if the user cares about hermiticity they will still cover the risks there

[UebelAndre]

I opened bazelbuild/rules_cc#448 which resolves should resolve this issue.

[keith]

fwiw i think it's fair for actions to require that PATH is set to something reasonable, so i imagine there will be some pushback on that

[UebelAndre]

fwiw i think it's fair for actions to require that PATH is set to something reasonable, so i imagine there will be some pushback on that

In practice, maybe? But wouldn't the ideal be the action has everything it needs to get the job done? And if so, why would PATH be needed? If this is an intentional change to require PATH then it'd be nice to have an incompatibility flag for an easier transition.

[hzeller]

Using /bin/bash would be a step back from /usr/bin/env.
More and more people use operating systems such as NixOS which they don't provide binaries at hard-coded places.

The issue seems to be that the CI environment just not provides a path to /bin ? Then that should be fixed.

[UebelAndre]

Using /bin/bash would be a step back from /usr/bin/env. More and more people use operating systems such as NixOS which they don't provide binaries at hard-coded places.

The issue seems to be that the CI environment just not provides a path to /bin ? Then that should be fixed.

@hzeller Is the issue is the not lack of PATH? Which I explicitly do not want in the action as it introduces volatility.

[UebelAndre]

@hzeller I think the direction to require PATH is wrong and introduces more ways for actions to behave differently on machines than to actually provide through Bazel the tools needed. I do not want to have to enable use_default_shell_env for this reason. If this is the direction from rules_cc then it should have been considered a breaking change and released with an appropriate semver. I'll defer to @illicitonion @krasimirgg and @scentini on a path forward if the use of /bin/sh (updated on bazelbuild/rules_cc#448) for the template is not acceptable.

[hzeller]

If things can be converted to /bin/sh that would be great. That is the only Posix-expected shell to exist.

If you use bash, you have to use /usr/bin/env (similar how you have to do that with python as that also is not in specific predictable paths).

[keith]

I think there are 2 issues going against the grain here.

1. Not having PATH does not mean that there isn't a calculated PATH, and that PATH therefore does not respect whatever the user is requesting with --incompatible_strict_action_env, or --action_env=PATH=something. Specifically on macOS the default PATH in bash when non is set includes /usr/local/bin, which you often want to avoid since that's not a hermetic install location (less of an issue now that homebrew moved their default install path)
2. Not setting use_default_shell_env=True means other env users might expect via --action_env will not be propagated to the action. Maybe this action "never" needs other env vars but as a user who has had to debug why my env vars weren't propagated only to specific actions before, that seems like a bug to me

[UebelAndre]

I think there are 2 issues going against the grain here.

1. Not having PATH does not mean that there isn't a calculated PATH, and that PATH therefore does not respect whatever the user is requesting with --incompatible_strict_action_env, or --action_env=PATH=something. Specifically on macOS the default PATH in bash when non is set includes `/usr/local/bin`, which you often want to avoid since that's not a hermetic install location (less of an issue now that homebrew moved their default install path)

2. Not setting use_default_shell_env=True means other env users might expect via --action_env will not be propagated to the action. Maybe this action "never" needs other env vars but as a user who has had to debug why my env vars weren't propagated only to specific actions before, that seems like a bug to me

Interacting with PATH at all feels like an anti-pattern that only occurs out of convenience. I think a more common and frustrating error in using PATH is an action failing and then the solution I'm given is "oh, just apt install ..." which can have a much larger impact on the rest of the system.

I do think --action_env should make it's way into all actions but if allowing this means setting use_default_shell_env=True and involuntarily getting extra variables on the system that I can only exclude by using an incompatibility flag with no timeframe for when it will be flipped (and thus the default) doesn't feel like a better solution to me. The bug feels like --action_env should be respected.

So TLDR my opinion is:

1. PATH should not be necessary and actions should track the tools they need with Bazel
2. --action_env should apply to all actions and cases where this doesn't happen should be considered a bug.

[keith]

The bug feels like --action_env should be respected.

Yea but the fix for this is top flip use_default_shell_env=True. It doesn't pull in all env, just some AFAIUI

PATH should not be necessary and actions should track the tools they need with Bazel

But there is still a PATH and you still rely on it, not for bash if you do the change back to /bin/bash but for potentially anything else in the script. And even worse the default PATH is less-hermetic than ones users can provide.

[aaliddell]

Bringing a couple of notes over from #3556 that I can't see having been discussed:

• The PATH could still be used but not in the action if use_default_shell_env would like to be avoided. This can be done by embedding the absolute bash path into the cc_wrapper script by using repository_ctx.which in rules_cc when writing the template. This would then do the PATH resolution once at templating time and the script would then not need PATH (unless it itself called something else). I have tested this works and you can see a working PoC at aaliddell/rules_cc@ccc68c0. That commit does not update all sripts in rules_cc that might be affected, just the cc_wrapper templates.

• There is actually a script in this repo that also has the same problem at https://github.com/bazelbuild/rules_rust/blob/main/util/process_wrapper/private/process_wrapper.sh. As far as I can see, if this was used in rustc.bzl and _use_sh_toolchain_for_bootstrap_process_wrapper was not set (or there was no sh toolchain), it would fail for the same reason as above. But this was just a quick scan, so maybe I missed a step