Skip to content

CI: build and publish Linux ARM64 native (test run, do not merge) - #1

Open
greenjon wants to merge 3 commits into
mainfrom
build/linux-arm64-ci
Open

greenjon wants to merge 3 commits into
mainfrom
build/linux-arm64-ci

Conversation

@greenjon

Copy link
Copy Markdown
Owner

Fork-internal PR only to trigger the CI matrix, including the new ubuntu-24.04-arm leg. Upstream follow-up to SpaiR#439.

greenjon and others added 3 commits October 26, 2026 22:51
generateLibs' Linux target has always been constructed via
newDefaultTarget(Os.Linux, Bitness._64), which defaults to
Architecture.x86 regardless of host architecture. That's the root
cause behind SpaiR#105: even on a native aarch64 host, the task emits
x86-only compiler flags (-mfpmath=sse -msse -m64), which a real
aarch64 g++/gcc rejects outright.

gdx-jnigen 2.5.2 (the library this build script sits on top of)
already ships a correct Architecture.ARM Linux target
(aarch64-linux-gnu- prefix, -fPIC, no SSE flags) — this task just
never selects it.

Add an opt-in `linuxarm64` env (mirroring the existing `macosarm64`
convention) that builds via that target instead, refactoring the
existing x86 Linux target into a shared createLinuxTarget() helper
(mirroring createMacTarget()) so both paths stay in sync. libName is
pinned to libimgui-java64.so on both architectures for consistency,
matching how the mac target already does this for x86_64/arm64.
SpaiR#439 added the linuxarm64 generateLibs target, but CI never invoked it,
so bin/ has no aarch64 library and nothing can be published from it.

Add a linuxarm64 vendor type (native FreeType build, no cross prefix)
and a build.sh case, and run it on ubuntu-24.04-arm. The output is named
libimgui-java64-arm64.so because archive-natives merges all platforms
into one flat directory and the x86-64 library has the same file name.

Refs SpaiR#105

Co-authored-by: Claude <noreply@anthropic.com>
Package the CI-built aarch64 library as a separate artifact. The jar
renames it to io/imgui/java/native-bin/libimgui-java64.so, the path the
loader in ImGui.java already looks up, so aarch64 consumers swap the
dependency and need no loader change. Having both Linux artifacts on one
classpath is not supported; select by os.arch.

Depends on the previous commit having put the library in bin/.

Co-authored-by: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant