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

JNA 4.5.1 chooses wrong libjnidispatch.so when using Oracle Java 8 on armhf #958

Closed
joelbygger opened this issue May 9, 2018 · 3 comments

Comments

@joelbygger
Copy link

joelbygger commented May 9, 2018

I am very green on Java and JNA, please be patient if nomenclature is wrong.

  • Fails with JNA 4.5.1
  • Works with JNA 4.5.0
  • Ubuntu 14 LTS
  • 32 bit i.MX6 ARMv7l (armhf, hard float)
  • Can be reprodued with "Hello world" from this repo, https://github.com/java-native-access/jna/blob/4.5.1. /www/GettingStarted.md
  • Compile with maven, downloads JNA via "net.java.dev.jna". Create a jar-with-dependencies, libjnidispatch.so exists for 30 something arhitectures.
  • Same result independent on what I compile with (Oracle or OpenJDK). OpenJDK can always run the jar, Oracle always fails.
  • No issues with OpenJDK Java 8
  • Fails with Oracle Java 8:
$ java -XshowSettings:properties -version
...
sun.arch.abi = gnueabihf
...
java version "1.8.0_172"
Java(TM) SE Runtime Environment (build 1.8.0_172-b11)
Java HotSpot(TM) Client VM (build 25.172-b11, mixed mode)

also tried with:

java version "1.8.0_73"
Java(TM) SE Runtime Environment (build 1.8.0_73-b02)
Java HotSpot(TM) Client VM (build 25.73-b02, mixed mode)
  • When using flag "-Djna.boot.library.path=" and pointing to specific JNA it works.

Output on success:

$ java -Djna.debug_load=true -jar hello-jar-with-dependencies.jar 
Looking in classpath from sun.misc.Launcher$AppClassLoader@1f96302 for /com/sun/jna/linux-arm/libjnidispatch.so
Found library resource at jar:file:/some/path/hello-jar-with-dependencies.jar!/com/sun/jna/linux-arm/libjnidispatch.so

Output on failure:

Looking in classpath from sun.misc.Launcher$AppClassLoader@1909752 for /com/sun/jna/linux-armel/libjnidispatch.so
Found library resource at jar:file:/some/path/hello-jar-with-dependencies.jar!/com/sun/jna/linux-armel/libjnidispatch.so
Exception in thread "main" java.lang.UnsatisfiedLinkError: /tmp/jna--873636902/jna2423240844359937896.tmp: /tmp/jna--873636902/jna2423240844359937896.tmp: cannot open shared object file: No such file or directory

My conclusion:
Wrong architecture (armel) is choosen when using JNA 4.5.1.

@joelbygger joelbygger changed the title JNA 4.5.1 chooses wrong libjnidispatch.so when using Oracle Java on armhf JNA 4.5.1 chooses wrong libjnidispatch.so when using Oracle Java 8 on armhf May 9, 2018
@matthiasblaesing
Copy link
Member

I assume the Oracle binaries suffer from the bug, that the binary is not marked to be hardfloat. Please see #920 for an explanation. You found the sun.arch.abi property. It might be worth to create patch, that checks this property to work around the oracle limitation - I'd appretiate such a patch.

@matthiasblaesing
Copy link
Member

Ok - I checked raspbian and the oracle 8 JDK and both show the problem. The flags header does not contain the hard-/softfloat markers. So it looks as if the toolchains of both builds don't support adding the flag.

I added an arm EABI build attributes parser to the detection engine and this works also on older binaries.

I tested:

  • raspbian OpenJDK 7
  • Oracle JDK 8 for ARMHF on rasbian
  • openjdk 7 on debian stable arm (hardfloat) and armel (softfloat) on qemu emulation

@joelbygger please see if this fixes the issue for you
@kunkun26 as you authored the changes in #863 I'd like you to review/test this change. It should be safe, but I don't routinely test on arm.

You can either build from the PR branches (#960, #961) or use the attached zip, which contains binaries for the 4.5.X and master branch (upcoming 5.0.0).

jna-test.zip

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

2 participants