Conversation
Builds the shiboken6 module wheel from pyside/pyside-setup's git checkout. shiboken6's own Python bindings are self-generated by shiboken6-generator (needs Qt6Core + libclang), so the workflow builds and pip-installs that first, using Rocky 10's AppStream clang-devel/llvm-devel/qt6-qtbase-devel packages instead of compiling LLVM/Clang or Qt from source.
…g from PyPI Rocky 10's riscv64 repos ship no patchelf package (gotcha 95), so pip installing the patchelf PyPI package builds NixOS/patchelf from source, which runs its own `make check` and fails 8/48 tests on riscv64. pyside-setup's build_patchelf() only needs the binary on PATH, so fetch NixOS/patchelf's own riscv64 release asset instead.
pyside-setup defaults to the Ninja CMake generator on Linux (_AVAILABLE_MKSPECS[0]), but no ninja binary is present in the manylinux_riscv64 image and upstream's requirements.txt doesn't list one either (their own CI images ship it). PyPI publishes a riscv64 ninja wheel, but CMake's generator search needs it on PATH, not just reachable via the venv's bin dir.
manylinux's CPython is built --disable-shared, so libpythonX.Y.a is installed under sysconfig's LIBPL (lib/pythonX.Y/config-*/), not LIBDIR or the Debian-style LIBDIR/MULTIARCH path that pyside-setup's build_info_collector.py searches, so its Python-library discovery fails. Symlink the static archive into LIBDIR where that search looks first; get_py_library() already accepts a static .a as a fallback.
…ball The previous symlink from sysconfig LIBPL was wrong: manylinux's finalize.sh strips every libpythonX.Y.a from lib/ to save space (before that, per its own build, the .a lives flat in LIBDIR, not under LIBPL), archiving them first into static-libs-for-embedding-only.tar.xz. Extracting that tarball puts libpython3.12.a back at the exact flat LIBDIR path build_info_collector.py's primary search checks first. Verified natively against the aarch64 manylinux_2_39 image (same finalize.sh, same layout) since riscv64 needs emulation locally.
PysideBuild.finalize_options() only fakes os.name to "nt" (to dodge distutils build.finalize_options' Windows-only --plat-name check) when cross-compiling or on macOS; on a native, non-cross-compiling Linux build --plat-name always hits that check and raises. auditwheel repair already retags the final wheel to manylinux_2_39_riscv64, and the shiboken6-generator wheel is never published, so the flag is not needed on either invocation.
shiboken6-generator's wheel declares shiboken6==6.11.2 as a runtime dependency, but shiboken6 is not built yet at this point (it is the very next step), so pip fails to resolve it. --no-deps breaks the cycle; the generator install here only needs its CLI tool and typesystem files for the following setup.py invocation.
luhenry
added a commit
that referenced
this pull request
Sep 10, 2026
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.
shiboken66.11.2Builds the shiboken6 Python binding support module from Qt for Python's
pyside-setupgit checkout (no sdist is published). Upstream publishes no riscv64 wheel.Mirrors upstream's own
setup.py bdist_wheel --build-type=shiboken6invocation.Differs from upstream
clang-devel/llvm-devel/qt6-qtbase-develpackages instead of upstream's prebuilt libclang/Qt installer - no riscv64 equivalent exists upstream.Matrix: single cp312 build, retagged cp310-abi3 by setup.py's own
--limited-api=yes(matches upstream's own wheel tag).Testing
import shiboken6smoke test (no functional test suite ships with this component upstream either).License: OK