Add fat binary gem support for ruby-3.1

[larskanis]

Ruby-3.1-x64 on Windows has a changed platform string "x64-mingw-ucrt" vc. "x64-mingw32".
Consequentally rake-compiler-dock has a new corresponding platform image.
See https://rubyinstaller.org/2021/12/31/rubyinstaller-3.1.0-1-released.html

Unfortunately the compiler triplet is still "x86_64-w64-mingw32" for both ruby platforms, although the compiled code isn't compatible.
Therefore we have to differ by RUBY_PLATFROM instead of the "host" string.

What problem is this PR intended to solve?

It shall add binary gems for ruby-3.1.

Have you included adequate test coverage?

This is another PR #2408

Does this change affect the behavior of either the C or the Java implementations?

C only.

Fixes #2397

[flavorjones]

@larskanis Thanks so much for shipping this. I'm going to merge #2408 and rebase this on top of it.

[larskanis]

Oh, I just noticed that arm64-darwin doesn't build. I'll update the PR.

[flavorjones]

@larskanis Can you please peek at 0c32749 and tell me if that Windows ucrt test for the native gem looks right?

[flavorjones]

@larskanis Not sure if you're actively working on this, I don't want to clobber any work you're doing ...

[flavorjones]

@larskanis So this change broke some things:

-    # Prefer host_alias over host in order to use i586-mingw32msvc as
-    # correct compiler prefix for cross build, but use host if not set.
-    recipe.host = RbConfig::CONFIG["host_alias"].empty? ? RbConfig::CONFIG["host"] : RbConfig::CONFIG["host_alias"]
+    recipe.host = RbConfig::CONFIG["host"]

An example is how we derive the name of the "ar" tool for building libgumbo (with this change, we end up looking for the nonexistent x86_64-redhat-linux-gnu-ar instead of x86_64-redhat-linux-ar).

I'm not familiar with why this particular change was made, and I wish we were collaborating more closely on these changes. Can you help me understand why this change was made and whether I can safely revert it (it seems to work fine when I do)?

[flavorjones]

@larskanis I'm going to step away for the evening, but I will have time tomorrow to collaborate -- in real time -- if you're willing and able to. Thanks for working on this!

[larskanis]

Tests look good now. I don't understand the JRuby install error. It looks like jruby/jruby#6904 . I tried to use ruby-maven from git, but to no avail.

[flavorjones]

Thank you! I have some context on the JRuby thing, I'll take a look this morning.

[flavorjones]

@larskanis rake-compiler sets the gemspec required_ruby_version to

spec.required_ruby_version = [
  ">= #{ruby_api_version(sorted_ruby_versions.first)}",
  "< #{ruby_api_version(sorted_ruby_versions.last).succ}.dev"
]

(see https://github.com/rake-compiler/rake-compiler/blob/master/lib/rake/extensiontask.rb#L282-L285)

For Nokogiri this will always be [">= 2.6", "< 3.2.dev"], which is incorrect for the windows gems now. I've patched it up locally in 56b89d9 but I'd like to understand if we should be using rake-compiler differently to make this happen automatically (or if we should add a feature to rake-compiler to do so).

[larskanis]

For Nokogiri this will always be [">= 2.6", "< 3.2.dev"], which is incorrect for the windows gems now.

I opened rake-compiler/rake-compiler#199 to fix this issue in rake-compiler.