jdx/mise · error · eyre::Report

macOS release targets cannot declare a libc family

Error message

macOS release targets cannot declare a libc family

What it means

Defensive invariant in release_asset_name: a macOS target was passed with a libc flavor (Some(Glibc)/Some(Musl)). macOS release assets are named mise-v{version}-macos-{arch} with no libc suffix because macOS has a single system libc; declaring one would produce a nonexistent asset name. In the current code this is unreachable from config or CLI: parse_remote_platform maps non-Linux remotes to libc=None and official_release_assets passes None for macos, so hitting it means a new internal call site is passing wrong data.

Source

Thrown at src/system/remote.rs:1093

    format!("{RELEASE_BASE_URL}/v{version}/{filename}")
}

fn release_asset_name(os: &str, arch: &str, libc: Option<LibcFlavor>) -> Result<String> {
    let release_arch = match arch {
        "x86_64" => "x64",
        "aarch64" => "arm64",
        "armv7" => "armv7",
        _ => {
            bail!(
                "mise {} has no official precompiled artifact for {os}/{arch}; set mise_bin, remote_mise, or bootstrap_command",
                env!("CARGO_PKG_VERSION")
            )
        }
    };
    let suffix = match os {
        "macos" if matches!(arch, "x86_64" | "aarch64") => {
            if libc.is_some() {
                bail!("macOS release targets cannot declare a libc family");
            }
            format!("macos-{release_arch}")
        }
        "linux" if matches!(arch, "x86_64" | "aarch64" | "armv7") => match libc {
            Some(LibcFlavor::Glibc) => format!("linux-{release_arch}"),
            Some(LibcFlavor::Musl) => format!("linux-{release_arch}-musl"),
            None => bail!("Linux release targets require a detected libc family"),
        },
        _ => {
            bail!(
                "mise {} has no official precompiled artifact for {os}/{arch}; set mise_bin, remote_mise, or bootstrap_command",
                env!("CARGO_PKG_VERSION")
            )
        }
    };
    Ok(format!("mise-v{}-{suffix}", env!("CARGO_PKG_VERSION")))
}

View on GitHub (pinned to 6f52dcdf99)

Solutions

  1. Pass None as the libc argument whenever os is macos
  2. Keep libc detection gated to Linux (as remote_platform_script does with its case statement)
  3. Add a unit test asserting RemotePlatform for a macos host always carries libc: None

Example fix

// before
let asset = release_asset_name("macos", "aarch64", Some(LibcFlavor::Glibc))?;

// after
let asset = release_asset_name("macos", "aarch64", None)?;
Defensive patterns

Strategy: validation

Validate before calling

// Guard at the call site: macos must never carry a libc family
let libc = if platform.os == "linux" { platform.libc } else { None };
let asset = release_asset_name(&platform.os, &platform.arch, libc)?;

Type guard

fn valid_asset_request(os: &str, arch: &str, libc: Option<LibcFlavor>) -> bool {
    match normalize_os(os).as_str() {
        "macos" => libc.is_none() && matches!(normalize_arch(arch).as_str(), "x86_64" | "aarch64"),
        "linux" => libc.is_some() && matches!(normalize_arch(arch).as_str(), "x86_64" | "aarch64" | "armv7"),
        _ => false,
    }
}

Prevention

When it happens

Trigger: A Rust change calls release_asset_name("macos", arch, Some(libc)) — e.g. someone reuses the Linux libc-detection path for macOS or constructs a RemotePlatform by hand with libc set.

Common situations: Refactoring the platform-detection code and accidentally widening the libc probe to non-Linux OSes; tests that build RemotePlatform values directly.

Related errors


AI-assisted analysis of jdx/mise@6f52dcdf99 (2026-08-22). Data as JSON: /api/errors/529600796d4a0092. Report an issue: GitHub.