Linux: release binary needs GLIBCXX_3.4.35; testers' systems only have 3.4.33 #147

New issue

Closed

opened 2026-09-28 18:52:23 +00:00 by backspace119 · 0 comments

backspace119 commented

2026-09-28 18:52:23 +00:00

Owner

Reported by a tester: the newest Linux build won't start. It requires GLIBCXX_3.4.35 (libstdc++ from GCC 15), and their system's libstdc++ only goes up to GLIBCXX_3.4.33 (GCC 14 era: e.g. Ubuntu 24.10/25.04, Debian 13, Fedora 41).

To do before the next release.

Why

We build on CachyOS with the current GCC, so the binary picks up symbol versions from the newest libstdc++. make glibc-check guards the glibc floor (<= 2.38, via glibc_compat.h symver pins), but nothing checks the GLIBCXX / CXXABI floor, so a GCC update silently raised it.

Options

Ship libstdc++ (+ libgcc_s) in the tarball's lib/. The launcher already sets LD_LIBRARY_PATH=./lib. Quickest and robust; slightly bigger package. Must make sure every bundled plugin (CEF/dullahan, VLC, gstreamer) resolves the same copy.
Statically link libstdc++/libgcc (-static-libstdc++ -static-libgcc) for the viewer and the plugins we build. No runtime dependency, but check that no prebuilt 3p .so needs a newer libstdc++ from the system.
Build releases in an older toolchain container (e.g. GCC 13/14) to set a lower floor. Most "correct", but more CI work and C++20/23 features may differ.

Also

Extend make glibc-check (scripts; see the Linux portability notes) to report the max GLIBCXX_* / CXXABI_* version each packaged binary needs, and fail above a chosen floor (e.g. 3.4.30 = GCC 12, or 3.4.32 = GCC 13).
Check the prebuilt 3p libraries in packaged/lib too (objdump -T | grep GLIBCXX_).

Related: Linux portability work (glibc symver pins, x86-64-v4 ISA check).

**Reported by a tester:** the newest Linux build won't start. It requires `GLIBCXX_3.4.35` (libstdc++ from GCC 15), and their system's libstdc++ only goes up to `GLIBCXX_3.4.33` (GCC 14 era: e.g. Ubuntu 24.10/25.04, Debian 13, Fedora 41). **To do before the next release.** ## Why We build on CachyOS with the current GCC, so the binary picks up symbol versions from the newest libstdc++. `make glibc-check` guards the glibc floor (<= 2.38, via `glibc_compat.h` symver pins), but nothing checks the **GLIBCXX** / **CXXABI** floor, so a GCC update silently raised it. ## Options 1. **Ship libstdc++ (+ libgcc_s) in the tarball's `lib/`.** The launcher already sets `LD_LIBRARY_PATH=./lib`. Quickest and robust; slightly bigger package. Must make sure every bundled plugin (CEF/dullahan, VLC, gstreamer) resolves the same copy. 2. **Statically link libstdc++/libgcc** (`-static-libstdc++ -static-libgcc`) for the viewer and the plugins we build. No runtime dependency, but check that no prebuilt 3p .so needs a newer libstdc++ from the system. 3. **Build releases in an older toolchain container** (e.g. GCC 13/14) to set a lower floor. Most "correct", but more CI work and C++20/23 features may differ. ## Also - Extend `make glibc-check` (scripts; see the Linux portability notes) to report the max `GLIBCXX_*` / `CXXABI_*` version each packaged binary needs, and fail above a chosen floor (e.g. 3.4.30 = GCC 12, or 3.4.32 = GCC 13). - Check the prebuilt 3p libraries in `packaged/lib` too (`objdump -T | grep GLIBCXX_`). Related: Linux portability work (glibc symver pins, x86-64-v4 ISA check).

backspace119 referenced this issue

2026-09-28 23:25:10 +00:00

Move CI runners off the workstation onto a build server #103

backspace119 referenced this issue from a commit

2026-09-28 23:25:44 +00:00

Build: GLIBCXX floor check, enforced in CI

backspace119 closed this issue

2026-09-28 23:25:44 +00:00