Repository navigation
Conversation
jxlpy (JPEG XL / libjxl Cython bindings) builds a C++ extension that links against a system-installed libjxl, which the manylinux_riscv64 image doesn't ship. Mirror upstream's own packaging.yml: build libjxl from source via CMake in CIBW_BEFORE_ALL (same v0.10.1 tag, same disabled TESTING/BENCHMARK/TOOLS/DEVTOOLS flags), install to /usr/local, and let cibuildwheel's default auditwheel repair bundle the resulting libjxl/libjxl_threads/brotli shared libraries. No SIMD hard requirement: no -march flag is passed anywhere in this build, so vendored highway collapses to its portable EMU128/SCALAR baseline on riscv64 rather than requiring RVV hardware.
cp312 and cp314 CI both fail identically at the CIBW_BEFORE_ALL_LINUX libjxl build step: linking examples/encode_oneshot fails with "undefined reference to skcms_private::baseline::run_program" against libjxl_cms.so. This is a libjxl/skcms toolchain issue on riscv64 in the example build, unrelated to jxlpy's cp310/cp311/cp313 (the cancelled legs would have hit it too - it is not interpreter-specific). The three examples (decode_oneshot, decode_progressive, encode_oneshot) are never used: setup.py only links -ljxl -ljxl_threads. Pass -DJPEGXL_ENABLE_EXAMPLES=OFF alongside the existing BENCHMARK/TOOLS/DEVTOOLS=OFF flags to skip building them.
|
Diagnosed the two genuine failures (cp312, cp314 — the cp310/cp311/cp313 legs showing Root cause: both failing legs die at the identical point in This happens while linking libjxl's own Fix: the three libjxl example executables ( Pushed as |
The folded >- scalar turned the newline after python -c " into a leading space before the first statement, which CPython 3.10-3.13 reject with IndentationError. Keep the first statement on the same line as the opening quote.
git checkout only moves the superproject tree; it never re-syncs already-cloned submodules, so --recursive's initial clone leaves third_party/skcms (and the other submodules) pinned to libjxl's default branch instead of v0.10.1. That newer skcms restructured its internal namespacing, so the cp310 build linked libjxl_cms.so against a mismatched skcms and failed at import time with an undefined symbol (skcms_private::baseline::run_program) - riscv64-specific because it's the one path whose linkage shape changed between the two skcms commits. Add `git submodule update --init --recursive` after the tag checkout to fix it.
jxlpy0.9.5Compiles a Cython/C++ extension binding libjxl's encode/decode API. Upstream publishes no riscv64 wheel.
Mirrors upstream's
packaging.yml: builds libjxl v0.10.1 from source via CMake inCIBW_BEFORE_ALL, same as upstream's own wheel job.Differs from upstream
auditwheel repairinvocation - cibuildwheel already runs one.Testing
examples/*.py); runs the same encode/decode round trip asexamples/encode_simple.py+examples/decode_simple.py.License: Wheel bundles libjxl (BSD-3-Clause, built from source) plus its vendored highway (Apache-2.0), brotli (MIT) and skcms (BSD-3-Clause); upstream's own build ships no licence text for them, so this build adds it.
Not built locally (low disk); CI's
pull_requestrun does the real riscv64 build.