cyx-6 opened a new pull request, #688:
URL: https://github.com/apache/tvm-ffi/pull/688
## Motivation
The orcjit addon links against conda-forge's LLVM, which is built with a
newer GCC whose libstdc++ carries `GLIBCXX_3.4.29+` symbols. Those exceed the
`manylinux_2_28` floor this project standardized on in #675, which is why the
addon has carried a `-static-libstdc++`/`-static-libgcc` workaround since the
original addon PR (#254).
This builds LLVM from source inside the `manylinux_2_28` image instead,
publishes the install prefix as a release asset, and has CI download it.
Because that toolchain already sits at the manylinux ABI floor, the workaround
is no longer needed.
## What changes
* **LLVM acquisition (Linux).** `/opt/llvm` is obtained by downloading
`llvm-<version>-linux-<arch>.tar.zst` and extracting it, instead of being built
or installed via conda. macOS/Windows keep the conda-forge binaries (no GLIBCXX
floor); their `actions/cache` step is split out so their install gating is
unchanged. Everything downstream is untouched — same `/opt/llvm`, same
`LLVM_PREFIX`, same bind-mount into the build container.
* **Drop `-static-libstdc++`/`-static-libgcc`,** so the addon no longer
bakes in a private copy of the C++ runtime.
* **Add an explicit ABI assertion.** auditwheel does *not* fail on a too-new
symbol — it silently selects a laxer tag, so a regression to `GLIBCXX_3.4.30`
would still produce a valid `manylinux_2_35` wheel and pass CI unnoticed. The
new step fails unless every wheel is tagged `manylinux_2_28` or lower, and logs
the highest `GLIBCXX`/`CXXABI` versions imported.
The by-name `--exclude-libs` list is deliberately **kept** rather than
collapsed to `--exclude-libs,ALL`. I tried that; it fails. The embedded
`liborc_rt.a` is linked by the JIT at run time and resolves its C++ runtime
through the process, including archive-only helpers such as
`_ZSt28__throw_bad_array_new_lengthv` that `libstdc++.so` does not export —
`ALL` localizes those and the ORC platform fails to materialize (`Failed to
materialize symbols: { (<Platform>, ...) }`). That holds whether libstdc++ is
static or dynamic, so the comment there is corrected rather than the flag
changed.
## Results
Full CI green on all four platforms. Both Linux legs now report:
```
max GLIBCXX imported: GLIBCXX_3.4.22
max CXXABI imported: CXXABI_1.3.11
C++ runtime refs (expect UND -> served by the process libstdc++):
_Znwm@GLIBCXX_3.4
__cxa_throw@CXXABI_1.3
__gxx_personality_v0@CXXABI_1.3
defined dynamic exports: 30 (x86_64; 29 on aarch64)
```
That is exactly the documented floor, and dynamic exports drop from ~965 to
~30 — the addon no longer re-exports a private libstdc++, removing the
interposition hazard with a host's own copy (e.g. PyTorch's bundled LLVM).
Tests: 89 passed x86_64 / 87 passed aarch64, plus the quick-start C and C++
examples.
Prebuilt LLVM is produced out-of-band, so this also removes a ~50 minute
from-source build from the CI path; the Linux orcjit jobs now spend a few
minutes downloading.
## Notes for reviewers
Two things worth flagging that are not visible in the diff:
1. **Artifact provenance.** Linux LLVM now comes from a release asset in
`mlc-ai/package`, which is outside the ASF org. The asset is currently a
**pre-release**, and the workflow that produces it lives on an unmerged branch
there. That side should land (and ideally be promoted out of pre-release)
before this is merged — hence the draft status. The download source is
parameterized via the `llvm_release_repo` input if you would prefer it mirrored
elsewhere.
2. **`publish_orcjit_wheel.yml` inherits this.** It calls the same composite
action without passing `llvm_version`/`llvm_release_repo`, so published PyPI
wheels will also start sourcing LLVM from that release. This is a supply-chain
change to a published artifact that the diff does not visibly touch.
Builds on #675 (`manylinux_2_28` standardization), which is what makes the
floor the right target.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
