Add Android (aarch64) cross-compile support to SwiftTimecodeCore#86
Merged
Conversation
The existing Linux/Glibc/Musl arms in the libc imports cover Linux but
not Android, whose Swift SDK exposes its libc as the `Android` module
(Bionic). Without an `#elseif canImport(Android)` arm, the imports fall
through to no-import on Android and the unqualified `pow`/`powf`/`trunc`
calls + the `ceiling` / `floor` qualified calls fail to resolve.
Verified against the Swift 6.3 open-source toolchain
(org.swift.630202603201a) with the Android Swift SDK artifact bundle
(android28+) — `swift build --target SwiftTimecodeCore --swift-sdk
aarch64-unknown-linux-android28` produces an ELF aarch64 .o.
Also adds a GitHub Actions job that runs the same cross-compile in CI
so future regressions surface immediately.
Files changed:
- Sources/SwiftTimecodeCore/Utilities/Outsourced/FloatingPoint and Darwin.swift:
add canImport(Android) → import Android in 3 places (top imports,
`ceiling`, `floor`).
- Sources/SwiftTimecodeCore/Timecode/Protocol Adoptions/Strideable.swift:
add canImport(Android) → import Android in the imports block.
- .github/workflows/build.yml:
new `android` job builds SwiftTimecodeCore for aarch64-android28
using vapor/swiftly-action to install Swift 6.3 + the Android SDK
artifact bundle.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`vapor/swiftly-action@v0.2 toolchain: "6.3"` is a floating selector — when Swift 6.3.1 shipped, CI started picking that up and failing to load the Android SDK's pre-built `.swiftmodule` files (which were compiled by 6.3.0). Swift's stable ABI covers the runtime, not the swiftmodule binary format — that requires an exact-version compiler match. Pin to "6.3.0" to track the Android SDK artifactbundle (also pinned to 6.3-RELEASE). Bump both in lockstep when swift.org publishes a 6.3.1 or 6.4 Android SDK bundle (currently 404).
The previous swift sdk install was incomplete — it only fetches Swift-side artifacts (stdlib, Foundation .swiftmodule files). C interop in SwiftOverlayShims needs the NDK's C sysroot (semaphore.h, libc, etc.), and the SDK bundle's destination JSON needs ANDROID_NDK_HOME baked in by the setup-android-sdk.sh script that ships with it. Without these, the build errors mid-compile with: 'semaphore.h' file not found … could not build C module 'SwiftOverlayShims' NDK r27d is paired with swift-6.3-RELEASE Android SDK — bump both together when swift.org publishes a newer SDK bundle.
Owner
|
Thanks very much for the submission - I will have a look at this soon. |
Owner
|
I'm just going to update the CI workflow, as I've recently built a custom Swift Android SDK setup action that I use for all of my Swift repos. It performs all the boilerplate necessary to download and setup the SDK. It supports all versions of the SDK available, so whatever Swift toolchain the runner has can be used which means pinning versions is not necessary and makes it more maintainable as new Swift toolchains and Android SDKs are released. |
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
The existing Linux/Glibc/Musl arms in the libc imports cover Linux but not Android, whose Swift SDK exposes its libc as the
Androidmodule (Bionic). Without an#elseif canImport(Android)arm, the imports fall through to no-import on Android and the unqualifiedpow/powf/trunccalls + theceiling/floorqualified calls fail to resolve.Verified against the Swift 6.3 open-source toolchain (org.swift.630202603201a) with the Android Swift SDK artifact bundle (android28+) —
swift build --target SwiftTimecodeCore --swift-sdk aarch64-unknown-linux-android28produces an ELF aarch64 .o.Also adds a GitHub Actions job that runs the same cross-compile in CI so future regressions surface immediately.
Files changed:
ceiling,floor).androidjob builds SwiftTimecodeCore for aarch64-android28 using vapor/swiftly-action to install Swift 6.3 + the Android SDK artifact bundle.