ci: fix JNI builds on Linux ARM64 + Windows ARM64, add GraalVM release#1
Merged
Conversation
- Install Android SDK on ubuntu-24.04-arm so com.android.library configures cleanly (SDK is preinstalled on ubuntu-latest but not on ARM images). - build-windows.bat always calls vcvarsall.bat with the requested arch, using amd64_arm64 when cross-compiling ARM64 from an x64 host. Previously a preexisting x64 cl.exe on PATH prevented the arm64 env from being set and caused LNK2019 unresolved external errors on the ARM64 DLL. - Simplify Maven coordinate from dev.nucleusframework.pdf:pdfium to dev.nucleusframework:pdfium, update README snippet accordingly. - Add release-graalvm.yaml: on every v* tag, build GraalVM native-image packages for Linux x64/arm64, macOS arm64/intel, Windows x64 and upload .deb/.dmg/.exe to a GitHub Release.
Validates :example:packageGraalvmNative on Linux x64, macOS ARM64 and Windows x64 for every pull request, catching regressions in the desktop build before merge. Mirrors Nucleus's test-graalvm.yaml.
android-actions/setup-android@v3 defaults to installing 'tools platform-tools', but the legacy 'tools' package has no ARM64 Linux build and fails with sdkmanager exit code 1. Install only 'platforms;android-36' which is what AGP needs at configuration time for :pdfium.
Previously the task linked against the x86_64 libpdfium.so regardless of host arch, so on ubuntu-24.04-arm the linker rejected the incompatible .so and failed with 'cannot find -lpdfium'. Pick the PDFium lib dir from System.getProperty('os.arch').
Two fixes to unbreak :pdfium:check on Linux. - Drop the Os.isFamily(FAMILY_MAC) guard around iOS cinterop. Kotlin/Native cross-compiles iOS klibs on any host and cinterop only needs the staged PDFium headers; libraryPaths/linkerOpts are only consumed at final link time (macOS). Previously all dev.nucleusframework.pdfium.native.* imports were unresolved on Linux, so compileKotlinIosSimulatorArm64 failed. - Wire installPdfiumWasm + generatePdfiumWasmRuntime as explicit deps of jsProcessResources too, not just wasmJsProcessResources. Both read from src/webMain/resources/pdfium, and Gradle 9 enforces this implicit-dep check strictly.
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
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.
Summary
Three independent fixes + one new workflow, kept in a single PR so CI validates them together before touching master.
Fixes
build-natives.yaml) — install Android SDK viaandroid-actions/setup-android@v3onubuntu-24.04-arm. The x64 runner ships with an SDK but the ARM image does not, andcom.android.libraryrequires one at configuration time.build-windows.bat) — always reinvokevcvarsall.batwith the target arch, usingamd64_arm64for cross-compiles. Previously the script skipped env setup whencl.exewas already on PATH (set byilammy/msvc-dev-cmdfor x64), so linkingpdfium.dll.libARM64 produced 23LNK2019unresolved externals.dev.nucleusframework.pdf:pdfium→dev.nucleusframework:pdfium. Flatter namespace, matches the user's published groupId. README snippet updated.New
release-graalvm.yaml— on everyv*tag (and on manual dispatch), builds the:exampledesktop app as a GraalVM native image for Linux x64/arm64, macOS arm64/intel, Windows x64. Packages.deb/.dmg/.exeand uploads them to a GitHub Release. Inspired by Nucleus'srelease-graalvm.yamlbut trimmed to this project's actual native-artifact surface (just PDFium JNI).Test plan
Pre Merge Checkspasses on this PR — validatesbuild-natives.yamlacross Linux x64/aarch64, macOS, Windows x64+arm64, then:pdfium:checkrelease-graalvm.yamlmanually viaworkflow_dispatchon this branch to validate the desktop builds end-to-end before mergingv149.0.7802.0on the fixed master to retry Maven Central publication