Differentiate between ARM hardware floating point and software

[tresf]

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

• IDEAL: Ship one binary to handle both hardware capabilities. Is this possible?
• BACKUP PLAN: Ship two binaries and use a patched native-lib-loader to fix this. (see @bmhm's upstream PR: Add directory layout according to os-maven-plugin and osdetector-gradle-plugin scijava/native-lib-loader#32)

Related #26

[bmarwell]

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]

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

[tresf]

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.

jssc/CMakeLists.txt

Line 33 in e02fb9c

set(CMAKE_CXX_STANDARD_LIBRARIES "-static-libgcc -static-libstdc++ ${CMAKE_CXX_STANDARD_LIBRARIES}")

[MrWhammy]

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]

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

No idea. It was cross-compiled using this:

jssc/.travis.yml

Line 46 in b09439e

- g++-arm-linux-gnueabihf

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

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]

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.