BUG: Android cross-compilation fails on Windows host due to hardcoded `linux-x86_64` NDK path

[keufcp]

What happened

Running perry compile --target android on Windows fails with two errors: Perry constructs an NDK toolchain path using the wrong host tag (linux-x86_64 instead of windows-x86_64), and native C dependencies fail to compile because Perry never sets CC_<target> environment variables for Android builds.

What you expected

Perry should resolve the NDK toolchain path using the correct host tag for the build machine (windows-x86_64 on Windows), and pass the relevant CC_<target> environment variables to cargo build so that cc-rs can compile native dependencies such as libsqlite3-sys and libmimalloc-sys — in the same way it already does for HarmonyOS via harmonyos_cross_env.

Minimal reproduction

Any valid Perry UI project triggers this. No specific source change is needed.

// any valid Perry UI project entry point, e.g. src/index.ts

Command you ran:

perry compile src/index.ts --target android

Environment

• Perry version: 0.5.924 (also reproduced on main as of latest)
• Host OS: Windows 11 (x86_64)
• Target: android
• Rust toolchain (if building from source):
• Installed via:
• NDK version: 30.0.14904198
• ANDROID_NDK_HOME: C:\Users\<user>\AppData\Local\Android\Sdk\ndk\30.0.14904198

Diagnostic output

Perry fails to locate the NDK clang binary:

Error: Android NDK clang not found at: C:\Users\<user>\AppData\Local\Android\Sdk\ndk\30.0.14904198/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android24-clang

Separately, because Perry never sets CC_<target> for Android (unlike HarmonyOS), cc-rs has no compiler to use and fails independently:

error occurred in cc-rs: failed to find tool "clang.exe": program not found (see https://docs.rs/cc/latest/cc/#compile-time-requirements for help)

Anything else

There are two independent bugs:

Bug 1 — Wrong NDK host tag (affects platform_cmd.rs and mod.rs)

The following two files share the same pattern that causes Windows to fall through to linux-x86_64:

• crates/perry/src/commands/compile/link/platform_cmd.rs:433 — hard error; build stops here on Windows
• crates/perry/src/commands/compile/link/mod.rs:704 — JNI stub compilation; silently skipped on failure (unwrap_or(false)), but produces a broken binary

// current (both files)
let host_tag = if cfg!(target_os = "macos") {
    "darwin-x86_64"
} else {
    "linux-x86_64"  // Windows falls through here
};

// proposed fix
let host_tag = if cfg!(target_os = "macos") {
    "darwin-x86_64"
} else if cfg!(target_os = "windows") {
    "windows-x86_64"
} else {
    "linux-x86_64"
};

Bug 2 — Missing android_cross_env (causes the cc-rs error)

For HarmonyOS, mod.rs:1313 and optimized_libs.rs:565 both call harmonyos_cross_env() to set CC_<target>, CXX_<target>, etc. before invoking cargo build. No equivalent exists for Android, so cc-rs never receives the NDK clang path and cannot compile native C dependencies.

The fix requires adding an android_cross_env function in library_search.rs (parallel to harmonyos_cross_env) and calling it at the same two sites:

// mod.rs — to be added alongside the existing is_harmonyos block
if is_android {
    if let Some(ndk) = std::env::var_os("ANDROID_NDK_HOME") {
        for (k, v) in library_search::android_cross_env(Path::new(&ndk), target) {
            cargo_cmd.env(k, v);
        }
    }
}

Also, the error message in platform_cmd.rs currently shows a macOS-style example path ($HOME/Library/Android/sdk/...), which is unhelpful for Windows users and should be updated.

[proggeramlug]

@keufcp Thanks for reproting this, it should work with the latest head version (must built from source until tonight when I release the next version) - can you test again?

[keufcp]

I've checked out commit df53c0f7c807b22fc0787df965f2b57e3508c321 and tested it on a clean working tree. However,
the compiler build (cargo build --release) fails due to a Rust compilation error in perry-runtime.

Here is the exact error output:

error[E0425]: cannot find function `set_path_times` in this scope
  --> crates\perry-runtime\src\fs\cp.rs:68:13
   |
68 |     let _ = set_path_times(&dst_string, atime / 1000.0, mtime / 1000.0, !follow);
   |             ^^^^^^^^^^^^^^ not found in this scope

It seems set_path_times is defined in crates/perry-runtime/src/fs/mod.rs but it's either missing an import in
cp.rs (e.g., use super::set_path_times; ) or lacking the proper visibility (like pub(crate) ).

Thanks!

[proggeramlug]

Closing as already fixed on main.

Both bugs described here landed in commit df53c0f7 ("fix(android): cross-compile works on Windows hosts (#1508)", PR #1523):

• Bug 1 (wrong NDK host tag): platform_cmd.rs and link/mod.rs now select windows-x86_64 on Windows hosts, and the ANDROID_NDK_HOME error message includes the Windows (%LOCALAPPDATA%\Android\Sdk\...) example path.
• Bug 2 (missing CC_<target>): android_cross_env() now exists in library_search.rs (mirroring harmonyos_cross_env, and additionally handling the NDK's .cmd wrapper scripts on Windows) and is invoked at both cross-build sites — link/mod.rs and optimized_libs.rs.

Why verification appeared to fail: you checked out df53c0f7 (the fix commit itself) but the build stopped on an unrelated Windows-only compile error in perry-runtime:

error[E0425]: cannot find function `set_path_times` in this scope
  --> crates\perry-runtime\src\fs\cp.rs:68

That's a separate regression (copy_preserve_timestamps called a #[cfg(unix)] function unconditionally; CI missed it because tests run on Linux/macOS). It's fixed in #1736. Once that merges and the next version is released, building from source — or the released Windows binary — will compile, and perry compile --target android should resolve the NDK toolchain and native C deps correctly.

If you still hit an Android cross-compile problem on main after #1736, please reopen with the new output. Thanks for the detailed report!

[keufcp]

Hi! Thanks for the quick fix for the host tag issue!
However, building on Windows still fails due to two remaining path issues. I verified the contents of the NDK
windows-x86_64/bin directory locally:

1. Missing AR environment variable for cc-rs: cc-rs fails to find aarch64-linux-android-ar. The NDK
   bin directory contains llvm-ar.exe. The fix is to export AR_<triple> pointing to llvm-ar.exe in
   android_cross_env.

   error occurred in cc-rs: failed to find tool "aarch64-linux-android-ar": program not found
   

2. Missing .cmd extension for clang on Windows: In platform_cmd.rs , the linker command is hardcoded to
   aarch64-linux-android24-clang without an extension. The Windows NDK bin directory contains both an extensionless file
   (which is a 209-byte shell script) and aarch64-linux-android24-clang.cmd . Rust's Command::new attempts to
   execute the shell script on Windows and fails during the linking stage with os error 193 .
   Error: %1 is not a valid Win32 application. (os error 193)

Proposed additional fixes:

In library_search.rs ( android_cross_env):

    let ar_ext = if cfg!(target_os = "windows") { ".exe" } else { "" };
    let llvm_ar = bin.join(format!("llvm-ar{}", ar_ext));

    vec![
        // ... existing CC and CXX exports
        (format!("AR_{}", triple), llvm_ar.display().to_string()),
        (format!("AR_{}", triple_under), llvm_ar.display().to_string()),
        // ...
    ]

In platform_cmd.rs (around line 446):

        let ext = if cfg!(target_os = "windows") { ".cmd" } else { "" };
        let clang = format!(
            "{}/toolchains/llvm/prebuilt/{}/bin/aarch64-linux-android24-clang{}",
            ndk_home, host_tag, ext
        );

Thanks!