I've checked old build jobs: path to C++ compiler was "
C:\msys64\mingw64\bin\g++.exe" and version 14.2. And after examining the
same path via RDP, I can note that now the compiler version is 8.1.

If we assume that the path to g++ was rerouted, then it's not clear g++
14.2 is supposed to be. I've checked common paths to mingw/msys/cygwin as
well as windows search - compiler appears to be absent.

Hi,
I've double checked - VS2019 has something. But now there is a new problem
- g++ apparently cannot run:
```
cmake -B../../build -G Ninja -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo
-- The CXX compiler identification is unknown
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Check for working CXX compiler: C:/msys64/mingw64/bin/g++.exe
-- Check for working CXX compiler: C:/msys64/mingw64/bin/g++.exe - broken
CMake Error at C:/Program
Files/CMake/share/cmake-4.1/Modules/CMakeTestCXXCompiler.cmake:73 (message):
  The C++ compiler

    "C:/msys64/mingw64/bin/g++.exe"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir:
'C:/projects/tempest/build/CMakeFiles/CMakeScratch/TryCompile-nj3foa'

    Run Build Command(s): C:/PROGRA~1/Meson/ninja.exe -v cmTC_81cdc
    [1/2] C:\msys64\mingw64\bin\g++.exe -o
CMakeFiles\cmTC_81cdc.dir\testCXXCompiler.cxx.obj -c
C:\projects\tempest\build\CMakeFiles\CMakeScratch\TryCompile-nj3foa\testCXXCompiler.cxx
    FAILED: [code=1] CMakeFiles/cmTC_81cdc.dir/testCXXCompiler.cxx.obj
    C:\msys64\mingw64\bin\g++.exe -o
CMakeFiles\cmTC_81cdc.dir\testCXXCompiler.cxx.obj -c
C:\projects\tempest\build\CMakeFiles\CMakeScratch\TryCompile-nj3foa\testCXXCompiler.cxx
    ninja: build stopped: subcommand failed.
```

Would it be possible in this case to revert change on VS2019 image or
upgrade msys on VS2017 image?

Hello, Owen!

I've attempted as you suggested: downgrade cmake and build normally.
Unfortunately, on VS2019 image cmake complaining about g++ regardless of
the cmake version.
I'm starting to assume that some patch is broken and g++.exe cannot run as
a subprocess, or something similar is going on.

Here is recent buildlog:
https://ci.appveyor.com/project/Try/tempest/builds/52795380/job/rkftuwwrk8asadpc

I've tested with downgraded cmake&ninja today - no improvement, C++ still
broken:

https://ci.appveyor.com/project/Try/tempest/builds/52801785/job/x6fsl2ds0b4f1s92

HI,

Using older version of gcc/g++ from existing
installation ("C:\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin\g++.exe"),
allows to configure cmake successfully.
Unfortunately, 8.1 is super old and can't compile the project.

> Just to clarify, you think there is something broken in our build
images? What could it be?

My working theory(only theory!), that cmake makes no difference between
failed compilation and crash. gcc may fail to launch, if it missing it's
own runtime *.dll's, such as libstdc++-6.dll. Maybe something preventing it
from finding them or from finding the correct ones .

Hi, Owen!

Are there any updates on this issue?

чт, 25 сент. 2025 г. в 19:13, Александр Веселов <[email blocked]>:

Would it be possible on your end to bisect, what image update start to
cause the issue? Generally it's not a normal situation, if cmake can't
recognize compiler - I'm also not sure what exactly can cause it.

> I'm not a C++ developer.

I've created a minimal reproducer here:
https://github.com/OwenMcDonnell/test-appveyor/pull/1
May you kick-off CI, to check, if mingw issue is reproducible? Thanks!

Here is build where cmake+mingw use to work last time:
https://ci.appveyor.com/project/Try/tempest/builds/52628098/job/wlbnko1d2qm13q5h

cmake version is 3.29.3 and mingw - 14.2.0.

In any case, the build system failure, in compiling "Hello World", is
quite a problem :)

ср, 1 окт. 2025 г. в 00:32, Owen McDonnell <[email blocked]
>:

Hello, Owen!

Any luck reproducing green build on older image? And are there any dates on
when this issue might be fixed? Thanks!

ср, 1 окт. 2025 г. в 19:23, Александр Веселов <[email blocked]>:

Hi,
It seems in build script for minimal reproducer missing initialization of
PATH variable; here is pr:
https://github.com/OwenMcDonnell/test-appveyor/pull/2
Generally, you can also work backwards, if needed, from your green run:
replace all code to single, file, replace cmake to trivial one (Hello world
- like), remove Vulkan instalation and so on.
I've also noticed that you are using "Previous Visual Studio 2019". Is it
something that any user can add to their build script? Can it be used as a
temporary workaround?

> Have you checked/raised an issue on msys and/or cygwin repos?

I'm not using Cygwin and Msys work on my windows laptop locally - doesn't
look like a compiler issue of any sort, at this point.

пн, 6 окт. 2025 г. в 08:06, Owen McDonnell <[email blocked]
>:

After a few more tweaks green job:
https://ci.appveyor.com/project/appveyor-tests/test-appveyor/builds/52864330

пн, 6 окт. 2025 г. в 22:57, Александр Веселов <[email blocked]>:

> That strongly suggests to me the problem is with msys and not our image.

Log shows that both are 14.0.2

What about use of older image? Is there a way for me to specify the exact
one to use in my build-script? Asking since it's now a major bottleneck in
my work.

ср, 8 окт. 2025 г. в 05:58, Owen McDonnell <[email blocked]
>:

> What is 14.0.2?

Do you know why, then on newer image, if mingw is downgraded back to
14.0.2, it still leads to error in cmake configuration?

чт, 9 окт. 2025 г. в 00:24, Owen McDonnell <[email blocked]
>:

Actually yes - we tested cmake and ninja, not mingw.
Tested today: manual install of 14.2 works.

To summarise:
* issue seem to be unreproducible with mingw14
* reproducible with mingw15 (part of msys)
* locally non-reproducible with llvm-mingw17 (I'm using one that comes with
QtCreator)

Maybe you can upgrade to mingw14 or add it to the setup? At the moment
folder " C:\mingw-w64" still at version 8.x