UnsatisfiedLinkError : cannot open shared object file

[rL071]

Hi, I did not find any answer for this problem on this forum.

I got this error :

java.lang.UnsatisfiedLinkError: /tmp/1522097373321-libjSerialComm.so: /tmp/1522097373321-libjSerialComm.so: cannot open shared object file: No such file or directory

The processor is armv7l.

I've tried : 1/ to put the .so file in /usr/lib and do "ldd" command 2/ to change rights on /tmp 3/ to specify a different tmp directory with -Djava.io.tmpdir 4/ to use a less recent library version 5/ to use "loadLibrary" and "load" in Java

Nothing works :(

Thanks in advance for your precious answer.

[s-frei]

Hi there,

I'm having the same issue and also don't know how to get rid of it...

uname -a Linux raspberrypi 5.4.65-v8+ #1341 SMP PREEMPT Tue Sep 15 13:20:32 BST 2020 aarch64 GNU/Linux

OS: Raspbian GNU/Linux 10 (buster) aarch64 Host: Raspberry Pi 4 Model B Rev 1.4 Kernel: 5.4.65-v8+

[hedgecrw]

Please test using this version of the library and let me know if you are still seeing the same problem: https://drive.google.com/file/d/1QzWPJg5MU_2YrnsB1MsOWeTbjYD84D2h/view?usp=sharing

[s-frei]

Please test using this version of the library and let me know if you are still seeing the same problem: https://drive.google.com/file/d/1QzWPJg5MU_2YrnsB1MsOWeTbjYD84D2h/view?usp=sharing

Thanks for your reply. I will give it a try as soon as I got time for that, the next days!

I was able to get rid of that problem passing -Dos.arch_full=armv7-hf, but forgot to mention this here...

[hedgecrw]

Btw, I see the original problem here. Your RPi is running an aarch64 OS (which is the 64-bit state of an armv8 processor); however, your Java binary is an aarch32 binary (which is the 32-bit state of an armv8 processor). This is an odd situation where your application architecture does not match your OS architecture, but it works because armv8 supports both the aarch32 and the aarch64 architectures. At startup, jSerialComm is detecting your OS as a 64-bit OS and trying to load the appropriate library, but its running within your 32-bit Java process, and therefore failing. Your solution of manually specifying -Dos.arch_full=armv7-hf is the correct solution here. Or updating your Java to a 64-bit version would work without requiring the arch_full flag.

[s-frei]

@hedgecrw sorry in advance writing in a closed PR. I somehow missed the notification on this...

I wasn't somehow able to get a JDK for aarch64 running. I'm using the LibericaJDK from Bellsoft. Maybe it would be a good idea to inform about the detected OS when the exception is thrown, that would've helped me a lot.

Anyhow, thanks for the good work! 😉 keep it up 🚀 I'm using your library in a spring boot app which acts as music player and when a new song comes up the title gets printed to an 32x8 LED panel which is controlled by an Arduino, and it works like a charm.

[hedgecrw]

@s-frei, that's actually a fantastic idea. I will update the next release to output the architecture of the native library trying to be loaded if it fails. Thanks for the suggestion!

[retrodaredevil]

@hedgecrw one of the users of SolarThing came across this issue on their RPi4 (https://github.com/wildmountainfarms/solarthing/issues/122). The -Dos.arch_full=armv7-hf is what fixed it for them. I assume they were running a 32-bit Java process as described above. How can I know if that particular flag needs to be added to the java command or can I detect that system property needs to be set and set it in my Java application?

Why isn't this something that is detected by jSerialComm? Shouldn't jSerialComm be able to know the java process is 32 bit? Maybe sun.arch.data.model should be used as the primary way to detect the architecture and then fall back to os.arch_full if it's not present?

Figured I'd revive this issue since it's exactly what's happening, but let me know and I'll open a new issue if that is preferred to reviving this.