[GR-39191] error linking the native image - multiple definition of `jvm' #4594
Comments
|
I am actually one step further in my research. But unfortunately the big problem still seems to be swing and awt. |
|
@Holger2019 try using the The issue is being worked on, as mentioned in a similar issue: #3938 |
|
Thank you very much for your comment. I am working on a bigger project that is written in Java 17. I tried it with this project under JDK 11 but as expected I get an error (Fatal error: java.lang.UnsupportedClassVersionError:) because the versions do not match. ;) in the meantime i managed to create a native image(corresponding to kkriske Ticket: #4165) under OS: Windows11 with jdk17. but this still needs the fontconfig.bfc for the .awt fonts. is there a way to integrate this fontconfig.bfc into the native image? That would be great. REM collect config for the app |
I don't think so, as this is a weird requirement of the Swing/AWT implementation in Windows JDK/JRE. This To change it requires a re-implementation of Swing/AWT in Windows, I guess. |
|
First of all, thank you for the support. :) That is unfortunately not nice to hear. If I understand correctly, this is a Windows problem. Accordingly, I'm currently trying to manage this in Ubuntu via WSL (OS: Ubuntu 9.4.0-1ubuntu1~20.04.1 (Windows Subsystem for Linux (Windows 11)). You said that the problems do not exist in Java 11. Now I changed my project to Java 11 and tried it with GRAAL version 22.1.0 of Java 11. Can anyone help me with this? I'm starting to get a little desperate. :) i have tried many ways. But in general, that's what I did:
|
|
Hi, Could you please share a minimal reproducer to this? Thank you |
|
Hi, that's a good idea. Thank you. :) |
|
I have a new specification to the project. it must also run on Windows. Does the Native image (generated in Linux) also run on Windows? |
|
I doubt it, for reason that @oubidar-Abderrahim gave above. But the fontconfig.bfc file would be the least of your worry, as the native image program in Windows also generates a few .dll files for Swing/AWT usage, in addition to your .exe file. I've mentioned the resulting structure of Windows files in my project here. If you want to avoid the multiple files needed for a Windows native executable, the best option is to abandon Swing/AWT and use JavaFX instead in your project. JavaFX would solve both of your problems in Linux and Windows. |
|
Thank you both for the quick and well explained answers. I think I have understood it (better) now. Unfortunately it's not an option to replace Swing at the moment, since the final phase is coming up. But I will keep it in mind for the future . ;) |
fniephaus
changed the title
|
It seems this may be related to https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8264047, and a fix by @jerboaa that landed via openjdk/jdk11u@0e4fdcf. I ran into a similar issue compiling my Truffle language that uses AWT: git clone https://github.com/hpi-swa/trufflesqueak.git
cd trufflesqueak
git checkout a5bd690792b71c5893a1075fd9f2c35d3c1df9f8
mx --env trufflesqueak buildWhen I do this using a Could you look into this please, @jerboaa? |
|
@fniephaus Is there a smaller reproducer than this trufflesqueak thingy? |
Not really, sorry. I had a chat with @pejovica about this today and it seems that the best fix for this is to dynamically link AWT libraries as we already do on Windows, which will hopefully happen sooner than later. So I don't think we need to investigate this on the JDK level at this point. |
|
OK. |
|
Hello, as explained above, I managed to create a native image on windows. this (.exe) runs fine as long as the necessary libraries (dll's and fontconfig.bfc) are available. The current question was, if these files (dll's and fontconfig) may be given to the customers together with the exe? the dlls were created automatically. As described here: https://github.com/chirontt/swingset3/tree/master/trunk/SwingSet3#caveats-on-native-image |
You have to because otherwise your Native Image executable does not work, right? I can't answer any licensing questions though. |
|
that is absolutely correct. Then I will contact Oracle support. Thank you very much for your help. |
|
I'm stuck with a very similar error (without the reference to 'jvm' ) when creating native image of a large Swing app (under Ubuntu 22.04 and after having exercised the app using the native-image agent): Any idea ? Complete log attached. |
|
This problem should go away when we support dynamic linking of AWT libraries on Linux. We've made some progress on that recently, so stay tuned for more updates on this soon! |
|
Fine ! I'll keep in touch. Thx. |
|
I downloaded GraalVM Community Edition 22.3.0 Java 19 from https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.0 page. objdump shows that symbol I build jdk 19 from jdk19u and labs-openjdk-19 repositories:
Could you provide more details how to build jdk19 for GraalVM so the |
|
I am facing the same issue with GraalVM 22.3 (17.0.5+8-jvmci-22.3-b08): https://scans.gradle.com/s/pp4d2ulbe7gdi/console-log?page=1#L73 |
|
#4921 is the roadmap item for better AWT support. Hopefully, we'll be able to ship improvements in the next release. |
|
I guess there's no workaround? |
|
Avoid AWT or build on Windows, but I wouldn't call these options workarounds. Is AWT used by the application or is it unclear why it's being pulled in? Maybe it's pulled in by accident (see #5224)? |
|
It is using awt, I was building this demo project. |
|
Ah ok, I haven't tried that demo myself but in that case, I'd try to use JDK11 (even though the readme mentions 17+). AWT on 11 can be statically linked. |
This commit switches from Maven to Gradle for building the project. It makes the instructions simpler, by using Gradle plugins: - the `application` plugin exposes the `run` method directly for the JVM version, without having to explain to grow the stack size - the official GraalVM native plugin exposes the `nativeCompile` and `nativeRun` tasks, respectively for building the native image and executing it In addition, this commit switches from using Java 19 to Java 11. The underlying reason is a [bug](oracle/graal#4594 (comment)) which prevents building the native image under Linux with AWT, with more recent versions of Java. Native configuration has been moved to the conventional `src/main/resources/META-INF/native-image` location. Although this isn't required for the JVM version, it simplifies the setup of the build.
|
I built graal with jdk 19 from jdk19u and labs-openjdk-19 repositories. Which way jdk static libraries are generated for graal that |
Yes, there is a workaround: use the Liberica NIK, its version for the JDK17 can successfully produce a Linux native image without this |
|
Fixed by #6088. |
Hello,
unfortunately I have a problem and have unfortunately found nothing that helps me.
Describe the issue
I am trying to convert a JAR file that uses swing / awt components into a native image. Since this does not work on Windows, I set up a ubuntu subsystem. This worked fine so far. However, I get a "linking" error during the "Creating image" step. According to my understanding this error is caused by multiple definitions of jvm ( /home/info/graalvm-ee-java17-22.1.0/lib/static/linux-amd64/glibc/libawt.a(awt_LoadLibrary.o):(.bss.jvm+0x0): multiple definition of `jvm'; /home/info/graalvm-ee-java17-22.1.0/lib/static/linux-amd64/glibc/libawt_xawt.a(XlibWrapper.o):(.bss.jvm+0x0): first defined here)
--> does anyone know how to solve this problem? If yes, many thanks in advance.
Steps to reproduce the issue
import javax.swing.JFrame;
public class Testgraal {
public static void main(String[] args) {
JFrame meinFrame = new JFrame("TEST JFrame");
meinFrame.setSize(200,200);
meinFrame.setVisible(true);
}
}
use Traceagent:
java -agentlib:native-image-agent=config-merge-dir=config/META-INF/native-image -jar /home/info/JAR-TEST/TEST.jar
build native-image:
native-image -cp config:. -Djava.awt.headless=false -jar /home/info/JAR-TEST/TEST.jar
I have tried many flags. But they didn't worked.
Describe GraalVM and your environment:
More details
output:
The text was updated successfully, but these errors were encountered: