Repository navigation
fix(bindings): name the NDK C compiler for Android release builds - #440
Merged
Merged
Conversation
0.26.0 added `ring` to the mobile cdylib through the telemetry uploader (`ureq` -> `rustls`). ring compiles C and assembly with cc-rs, which does not read cargo's linker setting and resolves a compiler on its own. All four Android jobs of the v0.26.0 release run failed in ring's build script with `failed to find tool "aarch64-linux-android-clang"`: the release workflow set the linker and AR only, and setup-ndk puts the NDK root on PATH rather than the toolchain bin, so cc-rs's probe found nothing on any ABI. Its fallback list would not have saved the 32-bit ABIs anyway: it names the API-16 clangs, which NDK r24 and later do not ship, which is also why `build-uniffi-android.sh` (toolchain on PATH) built arm64 and x86_64 but not armeabi-v7a or x86. Both paths now export CC_<triple> and CXX_<triple> pointing at the same versioned clang the linker uses. Verified locally against NDK r27 with the locked cc 1.2.43: ring alone fails under the exact CI env and under the script's env for armv7, and builds under both once CC is set; the full uniffi cdylib builds for armv7-linux-androideabi and passes the 16 KB alignment check.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What broke
The
v0.26.0Release & Publish run (34696833375) failed in all fourBuild Androidjobs, inring's build script:Nothing published: both
releaseandpublish-cratesdepend onbuild-android.Why
0.26.0 added
ringto the mobile cdylib via the telemetry uploader (ureq->rustls). It is the first dependency in the Android build that compiles C, and it does so through cc-rs, which never reads cargo's linker setting. The workflow set only the linker andAR. cc-rs probes PATH for a versioned clang and then<triple>-clang;setup-ndkputs the NDK root on PATH, not the toolchain bin, so every ABI came up empty.build-uniffi-android.shhas the same gap. It does put the toolchain on PATH, so cc-rs's fallback list findsaarch64-linux-android21-clangandx86_64-linux-android21-clang, but the list namesarmv7a-linux-androideabi16-clangandi686-linux-android16-clang, API levels NDK r24+ no longer ship, so the 32-bit ABIs fail locally too.Fix
Both paths export
CC_<triple>andCXX_<triple>pointing at the same versioned clang the linker uses. The workflow derives the variable name from the matrix target, so no new matrix fields.Verification
Local, NDK r27, the locked cc 1.2.43:
ringalone under the exact CI env (linker + AR, toolchain off PATH): fails with the CI error. WithCC_aarch64_linux_androidset: builds.ringalone under the script's env (toolchain on PATH) for armv7: fails witharm-linux-androideabi-clangnot found. WithCC_armv7_linux_androideabiset: builds.cargo build --release --locked --target armv7-linux-androideabi -p offline-protocol-uniffi: builds, andcheck-elf-alignment.pyreports 16 KB PT_LOAD alignment.A
workflow_dispatchdry run of the release workflow on this branch (version0.26.0) is the CI-side proof; link in the comments.After merge
Per the
version-gatenote and CONTRIBUTING, the tag can be deleted and re-pushed because nothing shipped: