Skip to content

windows-linker: bring evidence-based duplicate-symbol strip to Windows (stale-lib shadowing under /FORCE:MULTIPLE) #6626

Description

@proggeramlug

On Windows the link relies on /FORCE:MULTIPLE (with /IGNORE:4006 suppressing the per-symbol warnings) plus link order — first definition wins — so a stale prebuilt UI lib can silently shadow a freshly fixed runtime symbol. That is exactly how the #880 runtime fix got masked by a stale perry-ui-windows lib (hazard documented in a build_and_run.rs comment). The evidence-based strip_duplicate_objects_from_lib pass that removes duplicate objects before linking on other platforms is explicitly skipped on Windows, leaving the hazard structural. Found in the 2026-07-18 Windows audit (main @ 58e555e).

Evidence

  • crates/perry/src/commands/compile/link/build_and_run.rs:381-396 — hazard comment citing fix(gc): release-safe guard in js_shadow_frame_pop (was debug_assert only) #880 and lld-link's first-definition-wins under /FORCE:MULTIPLE.
  • crates/perry/src/commands/compile/link/build_and_run.rs:960-968 — strip-dedup skipped when is_windows ("/FORCE:MULTIPLE (COFF) handles duplicate symbols safely").
  • crates/perry/src/commands/compile/link/build_and_run.rs:1207/FORCE:MULTIPLE applied.
  • crates/perry/src/commands/compile/link/platform_cmd.rs:842/IGNORE:4006.

Suggested fix

Extend strip_duplicate_objects_from_lib to COFF archives (llvm-ar/llvm-nm are already in the toolchain) so duplicate objects are removed by evidence instead of masked by link order; or, at minimum, add a post-link assertion that no runtime-critical symbol resolved out of the UI lib, so a stale-lib shadowing regresses loudly instead of silently.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew capability or improvement

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions