tflite-runtime: Add version 2.14.0 - #2154
Merged
Merged
Conversation
Builds the TensorFlow Lite interpreter's pybind11 extension for riscv64 the way
upstream's own pip recipe does, tensorflow/lite/tools/pip_package/build_pip_package_with_bazel.sh:
one bazel target, //tensorflow/lite/python/interpreter_wrapper:_pywrap_tensorflow_interpreter_wrapper,
copied next to interpreter.py and the metrics shims and packaged with
setup_with_binary.py. No TensorFlow core, no MLIR converter, no flex delegate.
2.14.0 is the last tflite-runtime release, so the build is the 2023 monorepo's:
bazel 6.1.0 in .bazelversion (7.5.0 is bootstrapped instead, since nothing on the
TensorFlow side gates it beyond a versions.check("1.0.0") minimum), XNNPACK
b9d4073a, whose riscv64 production microkernels are scalar-only, so neither RVV
nor its zvfh fp16 variant is compiled, and pybind11 2.10.4, which is what caps the
matrix at cp311. cp310 is the floor because the manylinux riscv64 image ships no
older interpreter.
The one riscv64 gap is hermetic Python: TensorFlow 2.14 takes both the Python and
the numpy headers from rules_python 0.23.1's downloaded interpreter, which has no
riscv64 build - and would be the wrong interpreter for the wheel even if it did.
Both repositories are overridden with the container's own CPython and its numpy
through bazel's --override_repository, so no patch to the checkout is needed.
Tested by running add.bin through the installed wheel's Interpreter and comparing
the result against three times the input.
luhenry
added a commit
that referenced
this pull request
Sep 21, 2026
Contributor
|
luhenry
added a commit
that referenced
this pull request
Sep 21, 2026
…-497 Both riscv64 legs built and tested on the first CI cycle, and the publish job dry-ran clean. The four gotchas are the reusable half of that port: a hermetic Python that predates riscv64 supplies both the Python and the numpy headers, so two repositories have to be stood in (494); a Bazel port's loading phase, including those overrides, rehearses on x86_64 in minutes even behind blocked egress (495); gotcha 420's XNNPACK fp16 define does not apply to a 2023 pin whose riscv64 production microkernels are scalar-only (496); and an upstream build script's own env hooks take the whole riscv64 delta, with the later flag cancelling one the script hardcodes (497).
luhenry
marked this pull request as ready for review
September 21, 2026 11:26
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.
tflite-runtime2.14.0Bazel builds one target, the TFLite interpreter's pybind11 extension, which is then packaged with
setup_with_binary.py: no TensorFlow core, no MLIR converter, no flex delegate. Upstream publishes no riscv64 wheel.Mirrors upstream's
build_pip_package_with_bazel.sh, driven through its ownCUSTOM_BAZEL_FLAGShook.Differs from upstream
.bazelversion's 6.1.0 - no riscv64 release binary exists for either, 7.5.0 is what this repo bootstraps, and TensorFlow's only gate is aversions.check("1.0.0")minimumpythonandpypi_numpyoverridden with the container's CPython and numpy - TensorFlow 2.14 takes both header sets from rules_python 0.23.1's hermetic interpreter, which has no riscv64 build and would be the wrong interpreter for the wheel regardless--nosubcommands- undoes the script's-s, which prints every compile commandMatrix: cp310/cp311; 2.14.0 is the last release and pins pybind11 2.10.4, which predates CPython 3.12, and the manylinux riscv64 image ships no interpreter below 3.10.
Testing
testdata/add.binthrough the installed wheel'sInterpreterand checks the output against three times the inputLicense: OK