NoClassDefFoundError: Could not initialize class org.xerial.snappy.Snappy v.1.1.9.1

[StefanBratanov]

Hi,

We use snappy-java in our project and one of our users has issues running on an ARM (Radxa 5b board) with v1.1.9.1. Downgrading to 1.1.8.4 seems to fix the issue. See the following issue for more information: Consensys/teku#7022

I can see there is 1.1.10 version of snappy available (https://github.com/google/snappy/releases/tag/1.1.10) and Compilation fixes for various environments is mentioned. Is it possible a future release of snappy-java referencing this version will fix the issue above? Also is downgrading the only option for now?

[killergerbah]

I am also seeing this issue on snappy-java version 1.1.9.1 on our machines using arm64 CPUs:

! java.lang.UnsatisfiedLinkError: /tmp/snappy-1.1.9-09efcf6e-c392-4172-a25a-6c77bf371caa-libsnappyjava.so: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /tmp/snappy-1.1.9-09efcf6e-c392-4172-a25a-6c77bf371caa-libsnappyjava.so)

Our Docker containers run Ubuntu 20.04 which have glibc 2.31 installed

[xerial]

Probably related to #405. dockcross compilers used for building snappy-java native libraries might be using too new glibc version

[StefanBratanov]

Is there any possibility version 1.1.10 fixes that. Is it expected snappy-java to update soon to the newest version?

[snmvaughan]

I ran into the same issue, and was able to re-build the library on a Graviton host running an older OS. Our target environment uses a multi-arch image to run the same configuration on multiple platforms. I'm surprised that only the Graviton instance had an issue.

[xerial]

I've tested upgrades to snappy 1.10.0, but it seems there is almost no binary change except for some specific platform https://github.com/xerial/snappy-java/pull/431/files

Some Arm environment issue reported here might have a different cause.

[xerial]

The solution for this problem looks like using Linux OS with glibc 2.32 or later:
#417 (comment)

glibc 2.32 was released 3 years ago (2020) https://sourceware.org/glibc/wiki/Release/2.32, so generally speaking I'd recommend upgrading the OS version.

For supporting such an older version of glibc, we need to use an older version of the cross compiler (dockcross image) or prepare custom cross-compiler images, but it would be overkill for this project.

Building your own version of snappy-java with make native package command is another option.

[NersesAM]

Stumbled upon this when running our app on Arm machine. We are using latest stable debian image from dockerhub debian:11-slim. libc version on it is 2.31, I understand that it is years old now, but lots of linux distros are moving very slow, and compiling with latest may break lots of users apps.

I'd kindly ask to reconsider and if possible to compile with older versions.
https://github.com/dockcross/dockcross#summary-cross-compilers provides lts versions for compiling with old versions

https://github.com/xerial/snappy-java/pull/435/files this hopefully will fix it.

[xerial]

@NersesAM Good to know that Dockcross now provides LTS versions with older glibc. Now rebuilding arm binaries at #436

[xerial]

Rebuild Linux aach64 native lib using an LTS version of cross-compiler with glibc 2.28 #436. I'll prepare a snapshot version for testing purpose.

[xerial]

Published a new snapshot version. I hope this will fix the issue https://oss.sonatype.org/content/repositories/snapshots/org/xerial/snappy/snappy-java/1.1.9.1-26-41813272-SNAPSHOT/

I'll release snappy-java 1.1.10.0 if this works

[xerial]

Released https://github.com/xerial/snappy-java/releases/tag/v1.1.10.0

I'll close this ticket now. If you encounter a similar issue, could you file another ticket to have a fresh start? Thanks

[StefanBratanov]

Thank you @xerial for the quick turnaround. Appreciate it!

[xerial]

@StefanBratanov Kudos to @NersesAM. He provided a maintainable solution #417 (comment)