Skip to content

fix(windows): bundle the LLVM runtime with Perry - #8018

Merged
proggeramlug merged 4 commits into
mainfrom
fix/windows-llvm-runtime-package
Aug 13, 2026
Merged

fix(windows): bundle the LLVM runtime with Perry#8018
proggeramlug merged 4 commits into
mainfrom
fix/windows-llvm-runtime-package

Conversation

@proggeramlug

@proggeramlug proggeramlug commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Summary

  • bundle the official LLVM 22 LLVM-C.dll beside perry.exe in the Windows release zip
  • keep the DLL beside the executable when staging @perryts/perry-win32-x64
  • fail packaging/staging if the PE import or runtime DLL is missing
  • update the gc-native-roots status after fix: restore CI portability and GC correctness #8017's dynamic-link fix

perry.exe on current main links successfully after #8017, but imports LLVM-C.dll. The release workflow did not package that DLL, so an extracted release exited with Windows loader error 0xC0000135 unless LLVM happened to be installed globally. This completes the #7985 fix without restoring the incompatible static /MT + rpmalloc link.

Validation

  • cargo build --profile perry-dev -p perry on Windows with the official LLVM 22.1.8 archive
  • PE imports include LLVM-C.dll and VCRUNTIME140.dll
  • isolated perry.exe + LLVM-C.dll bundle runs with C:\llvm\bin removed from PATH
  • tests/test_stage_npm_windows_llvm.sh passes its copy and missing-DLL refusal arms
  • workflow YAML parse, shell syntax, and git diff --check

No version bump.

Closes #7985

Summary by CodeRabbit

  • Bug Fixes

    • Windows release and npm packages now include the required LLVM-C.dll alongside perry.exe.
    • Packaging now validates required Windows runtime files and fails clearly when they are missing, preventing startup loader errors.
    • Windows arm workflow documentation now reflects resolved linker, archive, and Git Bash packaging issues.
  • Tests

    • Added automated checks to verify Windows packages include the runtime DLL and reject incomplete packages.

@coderabbitai

coderabbitai Bot commented Aug 13, 2026

Copy link
Copy Markdown

Review Change Stack

Warning

Review limit reached

@proggeramlug, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 11 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 16ee72c0-097b-4c88-af1e-1af3ac13cb93

📥 Commits

Reviewing files that changed from the base of the PR and between 17b3726 and 9dedfab.

📒 Files selected for processing (1)
  • .github/workflows/gc-native-roots.yml

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 1aa76290-567c-4375-a689-5780ba72846c

📥 Commits

Reviewing files that changed from the base of the PR and between 81a88de and 17b3726.

📒 Files selected for processing (6)
  • .github/workflows/gc-native-roots.yml
  • .github/workflows/release-packages.yml
  • .github/workflows/test.yml
  • changelog.d/8018-windows-llvm-runtime.md
  • scripts/stage-npm.sh
  • tests/test_stage_npm_windows_llvm.sh

📝 Walkthrough

Walkthrough

Windows release and npm packaging now validate and bundle LLVM-C.dll beside perry.exe. Regression coverage checks successful staging and missing-runtime failures. Windows native-roots documentation records the linker, archive, and packaging fixes.

Changes

Windows LLVM packaging

Layer / File(s) Summary
LLVM runtime staging contract
scripts/stage-npm.sh, tests/test_stage_npm_windows_llvm.sh, .github/workflows/test.yml, changelog.d/8018-windows-llvm-runtime.md
Windows npm staging requires and copies LLVM-C.dll. The regression test covers successful staging and missing-DLL failure. CI runs the test, and the changelog records the packaging behavior.
Release validation and CI status
.github/workflows/release-packages.yml, .github/workflows/gc-native-roots.yml
Windows release packaging validates required files and verifies the LLVM-C.dll import with llvm-readobj before staging. The native-roots status documentation records the fixed Windows issues and pending green-run verification.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Mergeability Score: ⚪ Minimal · up to 17b37

The change bundles the required LLVM runtime with Windows builds and validates release and npm staging behavior; no actionable merge-blocking risk remains beyond normal checks.

Sequence Diagram(s)

sequenceDiagram
  participant ReleaseWorkflow as release-packages.yml
  participant LLVMReadobj as llvm-readobj.exe
  participant ReleaseStaging as Windows release staging
  ReleaseWorkflow->>ReleaseWorkflow: Check perry.exe, llvm-readobj.exe, and LLVM-C.dll
  ReleaseWorkflow->>LLVMReadobj: Inspect perry.exe imports
  LLVMReadobj-->>ReleaseWorkflow: Report LLVM-C.dll import
  ReleaseWorkflow->>ReleaseStaging: Stage perry.exe and LLVM-C.dll
Loading

Possibly related PRs

  • PerryTS/perry#7986: Updates the same Windows native-roots workflow for archive extraction and CI status.
  • PerryTS/perry#7387: Updates the Windows native-roots workflow configuration and status.
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and concisely describes bundling the LLVM runtime with Perry on Windows.
Description check ✅ Passed The description explains the change, rationale, linked issue, validation, and versioning status, so it is mostly complete despite omitted template headings.
Linked Issues check ✅ Passed The PR packages and stages LLVM-C.dll and fails closed when required runtime files are missing, completing the remaining Windows runtime work for [#7985].
Out of Scope Changes check ✅ Passed The workflow, staging, regression test, documentation, and changelog changes directly support the Windows LLVM runtime packaging objectives.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/windows-llvm-runtime-package

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@proggeramlug proggeramlug left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Audited exact commit 17b3726. The DLL import validation, release copy, npm staging refusal, and local copy/refusal regression are sound. One blocker remains in .github/workflows/gc-native-roots.yml: this PR changes the Windows status to FIXED and says the tar failure was fixed by --force-local, then says all four arms should pass. #8028 documents and changes the opposite: the runner uses bsdtar, --force-local was ineffective, and the Windows arm still fails until the path is normalized. Please make this status text accurate against the intended combined state (cygpath fix, with green status only after measured evidence). I have not merged this head.

@proggeramlug

Copy link
Copy Markdown
Contributor Author

Addressed in d0829e5. The workflow status now says Windows is only partially fixed, records that --force-local is ineffective with the runner's bsdtar, points to #8028's cygpath normalization, and explicitly requires a measured four-arm green run before promotion. YAML parsing and git diff --check pass.

@proggeramlug proggeramlug left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re-audited exact head d0829e5 after #8028 and #8027 landed. The functional packaging change is sound: release staging proves perry.exe imports LLVM-C.dll before copying it, npm staging requires/copies the DLL beside the executable, and the positive plus missing-DLL refusal regression passes locally. One blocker remains in the operational status comment: the merged result now says windows-latest is "pending #8028" and waits "until that fix is merged," but #8028 is already on main. Please update the combined-state wording to say the cygpath/native-env fix has landed while the arm remains unproven until a complete measured run. That preserves the important no-green-by-comment rule without leaving a false pending dependency. I have not merged this exact head. No version bump needed.

@proggeramlug

Copy link
Copy Markdown
Contributor Author

Addressed the remaining combined-state wording blocker in 9dedfab59. The workflow note now records that #8028's cygpath normalization and native Windows environment export have landed, while keeping windows-latest explicitly unproven until a complete measured four-arm green run. It also preserves the finding that --force-local was ineffective with the runner's bsdtar. YAML parsing and git diff --check pass; no version or lockfile change.

@proggeramlug proggeramlug left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re-audited exact head 9dedfab. The prior operational-comment blocker is fixed: it now records both landed fixes while keeping the Windows arm unproven until a measured complete run. Release staging validates the LLVM-C.dll import before copying the runtime, npm staging fails closed when the DLL is absent, and the positive plus refusal regression passes locally. Merge-tree and diff checks are clean. No version bump.

@proggeramlug
proggeramlug merged commit 690882d into main Aug 13, 2026
24 checks passed
@proggeramlug
proggeramlug deleted the fix/windows-llvm-runtime-package branch August 13, 2026 14:04
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.

windows: perry.exe cannot link against the official LLVM 22 release — /MT vs /MD, bundled rpmalloc, and missing inkwell target backends

1 participant