feat: statically link cpp redist for MSVC target#91
feat: statically link cpp redist for MSVC target#91vytautas-astrauskas-sensmetry wants to merge 1 commit intomainfrom
Conversation
|
Why is this a draft? It passes CI, so presumably works well enough. |
Signed-off-by: Vytautas Astrauskas <vytautas.astrauskas@sensmetry.com>
9460cce to
a741f49
Compare
|
For repo hygine - could you provide an update here @vytautas-astrauskas-sensmetry? I'm thinking we want to have this be ready-for-review, or updated PR description on why its stale, or close? |
The current main build needs to be tested on Windows without redist to determine whether changes in this PR are needed. |
|
@vytautas-astrauskas-sensmetry I ran our CI build for windows, and used the tool dumpbin to inspect things, and chatted with Opus 4.6 about it. I think this won't be needed based on that. ❯ Look at #91, then also consider this output from dumpbin Will we need to compile statically? ● Based on the dumpbin output, no, you don't need PR #91's changes — the C++ runtime is already statically linked. The key evidence: VCRUNTIME140.dll is absent from the dependency list. That's exactly the DLL that PR #91 aims to statically link. If it were dynamically linked, you'd All the listed dependencies are standard Windows system DLLs that ship with every Windows installation: ┌──────────────────────────────┬──────────────────────┐ No Visual C++ Redistributable is required to run this binary. This answers the question Vytautas raised in the PR comment — the current main build doesn't need the ❯ Can I see if it is actually statically linked? ● Searched for 3 patterns, read 1 file (ctrl+o to expand) ● Yes — .cargo/config.toml:2 already sets +crt-static for all Windows targets: [target.'cfg(windows)'] This is the Rust-level flag that statically links the C runtime. It's why VCRUNTIME140.dll doesn't appear in your dumpbin output. PR #91's linker-level |
No description provided.