This is not recommend in general but it is also not good for us specifically. To begin with, it just assumes the compiler is always gcc. Compiling OMSimulator with, for example, MinGW64 clang and then linking to libstdc++ instead of libc++ will, in the least, give you those warnings about duplicate sections having different sizes. For other compilers/runtimes it can have a more serious effect. I think the final executable segfaults for clang on MinGW-64's UCRT system.
There is no need for this. The only benefit of it was probably not having to ship libgccand libstdc++ with the OMSimulator binaries when making a package from the MinGW build. However, there is an MSVCbuild for Windows and that should be the one used for creating real Windows packages. The MinGW packages should be used for MSYS/MinGW systems only.
This is not recommend in general but it is also not good for us specifically. To begin with, it just assumes the compiler is always
gcc. Compiling OMSimulator with, for example, MinGW64clangand then linking tolibstdc++instead oflibc++will, in the least, give you those warnings about duplicate sections having different sizes. For other compilers/runtimes it can have a more serious effect. I think the final executable segfaults for clang on MinGW-64's UCRT system.There is no need for this. The only benefit of it was probably not having to ship
libgccandlibstdc++with the OMSimulator binaries when making a package from the MinGW build. However, there is anMSVCbuild for Windows and that should be the one used for creating real Windows packages. The MinGW packages should be used for MSYS/MinGW systems only.