Fails to launch - GLIBC_2.44

[Axi2433]

What problem does this solve?

So im using fedora 44 and beacuse GLIBC_2.44 is not in repositories of any stable distros a lot of them can't open them without much tinkering

here is the error it gives me when i tried using: APPIMAGE_EXTRACT_AND_RUN=1 ./FTHRClips-1.1.0-alpha-x86_64.appimage

qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
PySide6/__init__.py: Unable to import Shiboken from /tmp/appimage_extracted_.../base_library.zip, .../python3.14/lib-dynload, .../_internal: /lib64/libm.so.6: version `GLIBC_2.44' not found (required by .../python3.14/lib-dynload/math.cpython-314-x86_64-linux-gnu.so)
Traceback (most recent call last):
  ...
ImportError: /lib64/libm.so.6: version `GLIBC_2.44' not found (required by .../python3.14/lib-dynload/math.cpython-314-x86_64-linux-gnu.so)
[PYI-6967:ERROR] Failed to execute script 'pyi_rth_multiprocessing' due to unhandled exception!

Also here are my specs:

CPU: Ryzen 7 7800x3d
GPU: rtx 5070 (driver: 615.71.09)
RAM: 32 GB DDR5
DISK: 2 TB SSD NVME (1.6 free space)

Linux: Fedora 44
kernel: Linux 7.2.5-200.fc44.x86_64
DE: Kde plasma 6.7.5 (Wayland)

What would you like to see?

rebuild the PyInstaller bundle inside an older-baseline container (e.g. Debian oldstable, Ubuntu 20.04/22.04, or CentOS Stream via appimage-builder) so the resulting binary is linked against an older glibc and runs on current stable distros.

Alternatives you've considered

No response

[kalopsia-space]

This remains actionable. I have not found an older-glibc packaging fix on the maintained branch yet.

Please retest the current v1.1.1-alpha AppImage and include its SHA-256, ldd --version, distribution/version, and the exact bundled object that requests GLIBC_2.44. If the current artifact still has that requirement, the next fix is to rebuild from a documented older-glibc baseline and add a launch compatibility smoke test.

[Axi2433]

This remains actionable. I have not found an older-glibc packaging fix on the maintained branch yet.

Please retest the current v1.1.1-alpha AppImage and include its SHA-256, ldd --version, distribution/version, and the exact bundled object that requests GLIBC_2.44. If the current artifact still has that requirement, the next fix is to rebuild from a documented older-glibc baseline and add a launch compatibility smoke test.

1.1.1-alpha still fails and this time i didn't event wanted to launch as a process.

SHA-256: 12c0140d360e0ec1f8815b1ba167ba5ea21b6657be119345f375708e2c02c5f9 FTHRClips-1.1.1-alpha-x86_64_02f3ba9394badbdd4d7fecfe8e006715.appimage
ldd --version: ldd (GNU libc) 2.43
Distro:
NAME="Fedora Linux"
VERSION="44 (KDE Plasma Desktop Edition)"
RELEASE_TYPE=stable
ID=fedora
VERSION_ID=44
VERSION_CODENAME=""
PRETTY_NAME="Fedora Linux 44 (KDE Plasma Desktop Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:44"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f44/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=44
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=44
SUPPORT_END=2027-05-19
VARIANT="KDE Plasma Desktop Edition"
VARIANT_ID=kde
Object requiring GLIBC_2.44: _internal/python3.14/lib-dynload/math.cpython-314-x86_64-linux-gnu.so (same file as in v1.1.0-alpha)
Full log: As attachment

run-log.txt

[kalopsia-space]

I traced this to the published v1.1.1-alpha artifact being built from an older Linux-branch commit, before the older-glibc packaging fix landed.

The fix is now present on the maintained linux branch in commit d3f121638578908372b8ef722612f311c20aadba (merged PR #40). It:

• builds the AppImage on Ubuntu 22.04;
• enforces a GLIBC 2.35 ceiling over the frozen bundle and final AppImage;
• fails packaging if an object such as math.cpython-314-x86_64-linux-gnu.so requires a newer glibc; and
• runs this gate in CI.

The current linux branch CI run passed, including Linux AppImage (glibc baseline): https://github.com/FTHR-Community/FTHR-Clips/actions/runs/35547529431

The existing v1.1.1-alpha release cannot be considered fixed yet: its tag points to ce315ffc457295f262fce9abfc590d34ec86c4a8, and its published AppImage is the artifact that still requires GLIBC_2.44. A new AppImage must be built from the current linux branch and published as a new release (or the existing release must be deliberately replaced by a maintainer).