runai-model-streamer: Add version 0.16.1 - #2267
Merged
Merged
Conversation
luhenry
added a commit
that referenced
this pull request
Sep 24, 2026
Found upstream (run-ai/runai-model-streamer), filled home/repo, and recorded the feasibility findings in the notes.
Contributor
|
Add build-runai-model-streamer.yml, docs/packages/runai-model-streamer.yaml and the riscv64 toolchain patch for version 0.16.1.
…ve compiler cpp/toolchain/rules.bzl resolves gcc/g++/ar/ld/etc as /usr/bin/<arch>-linux-gnu-<tool>, the Debian cross-toolchain naming upstream's own x86_64/aarch64 devcontainer ships as real binaries. The riscv64 build runs natively inside manylinux_2_39_riscv64 (Rocky-based, not cross-compiling), whose compiler is the unprefixed system gcc/g++, so those paths didn't exist: analysis succeeded (repository_ctx.execute() tolerates a missing binary and just returns empty stdout for gcc-dumpversion), but every compile action then failed execvp'ing a gcc that was never there. Symlinking the expected triplet name onto the real tool fixes it without touching upstream's generic, unmodified toolchain code.
luhenry
force-pushed
the
runai-model-streamer
branch
from
September 24, 2026 07:00
501ebf8 to
a70e47d
Compare
…iplet Job 107529099711 (run 35967283033) failed bazel build streamer:libstreamer.so with an absolute-path-inclusion error on /usr/lib/gcc/riscv64-redhat-linux/14/include/stddef.h, a header gcc includes via its own builtin search path. cpp/toolchain/template/toolchain.bzl declares cxx_builtin_include_directories from the same <arch>-linux-gnu naming convention used for the toolchain's tool paths (/usr/bin/<arch>-linux-gnu-<tool>). That equals the compiler's own -dumpmachine for a genuine Debian cross-gcc (upstream's own devcontainer), but manylinux_2_39_riscv64's gcc is Red Hat's *native* riscv64-redhat-linux build, only reachable under the expected name via the tool symlinks already added in a70e47d -- its own compiled-in include search path still uses its real vendor triplet regardless of the invocation name, so aliasing a directory under a different name (which I tried first and reverted) changes nothing: gcc never looks there. Confirmed by inspecting the real image's filesystem directly (docker create/export, no riscv64 execution needed): only /usr/lib/gcc/riscv64-redhat-linux exists (no .../riscv64-linux-gnu), and the same RH-vs-Debian triplet split also applies to libstdc++'s per-target headers (/usr/include/c++/14/riscv64-redhat-linux vs the Debian-style /usr/include/riscv64-linux-gnu/c++/14 the toolchain config assumes), which would have surfaced as the same class of failure on the first C++ compile. Patch 0002 threads gcc's actual -dumpmachine output down as gcc_machine and uses it for cxx_builtin_include_directories specifically (tool_paths keeps the naming-convention triplet the workflow's symlinks provide). x86_64 and aarch64 are unaffected: a real cross-gcc's -dumpmachine already equals that convention. Verified patches 0001+0002 apply cleanly in sequence against a fresh v0.16.1 checkout, matching the workflow's git apply step, and pass ci_scripts/check_patch.py's Upstream-Status validation. Could not exercise the actual bazel build: manylinux_2_39_riscv64 is a riscv64 image and this host has no riscv64 qemu/binfmt registered (confirmed by a failed docker run), so verification is limited to patch-apply and direct toolchain-source/filesystem inspection, not a real bazel run.
… -l:libstdc++.a cpp/toolchain/template/toolchain.bzl's default_linker_flags feature always passes -static-libstdc++ -l:libstdc++.a for every link action on every arch (a deliberate upstream choice, not something riscv64-specific to work around). quay.io/pypa/manylinux_2_39_riscv64 has no libstdc++.a: verified by exporting the real image's filesystem (docker create/export), which has only usr/lib64/libstdc++.so.6* and usr/lib/gcc/riscv64-redhat-linux/14/ libstdc++.so, no .a. The archive ships in Rocky 10's CRB repo as libstdc++-static (riscv64, 14.3.1-4.4.el10, confirmed against CRB's primary.xml.gz) -- CRB is already enabled in this image's repo config, so this is a one-package dnf install, not a toolchain/BUILD patch. No change needed to the gpl_sources job: libstdc++-static's source RPM is gcc-14.3.1-4.4.el10.src.rpm, already covered by the existing `packages: gcc` collect-gpl-sources input.
The cp312-cp312 build image's Python venv has no setuptools preinstalled (newer CPython/pip dropped the implicit bootstrap), so setup.py's own `from setuptools import setup, find_packages` failed with ModuleNotFoundError right after bazel finished building libstreamer.so. Only `wheel` was being pip-installed; add setuptools alongside it.
setup.py bdist_wheel was tagging the wheel manylinux2014_riscv64, but
manylinux2014 (glibc 2.17) predates riscv64 glibc support entirely -
it's not a platform tag pip/uv recognize as valid for this arch, unlike
the manylinux_2_39_riscv64 tag every other package in this repo uses
(matching the actual quay.io/pypa/manylinux_2_39_riscv64 build image).
The test job's `uv pip install` refused the wheel outright:
error: Failed to determine installation plan
cause: A path (wheelhouse/runai_model_streamer-0.16.1-py3-none-manylinux2014_riscv64.whl) dependency is incompatible with the current platform
hint: The wheel is compatible with Linux (manylinux2014_riscv64), but you're on Linux (manylinux_2_39_riscv64)
… install
requirements.dev pins numpy==1.24.4, which ships no riscv64 wheel and fails
to build from source under Python >=3.12:
ModuleNotFoundError: No module named 'distutils'
(numpy 1.24.4's legacy setup.py needs distutils, removed from the stdlib in
3.12.) Our registry has riscv64 wheels for numpy 2.5.3 across cp312-cp314t,
so override the pin via a uv override file instead of patching upstream's
requirements.dev - nothing in this test suite depends on numpy 1.24.4
specifically.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
runai-model-streamer0.16.1Compiles
libstreamer.so, the C++ core that Run:ai Model Streamer's ctypes wrapper loads to stream tensors from local files into memory. Upstream publishes no riscv64 wheel.Mirrors upstream's own Bazel build (
cpp/toolchain,py/runai_model_streamer/Makefile'ssetup.py bdist_wheel --plat-name), narrowed to riscv64.Differs from upstream
build-ray.yml)Testing
file_streamer/safetensors_streamerunit suite against the installed wheel; its object-storage test fixtures are copied in from the checkout since setup.py never ships themLicense: OK
Patches
0001-toolchain-add-riscv64-as-a-supported-architecture.patch- To upstream.configure_toolchain()'sARCHITECTURESlist and its.bazelrcblock hardcode x86_64/aarch64 only; reproduces on any architecture.