Problems with MacOS when installing clang tools (from static binaries)

[2bndy5]

Hit an error in MacOS runners during field tests:

Error: {clang_installer::version:153}: Failed to download clang-tidy from static distribution: The static binaries are only built for x86_64 (amd64) architecture

This happens when homebrew fails to install a deprecated formuae:

Error: {clang_installer::downloader::native_packages:120}: Failed to install clang-tidy v11.0.0 using Homebrew package manager: brew failed to install llvm@11 package: ::warning::No available formula with the name "llvm@11". Did you mean llvm, llvm@21, llvm@19, llvm@18, llvm@17, llvm@16, llvm@15, llvm@14, llvm@12 or llvm@20?

Fortunately clang-installer is falling back to static binary download. Unfortunately, the static binaries only build for x86_64.

Good news! I think the latest static binaries' release, master-63858060, now includes aarch64 builds for MacOS. We just have to update clang-installer to use that release (from master-6e612956) here:

cpp-linter-rs/clang-installer/src/downloader/static_dist.rs

Line 49 in 8e2fcad

const CLANG_TOOLS_TAG: &str = "master-6e612956";

[2bndy5]

I don't often get to brag about something I did: The new error messages are very helpful and insightful. Trouble shooting seems to be rather easy because the error messages are so well designed! 🥇

[shenxianpeng]

Good news! I think the latest static binaries' release, master-63858060, now includes aarch64 builds for MacOS.

Now the latest static binaries release is https://github.com/cpp-linter/clang-tools-static-binaries/releases/tag/2026.06.05-5a535621

From this release I started to use release date + commit hash as tag, since master in the tag cannot bring much more information. (And also include others like https://github.com/cpp-linter/clang-tools-static-binaries/releases/download/2026.06.05-5a535621/versions.json)

[2bndy5]

Interesting. I can use that versions.json during compile time to set the max and min versions of supported clang versions. As it is right now, I have them hard-coded in multiple places:

• in CI test workflow:

  cpp-linter-rs/.github/workflows/run-dev-tests.yml

  Lines 99 to 117 in 8e2fcad

  	- name: Run test suite
  	env:
  	MIN_CLANG_TOOLS_VERSION: "11"
  	MAX_CLANG_TOOLS_VERSION: "22"
  	shell: nu {0}
  	run: |-
  	let max_ver = $env.MAX_CLANG_TOOLS_VERSION | into int
  	let min_ver = $env.MIN_CLANG_TOOLS_VERSION | into int
  	for $ver in ($min_ver..$max_ver) {
  	print $"::group::Testing with clang v($ver)"
  	with-env { CLANG_VERSION: $"($ver)" } {
  	nur test --profile warmup
  	let test_profile = (
  	if ($ver == $min_ver) { "all" } else { "ci" }
  	)
  	nur test --profile $test_profile
  	}
  	print "::endgroup::"
  	}

• the rust src looks at env vars then falls back to hard coded defaults.

  cpp-linter-rs/clang-installer/src/downloader/static_dist.rs

  Lines 46 to 49 in 8e2fcad

  	const MIN_CLANG_TOOLS_VERSION: u8 = 11;
  	pub(crate) const MAX_CLANG_TOOLS_VERSION: u8 = 22;
  	const CLANG_TOOLS_REPO: &str = "https://github.com/cpp-linter/clang-tools-static-binaries";
  	const CLANG_TOOLS_TAG: &str = "master-6e612956";

  cpp-linter-rs/clang-installer/src/downloader/static_dist.rs

  Lines 58 to 78 in 8e2fcad

  	pub fn get_major_version_range() -> RangeInclusive<u8> {
  	let min_clang_tools_version: u8 = option_env!("MIN_CLANG_TOOLS_VERSION")
  	.and_then(|v| match v.parse::<u8>() {
  	Ok(parsed) => Some(parsed),
  	Err(e) => {
  	log::error!("Invalid MIN_CLANG_TOOLS_VERSION env var value: {v}. Error: {e}");
  	None
  	}
  	})
  	.unwrap_or(MIN_CLANG_TOOLS_VERSION);
  	let max_clang_tools_version: u8 = option_env!("MAX_CLANG_TOOLS_VERSION")
  	.and_then(|v| match v.parse::<u8>() {
  	Ok(parsed) => Some(parsed),
  	Err(e) => {
  	log::error!("Invalid MAX_CLANG_TOOLS_VERSION env var value: {v}. Error: {e}");
  	None
  	}
  	})
  	.unwrap_or(MAX_CLANG_TOOLS_VERSION);
  	min_clang_tools_version..=max_clang_tools_version
  	}

I could make a build script that downloads that json and parses the max and min versions, then sets a compile-time-only env vars. The test CI will have to do something similar.
While I'm at it, I find a way to get the latest static binaries release and set that to a compile-time-only env var also.

PS - Seems to me that Windows ARM builds are the only ARM platform that is missing.

[shenxianpeng]

Yes, the venison json file will be shipped with the future releases 🤞

https://github.com/actions/runner-images/blob/main/images/windows/Windows11-Arm64-Readme.md it seems like also support to support windows arm builds as well

[2bndy5]

I think I need to have to rename the crate from clang-installer to clang-downloader. Apparently, Windows has a legacy protection feature that prevents running any executable with the word "install" in the name. I don't know why it works in CI, but it is super annoying.

Running any tests on Windows results in an error like this:

error: test failed, to rerun pass `-p clang-installer --lib`

Caused by:
  could not execute process `path/to\cpp-linter-rs\target\debug\deps\clang_installer-bfa2c0e32f7d9e3e.exe downloader::static_dist::tests::find_none --exact --nocapture --include-ignored` (never executed)

Caused by:
  The requested operation requires elevation. (os error 740)

[shenxianpeng]

Hmm, really? interesting. hopefully that would be the root cause then starting rename. btw installer better than downloader for user understanding.

[2bndy5]

I haven't been able to run any tests on windows since adding that crate named clang-installer. I've been depending on CI to see test results for windows (which takes A LOT longer than running tests locally).

I've been researching workarounds. I can disable the Windows feature globally, but that feels risky. I might be able to embed custom XML info using embed-resource at build time, but the test harness is not using the default cargo test (because our tests need to manipulate env vars in parallel). A lib rename seems to be the easiest, and that's considering I've already published v0.1.x releases under the clang-installer name.

[2bndy5]

@shenxianpeng what about clang-tools-manager instead?

[shenxianpeng]

@shenxianpeng what about clang-tools-manager instead?

this is a good one. I also asked AI to suggest the new name. it suggest clang-tools-setup or clang-get for refenrecne

[2bndy5]

I think "setup" was another word for exe names that windows won't run without elevated permission. I liked that one too