Sorry, I'm not sure to understand what these version "9.2" and "10.3" really are. By looking at archlinux I think that the version number of MinGC should be the same as GCC version number. So my understanding is that you are saying that you internally test with gcc 9.2 and gcc 10.3.To answer your question we also test internally using a version of MinGW 9.2 and MinGW 10.3
Now, if this is the case, it means that you have tested exactly with the same gcc 10.3 I have tried. In that case the point is - I imagine - you test it internally by recompiling from source (more about that below), otherwise I can't explaing why you didn't intercept the problem I found.
Ok, that is the most important point I want to discuss with you. From a general perspective, we can discuss it without even mentioning CopperSpice. And without mentioning MSYS2 either.Due to compiler ABI issues any C++ libraries you use and your application must agree.
So... The general idea is that the standard C++ library should be backward compatible, hence if one replaces an old version with a newer one, the C++ executables/dlls compiled against the old standard C++ library version should keep working with the newer one.
If that doesn't happen, it means that they have introduced a (likely unwanted) breaking change.
Back to my case, to CopperSpice and to MSYS2 now: it is possible that this breaking change has been actually introduced a couple of years ago with the __cxa_atexit commit into gcc. But that is a very specific issue that should be addressed as such and not with a shift in the philosophy of backward compatibility, as you are claiming tout court.
While it is true that building CS from source would work, it is time and resource consuming. On the other hand you seem to ignore that there is an alternative and one can use your binary of Cs with MinGW 11 (and 10) and make it work without recompiling all from sourceSo if you want to use MinGW 11 with MSys2, you can! However you will need to build CopperSpice from source
Very interesting. I used CMake 3.21. It is after the breaking change you were informed about?In the "CMakeLists.txt" for these examples there is a call to "InstallMinGW.cmake". This is a function in our exported CMake configuration. This function instructs CMake to copy the MinGW dll files. This works perfectly for CMake 3.20 or less. We were informed that CMake made a breaking change to how files use the environment path, so sometimes it can not find things. Someone is looking into a resolution and will correct this.
However I don't think the problem is about the env path at all. I have understood that CMake should copy MinGW dll files, Why doesn't it do that, at least in my case? Because it can't find them maybe? Not at all, I believe! Again, at least in my case, I believe that (here I can be wrong, but I'm quite confident, even if I'm not expert of cmake) CMake can find the dll files but can't copy them because those dll files actually have an incompatibility issue (which I suspect is again the same __cxa_atexit commit introduced in gcc).
Sorry, but just to reiterate myself, I fully disagree with that, in the sense that I see the MSys vs MSys2 stuff as completely unrelated to the compat issue of C++ standard library on MinGW. Indeed I discussed about this also in discord chat of MSys2, where jeremyd2019 confirmed my suspect about the cxa breaking change. Furhermore, as a proof of the fact that this is not a MSys2 vs MSys issue but an unexpected breaking change of std compat, I found a previous version (ante cxa change) of MSys2 libstdc++-6.dll that is different from your MSys libstdc++-6.dll but it is working as well and could also have solved my issue. In conclusion, sorry for repeating it once more, my issue could have been solved (aside from recompiling the source) by delivering a working libstdc++-6.dll together with your binary files.Just to reiterate, we use MSys and not MSys2. This is why your MinGW dll files are not working,