Conversation
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.
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
Closes #105 by adding an opt-in
linuxarm64env togenerateLibs, mirroring the existingmacosarm64convention.generateLibs' Linux target has always been constructed vianewDefaultTarget(Os.Linux, Bitness._64), which defaults toArchitecture.x86. That's the actual reason Linux ARM64 native builds have never worked here, even on a native aarch64 host: the task emits x86-only compiler flags (-mfpmath=sse -msse -m64), which a real aarch64g++/gccrejects outright withunrecognized command-line option.gdx-jnigen2.5.2 (already a dependency here) ships a correctArchitecture.ARMLinux target (aarch64-linux-gnu-prefix,-fPIC, no SSE flags) — this build script just never selects it.Changes
forLinuxArm64(opt-in via-Denvs=linuxarm64), following the same naming convention asforMacArm64/macosarm64.createLinuxTarget(Architecture)helper (mirroring the existingcreateMacTarget(Architecture)helper), used by bothforLinuxandforLinuxArm64.libNameis pinned tolibimgui-java64.soregardless of architecture, matching howcreateMacTargetalready keeps the same filename across x86_64/arm64 (the Java-side native loader distinguishes platforms by directory/classpath entry, not filename).ubuntu-24.04-armrunners), theaarch64-linux-gnu-cross-compiler prefix is cleared, since no cross toolchain is needed there and that package usually isn't installed on native ARM64 runners.forLinux(x86) behavior and output paths (linux64/...) are unchanged.Test plan
ubuntu-24.04-armGitHub Actions runner:./gradlew :imgui-binding:compileJava && ./gradlew :imgui-binding:generateLibs -Denvs=linuxarm64 -Dlocalproducesimgui-binding/build/libsNative/linuxarm64/libimgui-java64.so, confirmed viafile:forLinux/forWindows/forMac/forMacArm64paths are unchanged by this diff and weren't independently re-verified in this PR — happy to run the full existing matrix if useful.