Issue #17845 has been updated by larskanis (Lars Kanis).


I opened a pull request to ruby including the above patches: https://github.com/ruby/ruby/pull/4599

One remaining issue is about the gem platform. It is currently:

* `Gem::Platform.local.to_s` => "x64-mingw32" # equal in MSVCRT and UCRT

BUT gems with C-extension aren't compatible between MINGW-MSVCRT and MINGW-UCRT. Loading fails due to different libruby names (due to ruby-configure-mingw32-ucrt.patch above). If libruby would be named equally, then C extensions would often work to some extend, but can fail with a segfault or deliver wrong results. 

On the other hand the MSWIN platform isn't compatible to MINGW-UCRT. In theory gems compiled for MINGW-UCRT should run flawlessly on MSWIN, since they both share the same C runtime. But extensions compiled with MSWIN link to `x64-vcruntime140-ruby310.dll`, so that either loading of the DLL fails or the entry addresses are different leading to error `incompatible library version`. The other way around of using MSWIN gems in MINGW-UCRT doesn't work due to the additional dependency to `vcruntime140.dll`, which isn't part of Windows nor MSYS2.

More details to the different Windows compiler platforms are here: https://www.msys2.org/docs/environments/

Since all three Windows platforms aren't compatible they should have distinct Rubygems platform strings. I propose `x64-mingw32-ucrt` which fits into the naming scheme of MSWIN `x64-mswin64-140` and the proposed `x86_64-linux-musl` for Apline Linux. Or should we use the chance to drop the misleading "32" and call it `x64-mingw-ucrt`?


----------------------------------------
Feature #17845: Windows Ruby - ucrt build?
https://bugs.ruby-lang.org/issues/17845#change-92625

* Author: MSP-Greg (Greg L)
* Status: Open
* Priority: Normal
* Target version: 3.1
----------------------------------------
Currently, Windows Ruby is normally compiled two ways.

The first, mswin, is compiled using Microsoft's current Visual C compiler, and links to the universal runtime (ucrt).

The second, mingw, is compiled using MinGW gcc.  This links to msvcrt, an older version of Microsoft's Visual C runtime.

Previously, all the MSYS2 MinGW packages linked to msvcrt.  The MSYS2 project is now releasing build tools and packages linking to ucrt.

MSYS2 has provided ruby packages, and GitHub user @Biswa96 contributed https://github.com/msys2/MINGW-packages/pull/8518, allowing Ruby to compile with ucrt.

I tried the patch with ruby-loco, and it builds.  There are some test issues, haven't had a chance to look at them yet.

Normally, using exe/dll/so files together that use different versions of the runtime is not a good idea.  Building extension gems with ucrt may provide gems that can be used with mswin, but can't be compiled due to issues with Visual C (vs gcc).  Also, packages from the vcpkg project may be compatible with Ruby ucrt.

The reason for this post is that Windows Ruby built with ucrt is essentially another platform, but the build 'looks like' a mingw build.

This is really a third platform choice.  What should it be called? Things like `CONFIG['RUBY_SO_NAME']`, `RUBY_PLATFORM`, etc?

---Files--------------------------------
ruby-mingw32-ucrt.patch (622 Bytes)
ruby-configure-mingw32-ucrt.patch (687 Bytes)
ruby-configure-coroutine-mingw32.patch (351 Bytes)
ruby-i386-mingw32-ucrt-undef.patch (398 Bytes)
ruby-date-mingw32-ucrt-timezone.patch (333 Bytes)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>