https://github.com/clj-easy/graal-build-time was built to address this specifically 😄

essentially all the relevant classes need to be initialised individually, which is pretty much what lib does

Looks like a fix but I'm having an issue. Prior to using graal-build-time, the image was building fine with --initialize-at-build-time(even with graal 22.0) but would fail at runtime when calling a function that was relying on LazySodium (native lib not found, it's libsodium accessed through JNA). After adding graal-build-time, building the image fails:

Caused by: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: No instances of com.goterl.lazysodium.LazySodiumJava are allowed in the image heap as this class should be initialized at image runtime.

Is is the same issue as above, the lib cannot be found?

also theres this https://github.com/oracle/graal/issues/673#issuecomment-583413789 not sure if full JNA support has landed already or not

Ah, good point about JNA, but it sounds like it could work as long as all the JNA stuff is initialized at build time? So no, now it fails with this exception at build time instead of failing at run time with a link error. But I've entered a rabbit hole. I've tried forcing --initialize-at-run-time on consumer of that class and now am seeing dozens of errors, classes from Java libs being "unintentionally initialized at build time" 😅

@UCFG3SDFV You can add java packages for build time initialization by just adding the prefix

--initialize-at-build-time=java.pkg

Also are you supplying the the path to the shared lib correctly during the build process? I think it was -H:AdditionalLinkerOptions= or something? akin to passing -l/path/to/shared/lib for gcc

@U04V15CAJ But this is for JVM package, right? Whereas I now see complaints about stuff from Java libs like slf4j @U7ERLH6JX I tried using -Djava.library.pathwhen executing native-image

What is the difference between JVM package and Java libs?

Sorry, I misunderstood you 🙂