Windows - run renameSystem32Dlls on all versions

[MSP-Greg]

This fixes failures in ruby/ruby mingw64 & ucrt64 CI.

When running Ruby from a build folder or without the dll resolution provided by the RubyInstaller2 runtime, dll's in the Windows/System32 folder may be loaded.

[eregon]

Ah, but so it's only needed for mingw and ucrt ruby-loco versions, right? Maybe also mswin?
Could you only rename for those cases then?

For e.g. 3.1.0 and other builds which come from RubyInstaller2 it shouldn't be needed, right?

I have no idea how much effort it is, but it'd be nice if mingw/ucrt/mswin ruby-loco builds would have the dll resolution like RI2, that seems the best way to ensure the right dlls are picked no matter what.

[MSP-Greg]

I have no idea how much effort it is, but it'd be nice if mingw/ucrt/mswin ruby-loco builds would have the dll resolution like RI2, that seems the best way to ensure the right dlls are picked no matter what.

All do except maybe mswin, not.sure. The problem, as the original comment suggested, is when running Ruby from a build folder, that resolution is not in place. That happens in ruby/ruby, not ruby-loco. That's one of the reasons ruby-loco doesn't run tests from the build folder, it runs from the install folder, where the RI2 resolution exists...

Or, this is partially about ruby/ruby, and has nothing to do with ruby-loco.

[MSP-Greg]

Just to clarify, the vast majority of people using this action are running the installed/selected Ruby. That may not always be the case. When ruby/ruby runs make test-all, it's running the ruby.exe file it just built, not the Ruby selected by the Action.

But, the Ruby selected by the action determines what toolset is enabled, or whether mingw64 or ucrt64 is installed/added to Path.

[eregon]

Should ruby/ruby even use this action?
I guess it's convenient for the mingw64/ucrt64 setup and anyway make test-all ignores the ruby in Path?

IMHO it's better to do these renames in ruby/ruby workflow's yml.
This action doesn't guarantee anything if you are using another Ruby it did not set up.

Could you post an example failed log link too to see what it looks like?

[eregon]

My understanding is the issue only affects ruby/ruby, and the rename can just be done there.
This action should only rename when necessary (RubyInstaller1 if I understand correctly), and in no other cases to avoid surprises but also as a side effect to test the manifest/dll resolution works correctly on RI2.

[MSP-Greg]

As mentioned above, these OpenSSL files are generally not a problem when using recent MSYS2 based Rubies. They can cause issues when building Ruby master, and that is addressed in ruby/ruby build workflows.

Older Windows MSYS Rubies (2.3 and earlier) need to install EOL OpenSSL packages, and the file conflicts should be addressed in the same code. It is done in setup-ruby-pkgs.

Hence, closing...