Skip to content

Is glibc 2.35 required now? #190

Closed
Closed
Is glibc 2.35 required now?#190
Labels
compatibilityhelp wantedExtra attention is needed

Description

@jazdw
jazdw
opened on Jun 2, 2025

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]

Activity

  1. tresf commented on Jun 3, 2025

    @tresf
    tresf
    on Jun 3, 2025

    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

  2. pietrygamat commented on Jun 3, 2025

    @pietrygamat
    pietrygamat
    on Jun 3, 2025
    Collaborator

    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 ;).

  3. tresf commented on Jun 3, 2025

    @tresf
    tresf
    on Jun 3, 2025

    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.

  4. jazdw commented on Jun 3, 2025

    @jazdw
    jazdw
    on Jun 3, 2025
    Author

    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?

  5. hiddenalpha commented on Jun 3, 2025

    @hiddenalpha
    hiddenalpha
    on Jun 3, 2025

    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.

  6. tresf commented on Jun 3, 2025

    @tresf
    tresf
    on Jun 3, 2025

    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

  7. jazdw commented on Jun 4, 2025

    @jazdw
    jazdw
    on Jun 4, 2025
    Author

    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+

  8. jazdw commented on Jun 4, 2025

    @jazdw
    jazdw
    on Jun 4, 2025
    Author

    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.

  9. tresf commented on Jun 4, 2025

    @tresf
    tresf
    on Jun 4, 2025

    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

  10. jazdw commented on Jun 5, 2025

    @jazdw
    jazdw
    on Jun 5, 2025
    Author

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

  11. tresf commented on Jun 5, 2025

    @tresf
    tresf
    on Jun 5, 2025

    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).

  12. tresf
    added
    help wantedExtra attention is needed
    compatibility
    on Jun 5, 2025

  13. pietrygamat commented on Jun 10, 2025

    @pietrygamat
    pietrygamat
    on Jun 10, 2025
    Collaborator

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

  14. tresf commented on Jun 10, 2025

    @tresf
    tresf
    on Jun 10, 2025

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

    I re-ran the script and it comes back with GLIBC_2.3 for Linux Intel 32-bit and 64-bit now (versus GLIBC_2.35). If @jazdw is busy, I'd happily test on 20.04 (I have some testing to do this week, so I may just go ahead and do this today anyway).

  15. tresf commented on Jun 10, 2025

    @tresf
    tresf
    on Jun 10, 2025

    Tested Ubuntu 16.04, 20.04 and JSSC 2.10.1 works fine with both. Closed via #191.

  16. tresf
    closed this as completedon Jun 10, 2025

  17. jazdw commented on Jun 10, 2025

    @jazdw
    jazdw
    on Jun 10, 2025
    Author

    Thank you both for looking at this and getting a new build out. Everything works for me on Ubuntu 20.04 now. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    compatibilityhelp wantedExtra attention is needed

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions