Using JNA inside a native image does not work

[mavilein]

My team is evaluating whether we can use Graals native-image tool to ship binaries for our software. Some parts of our software is interacting with native code. We use the library JNA to do this. Therefore i have tested whether we can use JNA inside a native image created with Graal. In my tests i get the following error:

ld: library not found for -lhello
clang: error: linker command failed with exit code 1 (use -v to see invocation)

	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:593)
	at java.util.concurrent.ForkJoinTask.get(ForkJoinTask.java:1005)
	at com.oracle.svm.hosted.NativeImageGenerator.run(NativeImageGenerator.java:418)
	at com.oracle.svm.hosted.NativeImageGeneratorRunner.buildImage(NativeImageGeneratorRunner.java:278)
	at com.oracle.svm.hosted.NativeImageGeneratorRunner.build(NativeImageGeneratorRunner.java:375)
	at com.oracle.svm.hosted.NativeImageGeneratorRunner.main(NativeImageGeneratorRunner.java:104)
Caused by: java.lang.RuntimeException: host C compiler or linker does not seem to work: java.lang.RuntimeException: returned 1

The reproduction is available in this repo.

It would be great if JNA could work with Graal as many existing applications are build on top of it and it would be nice if we do not have to rewrite those parts.

[peter-hofer]

Unfortunately, your link is broken.
JNA generates and loads proxy classes at runtime, but native-image does not support dynamic class loading, so JNA is unlikely to work. You can try triggering the creation of the proxy classes already during the image build, for example from a static initializer.

[mavilein]

@peter-hofer : Oops the repo was private. I made it public now.
Are there docs for the workaround you mentioned?

[peter-hofer]

That's not a "workaround" for JNA with native-image -- I don't think we have tried using JNA before. Instead, what I described is just making use of the design of native-image, which has static initializers execute when a class is loaded, which is during image generation. Because you are running on a fully-featured JVM at that time, it is possible to use dynamic features such as bytecode generation, class loading and arbitrary reflection. If you manage to initialize all of the JNA code at that time, it will be readily available at runtime when these dynamic features are missing. You can find details on that in LIMITATIONS.md.

[sugoidogo]

For anyone else who ends up here with a similar issue, I believe this is what @peter-hofer is referring to.

[peter-hofer]

For anyone else who ends up here with a similar issue, I believe this is what @peter-hofer is referring to.

The class initializer section, yes. Note that my earlier statement above (#673 (comment)) about class initializers being run at image generation is no longer fully accurate, we now provide more control over class initialization with --initialize-at-build-time and --initialize-at-run-time.

Full support for JNA is still not available or planned, I'm closing this issue.