fatal error on Raspberry Pi

[ulde1]

When creating new SerialPort("/dev/ttyUSB0") my Raspberry Pi runs into a Fatal Error.

import jssc.SerialPort;

public class SerialTest {

    public static void main(String[] args) {
        new SerialPort("/dev/ttyUSB0");
    }

}

JRE version: OpenJDK Runtime Environment Zulu11.64+19-CA (11.0.19+7) (build 11.0.19+7-LTS)
Java VM: OpenJDK Client VM Zulu11.64+19-CA (11.0.19+7-LTS, mixed mode, serial gc, linux-arm)
Problematic frame:
C  [libjssc.so+0x3b48]

Hardware        : BCM2835
Revision        : 0010
Model           : Raspberry Pi Model B Plus Rev 1.2

OS:PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"

Any help would be appreciated.

Error report file with more information is attached.

hs_err_pid1114.log

[tresf]

I believe the libjssc.so is not compatible with your system. Here's how we create it:

https://github.com/java-native/jssc/wiki/Cross-Compilation#linux-arm-32-bit

Looking into why this occurs, I found this explanation, which I believe describes what we are seeing: https://raspberrypi.stackexchange.com/a/58986/132436

I'm not sure how to best handle this, but advice is welcome. If I understand correctly, it may be caused by an ARMv6 vs. ARMv7 target. If we can safely revert to ARMv6 (e.g. if it's forward compatible with ARMv7) this may be our best approach, but we will need to modify our wiki with instructions for how to do this.

Note, calling cmake from maven is a bit of a rube-goldberg experiment, so anyone interested in spearheading this may choose to call cmake directly while getting the environment configured.

[ulde1]

Thank you for your hints.

I compiled the source under Raspian on the destination Raspberry Pi itself:

apt install maven cmake g++ file git
git clone https://github.com/java-native/jssc.git
cd jssc
mvn

and there was a jssc/target/classes/natives/linux_arm/libjssc.so generated.

But no luck: The problem still persists. What can I do?

BTW: A Raspberry 4 runs luckily.

[tresf]

@ulde1 thanks kindly for this...

It's been a while since I've made a new jar and the documentation isn't the most clear... can you make sure the native components are updated? Here's some documentation on where they reside:

https://github.com/java-native/jssc/wiki/Compiling#uber-jar-artefact

Furthemore, feel free to edit any of this wiki, we want to be more friendly to people contributing fixes.

[ulde1]

I've solved the problem!

Simply use Version 2.8.0. Works like a charm on an old Raspberry Pi!

[tresf]

Reopening, since the latest version still has the bug.

[pietrygamat]

I played for a bit with this problem, and came up with very quick, dirty and efficient solution for @ulde1 on how to create arm6 compatible artifact in reproducible way from current sources. On x86 PC with docker installed run the following. Don't worry about dependencies yet:

git clone https://github.com/java-native/jssc.git
cd jssc
docker run --rm -it -v ~/.m2/repository:/root/.m2/repository:Z -v $(pwd):/work:Z docker.io/dockcross/linux-armv6-lts bash

Now, inside the container install required dependencies:

apt install -y cmake openjdk-11-jdk-headless maven
export JAVA_HOME=$(dirname $(dirname $(readlink -f $(which javac))))

The docker image contains the toolchains capable of building correct binaries, but our ant scripts are opinionated on where the toolchains should reside, thus we'll fix this with a simple trick: create symlinks from what maven/ant expects to what dockcross image already contains in different location:

ln -s $CROSS_ROOT/$CROSS_TRIPLE/bin/strip /usr/bin/arm-linux-gnueabihf-strip
ln -s $CROSS_ROOT/bin/$CROSS_TRIPLE-g++ /usr/bin/arm-linux-gnueabihf-g++
ln -s $CROSS_ROOT/bin/$CROSS_TRIPLE-gcc /usr/bin/arm-linux-gnueabihf-gcc 

And now build the project with maven - this should be 2 distinctive steps:

# build native for rpi
mvn clean install -Parmhf

# install jar into local maven repository
mvn clean install -Ppackage

Optionally build fat-jar with all the dependencies inside. I recommend to use mvn package, not mvn install because the resulting jar does not follow maven conventions, and putting it in local repository may lead to unforseen consequences. But since many find standalone fat-jar easier to use, that's how you do it.

mvn clean package -Ppackage -Pjar-with-dependencies

I have tested the resulting jar in both Raspberry Pi Zero W Rev 1.1 and Raspberry Pi 3 Model B Rev 1.2. I believe model Zero is similar to original Raspberry Pi Model B Plus Rev 1.2 you have, as it suffers from the same problem.

@tresf, as far as proposing actual PR to fix the issue - this is a separate matter. I do not want to add to the Rube-Goldberg, and introduce docker as a standard - I remember your objections here. Although I read that configuring build environment for cross-compilation targetting arm6 is getting harder, as there is no packages available in modern distros that do just that. Also - I don't know second thing about cmake :).

[tresf]

introduce docker as a standard - I remember your objections here

I think this is a perfect candidate for Docker.

there is no packages available in modern distros that do just that.

Completely agreed, this problem will only get worse. I actually help with another project that suffers the same.

Also - I don't know second thing about cmake :).

I'd be happy to help with the CMake parts if needed.

[tresf]

@pietrygamat what's next to close this out now that #140 is merged?

[pietrygamat]

@tresf Merge the branch with rebuilt artifacts (one mentioned in #140 or a new one generated with pipeline run from master). Then perhaps a release to maven central with next version?

[tresf]

@tresf Merge the branch with rebuilt artifacts (one mentioned in #140 or a new one generated with pipeline run from master). Then perhaps a release to maven central with next version?

This sounds like a great idea. I'll be frank, I'm not exactly sure how the precompiled branch merging should work. Perhaps we should proceduralized this? If you don't mind taking the reins, we can get this closed out.

[pietrygamat]

@ulde1 the updated libs are now in master, and we are preparing to release to maven central. Would you care to verifty if the version here https://github.com/java-native/jssc/releases/tag/v2.9.5 works as expected in your case? Hoping for the best, I will close this issue now.

[ulde1]

YES! I can confirm that this issue is resolved in Release 2.9.5.