Set ARFLAGS in the cargo_build_script rule

[armandomontanez]

This was preventing ar flags from propagating to the cargo build script runner.

[UebelAndre]

Seems reasonable to me! Would you also be able to add some sort of regression test to //test/cargo_build_script/...? I would love to know the plumbing of AR args continues to work.

edit: Also, thank you!

[armandomontanez]

Looks like the macOS failure is very relevant; the configured toolchain's AR binary is still not making it through. It looks like toolchains_llvm intends to use libtool-darwin, but either it's misconfigured, or something here still isn't picking up that tool.

[armandomontanez]

Looks like the macOS failure is very relevant; the configured toolchain's AR binary is still not making it through. It looks like toolchains_llvm intends to use libtool-darwin, but either it's misconfigured, or something here still isn't picking up that tool.

Hmm... or not. Looks like it's failing on other builds too. Test log contents:

exec ${PAGER:-/usr/bin/less} "$0" || exit 1
Executing tests from //test/cc_shared_library:test
-----------------------------------------------------------------------------
external/bazel_tools/tools/test/collect_cc_coverage.sh: line 99: : command not found
error: coverage collection script failed

[armandomontanez]

Hmm, Cross compilation with bzlmod on macOS does appear to be a real failure. Got mixed up with another failure.

TL;DR: cc-rs does not properly support libtool, which means enabling support for respecting the AR toolchain breaks all macOS toolchains that use libtool or llvm-libtool-darwin.

[armandomontanez]

I'd much rather emit an error if libtool is in use rather than using a non-hermetic ar, but that's a breaking change. For now, I'll retain the previous behavior but make it more likely to work as intended (catching llvm-libtool-darwin in addition to libtool, and clearing ARFLAGS that are now properly forwarded for other archiver tools).

I'll try to add libtool support to cc-rs in parallel, but probably shouldn't block on that.

[armandomontanez]

Ping :)

[UebelAndre]

Thank you!

[finn-ball]

Though I support the efforts to streamline bazel's toolchain and rust's, this has the potential to affect anything which depends on the cc-rs crate which can prepend cq to any ar command, conflicting with ar flags set by bazel's toolchain.

https://github.com/rust-lang/cc-rs/blob/9ec00e4bf2a8b087760245b0ec721fb3bd59731f/src/lib.rs#L2747
https://github.com/rust-lang/cc-rs/blob/9ec00e4bf2a8b087760245b0ec721fb3bd59731f/src/lib.rs#L3275

It is trivial to patch but just adding this here as a warning as this is a fairly fundamental crate to many builds.

[fhanau]

Though I support the efforts to streamline bazel's toolchain and rust's, this has the potential to affect anything which depends on the cc-rs crate which can prepend cq to any ar command, conflicting with ar flags set by bazel's toolchain.

https://github.com/rust-lang/cc-rs/blob/9ec00e4bf2a8b087760245b0ec721fb3bd59731f/src/lib.rs#L2747 https://github.com/rust-lang/cc-rs/blob/9ec00e4bf2a8b087760245b0ec721fb3bd59731f/src/lib.rs#L3275

It is trivial to patch but just adding this here as a warning as this is a fairly fundamental crate to many builds.

Seeing the same issue – this change results in running $AR rcsd cq when building some crates, causing the action to fail based on the archive being absent so far.

[armandomontanez]

Yep, this wasn't caught in presubmit due to how toolchains_llvm's ar flags end up being spelled out. Submitted a partial revert (reverted forwarding of AR flags, but not the finding of the archiver tool) as #3763, which is available in 0.68.1. Sorry for the inconvenience here.