Arch Linux User Repository

@ryanrhughes

the build option -march=compatibility was already added to the gradle script like 3 weeks ago.

Did that not fix it?

The current version has started throwing an error on older CPUs. Adding export NATIVE_IMAGE_OPTIONS="-march=compatibility" before the gradle call in the build seems to resolve this.

Kernel stored in /boot/d011433f085544ff88212bd38e983d42/linux/vmlinuz-linux
Initramfs stored in /boot/d011433f085544ff88212bd38e983d42/linux/initramfs-linux
The current machine does not support all of the following CPU features that are required by the image: [CX8, CMOV, FXSR, MMX, SSE, SSE2, SSE3, SSSE3, SSE4_1, SSE4_2, POPCNT, LZCNT, AVX, AVX2, BMI1, BMI2, FMA, F16C].
Please rebuild the executable with an appropriate setting of the -march option.
Please rebuild the executable with an appropriate setting of the -march option.
error: command failed to execute correctly

@alwyn The extra makedepends is needed because gradle and GraalVM can build a native binary, which lets us ship a standalone executable without requiring a JRE at runtime. Here are pros:

• No need for users to install JRE just to run the program.
• Much better runtime performance.
• The make dependency is build-time only. After build, you can remove it.
• No longer depends on JAVA_HOME, avoiding conflicts with other programs.

Personally I'm not sure how much I like the idea of requiring the installation of an external dependency in my makedepends. Have the pros been considered against the cons for this?

Working great now, was able to drop my changes. The self contained make Java is very convenient. Thanks.

@jmp0

Currently, limine-mkinitcpio-hook-git already uses Gradle and GraalVM25 to build a native image. Feel free to try it out.

Note: GraalVM is not available in the pacman repos, only in AUR. Since makedepends can't depend on AUR packages, GraalVM is bundled in the limine-mkinitcpio-hook-git PKGBUILD.

Thanks, I got it working with a PKGBUILD tweak and setting that config. However it seems like limine-snapper-sync's watcher daemon doesn't respect it properly, I had to add a systemd override to update the PATH. I think native images would improve this for both projects!

If Gradle's toolchain feature and the Gradle Wrapper is used, the make requirement could also be reduced to java-runtime>=17 (for latest Gradle).

And something like: optdepends=('jdk21-graalvm-bin: Install system-managed GraalVM JDK for compilation (without: Gradle will resolve a GraalVM JDK)') could also be added for completeness (matching the version configured in Gradle)

https://docs.gradle.org/current/userguide/toolchains.html#sec:provisioning

This way the package will "just work" in more cases than currently, and advanced users can more easily tune their install.

@jmp0

The PKGBUILD uses the fixed, stable, tested JDK 21 only for compiling, mainly for non-tech users who might otherwise fail to build due to a wrong or older Java version on their system.

For runtime, you can edit /etc/default/limine and set: JAVA_BIN_PATH="/usr/lib/jvm/<your custom JRE version>/bin"

The tool will run with your custom Java path for system, and should not conflict with any JAVA_HOME set for other apps or development.

I would also consider removing the runtime JRE dependency by using GraalVM 25 to create a native binary that doesn't require any installed JRE.

The PKGBUILD hardcodes the Java path, so only some of the Java runtime deps actually work, and custom JAVA_HOME won't work.