Description
The prebuilt Linux artifacts published for rive_native are built against a
glibc 2.38 / GCC 13 toolchain, and they reference symbols that do not exist in
older glibc. Two consequences, the first of which I think is the more
important one:
- A Flutter Linux app depending on
rive cannot be built on Ubuntu 22.04
at all. The link fails — this is not a runtime floor that a downstream
project can choose to accept, it is a hard build-time requirement on the
build host.
- Apps built on a new enough host inherit a runtime floor of GLIBC_2.38 /
GLIBCXX_3.4.32, because those requirements are baked into the prebuilt
static libraries before the app's build starts.
Together these mean rive currently requires Ubuntu 24.04+ / Fedora 39+ /
Debian 13+ both to build against and to run on, and excludes every enterprise
and LTS distribution still in wide use — including the current Debian stable
and the previous Ubuntu LTS:
| Distribution |
glibc |
libstdc++ |
Builds? |
Runs? |
| RHEL / Rocky / Alma 9 |
2.34 |
GLIBCXX_3.4.29 |
no |
no |
| Ubuntu 22.04 LTS (supported to 2027) |
2.35 |
GLIBCXX_3.4.30 |
no |
no |
| Debian 12 (bookworm) |
2.36 |
GLIBCXX_3.4.30 |
no |
no |
| Ubuntu 24.04 LTS |
2.39 |
GLIBCXX_3.4.33 |
yes |
yes |
The build failure
Building a Flutter Linux release on ubuntu-22.04 (glibc 2.35, GitHub Actions
runner), Flutter 3.44.8, rive 0.14.8 → rive_native 0.1.8:
/usr/bin/ld: plugins/rive_native/librive_native_plugin.so: undefined reference to `__isoc23_strtoull'
/usr/bin/ld: plugins/rive_native/librive_native_plugin.so: undefined reference to `__isoc23_strtoll'
/usr/bin/ld: plugins/rive_native/librive_native_plugin.so: undefined reference to `__isoc23_strtol'
/usr/bin/ld: plugins/rive_native/librive_native_plugin.so: undefined reference to `__isoc23_strtoul'
/usr/bin/ld: plugins/rive_native/librive_native_plugin.so: undefined reference to `__isoc23_sscanf'
/usr/bin/ld: plugins/rive_native/librive_native_plugin.so: undefined reference to `std::ios_base_library_init()'
clang: error: linker command failed with exit code 1
__isoc23_* are the C23 header redirects glibc introduced in 2.38, and
std::ios_base_library_init() is GLIBCXX_3.4.32, i.e. GCC 13's libstdc++.
Neither exists on 22.04, so the link cannot resolve them.
Where the requirements come from
Verifiable from your published artifacts alone — no application code involved:
curl -sSLO "https://rive-flutter-artifacts.rive.app/rive_native_versions/0.1.8%2B1/rive_native_artifacts_linux.zip"
unzip -q rive_native_artifacts_linux.zip -d rive_linux
cd rive_linux/lib/release
$ for f in librive.a librive_pls_renderer.a librive_harfbuzz.a libluau_vm.a; do
printf '%-24s %s\n' "$f" "$(strings -a $f | grep -o '__isoc23_[a-z]*' | sort -u | tr '\n' ' ')"
done
librive.a __isoc23_strtol
librive_pls_renderer.a __isoc23_sscanf
librive_harfbuzz.a __isoc23_strtol __isoc23_strtoul
libluau_vm.a __isoc23_strtoll __isoc23_strtoul __isoc23_strtoull
$ for f in librive.a librive_native.a librive_pls_renderer.a librive_yoga.a; do
printf '%-24s %s\n' "$f" "$(strings -a $f | grep -c '_ZSt21ios_base_library_initv')"
done
librive.a 93
librive_native.a 1
librive_pls_renderer.a 1
librive_yoga.a 1
The shared build shipped in the same archive shows the resulting floor
directly:
$ objdump -p rive_linux/lib/debug_shared/librive_native.so \
| grep -oE 'GLIBC(XX)?_[0-9][0-9.]*' | sort -Vu | tail -4
GLIBC_2.34
GLIBC_2.35
GLIBC_2.38
GLIBCXX_3.4.32
Why this can't be worked around downstream
Building the application on an older toolchain is precisely what fails —
the references come from the prebuilt .a files that linux/CMakeLists.txt
links from bin/lib/release/, so they are present regardless of the app's own
compiler. -static-libstdc++ would address the GLIBCXX half but not the glibc
symbol versions.
That leaves building rive_native from source (bin/setup.dart --build) in
CI, or dropping Rive on Linux. Both are considerably more costly than a change
to how the artifacts are produced.
Request
Please build the Linux rive_native artifacts against an older sysroot.
manylinux_2_28 (glibc 2.28) is the usual baseline for redistributable native
SDKs and would cover every distribution in the table above; even glibc 2.31
(Ubuntu 20.04) would resolve all of the failing cases.
Happy to test a candidate build against RHEL 9 and Ubuntu 22.04 if useful.
Environment
rive 0.14.8, rive_native 0.1.8 (artifacts 0.1.8+1)
- Flutter 3.44.8, Linux x86_64 desktop release build
- Build host: GitHub Actions
ubuntu-22.04; also reproduced as a runtime
failure on Rocky Linux 9.8 (glibc 2.34) with artifacts built on 24.04
Possibly related: #613 (whether Linux is officially supported) — the answer
affects how these artifacts should be targeted.
Description
The prebuilt Linux artifacts published for
rive_nativeare built against aglibc 2.38 / GCC 13 toolchain, and they reference symbols that do not exist in
older glibc. Two consequences, the first of which I think is the more
important one:
rivecannot be built on Ubuntu 22.04at all. The link fails — this is not a runtime floor that a downstream
project can choose to accept, it is a hard build-time requirement on the
build host.
GLIBCXX_3.4.32, because those requirements are baked into the prebuilt
static libraries before the app's build starts.
Together these mean
rivecurrently requires Ubuntu 24.04+ / Fedora 39+ /Debian 13+ both to build against and to run on, and excludes every enterprise
and LTS distribution still in wide use — including the current Debian stable
and the previous Ubuntu LTS:
The build failure
Building a Flutter Linux release on
ubuntu-22.04(glibc 2.35, GitHub Actionsrunner), Flutter 3.44.8,
rive0.14.8 →rive_native0.1.8:__isoc23_*are the C23 header redirects glibc introduced in 2.38, andstd::ios_base_library_init()isGLIBCXX_3.4.32, i.e. GCC 13's libstdc++.Neither exists on 22.04, so the link cannot resolve them.
Where the requirements come from
Verifiable from your published artifacts alone — no application code involved:
The shared build shipped in the same archive shows the resulting floor
directly:
Why this can't be worked around downstream
Building the application on an older toolchain is precisely what fails —
the references come from the prebuilt
.afiles thatlinux/CMakeLists.txtlinks from
bin/lib/release/, so they are present regardless of the app's owncompiler.
-static-libstdc++would address the GLIBCXX half but not the glibcsymbol versions.
That leaves building
rive_nativefrom source (bin/setup.dart --build) inCI, or dropping Rive on Linux. Both are considerably more costly than a change
to how the artifacts are produced.
Request
Please build the Linux
rive_nativeartifacts against an older sysroot.manylinux_2_28(glibc 2.28) is the usual baseline for redistributable nativeSDKs and would cover every distribution in the table above; even glibc 2.31
(Ubuntu 20.04) would resolve all of the failing cases.
Happy to test a candidate build against RHEL 9 and Ubuntu 22.04 if useful.
Environment
rive0.14.8,rive_native0.1.8 (artifacts0.1.8+1)ubuntu-22.04; also reproduced as a runtimefailure on Rocky Linux 9.8 (glibc 2.34) with artifacts built on 24.04
Possibly related: #613 (whether Linux is officially supported) — the answer
affects how these artifacts should be targeted.