My plan is to use Debian for it - see openHAB Packaging for the Pine64.
I have a .so file now to try. Will report back later.
Cool, good luck 
I didn’t have much time over the weekend unfortunately, and when I did, I failed to recall the command line option to override the RXTX/NRjavaserial library. I had to use it on CentOS a while back and still have that machine shut off somewhere. Worst case, i can fire it up and get the command line, but does anyone have it handy?
For posterity, this is the command line argument to override the built-in libNRJavaSerial.so native library. At least it was before karaf. Will give it a go tomorrow.
-DlibNRJavaSerial.userlib=/opt/nrjs/libNRJavaSerial.so
This is more daunting that I had hoped. It is beyond the file locking and simple compile flags that I have tried. Hopefully the NR dev team can pick it up and get 3.12 done proper. Maybe we just send them an odroid C2 or Pine board as incentive?
Hm, that’s a pity that you didn’t succeed in compiling it 
Yes, I would be happy to sponsor an ODROID board for MrDOS, if this makes him add arm64 support in 3.12. But I am wondering if it enough to ask him for hints on how to compile it yourself? He mentioned that it should be fairly simple, so maybe he can help on how to do the compilation the right way?
Through the post made over there recently, I was able to piece together a Makefile that worked for me.
15:45:15.912 [INFO ] [me.event.ThingStatusInfoChangedEvent] - ‘zwave:serial_zstick:1ba63962’ changed from UNINITIALIZED to INITIALIZING
15:45:15.919 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Connecting to serial port '/dev/ttyUSB0’
15:45:15.922 [INFO ] [me.event.ThingStatusInfoChangedEvent] - ‘zwave:serial_zstick:1ba63962’ changed from INITIALIZING to ONLINE
15:45:16.059 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Serial port is initialized
I can make the .so available, but in the meantime, here are the steps I took:
- Use the Makefile provided here
- edit the Makefile and add -I includes for your JVM to get the jni headers. You will need $JDK/include and $JDK/include/linux .
Mike look like this as an example: -I/opt/jdk1.8.0_73/include -I/opt/jdk1.8.0_73/include/linux
-
install liblockdev1 and liblockdev1-dev packages. Note, if you use a newer OS such as Xenial, which the Odroid ships with, you will have to go hunting for these. liblockdev1 is deprecated, but the packages can be found, they just cannot be installed with apt-get. Here is an example for xenial: liblockdev1-dev
-
make
-
take the resulting .so file and put it in a place that won’t get destroyed
-
edit runtime/karaf/bin/setenv and add -DlibNRJavaSerial.userlib=/opt/libNRJavaSerial.so to the ARCH specific area. Substitute your path where I have /opt/.
The part of mine now looks like this:
case "$ARCH" in
*arm*) ;;
*) EXTRA_JAVA_OPTS_ARCH="-XX:+UseG1GC -DlibNRJavaSerial.userlib=/opt/libNRJavaSerial.so" ;;
esac
- start openHAB
@xsnrg This is great news!
Do you think it is feasible to take https://github.com/NeuronRobotics/nrjavaserial/releases/download/3.12.0/nrjavaserial-3.12.0.jar and tweak it so that it also contains your .so? We could then put such a customized jar in the transport.serial bundle and have it all directly working for openHAB.
@Kai feasible, yes, but let me make it available for others to test first. Give this a go:
I want to make sure that it works on more than an odroid for one. A different jdk than mine would be a good test too - jdk1.8.0_73.
I tried it on a Pine64 with Ubuntu Xenial, i.e. without liblockdev1 installed - this fails with
java.lang.UnsatisfiedLinkError: /home/ubuntu/oh/lib/libNRJavaSerial.so: liblockdev.so.1: cannot open shared object file: No such file or directory thrown while loading gnu.io.RXTXCommDriver
java.lang.NoClassDefFoundError: Could not initialize class gnu.io.RXTXCommDriver thrown while loading gnu.io.RXTXCommDriver
I assume, you expected this.
As I want to use anyhow Debian Jessie for the openHAB SD card image, I will prepare a new card and test with that as well; Would you expect it to work there out of the box?
Correct, that was completely expected with Xenial. I provided the link above to download the needed packages. They are out there, just not in the default repos for easy download direct from apt.
I would expect it to work on Jessie as those packages are still available. I don’t know what the level of ARM64 support in Jessie is like though. There had to be some reason Odroid decided to go with Xenial, even pre-release.
Hmm, check this out: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734086 maybe they are not available much longer.
Just tried it on a Pine64 with Debian Jessie - unfortunately, no luck here either:
java.lang.UnsatisfiedLinkError: /home/pine64user/openhab/lib/libNRJavaSerial.so: liblockdev.so.1: cannot open shared object file: No such file or directory (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver
java.lang.NoClassDefFoundError: Could not initialize class gnu.io.RXTXCommDriver thrown while loading gnu.io.RXTXCommDriver
Here’s the system info:
pine64user@debianpine64:~$ uname -a
Linux debianpine64 3.10.65-4-pine64-longsleep #16 SMP PREEMPT Sun Apr 3 10:56:40 CEST 2016 aarch64 GNU/Linux
This has me wondering if the liblockdev version that installed is 32 bit?
ldd <install path to liblockdev1.so>
Also, the JDK is the 64 bit version, correct?
java -version
One more thing you could look at would be to run ldd against the NR .so to make sure it is pulling in 64 bit libraries:
ldd /home/pine64user/openhab/lib/libNRJavaSerial.so
edited: Did you try Xenial with the lockdev package added manually ?
Did you try Xenial with the lockdev package added manually ?
I tried to install the package, but it complained about too many missing dependencies and I gave up after a while.
I am now a step further and have installed the Docker container on Debian Jessie and will check how it behaves in there.
Here are links to both the packages needed. I should have just done that in the first place 
http://launchpadlibrarian.net/230433667/liblockdev1_1.0.3-1.6build2_arm64.deb
http://launchpadlibrarian.net/230433664/liblockdev1-dev_1.0.3-1.6build2_arm64.deb
Install the non-dev package first, and that should satisfy the dependencies for the dev package. Actually, with the pre-built .so, you may not even need the -dev package. That should only be needed for compile.
Good news! I managed to install liblockdev1 and your .so library seems to work on the Pine64 (on Debian)!
Unfortunately, it looks as if the ZWave.me dongle isn’t supported by the kernel (yet)… So still some work to do.
But regarding the compilation of a new JAR for io.transport.serial, I think we could go ahead. Is this something you would know how to do it (especially adding the lib for the arm64 architecture)? Such a new jar should definitely also include https://github.com/NeuronRobotics/nrjavaserial/issues/44, so that it is not bigger than needed.
Congratulations!
What is the comfort level with using a shared library compiled against another shared library that is no longer available in standard repositories for new operating systems? To ensure it works beyond tomorrow, we might have to include the shared library for liblockdev1.
I would rather it be cleaner, things that are temporary live forever.
I’d hope that the clean solution is going to be done in the nrjavaserial project itself; I am for now only interested in a temporary solution that makes the serial access working on the Pine64 (as the IoT package is going to be shipped very soon and thus we will have 2000 openHAB users on the Pine64 very soon). For this reason, I exceptionally vote for a quick working solution instead of a clean and future-proof one For the Pine image, I will make sure that liblockdev1 is available.
The quickest path then would be to edit the setenv in karaf/bin. There is already a section in there for ARM arch. Add ARM64 and the -D command line flag for the libNRjavaserial and you are done as long as liblockdev1 is also installed. This falls apart if setenv is actually a karaf file that we don’t have control over.
I don’t think I will have time to try to adjust the jar with timing that makes sense to get the boards shipped, unfortunately.