I’m developing a new binding for a device having serial port. I’ve written a small test for testing interaction with the device.

The lib I’m using for talking to the serial port is

…which in turn uses java comm implementation.

The Exception I’m getting is:

Can't load either x86_64 or arm6vl .so
/tmp/ /tmp/ wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
        at org.openhab.binding.proteusecometer.internal.ProteusEcoMeterSCommunicatorTest.communicateShouldWork(

And indeed, the arch of that shared object ist:

file /tmp/                                                
  /tmp/ ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, not stripped

So I guess java comm implementation generates the wrong shared object arch for my testing machine. Does anyone have a clue how I can influence the arch?

About my java:

  openjdk version "11.0.9" 2020-10-20                                                
  OpenJDK Runtime Environment (build 11.0.9+0-adhoc..source)                         
  OpenJDK 64-Bit Server VM (build 11.0.9+0-adhoc..source, mixed mode)

The strange thing is the file name of the shared object indicates the right arch (64 bit) but the lib itself is 32 bit encoded. Any ideas?


Did you change something to explicitly switch the serial library to use java comm? openHAB uses nrjavaserial by default which dynamically loads the correct for your architecture (embedded in the nrjavaserial JAR). I think almost nobody running openHAB is using java comm so it is not well tested or supported.

Hi @wborn, I didn’t change something but in that case chose the wrong implentation of SerialPortIdentifier within my test. Thank you for that information, I’ll stay away from java comm.

1 Like

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.