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


> I wonder if there is a standard target triplet for MinGW + UCRT. 

The compiler triplet for MINGW with UCRT is still 'x86_64-w64-mingw32'. This is defined in MSYS2 [here](https://github.com/msys2/MSYS2-packages/blob/master/filesystem/msystem#L72). It is not distinct from MSVCRT based MINGW because it differs only in a library (msvcrt.dll vs. ucrtbase.dll) and the dependent libraries are not part of the compiler triplet.

I did some testing with the patch used [in MSYS2](https://github.com/msys2/MINGW-packages/pull/8518/files). It doesn't establish any new platform strings, so that RbConfig is mostly the same with MSVCRT and UCRT. Extension libraries linked to MSVCRT usually load into a UCRT based ruby at the first attempt, but they fail later on. FFI fails when using long double values and Nokogiri fails in some test case while calling `free()` of msvcrt.dll. These are expected issues, when mixing MSVCRT and UCRT into one process.

So, I would propose a patch similar to [this](https://github.com/oneclick/rubyinstaller2-packages/blob/master/mingw-w64-ruby-head/0001-ucrt-v2.patch) rather than the one [in MSYS2](https://github.com/msys2/MINGW-packages/pull/8518/files). This sets

* CONFIG['arch'] = 'x64-mingw32' # equal in MSVCRT and UCRT
* CONFIG['sitearch'] = 'x64-ucrt' # vs. 'x64-msvcrt' in MSVCRT
* CONFIG['RUBY_SO_NAME'] = 'x64-ucrt-ruby310' # vs. 'x64-msvcrt-ruby310' in MSVCRT
* RUBY_PLATFORM = 'x64-mingw32' # equal in MSVCRT and UCRT

I'm uncertain if the use of UCRT should be reflected in `RUBY_PLATFORM`. In any case it should still contain "mingw" since I've seen a lot of code checking for Windows by `RUBY_PLATFORM=~/mingw|mswin/`.

Similarly Rubygems should use a different platform string for UCRT and MSVCRT based gems, since binary extensions are incompatible. This is still missing in the patch above. Maybe 'x64-mingw32-ucrt' as rubygems platform or 'x64-mingwucrt' or the platform of MSWIN?

My rough idea is to switch to UCRT with RubyInstaller-3.1. That means that all current releases keep using MSVCRT and that there will be no MSVCRT based RubyInstaller-3.1. 


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

* Author: MSP-Greg (Greg L)
* Status: Open
* Priority: Normal
----------------------------------------
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?



-- 
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>