feat(windows): sketch fix-pe.ts + bkwinvenv (skeletons for #346)#347
Draft
tannevaled wants to merge 1 commit into
Draft
feat(windows): sketch fix-pe.ts + bkwinvenv (skeletons for #346)#347tannevaled wants to merge 1 commit into
tannevaled wants to merge 1 commit into
Conversation
Concrete artefact for pkgxdev#346 — two new files mirroring the Linux side: lib/bin/fix-pe.ts — analog of lib/bin/fix-elf.ts for PE/COFF libexec/bkwinvenv — analog of libexec/bkpyvenv for hermetic Windows-binary bundling Both are skeletons — not wired into the build pipeline yet, no tests, no plumbing into the bottle/audit phases. The intent is to give shape to the architecture sketched in the RFC so the discussion can move to concrete code instead of design questions. ## fix-pe.ts (PE/COFF audit + sanitize pass) Three responsibilities, all light-weight since Windows has no RPATH: 1. Strip "+brewing" from embedded strings (length-preserving, same problem the libc.so linker-script fix solved at pkgxdev/pantry#12968 — needed to be done as a binary-safe byte sweep here) 2. (TODO) Strip absolute build paths from .pdb debug records 3. Audit-only check that every NEEDED DLL is either Windows-shipped (kernel32, ucrtbase, vcruntime140, …) or co-located in the bottle. Warn-not-fail; bundling is bkwinvenv's job. Notably absent: NO patchelf equivalent, NO RPATH rewriting, NO PT_INTERP analog. None of those concepts exist in PE/COFF. ## bkwinvenv (recipe-side hermetic-bundle helper) Mirrors bkpyvenv's stage/seal lifecycle: bkwinvenv stage <prefix> (currently no-op placeholder; reserved for future CC/LD wiring) bkwinvenv seal <prefix> For each bin/*.exe: 1. walk PE imports (llvm-readobj --coff-imports) 2. bundle non-system transitive DLLs into libexec/ 3. move exe → libexec/ 4. emit bin/<stem>.cmd wrapper that does "%~dp0\..\libexec\<exe>" %* This is the Windows answer to bklibcvenv (pkgxdev#344) — same opt-in hermeticity model, same bin/libexec layout, simpler wrapper because Windows' default DLL search order already favors the exe directory (no need for explicit loader invocation). ## What's NOT here No platform-handling fixes (`platform == 'windows'` branches in audit, bottle, env). Those go in follow-up commits once the shapes here get sign-off — likely: - audit step: skip fix-elf on windows hosts, run fix-pe instead - bottle step: produce .tar.xz with Windows binaries - env: PATH separator, file extensions, etc. Refs: pkgxdev#346 (RFC), pkgxdev#344 (bklibcvenv analog), pkgxdev/pantry#12984 (llvm-mingw recipe).
This was referenced May 22, 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.
Draft, paired with #346 (RFC) + pkgxdev/pantry#12984 (llvm-mingw recipe).
Two new files to give concrete shape to the architecture sketched in #346:
lib/bin/fix-pe.tsfix-elf.ts+brewingfrom PE binaries (binary-safe); audit-only DLL import checklibexec/bkwinvenvbkpyvenvbin/*.exe→libexec/, emit.cmdwrapperWhat's intentionally NOT here
platform == 'windows'branches added tobottle.ts,audit.ts, etc.The goal of this draft is to make the architecture reviewable as code, not to ship anything. If the shapes look right, the wiring + tests + CI work is a separate PR (or several).
Sanity check on the design
The Linux
bklibcvenv(you suggested the rename frombkcvenvfor clarity) and thisbkwinvenvend up with the same recipe-side API:So consumers learn one mental model: stage/seal + opt-in hermeticity, regardless of platform.
Key design points to push back on
fix-pedoesn't rewrite anything load-bearing — Windows has no RPATH/PT_INTERP to surgery. The only rewrite is the+brewingbyte-sweep (which is a generic problem, not a Windows-specific one). Do you want this consolidated into a generic post-rename pass on Linux and Windows? Currently the Linux side handles+brewingvia fix-elf RPATH rewriting; the new byte-sweep would be an addition.SYSTEM_DLLSallowlist — I hard-coded the common Windows-shipped DLLs. There's no canonical machine-readable list; we'd be maintaining it ourselves. Alternative: assume any DLL whose name doesn't match a bottle-shipped one is system. (Less safe but simpler.)bkwinvenv stageis currently a no-op — does it actually need a stage phase?bkpyvenv stagecreates the venv;bklibcvenv stagesets CC/CXX. For Windows, the toolchain is already wired (viallvm.org/mingw-w64dep). We might just needseal.Refs
bklibcvenv— Linux analog ofbkwinvenv)skip: fix-patchelf— same pattern applies on Windows asskip: fix-pe)llvm.org/mingw-w64recipe — toolchain bottle)