Updates for Windows MSYS2 update to OpenSSL 3

[MSP-Greg]

Also, ran yarn upgrade

Ideally, I need to push a PR to https://github.com/ruby/setup-msys2-gcc before this is added to a new release.

Also, this will fail, as it's looking for an archive file from the above that doesn't exist until I make the PR...

[eregon]

Looks good, just write here when it's ready to merge, and you can amend the commit or close/open the PR to retrigger the CI.

[MSP-Greg]

Thanks. I pushed the update to setup-msys2-gcc, and the code here is working as expected, as the correct build tools are being used. Not sure about the Windows 2022 image and the issues with Ruby 2.0 thru 2.3. See https://github.com/ruby/setup-ruby/actions/runs/3961026899. Some kind of tar error, I'll try to repo locally. It may be an issue with recent MSYS2 updates.

With Ruby 2.0 thru 2.3, we have MSYS, MSYS2, and Git tools all in the path. I've kind of assumed that someday it would cause issues. I've also wondered about dropping support for Ruby 2.3 and earlier on Windows, as the build tools are just too old...

[MSP-Greg]

@eregon This is ready. Thanks.

[eregon]

There are some errors with tar.exe:
https://github.com/ruby/setup-ruby/actions/runs/3961026899
master doesn't seem to have this problem:
https://github.com/ruby/setup-ruby/actions/runs/3886537654

How about removing the yarn upgrade in an attempt to avoid this problem?

[MSP-Greg]

How about removing the yarn upgrade in an attempt to avoid this problem?

Done, and it did fix the issue. Confused as to how it only caused errors with the older Rubies on Windows? Not concerned enough to find the issue...

This PR changes the installed gcc archive for Ruby 3.2 and all the master/head builds. Because MSYS2 changed the location of the cert/conf files when they went from OpenSSL 1.1.1 to 3.0.z, the mingw build can't find the certs...

[eregon]

Because MSYS2 changed the location of the cert/conf files when they went from OpenSSL 1.1.1 to 3.0.z, the mingw build can't find the certs...

Can we do anything so those don't break?

[MSP-Greg]

Can we do anything so those don't break?

Yes, push this PR. The problem is with the ruby-loco mingw build.

ruby-loco is currently patched to work with this PR. As soon as this is released, it will build correctly. I patched the build archive for now. The mingw build that failed was looking for the certs in the OpenSSL 1.1.1 location, but the (updated) build code is placing them in the 3.0 location.

One issue I've wondered about, but it's very specific to building Windows Ruby, is adding an input that allows selection of the build tool archive installed by this action. Or, there is often a chicken/egg problem (which came first?) when new, breaking package versions are released. This has only been an issue with OpenSSL. ruby-loco is using setup-ruby for the correct build tool selection. Right now, ruby-loco's code is assuming the mingw build uses the build tool archive with OpenSSL 3, which this PR implements.

[eregon]

OK, let's merge it then.

[MSP-Greg]

Thanks. Found the issue with the @actions/cache update. See https://github.com/actions/toolkit/blame/main/packages/cache/src/internal/constants.ts#L31

Need to do some more digging, but master is using C:\msys64\usr\bin\tar.exe. After I did the yarn upgrade, it used the new code, so the file is C:\Program Files\Git\usr\bin\tar.exe. Part of the issue is that Windows has a native tar.exe file, which previously counld't use zstd compression.

Anyway, MSYS2 often 'leads' Git, so I'll see if it's fixed after the next Git release? Still not sure about how the newer Rubies passed.