Is glibc 2.35 required now?

[jazdw]

Our CI runs on Ubuntu 20.04 and we are seeing this after upgrading from 2.9.6 to 2.10.0

17:18:05   java.lang.UnsatisfiedLinkError: /tmp/nativelib-loader_16340391621759678410/libjssc.so: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.35' not found (required by /tmp/nativelib-loader_16340391621759678410/libjssc.so)
17:18:05     at java.base/jdk.internal.loader.NativeLibraries.load(Native Method) ~[?:?]
17:18:05     at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:388) ~[?:?]
17:18:05     at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:232) ~[?:?]
17:18:05     at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:174) ~[?:?]
17:18:05     at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2394) ~[?:?]
17:18:05     at java.base/java.lang.Runtime.load0(Runtime.java:755) ~[?:?]
17:18:05     at java.base/java.lang.System.load(System.java:1970) ~[?:?]
17:18:05     at org.scijava.nativelib.NativeLibraryUtil.loadNativeLibrary(NativeLibraryUtil.java:373) ~[native-lib-loader-2.5.0.jar:2.5.0]
17:18:05     at org.scijava.nativelib.NativeLoader.loadLibrary(NativeLoader.java:139) ~[native-lib-loader-2.5.0.jar:2.5.0]

[tresf]

Yeah, it appears so. We use ubuntu-latest for our runners, but I suppose we could step this back a bit. Sadly, Ubuntu 20.04 is EOL so that's likely not going to happen unless you know of a way to link older libc versions from 24.04 / latest. I personally find this lack-of-backwards compat/dependency hell on Linux infuriating. /rant

[pietrygamat]

To be pedantic, the C++ compilation is happening on docker.io/dockcross:latest containers based on debian, so there is a hint of assumption that if something is outdated on debian it is really outdated ;).

[tresf]

To be pedantic, the C++ compilation is happening on docker.io/dockcross:latest containers based on debian

I keep forgetting this. Thanks for clarification. I assume it's using these? https://github.com/dockcross/dockcross/tree/master?tab=readme-ov-file#summary-cross-compilers

Quoting:

Base image for other toolchain images. From Debian Bookworm with GCC, make, autotools, CMake, Ninja, Git, and Python.

Which reads similar to this upstream bug (albeit for ARM64): dockcross/dockcross#663. Ironically, the ARM containers seem to support the -lts suffix to target Debian Buster for Raspberry Pi support but I don't see anything similar for target legacy Intel systems.

The initial spirit of JSSC was to work on the oldest-possible distro and we've done a pretty good job of keeping that alive, but I'm not sure dockcross provides an easy way to support 20.04. Thoughts welcome.

[jazdw]

I guess I was more wondering if this was intentional or not, it seems like maybe it wasn't since it was not mentioned in the release notes for 2.10.0.

The initial spirit of JSSC was to work on the oldest-possible distro and we've done a pretty good job of keeping that alive, but I'm not sure dockcross provides an easy way to support 20.04. Thoughts welcome.

It would be nice if jssc could support an older version of glibc but yeah since Ubuntu 20.04 is EOL, going back that far may not be feasible.

Is there a compatibility matrix of distros / glibc versions anywhere?

[hiddenalpha]

Is there a compatibility matrix of distros / glibc versions anywhere?

The best I could find so far was distrowatch.com. It is not a matrix and one has to search through distros themself.

But this page looks useful. Choose the distro in question, then (browser)-search for "libc" then in the table one can see which libc version was used in which distro version.

I don't know how accurate it is, but makes a good impression to me.

[tresf]

It would be nice if jssc could support an older version of glibc but yeah since Ubuntu 20.04 is EOL, going back that far may not be feasible.

Yeah it's a bit of a double-edge sword. The other C++ projects I work with are so excited to get ahold of newer compiler features that leaving the EOL clients in the dust is celebrated. JSSC is such a small codebase we don't gain much by doing this.

I've worked with dockcross as part of the gary-rowe/hid4java project and find it to be OK for firing up a quick build environment but quite confusing when trying to make changes to the environment. At a glance we could easily solve this issue by leveraging an older container. There's really no downsides to this besides complexity. dockcross may even be receptive to adding this, we can use this bug-report as our justification. For example, Ubuntu offers a legacy support package for 14.04 until 2026!, but at some point, we'll need to draw a line in the sand somewhere.

JSSC is a project that a few (mainly 3-4) of us picked up after it was abandoned by its author. The original project was built by-hand by Alexey without much documentation on the process. We've modernized it a bit, but this has the downside of using whatever minimum-os-version the internet thinks is relevant at the time.

If the code compiles and doesn't break the work @hiddenalpha's been doing, I have no objections to targeting an older distro. I assume this can be influenced here, but I'm not well-versed enough in Docker to know... https://github.com/dockcross/dockcross/blob/abab9c6b4bd5dcc5542b0c2b0637f06269e6be5f/Dockerfile.in#L1-L2

[jazdw]

Reading some dockcross issues it seems like the dockcross/manylinux_xxx images can be used to build a library compatible with many older distros.

e.g. dockcross/manylinux_2_28-x64 would support the following distros:
https://github.com/pypa/manylinux?tab=readme-ov-file#manylinux_2_28-almalinux-8-based

Debian 10+
Ubuntu 18.10+
Fedora 29+
CentOS/RHEL 8+

There's also an older version which supports x86 and even older distros - dockcross/manylinux2014-x86
https://github.com/pypa/manylinux?tab=readme-ov-file#manylinux2014-centos-7-based-glibc-217

Debian 8+
Ubuntu 13.10+
Fedora 19+
RHEL 7+

[jazdw]

The best I could find so far was distrowatch.com. It is not a matrix and one has to search through distros themself.

Sorry I was more talking about a compatibility matrix of jssc versions and glibc/distros that they support. But yeah I had forgotten about distrowatch as a good source for looking up glibc versions for distros, so thanks.

[tresf]

The best I could find so far was distrowatch.com. It is not a matrix and one has to search through distros themself.

Sorry I was more talking about a compatibility matrix of jssc versions and glibc/distros that they support. But yeah I had forgotten about distrowatch as a good source for looking up glibc versions for distros, so thanks.

If my logic is correct (summarized for Linux x64):

Version	Minimum GLIBC Version
2.10.1-alpha1	2.35
2.10.0	2.35
2.9.6	2.3
2.9.5	2.3
2.9.4	2.4
2.9.3	2.4
2.9.2	2.4
2.9.1	2.4
2.9.0	2.4
2.8.0	2.4
2.6.0	2.4
2.5.0	2.4
0.9.0	2.4

Show all architectures

2.10.1-alpha1:
- linux_32: GLIBC_2.35
- linux_64: GLIBC_2.35
- linux_arm: GLIBC_2.4
- linux_arm64: GLIBC_2.17
- linux_ppc: GLIBC_2.35
- linux_riscv32: GLIBC_2.34
- linux_riscv64: GLIBC_2.34

2.10.0:
- linux_32: GLIBC_2.35
- linux_64: GLIBC_2.35
- linux_arm: GLIBC_2.4
- linux_arm64: GLIBC_2.17
- linux_ppc: GLIBC_2.35
- linux_riscv32: GLIBC_2.34
- linux_riscv64: GLIBC_2.34

2.9.6:
- linux_32: GLIBC_2.3
- linux_64: GLIBC_2.3
- linux_arm: GLIBC_2.4
- linux_arm64: GLIBC_2.17
- linux_ppc: GLIBC_2.34
- linux_riscv32: GLIBC_2.34
- linux_riscv64: GLIBC_2.34

2.9.5:
- linux_32: GLIBC_2.3
- linux_64: GLIBC_2.3
- linux_arm: GLIBC_2.4
- linux_arm64: GLIBC_2.17
- linux_ppc: GLIBC_2.34

2.9.4:
- linux_32: GLIBC_2.4
- linux_64: GLIBC_2.4
- linux_arm: GLIBC_2.4
- linux_arm64: GLIBC_2.17
- linux_ppc: GLIBC_2.17

2.9.3:
- linux_32: GLIBC_2.4
- linux_64: GLIBC_2.4
- linux_arm: GLIBC_2.4
- linux_arm64: GLIBC_2.17
- linux_ppc: GLIBC_2.17

2.9.2:
- (BROKEN ARCHIVE?)

2.9.1:
- linux_32: GLIBC_2.4
- linux_64: GLIBC_2.4
- linux_arm: GLIBC_2.4
- linux_arm64: GLIBC_2.17
- linux_ppc: GLIBC_2.17

2.9.0:
- linux_32: GLIBC_2.4
- linux_64: GLIBC_2.4
- linux_arm: GLIBC_2.4
- linux_arm64: GLIBC_2.17
- linux_ppc: GLIBC_2.17

2.8.0:
- linux_armhf: GLIBC_2.4
- linux_armsf: GLIBC_2.4
- linux_x86_64: GLIBC_2.2.5
- linux_x86: GLIBC_2.1.3

2.6.0:
- linux_armhf: GLIBC_2.4
- linux_armsf: GLIBC_2.4
- linux_x86_64: GLIBC_2.2.5
- linux_x86: GLIBC_2.1.3

2.5.0:
- linux_armhf: GLIBC_2.4
- linux_armsf: GLIBC_2.4
- linux_x86_64: GLIBC_2.2.5
- linux_x86: GLIBC_2.15

0.9.0:
- linux_x86_64: GLIBC_2.4
- linux_x86: GLIBC_2.4

Source: https://gist.github.com/tresf/b00fd445ca90742b09af1b315d092eae

[jazdw]

Thanks for putting that together @tresf Big jump from 2.3 to 2.35

[tresf]

Thanks for putting that together @tresf Big jump from 2.3 to 2.35

Yeah it sure is.

Reading some dockcross issues it seems like the dockcross/manylinux_xxx images can be used to build a library compatible with many older distros.

If we can make a small change like this to our CI to yield better backwards compatibility, I think this is a great idea. As a comparison, I believe our macOS builds are good dating back 12 years and our Windows builds are good dating back over 20 years (IIRC, they'll still run on XP SP0), so I think this adding better backwards compatibility for Linux is well justified assuming it doesn't break any of our native build logic (C++ code, cmake scripts, etc).

[pietrygamat]

@jazdw, we have pushed the re-built artifacts to Maven central as a release 2.10.1 - should be available there soon.