fix(link): #886 — link perry-ext-* libs in jsruntime arm so express + http compiles#887
Merged
Merged
Conversation
…sruntime arm of build_and_run_link
Express (perry.compilePackages: ["express"]) link-failed on
_js_node_http_create_server / _js_node_http_res_end because
build_and_run_link's `if let Some(ref jsruntime) = jsruntime_lib {...}`
arm appended only jsruntime + runtime — the parallel
`else if ctx.needs_stdlib` arm that emits well_known_libs +
stdlib_lib was unreachable. The codegen-side FFI provenance
registry (#884) correctly drained OwnerKind::WellKnown("http") into
ctx.native_module_imports, and the auto-optimize layer built
libperry_ext_http.a + pushed it onto well_known_libs — but the
link command then silently dropped it.
Fix mirrors the well-known emission into the jsruntime arm:
after jsruntime + runtime, when ctx.needs_stdlib is true,
append stdlib_lib (if Some) + every well_known_libs entry.
Mach-O / ELF archive scan is first-definition-wins, so
jsruntime's bundled-stdlib copies still win for duplicate js_*
symbols (the documented duplicate-symbol warnings); the
perry-ext-* libs cover symbols neither jsruntime nor its
bundled stdlib carries.
Validation: express repro links cleanly (advances to a separate
runtime TypeError from the Proxy/callable shape — out of scope
per the issue). New regression test exercises both halves
standalone: static-import a .js fixture (forces ctx.needs_js_runtime)
+ http.createServer (forces well_known_libs to contain
perry-ext-http). cargo test --release --workspace clean (1098
passed, 0 failed).
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
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.
Summary
perry.compilePackages: ["express"]) link-failed on_js_node_http_create_server/_js_node_http_res_endeven thoughauto-optimize: built …/libperry_ext_http.aran successfully. Trace viaPERRY_DEBUG_LINK=1confirmed the linker command-line omitted bothlibperry_stdlib.aand everylibperry_ext_*.a.build_and_run_link'sif let Some(ref jsruntime) = jsruntime_lib {…}arm only appended jsruntime + runtime; the parallelelse if ctx.needs_stdlibarm that emitswell_known_libs+stdlib_libwas unreachable whenever a V8-fallback .js module flippedctx.needs_js_runtime = true. The codegen-side FFI provenance registry (fix: #835/#846 followup — feed codegen FFI provenance into auto-optimize stdlib features #884) correctly drainedOwnerKind::WellKnown("http")intoctx.native_module_importsand the auto-optimize layer builtperry-ext-http.a+ pushed it ontowell_known_libs— but the link command then silently dropped it.ctx.needs_stdlib, appendstdlib_lib(if Some) + everywell_known_libsentry. First-definition-wins archive scan keeps jsruntime's bundled-stdlib copies for duplicates; the perry-ext-* libs only fill gaps.Test plan
test-files/test_issue_886_jsruntime_http_link.ts+test-files/fixtures/issue_886_pkg/index.jsexercises both halves standalone: static-import a.jsfixture (forcesctx.needs_js_runtime = true) +import { createServer } from "node:http"; createServer(...)(forceswell_known_libsto contain perry-ext-http). Fails to link without the fix (verified by reverting + rebuilding); compiles + links + reachesserver created: trueruntime output post-fix.mkdir /tmp/perry-express && cd /tmp/perry-express && echo '{"perry":{"compilePackages":["express"]}}' > package.json; npm install express; echo 'import express from "express"; console.log(typeof express);' > main.ts; perry main.ts -o out) links cleanly post-fix — advances to a separate, pre-existing runtimeTypeErrorfrom the Proxy / callable-shape path (out of scope per the issue).cargo build --release -p perry-runtime -p perry-stdlib -p perry -p perry-jsruntimeclean.cargo test --release --workspaceclean (1098 passed, 0 failed, excluding cross-host UI crates).Refs #886 (express link failure), follows #884 (the v0.5.930 codegen-side FFI provenance work that this PR completes by wiring the well-known half through to the link line).