Support for libtool as the archiver on macOS #1608
Description
Summary
When building with Bazel (using rules_rust), the environment variables AR and AR_FLAGS may be set based on the resolved C/C++ toolchain. On macOS, that toolchain sometimes defines the archiver as libtool or llvm-libtool-darwin, rather than ar.
However, cc-rs currently assumes that the archiver is always ar when targeting Unix-like platforms, which fails because default ar flags such as "rq" or "s" do not exist on libtool.
More importantly, libtool doesn't support adding objects to an existing archive (but creates a symbol index by default).
So currently, the invocation logic as well as the default flags are incompatible with libtool.
Exotism
This situation may be somewhat “exotic” in a pure Rust context, since Rust projects don’t use Bazel directly.
However, when embedding Rust crates into larger multi-language monorepos (e.g., C/C++/Rust together under Bazel), rules_rust propagate its C toolchain environment to Rust builds — including AR and AR_FLAGS, CFLAGS etc.
That makes cc-rs a point of failure when it assumes ar semantics, even though AR may correctly point to libtool according to the toolchain configuration.
Next steps
Does it make sense for cc-rs to support libtool as a valid archiver on macOS, given this growing cross-toolchain use case?
If so, would changing the logic to support a special libtool path make sense ?
Example error:
error occurred in cc-rs: command did not execute successfully (status code exit status: 1):
ZERO_AR_DATE="1" "llvm-libtool-darwin" "cq" "external/rules_rust++crate+crates__libmimalloc-sys-0.1.44/_bs.out_dir/libmimalloc.a" "external/rules_rust++crate+crates__libmimalloc-sys-0.1.44/_bs.out_dir/077ae3504b1c7768-static.o"