jdx/mise · error

could not identify the libc provided by remote loader {inter

Error message

could not identify the libc provided by remote loader {interpreter} on '{}'; set mise_bin, remote_mise, or bootstrap_command

What it means

The remote host does have a dynamic loader, but the probe could not classify it as glibc or musl (parse_libc_flavor returned nothing for the interpreter output). mise must know the remote libc family to compare it against the local binary's requirements and choose a compatible artifact.

Source

Thrown at src/system/remote.rs:1774

    );
    let remote_output = session.output_async(&["sh", "-c", &check]).await?;
    if remote_output
        .lines()
        .any(|line| line == "MISE_LOADER_MISSING")
    {
        bail!(
            "remote host '{}' does not provide the dynamic loader required by local mise: {interpreter}; set mise_bin, remote_mise, or bootstrap_command",
            session.host.name
        );
    }
    let remote_libc = parse_libc_flavor(&remote_output).ok_or_else(|| {
        eyre!(
            "could not identify the libc provided by remote loader {interpreter} on '{}'; set mise_bin, remote_mise, or bootstrap_command",
            session.host.name
        )
    })?;
    if local_libc != remote_libc {
        bail!(
            "remote host '{}' libc {remote_libc:?} is incompatible with local mise libc {local_libc:?}; set mise_bin, remote_mise, or bootstrap_command",
            session.host.name
        );
    }
    let required = match local_libc {
        LibcFlavor::Glibc => max_required_glibc_version(&binary_bytes).ok_or_else(|| {
            eyre!(
                "could not determine the glibc ABI required by local mise; set mise_bin, remote_mise, or bootstrap_command"
            )
        })?,
        LibcFlavor::Musl => parse_musl_runtime_version(&combined_output(&local_output))
            .ok_or_else(|| {
                eyre!(
                    "could not determine the musl version used by local mise loader {interpreter}; set mise_bin, remote_mise, or bootstrap_command"
                )
            })?,
    };
    let available = match remote_libc {

View on GitHub (pinned to afd2eddd3a)

Solutions

  1. Set `remote_mise`/`mise_bin` to a known-compatible binary, skipping libc matching
  2. Install standard glibc or musl tooling (ldd, loader at canonical path) on the remote
  3. Provide `bootstrap_command` that installs a static (musl) mise build independent of the remote libc
  4. Normalize the remote environment so the loader sits at its canonical path

Example fix

# before
[remote]
host = "root@uclibc-box"

# after
[remote]
host = "root@uclibc-box"
mise_bin = "/opt/bin/mise"  # static musl binary, libc matching skipped
Defensive patterns

Strategy: fallback

Validate before calling

# confirm the remote libc is classifiable before relying on auto-matching
ssh "$HOST" 'ldd --version 2>&1 | head -1' | grep -qiE 'glibc|musl' || echo "unclassifiable libc; configure remote_mise/mise_bin" >&2

Prevention

When it happens

Trigger: `mise rsync`/push against a remote where the loader probe output doesn't parse — e.g. a musl loader present but ldd/--version output in unexpected format, uclibc or other niche libc, patched/renamed loaders, or interpreter strings pointing to non-standard paths.

Common situations: Embedded Linux systems, alternative libcs (uclibc-ng), NixOS or Gentoo systems with unusual loader layouts, or containers with partially removed libc tooling.

Understand the failure class

Background: "unsupported platform" / "not supported on this platform" errors: what they mean and how to fix them — this error's family across 47 libraries.

Related errors


AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09). Data as JSON: /api/errors/8394ab178fdc3145. Report an issue: GitHub.