Precompiled x64-mingw-ucrt gem fails to load on Windows: LoadError: cannot load such file -- wasmtime/wasmtime_rb

[andrew2net]

Summary

The precompiled x64-mingw-ucrt gem (v41.0.1) installs successfully on Windows but fails at runtime when require "wasmtime" is called.

Environment

• OS: Windows Server 2022 (windows-latest on GitHub Actions)
• Ruby: 3.2, 3.4, and 4.0 (all via RubyInstaller2 UCRT)
• Gem version: wasmtime 41.0.1 (x64-mingw-ucrt)
• Install method: Bundler (bundle install)

Error

Failure/Error: require "wasmtime"

LoadError:
  cannot load such file -- wasmtime/wasmtime_rb
# ./vendor/bundle/ruby/3.4.0/gems/wasmtime-41.0.1-x64-mingw-ucrt/lib/wasmtime.rb:13:in '<top (required)>'

The loader in lib/wasmtime.rb tries wasmtime/3.4/wasmtime_rb first, then falls back to wasmtime/wasmtime_rb — both fail.

Reproduction

Any gem depending on wasmtime ~> 41.0 installed via Bundler on Windows with RubyInstaller2 UCRT will hit this. Our CI run demonstrating the failure: https://github.com/relaton/relaton-un/actions/runs/23171604086

Observation

The build-gems.yml workflow only smoke-tests precompiled gems when matrix.ruby-platform == 'x86_64-linux':

- name: Smoke gem install
  if: matrix.ruby-platform == 'x86_64-linux' # GitHub actions architecture
  run: bundle install && bundle exec rake pkg:${{ matrix.ruby-platform }}:test

The x64-mingw-ucrt variant is cross-compiled but never tested on an actual Windows runner, so this breakage isn't caught in CI.

[jeffcharles]

I tested requiring wasmtime with Ruby 3.4 on Windows 11 and was able to reproduce the error. It's weird, inspecting the .so file with file reports the gem is PE32+ executable (DLL) (console) x86-64, for MS Windows so I'm not clear on why it would be failing to load and reporting an error that it's not a valid Win32 application. I also inspected the binary for the PE headers and can confirm it's a PE file for 64-bit Windows. Not sure if there's a transitive dependency that's causing a load error to bubble up.

[jeffcharles]

It looks like the DLL is trying to load api-ms-win-core-synch-l1-2-0.dll and bcrypt.dll and failing. I've confirmed bcrypt.dll is present in C:\Windows\System32 so not sure why that's failing to load. api-ms-win-core-synch-l1-2-0.dll is a virtual DLL so doesn't have a physical file and should just be loadable. bcrypt is linked to the synch DLL so potentially the synch DLL not being loadable may be causing the bcrypt DLL to appear to be not loadable.