Skip to content

libclang: add build-libclang.yml for riscv64 wheels - #866

Open
luhenry wants to merge 3 commits into
mainfrom
libclang
Open

libclang: add build-libclang.yml for riscv64 wheels#866
luhenry wants to merge 3 commits into
mainfrom
libclang

Conversation

@luhenry

@luhenry luhenry commented Sep 3, 2026

Copy link
Copy Markdown
Member

Compiles libclang.so from the LLVM 18.1.1 source release and packages it as the clang.cindex Python bindings wheel. Upstream publishes no riscv64 wheel.

Mirrors upstream's libclang-linux-amd64.yml/libclang-linux-aarch64.yml, narrowed to riscv64.

Differs from upstream

  • Builds natively in one docker run instead of GitHub-hosted GH Actions steps - the manylinux_riscv64 image ships no Node for a container: job.
  • dnf install libstdc++-static (Rocky's CRB repo) before configuring - -static-libgcc/-static-libstdc++ needs it and the image has no static libs by default.
  • -DLLVM_TARGETS_TO_BUILD=RISCV, native build, no cross toolchain (the runner is riscv64 hardware).
  • No musllinux and no sdist job, matching this repo's usual scope for these ports.

Testing

  • Parses a small C snippet through clang.cindex after installing the built wheel, verifying the bundled libclang.so loads and works - upstream's own CI only checks GLIBC symbol versions, no functional test.

License: OK - Apache-2.0 WITH LLVM-exception, matching upstream's LICENSE.TXT. Wheel statically links libstdc++/libgcc from the manylinux image's gcc (GPL-3.0-or-later WITH GCC-exception-3.1); gpl_sources job publishes the corresponding source RPM.

Built and smoke-tested locally under riscv64 QEMU up through cmake configure; full build not yet run in CI.

Compiles libclang.so from the LLVM 18.1.1 source release inside
manylinux_2_39_riscv64 and packages it via upstream's own setup_ext.py,
mirroring libclang-linux-amd64.yml/libclang-linux-aarch64.yml narrowed to
riscv64. Upstream publishes no riscv64 wheel.
setup_ext.py imports distutils directly; Python 3.12 dropped it from
the stdlib and pip install wheel alone doesn't pull in setuptools'
compatibility shim, so the wheel build died with ModuleNotFoundError
after the full LLVM/Clang compile finished (gotcha 211).
wheel>=0.44.0 dropped wheel.bdist_wheel.get_platform in favour of
setuptools' own bundled bdist_wheel command. Upstream's setup_ext.py
imports get_platform directly from wheel.bdist_wheel, so an unpinned
`pip install -U wheel` now breaks it with:

  ImportError: cannot import name 'get_platform' from 'wheel.bdist_wheel'

right after last commit's distutils fix gets past the first import.
Reproduced and fixed against the real setup_ext.py + a stub native/
tree in quay.io/pypa/manylinux_2_39_riscv64 (no LLVM rebuild needed):
wheel 0.48.0 fails identically, wheel==0.43.0 produces a real wheel.
Filed as gotcha 225.
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