Skip to content

pyopen-wakeword: Add version 1.1.0 - #4316

Draft
luhenry wants to merge 14 commits into
mainfrom
pyopen-wakeword
Draft

luhenry wants to merge 14 commits into
mainfrom
pyopen-wakeword

Conversation

@luhenry

@luhenry luhenry commented Nov 2, 2026 •

Copy link
Copy Markdown
Member

Builds libtensorflowlite_c.so via Bazel from tensorflow/tensorflow v2.17.1 and bundles it in the wheel. Upstream publishes no riscv64 wheel.

Mirrors upstream's publish.yml, substituting a from-source Bazel build of //tensorflow/lite/c:libtensorflowlite_c.so for the prebuilt binary upstream downloads from tphakala/tflite_c (no riscv64 binary there).

Differs from upstream

  • Builds libtensorflowlite_c.so itself via Bazel - no riscv64 binary exists to download
  • Reuses the Bazel-on-riscv64 bootstrap already proven by the tflite-runtime port

Matrix: single build (py3-none wheel, no interpreter matrix)

Testing

  • same as upstream (pytest tests against the installed wheel)

License: Wheel bundles a TensorFlow Lite C API shared library (Apache-2.0); upstream ships no licence text for it either, across all its platform wheels.

CI running on riscv64; results pending.

Upstream ships no Python extension; it vendors a per-platform prebuilt
libtensorflowlite_c.so from https://github.com/tphakala/tflite_c, which
publishes no riscv64 binary. This builds that same Bazel target
(//tensorflow/lite/c:libtensorflowlite_c.so) from tensorflow/tensorflow
v2.17.1 -- the version upstream's own vendored binaries are built from --
reusing the Bazel-on-riscv64 bootstrap already proven by the tflite-runtime
port, and bundles the result in place of the download.
luhenry added a commit that referenced this pull request Nov 2, 2026
numpy publishes no riscv64 wheel on PyPI, so --only-binary=:all: numpy
fails in both the build and test containers. Pass PIP_EXTRA_INDEX_URL
into them as build-tflite-runtime.yml does.
The Bazel build of libtensorflowlite_c.so (via XNNPACK's vendored cpuinfo)
failed compiling src/riscv/linux/riscv-hw.c: fatal error: sys/hwprobe.h: No
such file or directory. manylinux_2_39_riscv64's glibc (2.39) predates that
header (added in glibc 2.40), but cpuinfo's riscv64 config unconditionally
needs it for vendor/uarch detection via the riscv_hwprobe(2) syscall. Shim the
header and the __riscv_hwprobe() wrapper over the raw syscall (number 258 per
Linux's scripts/syscall.tbl) so cpuinfo gets real hardware data from the
kernel instead of failing to build.
_publish-wheel.yml now requires a matrix input (main's "publish:
Validate effective wheel targets"), but this PR branch forked before
that landed and pyopen-wakeword has never been merged to main, so
build-pyopen-wakeword.yml never picked up the matching one-line update every
already-published package's workflow got. The merge ref combines the
new required-input _publish-wheel.yml with this branch's old
build-pyopen-wakeword.yml, so any run has failed startup with "Input matrix is
required, but not provided".

Pass it the same way the mass-update commit did for every other
package's publish job.
…root

The shim's header and object file were written to /tmp/override/hwprobe,
a path outside the tensorflow checkout. Passing it to every compilation
via a global --copt=-I works for the python/pypi_numpy overrides because
those are registered bazel repositories, but a bare absolute -I/--linkopt
path outside the execution root is rejected once a real source file
(tensorflow/lite/core/c/common.cc) is compiled:

  The include path '/tmp/override/hwprobe/include' references a path
  outside of the execution root.

Write the shim under a riscv_hwprobe/ directory inside the tensorflow
checkout instead, so the same files are part of the exec root and the
-I/--linkopt flags resolve to paths bazel actually allows.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant