-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for statically linking Jansi JNI library #246
Comments
+1. We are also facing this issue. |
A PR would be welcomed @rsenden |
Let me give it a try, I'm doing some work on this. |
Thanks for looking into this!
…On Thu, Sep 28, 2023, 19:58 Glavo ***@***.***> wrote:
Let me give it a try, I'm doing some work on this.
—
Reply to this email directly, view it on GitHub
<#246 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACB4GAQBMK4QAN5UWKDWZXTX4W3EHANCNFSM6AAAAAATDB4VSU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@Glavo you're still planning to work on this feature ? If that's the case, I can wait a bit before starting a 2.5.0 release. |
I don't think it can be done in a short time. If I don't find a workaround, I need to wait for GraalVM to solve #7507, or give up on what I'm trying and explore something else. |
hmm, I found another easier way. I'll give it a quick try and if it works I'll report the results here. |
We have a picocli-based application for which we build native images for Windows, Linux & MacOS using GraalVM. For various reasons, we build a statically linked executable for Linux, and dynamically linked executables for Windows/MacOS.
We would like to add Jansi (and JLine) to our application. Jansi 2.4.0 works just fine for our dynamically linked executables, however it fails to load the native jansi library in the statically linked executable because
musl
apparently doesn't support dynamic library loading (see oracle/graal#4028 (comment)):Apart from this issue, it's also just more logical to statically link the Jansi library when building native images, to avoid dynamic extraction of the library to a temporary directory and then loading it.
Based on what I've read so far, I think the following would be needed:
JNI_OnLoad
(for dynamic linking) orJNI_OnLoad_jansi
(for static linking)Makefile
to add support for buildinglibJansi.a
/jansi.lib
files.a
/.lib
files, to avoid users having to build these themselvesSystem.loadLibrary("jansi")
(either always try, or use a system property to decide between this and the originalSystem.load(path)
-based approach)org.graalvm.nativeimage:svm
dependency@AutomaticFeature
(alternatively, publish a newjansi-<version>-static-feature.jar
artifact that readily includes this feature, such that users can simply add this as a dependency)-H:CLibraryPath=/path/to/dir/containing/libJansi.a
option tonative-image
invocationjansi/src/main/resources/META-INF/native-image/jansi/resource-config.json
Line 5 in 00e15cb
For reference, some links related to statically linking JNI libraries:
The text was updated successfully, but these errors were encountered: