Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ruby 3.4 update #408

Merged
merged 3 commits into from
Jan 10, 2025
Merged

Ruby 3.4 update #408

merged 3 commits into from
Jan 10, 2025

Conversation

jbourassa
Copy link
Collaborator

@jbourassa jbourassa commented Dec 30, 2024

Support Ruby 3.4:

  • Update rb-sys
  • Fix tests (updated error message in Ruby 3.4)
  • Fix example (old magnus was incompatible with 3.4)
  • Update test and release workflows to use Ruby 3.4

TODOs:


I won't cut a new version right away given we're due for a Wasmtime version bump, so we'll create a new release soon for that.

- Precompile gem for Ruby 3.4
- Use Ruby 3.4 in GitHub actions
@jbourassa jbourassa marked this pull request as ready for review January 10, 2025 11:47
@jbourassa
Copy link
Collaborator Author

Thanks @saulecabrera. I have a PR cooking that should fix the Windows CI, I’ll open it later today.

@jbourassa jbourassa merged commit e5270ae into main Jan 10, 2025
27 of 29 checks passed
@jbourassa jbourassa deleted the ruby-3.4 branch January 10, 2025 18:46
@saulecabrera
Copy link
Member

There's a failure on main, unrelated to Windows AFAICT; I'm trying to sanity check if it's related to the Ruby upgrade or if it's due to something else. I haven't spent a bunch of time investigating this failure; have you seen this failure before?

@jbourassa
Copy link
Collaborator Author

jbourassa commented Jan 12, 2025

Hmm the issue is on 3.3, looks like something related to oxidize-rb/rb-sys#475.

I downloaded the artifacts and 3.3 is indeed missing:

wasmtime-28.0.0-arm64-darwin ❯ tree lib
lib
├── wasmtime
│   ├── 3.1
│   │   └── wasmtime_rb.bundle
│   ├── 3.2
│   │   └── wasmtime_rb.bundle
│   ├── 3.4
│   │   └── wasmtime_rb.bundle
│   ├── component.rb
│   ├── error.rb
│   └── version.rb
└── wasmtime.rb

Now why aren't we seeing the fix, that's the question.

@jbourassa
Copy link
Collaborator Author

jbourassa commented Jan 13, 2025

Now why aren't we seeing the fix, that's the question.

I think it's related to how the GitHub action picks the version; it uses the first rb_sys line in the Gemfile.lock, regardless of the current version.

Updating the rb_sys minimum version in the gemspec should do it? Let's try that.

(Also, we're on a deprecated version of the cross-gem action, but hopefully that's not the culprit here Edit: it may have something to do, more digging is necessary).

jbourassa added a commit that referenced this pull request Jan 13, 2025
See this comment for details: #408 (comment)
@jbourassa jbourassa mentioned this pull request Jan 13, 2025
jbourassa added a commit to jbourassa/wasmtime-rb that referenced this pull request Jan 13, 2025
@jbourassa
Copy link
Collaborator Author

jbourassa commented Jan 13, 2025

(Also, we're on a deprecated version of the cross-gem action, but hopefully that's not the culprit here Edit: it may have something to do, more digging is necessary).

I've updated the workflow in my fork to use the current cross-gem action. That (with the rb-sys version bump?) should do it, but I'm running into a weird issue: the rustc process dies without any output:

/usr/local/cargo/bin/cargo rustc --crate-type cdylib --package wasmtime-rb --manifest-path /home/runner/work/wasmtime-rb/wasmtime-rb/ext/Cargo.toml --target aarch64-unknown-linux-gnu --target-dir /home/runner/work/wasmtime-rb/wasmtime-rb/tmp/rb-sys-dock/aarch64-linux/target --lib --profile release -- -C linker=aarch64-linux-gnu-gcc -L native=/usr/local/rake-compiler/ruby/aarch64-linux-gnu/ruby-3.1.0/lib -C link-arg=-pipe -C link-arg=-lm
   Compiling proc-macro2 v1.0.92
<snip...>
   Compiling postcard v1.1.1
Error: Process completed with exit code 1.

See this example run.

I can reproduce by SSHing into the GitHub Action and:

  • editing the locally-installed gem source so that interactive? is false
  • rm -rf tmp to ensure a fresh build
  • rb-sys-dock --platform aarch64-linux --directory . --ruby-versions 3.1,3.2,3.3,3.4 --build

Interestingly, interactive or subsequent builds do not suffer from this.

I also found that not running sigfw as process 1 (again by editing the gem code) makes the build pass. Does that mean something is sending SIGINT to our process while it compiles?

@jbourassa
Copy link
Collaborator Author

I created an issue with my finding and broader context: #418

jbourassa added a commit that referenced this pull request Jan 13, 2025
See this comment for details: #408 (comment)
@jbourassa
Copy link
Collaborator Author

Ruby 3.4 + Windows should now be green, CI is still running compilation and tests succeeded: https://github.com/bytecodealliance/wasmtime-rb/actions/runs/12750608774/job/35545705015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants