Feature Request: Use the default linking of native-image

[kkriske]

Substrate currently uses the -H:+ExitAfterRelocatableImageWrite to take over the compilation/linking process after that. Has there ever been an attempt to use the default -H:NativeLinkerOption=, --native-compiler-options=, --native-compiler-path,.. options to modify linking instead? If so what are the reasons this is not possible, or the reasons why the current approach was chosen?

I have created multiple PR's to expand the list of e.g. windows libs passed to the linker (https://github.com/gluonhq/substrate/blob/master/src/main/java/com/gluonhq/substrate/target/WindowsTargetConfiguration.java#L50-L70). Native-image is capable of figuring out which java libs to include, and equally important which ones not to include based on the required featureset of the application. This distinction is lost in the link

An additional side-effect of using the -H:+ExitAfterRelocatableImageWrite flag is that any required shim dll is not created, which requires for example the workaround described here: #1103 (comment)
Using the default native-image linking would allow these shims to be created as well, including the proper exports on the main executable as well.

Expected Behavior

Additional linker requirements are passed into native-image.

Current Behavior

The -H:+ExitAfterRelocatableImageWrite is passed to native-image and custom linking is performed afterwards.

Context

• The custom linking causes some hard to maintain linking flags to be added as -H:NativeLinkerOption= arguments through the gluon plugin, when specific features of the JVM are required e.g. fontmanager.
• Additional workarounds are needed to create required shim dlls, mainly if awt is used.

I am willing to help with implementation of this, but I want to know a few things first:

1. Has this been attempted before? What was the outcome?
2. What is the reasoning behind the current approach in the first place?
3. Are you interested in this feature request at all?

[ctoabidmaqbool]

@kkriske I am not entirely sure about this, but I think this issue might be related to the following one:
java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "JNI_OnLoad_fontmanager" referenced by

From my experience, when using the GluonFX Maven or Gradle plugins (e.g., versions 1.0.24 or 1.0.25), which were based on GraalVM CE Gluon 23+25.1-dev-2409082136 and the vmone approach, I did not encounter the problem. However, when switching to GluonFX plugins versions 1.0.23 or 1.0.26 (based on 1.0.23, without the vmone approach and GraalVM CE Gluon 22.1.0.1-Final), I started experiencing issues, such as the JNI_OnLoad_fontmanager error and challenges with AWT/Swing support.

In plugin versions 1.0.24 and 1.0.25, it seems that fontmanager and AWT support were properly integrated or fixed.
For more details, we could also examine the changes between Substrate versions 0.0.65 and 0.0.66.

By the way, I have previously reported a related issue here:
Issue #1261 - java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "JNI_OnLoad_fontmanager"

I hope this information helps in investigating the problem further. Please let me know if you need more details or assistance.

[kkriske]

Last version I've used is (I think) substrate v0.0.63 which is maven plugin v1.0.23.
All mentioned issues are relevant for these versions, which seem to be the same as the latest version if I understand you correctly.

I have no idea what vmone is and what i'ts purpose is supposed to be.
I've also always used official GraalVM CE versions, never the Gluon version as these, last I checked, only had fixes for mobile platforms on top of the official version and I do not target these platforms.

So I don't think you references are related to my suggestion? Could you elaborate on what vmone is and why it would not have these issues?