Skip to content
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

Open
rsenden opened this issue Dec 19, 2022 · 8 comments
Open

Add support for statically linking Jansi JNI library #246

rsenden opened this issue Dec 19, 2022 · 8 comments

Comments

@rsenden
Copy link

rsenden commented Dec 19, 2022

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)):

open("/tmp", O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_DIRECTORY) = 4
open("/tmp/jansi-2.4.0-83026643492bd4eb-libjansi.so.lck", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4
open("/tmp/jansi-2.4.0-83026643492bd4eb-libjansi.so", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4
open("/tmp/jansi-2.4.0-83026643492bd4eb-libjansi.so", O_RDONLY|O_LARGEFILE) = 4
Failed to load native library:jansi-2.4.0-83026643492bd4eb-libjansi.so. osinfo: Linux/x86_64
java.lang.UnsatisfiedLinkError: Can't load library: /tmp/jansi-2.4.0-83026643492bd4eb-libjansi.so

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:

  • jansi.c: Export either JNI_OnLoad (for dynamic linking) or JNI_OnLoad_jansi (for static linking)
  • Update Makefile to add support for building libJansi.a/jansi.lib files
  • Optional: publish pre-built .a/.lib files, to avoid users having to build these themselves
  • Update JansiLoader to (also) try System.loadLibrary("jansi") (either always try, or use a system property to decide between this and the original System.load(path)-based approach)
  • Document how to statically link Jansi:
    • Add org.graalvm.nativeimage:svm dependency
    • Add the required GraalVM @AutomaticFeature (alternatively, publish a new jansi-<version>-static-feature.jar artifact that readily includes this feature, such that users can simply add this as a dependency)
    • Add -H:CLibraryPath=/path/to/dir/containing/libJansi.a option to native-image invocation
    • Add a resource exclude to prevent dynamic Jansi libraries being added to the native image, basically making GraalVM ignore:
      {"pattern": "org/fusesource/jansi/internal/native/.*"}

For reference, some links related to statically linking JNI libraries:

@xtaixe
Copy link

xtaixe commented Dec 19, 2022

+1. We are also facing this issue.

@gnodet
Copy link
Member

gnodet commented Mar 20, 2023

A PR would be welcomed @rsenden

@Glavo
Copy link
Contributor

Glavo commented Sep 28, 2023

Let me give it a try, I'm doing some work on this.

@rsenden
Copy link
Author

rsenden commented Sep 29, 2023 via email

@gnodet
Copy link
Member

gnodet commented Oct 2, 2023

@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.

@Glavo
Copy link
Contributor

Glavo commented Oct 2, 2023

@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.

@Glavo
Copy link
Contributor

Glavo commented Oct 2, 2023

hmm, I found another easier way. I'll give it a quick try and if it works I'll report the results here.

@Glavo
Copy link
Contributor

Glavo commented Oct 2, 2023

@gnodet I think #269 is more promising, please wait for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants