I would like to have seen a reference to an actual report or documentation.
There are issues which look like rc but are triggered by using a wrong cmake.
And there are cases where flags are passed through the msys environment which might heuristically determine that /c65001 is an absolute POSIX path which must be converted to a Windows path.

Hi Kai.

I don't exactly know what or where the problem was, but it was fixed with this change. I am using the latest Visual Studio 2026.

I don't see any problems building ports that use MSYS2. Do you know of any that may be problematic? I'll be happy to fix any issues. This would only happen with commands being executed by MSYS2's sh.exe, e.g. from make.

It seems really strange to me that the toolchain files are "fixed" without knowing "what or where the problem was". Such changes invalidate everybody's cached artifacts.

In vcpkg CI, there were no problems with msys2 based ports before and after this PR.

Just FTR - but probably unrelated - the issues with msys2 mingw cmake and VS rc.exe look like #49203.
Search for RC1107:
https://github.com/microsoft/vcpkg/issues?q=is%3Aissue%20state%3Aopen%20%22RC1107%22

@dg0yt I'm sorry, the change looked plausible to me but I agree we should probably be more specific about a "demonstrate the before/after fix". (There are a lot of Windows tools that require /arg rather than -arg or --arg and I could easily imagine some versions of rc.exe having such limitations... the resource compiler is very old and dates back to at least the mid 90s. And our build lab has recent-ish tools where I could imagine that would be changed)

I had this problem and it was definitely the problem, because rc.exe was throwing an error and my builds were failing, and once I changed the option to the slash form they were no longer failing.

It's possible some government person was doing something to my toolchain and they have some version of rc.exe that does not work with the dash form. My build log files have been deleted, which makes this more likely.