search

oracle / graal

GraalVM compiles Java applications into native executables that start instantly, scale fast, and use fewer compute resources 🚀
https://www.graalvm.org
Other
20.36k stars 1.63k forks source link

windows java.lang.UnsatisfiedLinkError: no awt in java.library.path #4344

Closed lilili87222 closed 2 years ago

lilili87222 commented 2 years ago

Describe the issue code,BufferedImage cause awt link fail

new BufferedImage(width, height, BufferedImage.TYPE_INT_RGB);

Steps to reproduce the issue Please include both build steps as well as run steps

  1. [runagent ,add the json generated to config]
  2. [build success,but fail when run]

Describe GraalVM and your environment:

More details

        [周一 2月 21 16:44:28 CST 2022][信息] [SUB] Exception in thread "JavaFX Application Thread" java.lang.UnsatisfiedLinkError: no awt in java.library.path
    [周一 2月 21 16:44:28 CST 2022][信息] [SUB]  at com.oracle.svm.core.jdk.NativeLibrarySupport.loadLibraryRelative(NativeLibrarySupport.java:132)
    [周一 2月 21 16:44:28 CST 2022][信息] [SUB]  at java.lang.ClassLoader.loadLibrary(ClassLoader.java:135)
    [周一 2月 21 16:44:28 CST 2022][信息] [SUB]  at java.lang.Runtime.loadLibrary0(Runtime.java:830)
    [周一 2月 21 16:44:28 CST 2022][信息] [SUB]  at java.lang.System.loadLibrary(System.java:1871)
    [周一 2月 21 16:44:28 CST 2022][信息] [SUB]  at java.awt.image.ColorModel$1.run(ColorModel.java:209)
    [周一 2月 21 16:44:28 CST 2022][信息] [SUB]  at java.awt.image.ColorModel$1.run(ColorModel.java:207)
    [周一 2月 21 16:44:28 CST 2022][信息] [SUB]  at java.security.AccessController.doPrivileged(AccessController.java:89)
    [周一 2月 21 16:44:28 CST 2022][信息] [SUB]  at java.awt.image.ColorModel.loadLibraries(ColorModel.java:206)
    [周一 2月 21 16:44:28 CST 2022][信息] [SUB]  at java.awt.image.ColorModel.<clinit>(ColorModel.java:219)
    [周一 2月 21 16:44:28 CST 2022][信息] [SUB]  at java.awt.image.BufferedImage.<clinit>(BufferedImage.java:286)

"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvars64.bat" Visual Studio 2022 Developer Command Prompt v17.0.1 Copyright (c) 2021 Microsoft Corporation

kristofdho commented 2 years ago

It looks like you are using javafx. I'll assume you're also using Gluon Substrate though their maven or gradle plugin. The problem is that gluon substrate does not automatically add awt.dll and the required shims of java.dll and jvm.dll as output artefacts, like native-image does.

Take a look at this comment, explaining how I worked around a similar issue: https://github.com/gluonhq/substrate/pull/1103#issuecomment-1029133322

For your issue, you can probably get away with just copy pasting awt.dll, java.dll and jvm.dll next to your executable. That is how we worked around it before we encountered the fontmanager issue. Keep in mind that deeper issues like that can occur because by copying these dlls you are essentially using an uninitialized java.dll and jvm.dll, because native-image initializes the versions that are statically linked into the executable. That is why the shim dlls exist, so if you run into issues with that, you'll have to use workaround described in the linked comment.

lilili87222 commented 2 years ago

It looks like you are using javafx. I'll assume you're also using Gluon Substrate though their maven or gradle plugin. The problem is that gluon substrate does not automatically add awt.dll and the required shims of java.dll and jvm.dll as output artefacts, like native-image does.

Take a look at this comment, explaining how I worked around a similar issue: gluonhq/substrate#1103 (comment)

For your issue, you can probably get away with just copy pasting awt.dll, java.dll and jvm.dll next to your executable. That is how we worked around it before we encountered the fontmanager issue. Keep in mind that deeper issues like that can occur because by copying these dlls you are essentially using an uninitialized java.dll and jvm.dll, because native-image initializes the versions that are statically linked into the executable. That is why the shim dlls exist, so if you run into issues with that, you'll have to use workaround described in the linked comment.

Yes ,i copy those dll next to executable ,and it works. Is there any other place to put those dll ,such as folder next to the executable ?

I compile

-Djava.library.path=.;$BINARYEN_PATH\runtime

System.setProperty("java.library.path",System.getProperty("java.library.path")+";./runtime;");

put dll in runtime folder

but it not work.

kristofdho commented 2 years ago

The java.library.path argument you supply at compile time is just that, an extra argument to the compiler. It doesn't get stored into the native image.

Using System.setProperty in your main method also doesn't work, because you tell java where to find awt.dll but then windows takes over and tries to find java.dll and jvm.dll as dependencies of awt. But windows doesn't know about your subfolder. It does know about the directory of your executable, so they have to be next to the exe.

lilili87222 commented 2 years ago

The java.library.path argument you supply at compile time is just that, an extra argument to the compiler. It doesn't get stored into the native image.

Using System.setProperty in your main method also doesn't work, because you tell java where to find awt.dll but then windows takes over and tries to find java.dll and jvm.dll as dependencies of awt. But windows doesn't know about your subfolder. It does know about the directory of your executable, so they have to be next to the exe.

Thanks very much.

ygarg465 commented 2 years ago

I encountered the same problem but moving these three files doesn't solve this for me.

ctoabidmaqbool commented 2 months ago

https://github.com/praj-foss/swing-graalvm-demo/issues/5