OpenCode link fails on main: undefined `__perry_wrap_perry_fn_…effect_src_Array_ts__Array_` (and PERRY_NO_AUTO_OPTIMIZE=1 hits a tokio archive mismatch)

[proggeramlug]

Compiling OpenCode v1.18.30 (#10107) on current main fails at the link step with an undefined wrapper symbol. Codegen completes; only the link fails.

Undefined symbols for architecture arm64:
  "___perry_wrap_perry_fn_opencode_node_modules__bun_effect_4_0_0_beta_83_node_modules_effect_src_Array_ts__Array_",
  referenced from:
      _perry_closure_..._effect_src_Chunk_ts__25              in c316355eae28ea51.o
      _perry_closure_..._effect_src_Cron_ts__14               in a409843744941715.o
      _perry_closure_..._effect_src_internal_effect_ts__72    in 9c215f79c17003d8.o
      _perry_closure_..._effect_src_internal_effect_ts__541   in 9c215f79c17003d8.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1
Error: Linking failed

Four closures across three effect modules reference the wrapper for effect/src/Array.ts's Array export, and it is not in any object handed to the linker.

Where it looks like it comes from

The log shows the auto-optimize pass rebuilding runtime+stdlib immediately before the failure:

auto-optimize: rebuilding runtime+stdlib (panic=abort, features=async-runtime,bundled-streams,crypto,…)

That pass internalizes and dead-strips, and the tree already carries #[used(compiler)] keepalive anchors specifically because it has dropped still-referenced symbols before (#4876 — "the auto-optimize internalize+dead-strip pass can't drop it"). A wrapper reached only from other modules' closures looks like the same class of victim.

PERRY_NO_AUTO_OPTIMIZE=1 is not a workaround

Turning the pass off replaces this with a different hard failure:

Error: error: the wrapper archive(s) below bundle a DIFFERENT tokio compilation
than the stdlib archive they would be linked with.

so there is currently no way to link this program on main: with auto-optimize the wrapper symbol is missing, without it the archives disagree about tokio.

Repro

perry compile src/index.ts --platform bun \
  --output <out> --cache-dir <dir> \
  --asset-module "opencode-web-ui.gen.ts=<repo>/packages/app/dist"

from packages/opencode of OpenCode v1.18.30 (perry.json defines per the tracking issue), macOS arm64, perry v0.5.1633 (0fa3915293, merge train 253). ~2h to reach the link step; the object cache is warm afterwards so a retry reaches it in minutes.

The same program links and runs on v0.5.1592, so this is a regression somewhere in 1592…1633.

[proggeramlug]

Reproduced on Linux x86_64, on main 681d7024 plus #11817 and #11819. Those two fix earlier Linux-only failures that stopped the OpenCode build before it could reach this link step. Codegen now completes for every module, and the link fails on this symbol alone.

The auto-optimize hypothesis above is refuted. In this build the auto-optimize pass never ran: perry could not locate its workspace (find_perry_workspace_root found nothing, because my CARGO_TARGET_DIR is outside the source tree), so it linked the stock prebuilt runtime with no internalize/dead-strip pass at all. The link fails the same way. Whatever drops this symbol, it is not that pass.

On Linux the unresolved symbol is the wrapper's closure-info record:

undefined reference to `__perry_wrap_perry_fn_opencode_node_modules__bun_effect_4_0_0_beta_83_node_modules_effect_src_Array_ts__Array_$info'

The referencing closures are the same four as in the report above: Chunk.ts__25, Cron.ts__14, internal/effect.ts__72 and __541.

Nothing in the build defines it. I ran llvm-nm over all 14,577 objects in the compile's object cache:

• 6 objects reference …effect_src_Array_ts__Array_$info as undefined (U).
• 0 objects define it.
• 0 objects define or reference the wrapper function __perry_wrap_perry_fn_…effect_src_Array_ts__Array_ itself. The importers take the address of the wrapper's info record without ever naming the wrapper.

So this is not a symbol that was emitted and then dropped. It was never generated. The importing modules assume effect/src/Array.ts will emit a wrapper and its $info for its Array export, and the owning module never does. That points at whatever decides, per owning module, which functions get a __perry_wrap_ wrapper: the need is evidently discovered only in the importers. On macOS the same gap surfaces as the wrapper function being missing rather than its info record.