installation on windows MSYS2 MinGW 64bit

[giuliohome]

Thank you for your reply. Nice to chat with you again. I've not received a notification via email, but ok, I am back to the forum anyway, eventually.

To answer your question we also test internally using a version of MinGW 9.2 and MinGW 10.3

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.
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.

Due to compiler ABI issues any C++ libraries you use and your application must agree.

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.
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.

So if you want to use MinGW 11 with MSys2, you can! However you will need to build CopperSpice from source

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 source

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.

Very interesting. I used CMake 3.21. It is after the breaking change you were informed about?
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).

Just to reiterate, we use MSys and not MSys2. This is why your MinGW dll files are not working,

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.

[barbara]

>> . . . not received a notification via email

About new posts? If you want an alert you will need to adjust your notification settings for this forum. Glad you saw our reply.

>> Sorry, I'm not sure to understand what these version "9.2" and "10.3" really are.

MinGW is a port of GCC to Windows. If you find a version of MinGW on a Linux distribution this is a compiler designed to cross compile to Windows. When working on Arch and targeting for Arch you would use GCC and not MinGW.

It is likely the version numbers between gcc and MinGW will be the same, however there are no rules to say they must happen.

>> So my understanding is that you are saying that you internally test with gcc 9.2 and gcc 10.3.

As we mentioned, on Windows we test with MinGW 7.3, 9.2 and 10.3. On other platforms we test with both clang and gcc, with a very wide range of versions. The release versions are marked on our documentation.

>> ... 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.

The C and C++ standard library versions are not always interchangeable between compiler versions. It would be nice but sadly this does not work. On platforms like Debian they are really good with versioning so you can move between versions a lot easier. Windows does *not* work this way. Again, it would be nice but it just does not work and this can be frustrating.

>> ... it means that they have introduced a breaking change.

Trying to very clear, Windows is a very unique operating system. There are no compiler breaking changes that are causing problems. Every new compiler release can be considered a breaking change since feature X may be implemented differently. Even building the compiler with different options can produce incompatible ABI.

Keep in mind, there is no guarantee the C++ standard library for one exact version will be the same for gcc, clang, mingw, and msvc. Yes, this can be very scary if you release cross platform software! We have personally asked some of the maintainers of the C++ standard and libC++ this exact question. The people who maintain their version of the C++ standard are "asked" to follow the rules but it is not a requirement.

>> ... to CopperSpice and to MSYS2 now: it is possible that this breaking change has been actually introduced

There is no bug or breaking change that is causing the ABI mismatch and this has nothing to do with CopperSpice. On Windows you must build your application and libraries with the exact same version of the compiler. There is no way around this today and fixing this would involve a change in how DLL's work, which will never happen.

>> ... 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 source

Sadly, no this does not work on Windows. In fact release and debug on MSVC are not even ABI compatible with the exact same version of their compiler. This is not something we made up. We work very closely with developers at MS. CopperSpice is part of their conformance test suit to ensure changes they make work on newer versions.

>> I used CMake 3.21 . . .

Yes, this is interesting. We have a client that simply moved from 3.16 to 3.21 and CMake stopped finding the MinGW dll files. Moving back to 3.16 and not changing anything else worked. After reading some of the CMake documentation we confirmed they made a change in CMake. It is a bit odd but they made one change in 3.20 and another in 3.21 which may conflict. It happens with newer versions of the tools and this issue is being tested in our office.

>> CMake should copy MinGW dll files, Why doesn't it do that, at least in my case?

This is good question since no other user ( and we have a lot of them! ) has reported this issue. This is why we are talking with you, to figure out why. We want to find the root cause and many times it is simply a user setup we did not anticipate. So thank you for working with us.

>> CMake can find the dll files but can't copy them because those dll files actually have an incompatibility issue

Not necessarily, it is actually pretty complicated to know if CMake can find the files. Since it did not copy them for your use case, it did not find them. Please understand we know you have an issue and our team wants to know exactly why. We are not going to simply toss some code in as a quick short term fix.

Our belief is that your environment path maybe set up to search for the MinGW files in some path before it finds the right ones in the MinGW folder. CMake can be picky on how it searches your computer for files it needs to install. In our dream world everyone would have the same setup, but that is silly.

>> I see the MSys vs MSys2 stuff as completely unrelated to the compat issue of C++ standard library on MinGW

This is simply not accurate. MSys2 has their own version of MinGW and that is fine. Their compiler will work just fine if you are willing to compile CS with it. When our clients need support for a specific toolchain on some given platform, we are more than willing to provide it, as part of their paid support.

There are fundamental issues when mixing toolchains on Windows and you must be very careful. MSys does not provide a compiler which is why the runtime DLL files must come from MinGW. If you want to mix and match you can try, but please know it is very likely to break somewhere along the way.

>> ... issue could have been solved by delivering a working libstdc++-6.dll

CopperSpice is a library and the binary files on our download site and github contain only the library components. We do not supply a compiler, linker, standard library, or any of the other tools you might need. If you download the CopperSpice binary files for Debian or Ubuntu it also comes with just the CopperSpice files. You might need to install various dependencies like GStreamer or OpenSSL, all of which we document.

We provide a link to the exact version of MinGW used to build CopperSpice. If you want to use our pre-built binary files to compile and link your C++ application, you will need to use this version of MinGW. Then you will have everything you need on your development computer.

Just having the "right" runtime dll files will not be enough for your development system.

If you download the Windows binary for our KitchenSink Demo, Diamond Editor, or DoxyPress, you will see they contain the runtime dll binaries since these are applications. We compiled these programs with the same toolchain we used to build CopperSpice.

We have a large number of clients using Windows and several have requested that our team provide updated versions to MinGW and some of the tools in MSys. This is something currently under active development.

Barbara

[barbara]

We have discovered the problem and it affects anyone using CMake 3.17 or newer if you are compiling with any version of MinGW.

The CMake developers decided to change the function find_library() and they no longer support a .dll suffix. This means the run time libraries are not found and therefore can not be copied to the deploy folder.

If your path was set at run time to include the location of these MinGW runtime files, your application would run just fine. However, the dll files were not copied to the deploy folder as intended.

We are making a minor change to one of our CMake scripts in CopperSpice to add the missing dll suffix to the search path. This correction will be pushed to github shortly.

Barbara