Skip to content

tables: add build-tables.yml for riscv64 wheels - #1010

Merged
luhenry merged 5 commits into
mainfrom
tables
Sep 6, 2026
Merged

tables: add build-tables.yml for riscv64 wheels#1010
luhenry merged 5 commits into
mainfrom
tables

Conversation

@luhenry

@luhenry luhenry commented Sep 6, 2026

Copy link
Copy Markdown
Member

Cython wrapper around HDF5, with its own bundled blosc/bzip2 codec filters. Upstream publishes no riscv64 wheel.

Mirrors upstream's wheels.yml.

Differs from upstream

  • Neutralized before-build (hash-pinned, no riscv64 wheels) - build-system.requires resolves normally.
  • Builds HDF5 2.2.0 from source in before-all - mirrors upstream's own get_hdf5.sh, no riscv64 cache image.
  • auditwheel repair --exclude libblosc2.so* - blosc2's shared lib comes from our own blosc2 wheel, loaded via tables' own ctypes hook.
  • Build floor is cp312, not cp311 - numexpr (a runtime dep) has no cp311 riscv64 build on this registry yet.

Testing

  • same as upstream

License: Wheel vendors HDF5 (BSD-style) and bzip2 (bzip2 license); upstream's license-files glob already ships HDF5's text, this adds bzip2's alongside it.

Builds HDF5 2.2.0 from source (mirroring PyTables' own get_hdf5.sh) and
links the bundled blosc2 shared lib from our own riscv64 blosc2 wheel.
The vendored hdf5-blosc2/src/blosc2_filter.c (a plain copy, not a git
submodule) uses BLOSC2_MAX_DIM, which c-blosc2 3.0 renamed to
B2ND_MAX_DIM. Any blosc2 satisfying this project's own floor
(>= 2.3.0) that bundles that newer c-blosc2 -- including the 4.11.0
this registry publishes, the only riscv64 build available here --
fails to compile it. Backports the fix PyTables already carries on
master (not yet in a tagged release) for the same reason: switching
hdf5-blosc2 to a real submodule pinned past the rename.
tables.tests.test_basics.ThreadingTestCase.test opens the same file
from 10 threads and reads an array from each without full locking.
It fails intermittently on our riscv64 runners every run so far: a
NoSuchNodeError under classic GIL Python (cp312/313/314), a segfault
inside tables.utilsextension under free-threaded cp314t. Not new or
riscv64-specific -- PyTables/PyTables#946 reported the same "one
thread's queue entry isn't 'OK'" shape on x86_64 in 2022; it stopped
reproducing for the reporter and the maintainer couldn't reproduce it
either, so it was closed with no code fix. Skip it rather than block
every run on a pre-existing, timing-sensitive race nobody has a fix
for.
The cp314t leg can't use the stable ABI, so its extensions are tagged
"*.cpython-314t-riscv64-linux-gnu.so" rather than "*.abi3.so". The
post-build check hardcoded the abi3 suffix, so once the test suite
itself got past ThreadingTestCase, cp314t's wheel failed this check
with an empty found_ext set. Match on the module name instead of the
suffix so the same check works for both legs.
pyproject.toml's explicit license-files list only ever named
LICENSE.txt, so nothing else ever reached dist-info/licenses/ --
confirmed against the real PyPI wheel, which has the same gap. Extend
it to the licences of what this build actually compiles in or links
(c-blosc + its bundled LZ4/zlib/zstd, HDF5, h5py, and our own added
BZIP2.txt), not the whole upstream LICENSES/ directory: most of the
rest of it (FastLZ, Snappy, Windows-only shims, the docs theme) covers
content this build never ships, and a wildcard would misdeclare it.
Update the post-build check to assert the exact set so a future patch
that stops applying fails loudly instead of silently shipping fewer
licences.
@luhenry
luhenry merged commit 538d358 into main Sep 6, 2026
7 checks passed
@luhenry
luhenry deleted the tables branch September 6, 2026 18:41
@luhenry luhenry linked an issue Sep 6, 2026 that may be closed by this pull request
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.

tables riscv64 support

1 participant