Solvedlwjgl3 Provide support for ARM64/M1 devices (Windows and macOS)

Hi all,

I work on the Microsoft Java Engineering Group, and I'd like to openly discuss how we can help port LWJGL to Windows on ARM64 devices (e.g. Surface X) as well as macOS on Apple Silicon M1.

Bruno Borges

26 Answers

✔️Accepted Answer

We're all green! 🎉

Users with access to ARM hardware should now be able to build and test LWJGL 3 locally on macOS and Windows. Please open new issues (or contact me on Slack/Discord) if you face any trouble.

The first 3.3.0 snapshot will also be available very soon (hopefully tomorrow).

Other Answers:

Hey Bruno,

Porting LWJGL means getting the CI pipelines to build its native dependencies for the new platform/architecture. LWJGL has a simple core that's easy to build, but the different bindings depend on native libraries with varying implementation quality and build complexity. Some will be trivial to build, others may require simple fixes we can apply on our own, sometimes we may have to wait for the upstream maintainers to do the work. A few might even be impossible to build. In any case, we don't need every dependency to release LWJGL and our build customizer can handle platforms/architectures with missing bindings.

I'm guessing that Microsoft is mostly interested in getting Minecraft to run on ARM64. We could focus on bindings that Minecraft uses first, deal with the rest later. Those most likely include: GLFW, OpenGL, OpenAL and stb. Could you please confirm and check if they use anything else?

We have a separate account for CI (LWJGL-CI). Each repository has a single "LWJGL CI" commit on top of the upstream commits. This commit includes the build scripts and any fixes that need to be applied. When the binding is updated, the CI commit is rebased on top of the new upstream commit. This keeps the history clean and enables interested users to easily identify in which state each binding has been built (it's always the HEAD~1 commit). There are two interesting files in each CI commit: .travis.yml and appveyor.yml (note: we completely overwrite those files if they exist in the upstream project). We use Travis CI for Linux and macOS builds, AppVeyor for Windows builds. Each build file contains a matrix of builds for the various architectures. Artifacts are uploaded to LWJGL's S3 build bucket. Before opening a PR and while testing a new build, you probably want to comment out the awscli installation and aws s3 cp commands, to avoid build errors. Ideally, replace them with your own upload procedure to test the artifacts.

As a test, I got GLFW to build on Windows ARM64 and macOS ARM64. It was straightforward:

One problem is that I don't have any hardware to test on, but I'm getting:

dumpbin /HEADERS glfw.dll | findstr machine

AA64 machine (ARM64)

for and

file libglfw.dylib

libglfw.dylib: Mach-O 64-bit dynamically linked shared library arm64


I ran Minecraft on Surface Pro X with native architecture (arm64). Details: MultiMC/Launcher#3025 (comment)
I wrote here bcuz it's the first result when I type minecraft windows aarch64 in Google

Edit: easier version:

The migration is moving along nicely. I found solutions to the above two issues and the following projects are now building with Github Actions:

Hello, an update:

The dyncall bindings in LWJGL have now been replaced with libffi. Apologies to @lewurm and anyone else that spent time on getting dyncall to work on ARM64, your effort is much appreciated. However, I believe this was a necessary step towards supporting more platforms/architectures (libffi supports virtually everything we could ever need). This migration has also resolved a range of long-standing issues in LWJGL (e.g. dyncall couldn't handle structs returned by-value) and the new support for upcalls is both simpler and more efficient.

For users that would like to help with the migration process or simply want to experiment with LWJGL, the nightly build ( now includes an up-to-date libffi static library for all current+future supported platform/architectures:

  • Linux: arm32, arm64, mips64, x64
  • macOS: arm64, x64
  • Windows: arm64, x64, x86

Next step is updating the CI infrastructure. Unfortunately, there was a major setback recently, with the changes to Travis CI's pricing model. The new plan is to migrate everything to Github Actions. I've made some testing with libffi (workflow here) and I'm happy with what I'm seeing so far. It will be great having everything in one place (vs some on Travis CI, some on AppVeyor).

A couple of issues atm:

  • The macOS/ARM64 build on Github Actions worked fine when I first set it up, but is no longer available. The macos-11.0 runner is in private preview atm and I'm not sure when it's going to be available again.
  • I can't get libffi to build on Windows (on any architecture). Basically, I've been trying to port this AppVeyor script, which builds just fine (output here), to Github Actions. Any tips on what I may be doing wrong will be appreciated!

More Issues: