Skip to content

jxlpy: Add version 0.9.5 - #3039

Draft
luhenry wants to merge 5 commits into
mainfrom
jxlpy
Draft

luhenry wants to merge 5 commits into
mainfrom
jxlpy

Conversation

@luhenry

@luhenry luhenry commented Oct 13, 2026 •

Copy link
Copy Markdown
Member

Compiles 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 in CIBW_BEFORE_ALL, same as upstream's own wheel job.

Differs from upstream

  • Relies on cibuildwheel's default repair step instead of a manual auditwheel repair invocation - cibuildwheel already runs one.

Testing

  • No upstream test suite (only examples/*.py); runs the same encode/decode round trip as examples/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_request run does the real riscv64 build.

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.
luhenry added a commit that referenced this pull request Oct 13, 2026
@luhenry
luhenry marked this pull request as draft October 14, 2026 11:35
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.

luhenry commented Oct 16, 2026 •

Copy link
Copy Markdown
Member Author

Diagnosed the two genuine failures (cp312, cp314 — the cp310/cp311/cp313 legs showing cancelled are unrelated runner-pool starvation, no action needed there).

Root cause: both failing legs die at the identical point in CIBW_BEFORE_ALL_LINUX's libjxl build — not in jxlpy's own extension, and not interpreter-specific:

/usr/bin/ld: lib/libjxl_cms.so.0.10.1: undefined reference to
  `skcms_private::baseline::run_program(...)'
collect2: error: ld returned 1 exit status
gmake[2]: *** [CMakeFiles/encode_oneshot.dir/build.make:104: encode_oneshot] Error 1

This happens while linking libjxl's own examples/encode_oneshot, a toolchain/ABI issue building vendored skcms on riscv64 that's internal to libjxl v0.10.1, unrelated to jxlpy. Since the CIBW_BEFORE_ALL_LINUX cmake invocation is identical across the whole matrix, this would have hit cp310/cp311/cp313 too had they not been cancelled first — it's a single shared root cause, not two distinct ones.

Fix: the three libjxl example executables (decode_oneshot, decode_progressive, encode_oneshot) are never used — setup.py's extra_link_args only needs -ljxl -ljxl_threads, built and installed well before the examples step. They're gated by JPEGXL_ENABLE_EXAMPLES (default ON, and not among the already-disabled BENCHMARK/TOOLS/DEVTOOLS flags). Added -DJPEGXL_ENABLE_EXAMPLES=OFF alongside those, which skips the broken example link entirely without touching libjxl/skcms source or the LIBJXL_TAG pin.

Pushed as bced3b17e (rebased to 65a87f5d1 after a queue:/merge commit landed on the branch in the meantime). Re-running CI now.

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.

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