Add ARM64 build support for Linux and macOS

[bahnwaerter]

The framework update introduces build support for the 64-bit ARM (aarch64) target architecture. The Ultimate framework and its components can now be built and executed on ARM64 platforms running Linux and macOS. This feature resolves #749.

[schuessf]

Thank you for your work! I tried running the build using makeFresh.sh (also on my Raspberry Pi) and it suceeded. However, I found a few issues:

• makeZip.sh currently always copies the x86_64 folder. Instead, the target architecture (e.g. aarch64) should be passed as a parameter.
• Currently, the repository only contains x86 solver binaries, which are therefore the only ones packaged. As a result, the build cannot be executed on aarch. Although aarch builds of Z3, MathSAT, bitwuzla, and CVC5 are available and could be integrated (for Z3, we could also adapt our build script to build for aarch), there is no aarch version of CVC4. Maybe we can also use this as an opportunity to replace CVC4 with bitwuzla (which I already stated here). We mainly use CVC4 for bitvectors, and I made some experiments that showed that bitwuzla is slightly better for that use case.
• I also tried running the resulting build on my Raspberry Pi, but I always got a ClassNotFoundException: org.eclipse.swt.SWTError cannot be found by org.eclipse.ui.workbench_3.136.0.v20250814-1558, but I did not figure out why. Is there still some issue with the build or is there some missing requirement on my system?

[bahnwaerter]

Thank you @schuessf for testing the new ARM64 support.

makeZip.sh currently always copies the x86_64 folder. Instead, the target architecture (e.g. aarch64) should be passed as a parameter.

I haven't added support to the makeFresh.sh script yet. I will do this together with the new feature for automatically building Docker images.

Currently, the repository only contains x86 solver binaries, which are therefore the only ones packaged. As a result, the build cannot be executed on aarch. [...]

That's a great idea and we should check that out!

I also tried running the resulting build on my Raspberry Pi, but I always got a ClassNotFoundException: org.eclipse.swt.SWTError cannot be found by org.eclipse.ui.workbench_3.136.0.v20250814-1558, but I did not figure out why. Is there still some issue with the build or is there some missing requirement on my system?

It seems like there is a component missing on your system that is required by the Java virtual runtime in order to avoid runtime issues. Which version of Raspberry Pi OS have you used for testing?

[schuessf]

makeZip.sh currently always copies the x86_64 folder. Instead, the target architecture (e.g. aarch64) should be passed as a parameter.

I haven't added support to the makeFresh.sh script yet. I will do this together with the new feature for automatically building Docker images.

👍
Sure I was just checking what is missing to make the build enviroment fully ready for aarch -- also as a reminder 😉

I also tried running the resulting build on my Raspberry Pi, but I always got a ClassNotFoundException: org.eclipse.swt.SWTError cannot be found by org.eclipse.ui.workbench_3.136.0.v20250814-1558, but I did not figure out why. Is there still some issue with the build or is there some missing requirement on my system?

It seems like there is a component missing on your system that is required by the Java virtual runtime in order to avoid runtime issues. Which version of Raspberry Pi OS have you used for testing?

Oh, it looks like the problem is resolved. I already installed GTK3 before, which seems to fix the issue, but it required a reboot first (which I didn't expect).
I am using Raspberry Pi OS Lite (Trixie).

[schuessf]

Okay, since my issue was fixed, I was now able to actually run Ultimate on my Raspberry Pi, by performing the additional steps:

• run makeFresh.sh
• overwite the content of UAutomizer-linux with CLI-E4/linux/gtk/aarch64
• download the aarch solvers and pretend bitwuzla to be CVC4 😉