@ntkme

Thanks for the work on this. I'm fine with the rewrite, as anyone interested in it should be familiar with PowerShell, Bash, and MSYS2.

One question. The current code in the msys2-extra job has the following:

matrix:
  include:
    - os: windows-2022
      sys: mingw64
      env: x86_64
      variant: -gcc@14-openssl@1.1
    - os: windows-2022
      sys: ucrt64
      env: ucrt-x86_64
      variant: -gcc@14
    - os: windows-2022
      sys: ucrt64
      env: ucrt-x86_64
      variant: -gcc@14-openssl@1.1

Might we be able to specify packages in the matrix, something like:

matrix:
  include:
    - os: windows-2022
      sys: mingw64
      env: x86_64
      variant: -gcc@14-openssl@1.1
      packages: gcc-14.2.0-3 openssl-1.1.1.w-1
    - os: windows-2022
      sys: ucrt64
      env: ucrt-x86_64
      variant: -gcc@14
      packages: gcc-14.2.0-3
    - os: windows-2022
      sys: ucrt64
      env: ucrt-x86_64
      variant: -gcc@14-openssl@1.1
      packages: gcc-14.2.0-3 openssl-1.1.1.w-1

Right now, there are two steps Downgrade to openssl@1.1 and Downgrade to gcc@14. It would be nice if the downgrade packages didn't require code to be written for each one? The code for the 'ri2 package signing key' could be shared by all?

Right now, there are two steps Downgrade to openssl@1.1 and Downgrade to gcc@14. It would be nice if the downgrade packages didn't require code to be written for each one? The code for the 'ri2 package signing key' could be shared by all?

Definitely possible. The reason that I split them is mainly that openssl require a v3 library backup and restore step, which is quite unique, but I can wrap two steps around the generic downgrade step. Will update.

The reason that I split them is mainly that openssl require a v3 library backup

Sorry, I forgot v3 dll's need to be kept for the other items installed when we downgrade to OpenSSL 1.1...

Also, one thing discussed was possibly adding a json file here that would be copied to setup-ruby, it would contain the logic for the archive package selection. Something similar to what you added to the readme. A quick object might be something like (ruby code, not complete) the below:

Once again, the goal is to keep repo updates for MSYS2 package compatibility issues as 'code free' as possible...

  'ucrt' =>
  [
    { greater_than_eq: [3,5,0],
      package: 'msys2-ucrt64.7z'
    },
    { greater_than_eq: [3,2,0],
      package: 'msys2-ucrt64-gcc@14.7z'
    },
    { less_than: [3,2,0],
      package: 'msys2-ucrt64-gcc@14-openssl@1.1.7z'
    },
    { error: 'unknown version' }
  ],
  'mingw' =>
  [
    { greater_than_eq: [3,5,0],
      package: 'msys2-mingw64.7z'
    },
    { greater_than_eq: [3,2,0],
      package: 'msys2-mingw64-gcc@14.7z`
    },
    { less_than: [3,2,0],
      package: 'msys2-mingw64-gcc@14-openssl@1.1.7z`
    },
    { error: 'unknown version' }
  ],
  'mswin' =>
  [
    { greater_than_eq: [2,0,0],
      package: 'vcpkg-x64-windows.7z'
    },
    { error: 'unknown version' }
  ]
}

Thanks again. Somewhat busy with family things this afternoon...

Once again, the goal is to keep repo updates for MSYS2 package compatibility issues as 'code free' as possible...

My worry is the cost of creating and maintaining a DSL/schema and parser for it would be way too expensive than just writing the code directly. Also, I'm worried in the future we might need to certain feature detection instead of relying on simply version number, which a fixed JSON won't be able to handle.

  const msys2Type = os.arch() === 'arm64'
    ? 'clangarm64'
    : rubyIsMSVCRT(prefix)
      ? 'mingw64'
      : 'ucrt64'

  let suffix = `-${msys2Type}`
  if (!(common.isHeadVersion(version) || common.floatVersion(version) >= 3.5) && msys2Type !== 'clangarm64') {
    suffix += '-gcc@14'
  }
  if (!(common.isHeadVersion(version) || common.floatVersion(version) >= 3.2)) {
    suffix += '-openssl@1.1'
  }

Consider the code above, I think a DSL will be way less efficient than this.

@MSP-Greg I have a question for you as I don't know much about vcpkg and mswin builds.

I'm seeing the following warning in setup-ruby's test when it's running &"$env:VCPKG_INSTALLATION_ROOT\vcpkg" list, with or without my change:

warning: The vcpkg C:\vcpkg\vcpkg.exe is using detected vcpkg root C:\vcpkg and ignoring mismatched VCPKG_ROOT environment value C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\vcpkg. To suppress this message, unset the environment variable or use the --vcpkg-root command line switch.

I think what happens here is that Setting up MSVC environment step is exporting VCPKG_ROOT to the vcpkg bundled within Visual Studio. Therefore, I think the C:\vcpkg simply won't be used by MSVC. So why are we even try to install packages into C:\vcpkg if that's not going to be used.

Maybe this is simply an oversight as the code was written before this change? https://devblogs.microsoft.com/cppblog/vcpkg-is-now-included-with-visual-studio/

So maybe we should install vcpkg packages into both C:\vcpkg and Visual Studio's vcpkg?

Ok it seems https://github.com/MSP-Greg/ruby-loco is hardcoded to use $VCPKG_INSTALLATION_ROOT and C:\msys64, and my change of moving msys64 to a different location may break things there.

I was starting to type this when you sent the last post/message.

Yes. Ruby doesn't really need vcpkg, it just needs the packages. And, yes, 'ruby-loco' and the code in setup-ruby and setup-msys2-gcc has been around for a while, which you've probably noticed.

Given that the vcvars code is setting VCPKG_ROOT to C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\vcpkg, maybe we should keep the files in C:\vcpkg, as it doesn't contain dated info like 2022?

As to the warning, maybe change the workflow step code (add VCPKG_ROOT or use the suggested argument)?

JFYI, I was looking at the job logs and was confused. Any thoughts on a better name than gcc and ridk version (mingw), which I wouldn't expect to have info for a mswin build...

maybe we should keep the files in C:\vcpkg, as it doesn't contain dated info like 2022?

I guess my question was more of whether these DLLs are required at a hard coded location during mswin ruby's run-time to match the location during compile/link-time? If that's the expectation, then I totally agree that having 2022 in the path is going to cause trouble in the future. - If it's just a compile-time requirement, then I think it does not really matter as long as the correct VCPKG_ROOT is set during compilation.

If the DLLs and headers are only a compile-time dependencies (e.g. if they get bundled into the mswin ruby distribution for runtime), then I think a better way to handle this is to remove the vcpkg packages from setup-ruby, and put that step directly into ruby-loco?

If the DLLs and headers are only a compile-time dependencies

They're needed for compiling std-lib extension items and other extension gems.

Got it. Still not sure about how the compiler find the right location as in setup-ruby we didn’t export VCPKG_ROOT to the correct one with the packages installed… Or maybe it will actually fail to compile and it’s just that we never tried as the CI only test compiling the json gem.

Do you know which std gem(s) need these dependencies that I can do a test?

Fiddle requires libffi, Psych requires libyaml, openssl requires openssl, zlib require zlib.

Puma compiles against openssl.

I think most of these are tested in their respective Ruby repos, all of the above are tested on at least one of the MSYS2 builds, and also mswin.

EDIT: most of the3 above have worked for a long time (years). Note that the compilers are part of the Visual Studio install, they aren't part of vcpkg.

Not sure about arm64, I haven't started a ruby-loco build for that yet... Lars Kanis has one built, I could check there...

Oh, I didn't realize that ruby also bundles libwinpthread-1.dll. - That explains everything.

I was looking at the changes in mingw-w64 and found the changes in the headers seem to be compatible, but did not realize that we have two libwinpthread-1.dll, one from ri2 and one from msys2.

Sounds like we want to downgrade libwinpthread and related packages in msys2 for all ruby versions where we do gcc@14 downgrade. Hopefully, the upcoming rubies built on gcc@15 (3.5.0, 3.4.4, 3.3.9, 3.2.9) should also get linked against the up-to-date libwinpthread-1.dll, so that they will not require downgrade. - FYI @larskanis

I just checked the last GHA builds of stable Ruby branches of 3.4, 3.3 & 3.2, and they were done last week, but before the changes happened. I'll run them locally with all current packages...

I can upload all the required packages to the release here.

BTW, no idea where I got LA from, your profile shows Bay area...

My two cents: If we're bundling vendor provided DLLs in RI2 or whatever packaging, maybe it should also bundle the necessary headers from the vendor so that the compiler can always find the matching pairs of headers/dlls, without having to rely on the end user to install the "correct" version of header from the vendor.

@ntkme not sure what you're following, see https://bugs.ruby-lang.org/issues/21327#note-3

@ntkme I just uploaded the 24 x64 'r688' packages here.

Note that the rails test step actually also did not work properly, but somehow it didn't fail the test. @deivid-rodriguez you might want to check this?

Forgot to answer here. I had noticed this, too. I think it may be some issue in rails new where it does not properly abort when some necessary subcommand fails, like bundle install?

I just uploaded the 24 x64 'r668' packages here.

Thanks. I also pushed commits to do the downgrade, as well as run a regression test for updating the date gem.

@MSP-Greg It seems like date gem on clangarm64 is also broken. I'm going to create a new variant for downgrading. Could you please upload the same set of package for clangarm64?

@ntkme I just uploaded the twelve mingw-w64-clang-aarch64 packages.

@ntkme Thanks. Since arm head hasn't been built since 05-May...

Once this is merged (and setup-ruby), I may try a ruby-loco arm build. A few days can change a lot of things.

Since arm head hasn't been built since 05-May...

Yes, I've commented out the test for arm head for now.

I saw that rubyinstaller-head-arm.7z was updated so I gave it a try and run into this: oneclick/rubyinstaller2#434

It brings us to a weird situation that msys64 needs to be extracted to $rubyPrefix\msys64 before setup-ruby runs ruby --version. So we will need to know exactly where $rubyPrefix will be before running setup-ruby. I'm going to comment out the clangarm64 test again for now.

To no one's surprise, the missing DLL in rubyinstaller-head-arm is libwinpthread-1.dll: oneclick/rubyinstaller2#434 (comment)

clangarm64 ruby head test is now passing after I disabled the "update bundler" step in setup-ruby. The problem is that in this repo we're intentionally setting up msys2 after installing ruby during our test. Not having msys2 installed currently causes the built-in date gem to crash, and the "update bundler" step loads the date gem.

See oneclick/rubyinstaller2-packages#25 (comment) and ruby/date#126 (comment)

@MSP-Greg I think we're out of the woods for libwinpthread-1.dll issues. The setup-ruby PR has got approval. Can you please do a final check for this and see if we are good to go?

@ntkme

Can you please do a final check for this and see if we are good to go?

Done. LGTM.

As I see it, this doesn't affect the current setup-ruby from running, as the current releases are remaining. Agreed?

Thanks for all your work.

As I see it, this doesn't affect the current setup-ruby from running, as the current releases are remaining. Agreed?

Correct, the msys2-gcc-pkgs tag and release assets will be untouched and they will stop receiving future updates. Basically, it will become immutable but will remain functional.

@MSP-Greg One last thing you might want to do before merging this is downgrade mingw-w64 packages for the current setup so that they are frozen at the older version...