What causes "Failed to resolve binary {name}" in linera-io/linera-protocol?

Build the needed package so its binary lands beside the current one: cargo build -p

Failed to resolve binary {name}

Error message

Failed to resolve binary {name}

What it means

resolve_binary (used across Linera tooling to spawn helper binaries like proxies and workers) looks for the requested binary next to the currently running executable and bails if it is not present. The error log printed just before suggests the fix: build or install the missing package so the binary sits in the same directory as the current executable.

Source

Thrown at linera-base/src/command.rs:78

) -> Result<PathBuf> {
    let current_binary = current_binary.as_ref();
    debug!(
        "Resolving binary {name} based on the current binary path: {}",
        current_binary.display()
    );

    let current_binary_parent =
        binary_parent(current_binary).expect("Fetching binary directory should not fail");

    let binary = current_binary_parent.join(name);
    let version = format!("v{}", env!("CARGO_PKG_VERSION"));
    if !binary.exists() {
        error!(
            "Cannot find a binary {name} in the directory {}. \
             Consider using `cargo install {package}` or `cargo build -p {package}`",
            current_binary_parent.display()
        );
        bail!("Failed to resolve binary {name}");
    }

    // Quick version check.
    debug!("Checking the version of {}", binary.display());
    let version_message = Command::new(&binary)
        .arg("--version")
        .output()
        .await
        .with_context(|| {
            format!(
                "Failed to execute and retrieve version from the binary {name} in directory {}",
                current_binary_parent.display()
            )
        })?
        .stdout;
    let version_message = String::from_utf8_lossy(&version_message);
    let found_version = parse_version_message(&version_message);
    if version != found_version {

View on GitHub (pinned to 6c226ddcb3)

Solutions

Build the needed package so its binary lands beside the current one: cargo build -p <package>
Or build the whole workspace (make build / cargo build) before running local networks
If installed via cargo install, install the companion package at the same version
Copy the missing binary into the running executable's directory

Example fix

# before
cargo build -p linera-server && ./target/debug/linera-server ...  # linera-proxy missing

# after
cargo build -p linera-server -p linera-proxy && ./target/debug/linera-server ...

Defensive patterns

Strategy: validation

Validate before calling

let binary = linera_base::command::current_binary_parent()?.join(name);
assert!(binary.exists(), "{} missing — run `cargo build -p {package}`", binary.display());
// only then call resolve_binary(name, package).await

Try / catch

// resolve_binary returns Result — handle the Err instead of unwrapping:
match linera_base::command::resolve_binary(NAME, PACKAGE).await {
    Ok(path) => spawn(path),
    Err(e) => eprintln!("missing or unusable {NAME}: {e:#}; build it with cargo build -p {PACKAGE}"),
}

Prevention

Build the whole workspace (make build) before running multi-process tooling
In Docker, copy all required sibling binaries from the same build stage
Pre-flight scripts should assert each required binary exists in the executable's directory

When it happens

Trigger: A Linera binary spawning a sibling process (e.g. linera-server/net-up launching linera-proxy or linera-storage-service) when only one package of the workspace was built — the sibling binary was never produced in target/<profile>/.

Common situations: cargo build -p linera-server alone instead of building the workspace; cargo install of a single package putting binaries in ~/.cargo/bin while the running binary lives elsewhere; partial Docker images copying only one binary; running binaries from target/debug/deps (test harness) where siblings are missing.

Related errors

AI-assisted analysis of linera-io/linera-protocol@6c226ddcb3 (2026-08-22). Data as JSON: /api/errors/003e650b455ab507. Report an issue: GitHub.