Windows Cross-Compilation to Android: Linker errors and fixes

[YC-CLT]

Windows Cross-Compilation to Android Linker Failures

What happened

On Windows 11 using Perry 0.5.1206 (official release binary perry-windows-x86_64.zip) to compile a TypeScript application targeting aarch64-linux-android, the linking phase failed with multiple cascading errors:

1. The command line exceeded Windows CreateProcess's 32767 character limit (error: The command line is too long.), causing the compilation to fail immediately.

2. After enabling response files, backslashes \ in paths were interpreted as escape characters by clang/lld, causing object files to not be found (example errors: no such file or directory: '\?D:...o' and no such file or directory: 'd:Code...perry_stdlib.a').

3. The NDK's .cmd wrapper invoked via cmd.exe /c added unnecessary command-line length overhead and introduced potential argument-passing issues.

4. The default_output_path function lacked a special case for Android targets, returning the bare name app, which already existed as a directory. This caused the linker to fail with: ld.lld: error: cannot open output file app: Is a directory.

5. A Rust 1.96 macro compatibility issue: replace_expr!($i f64) was missing a comma, causing a compilation error (no rules expected f64).

I subsequently modified the Perry source code (based on the 0.5.1206 tag) to fix the above issues, rebuilt my own Perry binary, and ultimately compiled successfully, producing app/libapp.so.

What you expected

Perry should successfully cross-compile Android dynamic libraries on Windows out-of-the-box. The output filename should be lib<project>.so (e.g., libapp.so), and the linking process should not be blocked by command-line length limits or path escaping issues, without requiring manual build script modifications.

Minimal reproduction

Using the official Perry release perry-windows-x86_64.zip (or building from source), on Windows 11, run:

perry compile src/ts/app.ts --target android

The project needs enough object files (approximately 154 .o files) to trigger the command-line length limit. If minimization is difficult, reproducing with the above command and configuration should suffice.

Environment

• Perry version: 0.5.1206 (initially used official release binary perry-windows-x86_64.zip; later modified source code from the same version tag and rebuilt)
• Host OS: Windows 11 (x86_64)
• Target: aarch64-linux-android
• Rust toolchain (when building from source): 1.96.0 (ac68faa20 2026-05-25)
• Android NDK: 30.0.14904198
• Installed via: Initially downloaded release zip, later modified and compiled from source

Diagnostic output

Excerpts from error outputs at various stages:

Error: linking with `cmd.exe /c ...` failed: The command line is too long.
error: could not compile `app` (bin "app") due to previous error

clang: error: no such file or directory: '\?D:Code...o'
clang: error: no such file or directory: 'd:Code...perry_stdlib.a'

ld.lld: error: cannot open output file app: Is a directory

error: no rules expected `f64`
   --> crates/perry-runtime/src/abi_trampoline.rs:234:53

Debug output during the fix (response file successfully enabled):

DEBUG response_file: cfg_windows=true is_windows=false use_response_file=true
DEBUG response_file: msvc_quoting=false arg_count=154
DEBUG response_file: CREATED at D:\Temp\perry-link-9856.rsp

Final successful compilation output (using the modified version):

Copied companion library: libhone_editor_android.so
Wrote executable: app/libapp.so
Binary size: 50.6MB

Anything else

The fixes involved the following source files (based on Perry source tree 0.5.1206):

• perry/crates/perry/src/commands/compile/link/platform_cmd.rs
  Changed the NDK clang invocation from aarch64-linux-android24-clang.cmd wrapper to directly calling clang.exe (with --target specified), avoiding the overhead of cmd.exe /c.

• perry/crates/perry/src/commands/compile/link/mod.rs
  Modified the quote_response_arg function: in non-MSVC (i.e., GNU-style) mode, if a path contains backslashes, proactively replace them with forward slashes. Also fixed the @response.rsp argument path to use forward slashes, preventing clang/lld from interpreting \ as an escape character.

• perry/crates/perry/src/commands/compile/run_pipeline.rs
  Added a special case for the Android target in default_output_path, returning PathBuf::from(format!("{}/lib{}.so", stem, stem)), ensuring the output file is placed in a subdirectory named after the project (e.g., app/libapp.so).

• perry/crates/perry-runtime/src/abi_trampoline.rs
  Fixed replace_expr!($i f64) to replace_expr!($i, f64), resolving the Rust 1.96 macro parsing compatibility issue.

All modifications were made to the source code, and a custom Perry binary was rebuilt. The compilation pipeline then completed successfully, producing a 50.6 MB binary.

[proggeramlug]

Thanks for the unusually thorough diagnosis — the four root causes are clear and well-argued. I dug into each against current main:

1. replace_expr! macro (Rust 1.96) — fixed in #5741. Confirmed: call_all_f64_fallback invoked replace_expr!($i f64) but the matcher is ($_t:expr, $sub:ty). Reproduced your exact error: no rules expected f64 on rustc 1.96.0; the comma fix compiles. The block is #[cfg(not(any(aarch64, all(x86_64, not(windows)))))], so it only bites x86_64-Windows host source builds — which is why CI (aarch64 / x86_64-unix) never caught it.

The other three are Windows-host / Android-NDK specific, and I don't have a Windows box or an Android NDK to verify a change end-to-end, so I'm leaving analysis + concrete pointers rather than submitting them blind (a mis-adapted response-file quoting change could regress Windows GNU-style links that currently work). Here's where each lives on current main:

2. Backslash escaping in GNU-style response files. crates/perry/src/commands/compile/link/mod.rs → quote_response_arg (around line 304). Note the response-file mechanism for "command line too long" already exists on main (rewrite_link_with_response_file), so that part may already be handled vs. 0.5.1206. The residual bug is exactly as you describe: an unquoted Windows path (needs_quote is false — no spaces) keeps its backslashes, and clang/lld treat \C, \p, … as escapes. Your fix (in non-MSVC mode, normalize \ → /) is a clean sidestep since Windows clang accepts forward slashes. The @<file> arg in rewrite_link_with_response_file (new_cmd.arg(format!("@{}", rsp.display()))) would want the same normalization.

3. Android default-output path. crates/perry/src/commands/compile/run_pipeline.rs → default_output_path (around line 4727). Android currently falls through to else { PathBuf::from(stem) } → bare app → ld.lld: cannot open output file app: Is a directory. There's already a precedent immediately above for exactly this shape — HarmonyOS returns lib{stem}.so. Suggest adding the Android target(s) to that same branch so it yields libapp.so (matching the existing convention), rather than a app/libapp.so subdir (the subdir in your build was working around your project's app name collision specifically).

4. NDK clang via cmd.exe. crates/perry/src/commands/compile/link/platform_cmd.rs (around line 576, aarch64-linux-android24-clang.cmd). Invoking clang.exe directly with --target aarch64-linux-android24 avoids the cmd.exe /c length overhead and the .cmd arg-passing quirks, as you found.

If you'd like, your working branch is the ideal source for a PR on items 2–4 (you can verify on Windows + NDK, which I can't) — happy to review. Otherwise this is a clear, well-scoped set for a maintainer with Windows CI. #5741 takes care of #1 so at least the source build unblocks.

[YC-CLT]

Thanks for the detailed analysis! I've already applied the fixes for Bugs 2–4 locally. The changes are small, so I won't submit a separate PR – I'll just paste them here for reference. All four fixes add up to fewer than 20 lines. Feel free to cherry-pick or apply them manually at your convenience.

---

Bug 2 — Backslash escaping in response files

File: crates/perry/src/commands/compile/link/mod.rs

Location	Line(s)	Change
quote_response_arg function	L304	Replace \ with / in paths for non‑MSVC mode
Actual fix	L311–314	Add: if !msvc && arg.contains('\\') { return arg.replace('\\', "/"); }
@path argument in rewrite_link_with_response_file	L350	Also normalize the response file path itself
Actual fix	L363–368	Non‑MSVC branch: format!("@{}", rsp_display.replace('\\', "/"))

// In quote_response_arg (L311–314)
if !needs_quote {
    if !msvc && arg.contains('\\') {
        return arg.replace('\\', "/");
    }
    return arg.to_string();
}

// In rewrite_link_with_response_file for @path (L363–368)
let rsp_display = rsp.display().to_string();
let rsp_arg = if msvc {
    format!("@{}", rsp_display)
} else {
    format!("@{}", rsp_display.replace('\\', "/"))
};
new_cmd.arg(rsp_arg);

---

Bug 3 — Bypass the NDK .cmd wrapper

File: crates/perry/src/commands/compile/link/platform_cmd.rs

Location	Line(s)	Change
NDK clang path construction	L575–583	Use clang.exe directly instead of aarch64-linux-android24-clang.cmd; --target is already specified later in the arguments.

// After fix (L575–583)
let clang = format!(
    "{}/toolchains/llvm/prebuilt/{}/bin/clang{}",
    ndk_home, host_tag,
    if cfg!(target_os = "windows") { ".exe" } else { "" }
);

---

Bug 4 — Android default_output_path

File: crates/perry/src/commands/compile/run_pipeline.rs

Location	Line(s)	Change
default_output_path function	L4728	Add a special case for Android
Actual fix	L4755–4759	Output {stem}/lib{stem}.so. I used a subdirectory because my project name app collided with the Android module directory – if you prefer a plain lib{stem}.so, feel free to adjust.

// After fix (L4755–4759)
} else if matches!(target, Some("android")) {
    PathBuf::from(format!("{}/lib{}.so", stem, stem))
}

---