The Linux floor is the runtime's, not the build host's — 2026-10-06

A measurement from the engineering record. It corrects the known issue "The Linux wheel misses RHEL 9 by one glibc minor", whose stated closer — build inside a manylinux_2_34 container — would not have closed it.

The question

The Linux wheel is tagged manylinux_2_35. Ubuntu 22.04 and Debian 12 install it; RHEL 9 and its rebuilds, at glibc 2.34, are declined by pip. The issue, and README's platform table with it, said the floor was the build host's (ubuntu-22.04, glibc 2.35) and that building inside a manylinux_2_34 container would reach 2.34. The round that set out to do that measured first.

What was measured

The two Linux wheels of release 1.11.0, downloaded from the release and read with objdump -T inside a quay.io/pypa/manylinux_2_34_aarch64 container (AlmaLinux 9.8, glibc 2.34, libstdc++ from GCC 11):

Both architectures read the same. The two runtime libraries are copied unchanged from the toolchain's modular/lib by bundle_artifact.py, and the toolchain's own copies carry the same requirements, so the wheel inherits them from Modular's build of the runtime, not from the runner. The m0serve binary itself, built on a 2.35 host, requires only 2.34.

Two consequences:

• A manylinux_2_34 build would not lower the tag. wheel_tag.py takes the strictest floor across the staged files, and libAsyncRTRuntimeGlobals.so would still say 2.35. The build log has said so at every release, in the tag script's note that the floors differ and which file set the strictest; nobody read it against the issue.
• Even relabelled, the wheel would not run on RHEL 9. The runtime needs GLIBCXX_3.4.30, which is GCC 12's libstdc++; RHEL 9 ships GCC 11's (3.4.29) as its system library, and its gcc-toolsets add a newer compiler without replacing it. pip refusing the wheel on the glibc tag is, for RHEL 9, the right answer reached by accident.

The compiler meets the same wall: in that container uv sync installed the pinned toolchain, and mojo --version failed with GLIBCXX_3.4.30' not found. The toolchain's manylinux_2_34 tag is a glibc promise, not a libstdc++ one.

What was decided

Nothing to build. The issue stays open with its cause corrected and a closer that can be read off a future release's wheel: when libAsyncRTRuntimeGlobals.so needs no symbol above GLIBC_2.34 and libKGENCompilerRTShared.so none above GLIBCXX_3.4.29, the measured tag drops to manylinux_2_34 on its own and RHEL 9 is reached, and both facts are one objdump -T per file on the wheel's _lib/. The tag script now names the file that set the floor on every run rather than only when floors differ, so the next person asking the question reads the answer where the wheel is built. Bundling a libstdc++ was considered and not done: it would meet the GLIBCXX half and not the glibc half, and a wheel that ships the C++ runtime is a different promise than the one the consume jobs prove.