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.
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.
@Kai@xsnrg , thanks for sharing the library and the insights. Got it working with OH1.8 on Pine64 with Aeon USB stick (gen 2) and Debian. Will need to run it for a while to rule out possible issues and stability, but at least basic init of all nodes seems good in the logs.
I don’t have any ability to test it for a few days (no 64 bit ARM here). It contains the new native library, but not sure of the native selection process… It seemed too easy. If the 64 bit works, please check on a 32 bit ARM as well.
It uses a system call to return the arch type, and then matches it against a list. This likely means I did not get the arch type correct for it to match on. I did not have a board to test it with when I created the jar, so that wasn’t helpful.
I suspect it could with some work. All the current one seems to be doing is using the system call to return the arch type and then looking in the right folder for the library. There is even some chance involved, because there are multiple libraries in each arch folder. It starts loading them in the order of newest arch to oldest so that the most feature rich library supported by the hardware is loaded, but this is really inefficient, and I could see it causing problems if it does not already.
The native code libraries still need to be part of the jar as it is right now, so any new arch types would need a rebuild of the jar instead of just adding a new native library. The whole of this could stand to be re-factored, but without a lot of time to give it, I was trying to get a working jar that had the 64 bit lib in it for now. We really need the NRjavaserial folks to take this one on. There are a lot of good ideas on their forum, and some PRs as well, but I understand the time and commitment OSS takes, and it doesn’t put food on the table for most.
Tonight I managed to find a C2 to continue to experiment with. I followed the 7 steps outlined previously to make sure the steps and the .so file are still good on another machine, and am happy to say there are no problems.
I hope to give the nrjavaserial jar another go in the coming days.
openhab | openhab> java.lang.UnsatisfiedLinkError: Can't load library: /opt/libNRJavaSerial.so thrown while loading gnu.io.RXTXCommDriver openhab | java.lang.NoClassDefFoundError: Could not initialize class gnu.io.RXTXCommDriver thrown while loading gnu.io.RXTXCommDriver
just dropped into this thread while failing to set up my ComfoAir-binding with OH 1.8.3 on my pine64 (not openHAB-edition but plain KS board).
I went a long way of HW-debugging to get the serial wiring correct and am now using ComfoAir -> MAX3232 TTL -> uart2 on PINE (RPi2-Bus pins 8/10). Now I can read (manually using a small python script) incoming data on /dev/ttyS2 (after enabling the uart2 in the device tree blob). But OpenHab’s comfoair binding said, it did not know about /dev/ttyS2 and I have no serial ports.
Enabling the debug-log led me to the actual exception, namely java.lang.UnsatisfiedLinkError: /tmp/libNRJavaSerial_ubuntu_0/libNRJavaSerial.so: /tmp/libNRJavaSerial_ubuntu_0/libNRJavaSerial.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch) and this seems exactly what this thread is about.
So: what do I need to do? Does a current nightly build of OpenHab already contain a fix? Do I have to download the .so manually and point OH to it? Any advice?