fix: Add platform guards for WASM import symbols to fix Windows linking #43
Conversation
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
Adds three Claude workflows: - claude.yml: Responds to @claude mentions in issues/PRs - claude-code-review.yml: Automated PR code reviews - claude-ci-analysis job in ci.yml: Analyzes CI failures when 'claude-debug' label is present Features: - Opt-in debugging with 'claude-debug' label - Automatic code review on PR creation - Interactive @claude support for questions and debugging - Reads CI logs and provides root cause analysis 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Changed all Claude workflows to use ANTHROPIC_API_KEY environment variable instead of claude_code_oauth_token parameter. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Composite actions need environment variables at job level, not step level, to properly access them during validation. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Fixes freenet/river#39 Windows MSVC linker requires all external symbols to be resolved, even for cdylib crates. The WASM import symbols (__frnt__logger__info, __frnt__rand__rand_bytes, __frnt__time__utc_now) are only valid when compiling to wasm32-unknown-unknown target. This change: - Guards WASM imports with #[cfg(target_family = "wasm")] - Provides stub implementations for non-WASM targets - Allows contracts to compile on Windows native target The stub implementations are never used at runtime since contracts only execute in the Freenet WASM runtime. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
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
Fixes freenet/river#39
Windows MSVC linker errors when building contracts because it requires all external symbols to be resolved, even for
cdylibcrates. The WASM import symbols are only valid for thewasm32-unknown-unknowntarget.Root Cause
The external symbols
__frnt__logger__info,__frnt__rand__rand_bytes, and__frnt__time__utc_noware declared as WASM imports using#[link(wasm_import_module = "...")]. These symbols are provided by the Freenet WASM runtime at load time.When compiling contracts on Windows for the native target (x86_64-pc-windows-msvc), the MSVC linker (
link.exe) is strict and requires all external symbols to be resolved during linking, causing LNK2019 errors. Linux/Mac linkers are more lenient.Changes
#[cfg(target_family = "wasm")]#[cfg(not(target_family = "wasm"))]Testing
Impact
The stub implementations are never used at runtime since contracts only execute in the Freenet WASM runtime. This change only affects compilation, not runtime behavior.
Next Steps
After this PR is merged:
[AI-assisted debugging and comment]