macOS: no awt in java.library.path

[jkeys089]

ERROR: java.lang.UnsatisfiedLinkError: no awt in java.library.path when attempting to build a native image that depends on AWT on macOS.

Original issue reported at #2842

The parent issue has been resolved for both windows and linux but remains on macOS. Per @vjovanov, I'm creating a separate report to track this issue specifically for macOS since the parent issue has been closed.

[pedrofraca]

You can follow instructions here in the meantime to use docker to build it and run it, and do a port forwarding so you can still access from the mac and continue development while this gets fixed. https://github.com/Karm/quarkus-quickstarts/blob/quarkus-awt/awt-graphics-rest-quickstart/src/main/docker/Dockerfile.native

[sureshg]

I tried to compile a jetbrain compose app on Mac using the latest build GraalVM CE 22.0.0.2 and still have the same issue. The compilation was successful though. Any plans to fix this in the coming release?

Exception in thread "main" java.lang.UnsatisfiedLinkError: no awt in java.library.path
	at com.oracle.svm.core.jdk.NativeLibrarySupport.loadLibraryRelative(NativeLibrarySupport.java:132)
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:47)
	at java.lang.Runtime.loadLibrary0(Runtime.java:818)
	at java.lang.System.loadLibrary(System.java:1989)
	at java.awt.Toolkit$2.run(Toolkit.java:1388)

[vjovanov]

@pejovica did the AWT for Windows so he can give a better estimate.

[Jason5Lee]

Is there any GraalVM-compatible way to read the clipboard on macOS since I cannot use java.awt.Toolkit ?

[ftomassetti]

I am also experiencing this issue, and I hope it can be fixed

[pejovica]

We plan to work on this in the near future using the same approach as we did for Windows (see #3084), so the main thing missing is support for dynamic linking of JDK libraries. Basically, we need the equivalent of #3085 but for macOS.

[petermz]

@pejovica One tricky problem with supporting AWT on Mac is that Cocoa requires the event loop (RunLoop in their lingo) to be started on the main thread. So JDK's libjli (Java Launch Interface) spawns another thread right away and runs JVM there, while parking the original thread in the run loop, i.e. does something like the following:

Main Thread                                        Spawned Thread
-----------                                        --------------
main() {
    if (!RunLoopStarted) {
        RunLoopStarted = true
        spawn new thread       ------------->      re-invoke main() here
        start RunLoop
    } else {
        // JVM startup routine
    }
}

I ported this logic to SVM some time ago. The result was a change to JavaMainWrapper which worked but was rather hack-like. If you are interested I can put up a PR with my changes for reference.

[david-sitsky]

I also hit this issue today and would love to see it fixed. Do we have any rough idea of timings as to when it might be? Many thanks..

[zingermax]

Were also experiencing this issue, hope this can be fixed soon.

[bobjacobsen]

Seeing this with 22.1.0