ci(mobile): put NDK bin on PATH so openssl-src finds the legacy ranlib symlink#6338
Conversation
…b symlink #6335 symlinked the legacy `<target>-ranlib` / `-ar` / `-nm` / `-strip` names to their llvm equivalents inside the NDK bin directory, but that directory is not on `$PATH`, so the Android Tauri builds still failed with `aarch64-linux-android-ranlib: not found` (exit 127). The CI log shows why the symlink alone was not enough: openssl-src invokes Configure as `env -u CROSS_COMPILE AR="<abs>/llvm-ar" ... RANLIB="aarch64-linux-android-ranlib"` — it passes AR as an absolute path but RANLIB as a bare command name, so RANLIB is resolved through a `$PATH` lookup that never included the NDK bin directory. Append `$NDK_BIN` to `$GITHUB_PATH` in the symlink step (mobile-smoke.yml aarch64 job, release.yml aarch64 + armv7 job) so the bare-name RANLIB resolves to the symlink. The symlinks themselves are unchanged. Verification: cannot reproduce the Android cross-compile locally (Linux-only, NDK r27 host toolchain); the fix is grounded in the run-28226134802 log line `RANLIB="aarch64-linux-android-ranlib"` (bare name) versus `AR="<abs>/llvm-ar"` (absolute), and `AR` resolving from exactly the `$NDK_BIN` dir we symlink into. Both workflow files pass `yaml.safe_load`.
github-actions
Bot
added
size/S
houko
left a comment
houko
left a comment
There was a problem hiding this comment.
The fix itself looks correct — the root cause analysis (bare RANLIB resolved via PATH, absolute AR isn't) matches the CI log and the echo "$NDK_BIN" >> "$GITHUB_PATH" one-liner is the right fix.
One prose-style note (CLAUDE.md "Prose wrapping" rule): the paragraph this PR modifies in both workflow files column-wraps mid-sentence.
The project rule is one sentence per line in any prose block being touched.
The new last sentence currently spans four lines:
# "ranlib: not found" (exit 127). Symlink the legacy names to the llvm
# equivalents AND put the NDK bin dir on PATH: openssl-src passes RANLIB
# to Configure as a bare command name (unlike AR, which it passes as an
# absolute path), so the symlink is only resolvable via a PATH lookup.Sentence-based form would put "ranlib: not found" (exit 127). and the Symlink… sentence on separate lines (the earlier sentences in the unchanged portion of the block have the same issue, but those aren't touched by this PR so they're out of scope here).
This doesn't affect correctness — just flagging so the author is aware before the maintainer reviews style.
Generated by Claude Code
1 participant
Problem
The Android Tauri builds — mobile-smoke
Android (debug, unsigned)and releaseMobile / Android— have been failing onmainsince OpenSSL was vendored (#6279).#6335 was meant to fix this but only got halfway: the latest
mainpush still fails withaarch64-linux-android-ranlib: not found(exit 127), e.g. run 28226134802.Root cause
#6335 symlinked the legacy
<target>-ranlib/-ar/-nm/-stripnames to theirllvm-*equivalents inside the NDK bin directory, but never put that directory on$PATH.The CI log shows why the symlink alone is not enough — openssl-src invokes Configure as:
It passes
ARas an absolute path (resolves fine) butRANLIBas a bare command name. The bare name is resolved through a$PATHlookup, and the NDK bin directory — where theaarch64-linux-android-ranlibsymlink lives — was not on$PATH. Somake install_devexits 127.That
ARresolves from exactly the$NDK_BINdirectory we symlink into is what confirms the symlink itself is valid (not dangling); the only missing piece is PATH visibility.Fix
Append
$NDK_BINto$GITHUB_PATHin the existing "Symlink legacy NDK binutils" step, so the bare-nameRANLIBresolves to the symlink..github/workflows/mobile-smoke.yml— aarch64 job.github/workflows/release.yml— aarch64 + armv7 jobThe symlinks themselves are unchanged; this only makes them findable.
Verification
RANLIB="aarch64-linux-android-ranlib"(bare) vsAR="<abs>/llvm-ar"(absolute), withARresolving from the same$NDK_BINwe symlink into.yaml.safe_load.Note (separate, transient)
The
Test / Securityjob on the samemainpush failed independently with a transient crates.io download error (OpenSSL SSL_read: SSL_ERROR_SYSCALLwhile fetchinged25519-dalek) — infrastructure, not code. That run's failed jobs were re-run; no change required here.