search

java-native / jssc

Java library for talking to serial ports (with added build support for maven, cmake, MSVC)
https://discord.gg/RBsUfE9sX9
GNU Lesser General Public License v3.0
170 stars 53 forks source link

Differentiate between ARM hardware floating point and software #35

Open tresf opened 5 years ago

tresf commented 5 years ago

"hf" and "sf" are suffix abbreviations that represent CPU capabilities on ARM devices.

JSSC 2.8.0 had this distinction and supported loading the right one. It uses some tricks for this, including the readelf binary, which isn't necessarily available on all platforms by default. Here's the code:

https://github.com/java-native/jssc/blob/v2.8.0/src/java/jssc/SerialNativeInterface.java#L118-L135

This functionality was removed with the master branch due to native-lib-loader library not having the same distinction capabilities.

We are investigating two options:

Related #26

bmarwell commented 5 years ago

Other libraries use uname for this and look for gnu-something. This will also work only on Linux. But yes, I commented on the upstream issue that we should keep that in mind.

MrWhammy commented 3 years ago

Could this be the cause for the attached error on Raspbery Pi Zero?

tresf commented 3 years ago

Could this be the cause for the attached error on Raspbery Pi Zero?

No, because your JVM uses hard-float (which most non-legacy arm devices will).

Your issue may be related to this stack trace:

Internal exceptions (10 events):
Event: 1.558 Thread 0xb4f07400 Exception <a 'java/security/PrivilegedActionException'> (0xab4cdec0) thrown at [/openjdk-8-8u212-b01/src/hotspot/src/share/vm/prims/jvm.cpp, line 1502]
Event: 1.558 Thread 0xb4f07400 Exception <a 'java/security/PrivilegedActionException'> (0xab4ce0c0) thrown at [/openjdk-8-8u212-b01/src/hotspot/src/share/vm/prims/jvm.cpp, line 1502]
Event: 1.559 Thread 0xb4f07400 Exception <a 'java/security/PrivilegedActionException'> (0xab4ceb08) thrown at [/openjdk-8-8u212-b01/src/hotspot/src/share/vm/prims/jvm.cpp, line 1502]
Event: 1.559 Thread 0xb4f07400 Exception <a 'java/security/PrivilegedActionException'> (0xab4ced08) thrown at [/openjdk-8-8u212-b01/src/hotspot/src/share/vm/prims/jvm.cpp, line 1502]
Event: 1.603 Thread 0xb4f07400 Exception <a 'java/security/PrivilegedActionException'> (0xab4dae80) thrown at [/openjdk-8-8u212-b01/src/hotspot/src/share/vm/prims/jvm.cpp, line 1502]
Event: 1.603 Thread 0xb4f07400 Exception <a 'java/security/PrivilegedActionException'> (0xab4db080) thrown at [/openjdk-8-8u212-b01/src/hotspot/src/share/vm/prims/jvm.cpp, line 1502]
Event: 2.211 Thread 0xb4f07400 Exception <a 'java/io/FileNotFoundException'> (0xab61c1d8) thrown at [/openjdk-8-8u212-b01/src/hotspot/src/share/vm/prims/jni.cpp, line 710]
Event: 6.714 Thread 0xb4f07400 Exception <a 'java/lang/NoSuchFieldError': method resolution failed> (0xab52aa88) thrown at [/openjdk-8-8u212-b01/src/hotspot/src/share/vm/prims/methodHandles.cpp, line 1167]
Event: 6.739 Thread 0xb4f07400 Exception <a 'java/lang/NoSuchFieldError': method resolution failed> (0xab536c00) thrown at [/openjdk-8-8u212-b01/src/hotspot/src/share/vm/prims/methodHandles.cpp, line 1167]
Event: 9.546 Thread 0xb4f07400 Exception <a 'java/lang/NoSuchMethodError': org.slf4j.impl.StaticMDCBinder.getSingleton()Lorg/slf4j/impl/StaticMDCBinder;> (0xab58c348) thrown at [/openjdk-8-8u212-b01/src/hotspot/src/share/vm/interpreter/linkResolver.cpp, line 620]

If that's the case, it's hard to know for sure, but may be a simple as a bug specific to that exact JVM build. If you extract another JVM and test it, does the issue go away? This could mean a variety of things, but at a glance, the JNI function call doesn't match. This could mean that you need to recompile your Java project with 2.9.2 on the classpath or could be something we missed in our native .so compile flags.

https://github.com/java-native/jssc/blob/e02fb9c475535bf2d221e50c97858f19a393845d/CMakeLists.txt#L33

MrWhammy commented 3 years ago

I compiled the master branch on my Pi Zero and now I don't get the error anymore (did not change JVM)

git clone https://github.com/java-native/jssc.git
cd jssc
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-armhf
mvn clean install -DskipTests

The generated jar file does work (I renamed the jar file from jssc-2.9.3-SNAPSHOT.jar to jssc-2.9.2.jar)

17:49:28.004 [main] DEBUG o.s.nativelib.NativeLibraryUtil - processor is ARM os.arch is arm
17:49:28.006 [main] DEBUG o.s.nativelib.NativeLibraryUtil - architecture is LINUX_ARM os.name is linux
17:49:28.014 [main] DEBUG o.s.nativelib.NativeLibraryUtil - architecture is LINUX_ARM os.name is linux
17:49:28.017 [main] DEBUG o.s.nativelib.NativeLibraryUtil - platform specific path is natives/linux_arm/
17:49:28.020 [main] DEBUG o.scijava.nativelib.BaseJniExtractor - mappedLib is libjssc.so
17:49:28.024 [main] DEBUG o.scijava.nativelib.BaseJniExtractor - URL is jar:file:/opt/p1processor/jssc-2.9.2.jar!/natives/linux_arm/libjssc.so
17:49:28.026 [main] DEBUG o.scijava.nativelib.BaseJniExtractor - URL path is file:/opt/p1processor/jssc-2.9.2.jar!/natives/linux_arm/libjssc.so

Is something wrong with the provided libjssc.so in 2.9.2 maybe?

tresf commented 3 years ago

Is something wrong with the provided libjssc.so in 2.9.2 maybe?

No idea. It was cross-compiled using this:

https://github.com/java-native/jssc/blob/b09439e0b419750ae7ea150822f9ae06b8ef2e6c/.travis.yml#L46

... perhaps there's some flags we're missing? Certain CPU features might cause this, and if that case, we'd want to disable them. Any insight is welcome, we'll add it to the toolchain.

MrWhammy commented 3 years ago

I'm afraid I was unable to find out. I tried cross compiling on my machine, but that didn't work out (could not find compiler arm-linux-gnueabihf-g++-5, maybe to do with me not installing the correct package (I'm on Fedora)).

I gathered the CMake output files, in case it's of any use.

Thanks for your help!

tresf commented 3 years ago

The armhf binaries we ship were originally tested on similar hardware, cross-compiled using Ubuntu, tested on a Pi. If no one fixes the binary system, this won't get patched any time soon.

There is simply too many OS and hardware combinations for one person to maintain, it requires testing and collaboration from others. Originally when this project was formed there were three volunteers and now it's just one.

In regards to the compiler, it's probably a few letters off on Fedora, we'd happily accept a PR which uses the correct cross-compiler.

Also if the wiki needs improvement to clarify anything, we're welcome to feedback.