问如何避免用`msvcrt.dll`编译MinGW64？

EN

我有一些C++代码，可以编译到各种平台，即Linux32/64位，Windows32/64位。对于Windows部分，我使用了最新的gcc编译器提供的明明威64软件包。我遇到的问题是，32位编译拖着微软通过msvcrt.dll提供的libc，而DLL有一些问题：

1. 是不可发行的(它随Windows而来，不可替换)
2. 有版本(每个Windows版本都有不同的版本，并增加了功能)
3. 它依赖于其他Windows DLL，即围绕该特定版本的DLL的库生态系统，这些库也是系统的一部分。

mingw使用特定的版本，因此它不会默认地在旧版本上运行，例如在Windows中:它将需要不存在的API的入口点。

我尝试静态链接，但没有效果，msvcrt.dll总是被拖动(-static，- statically，-static++，您可以给它命名)。

我非常坦率地尝试将Windows附带的msvcrt.dll替换为适用于最新版本的Windows，但这完全阻止了Windows的启动。

我尝试将正确的msvcrt.dll复制到我的可执行路径中，但是由于它是每个人都使用的库，它已经加载，并且不会从不同的文件中加载另一个实例。

我试着修补我的可执行文件，这样它就会调用相同的DLL，但是使用不同的名称，所以愚蠢地让Windows只为我的可执行文件加载一个更新的版本，而且第一步有效，但是它启动了一个永远无法满足的DLL依赖的噩梦，因为它将引入其他系统库，比如ntdll.dll，这些库也必须进行修补等等。

我试着在这里和不同的论坛上浏览有关这个问题的几个问题，但是所有的问题都归结为msvcrt.dll是一个您不应该担心的库，但这是不正确的，它存在着大量的兼容性问题。

我意识到mingw正在慢慢地离开像Windows这样的旧操作系统，但是我真的想要一个不应该像看起来那么复杂的问题的解决方案。首先，我将mingw-w64-i 686-libwinpthread线程和mingw-W64-i 686-mingw线程的级别从当前的7.0.0.5325降至不太远的7.0.0.5273，以避免调用Vista中引入的API GetTickCount64()。一旦修复了这个问题，它就会向我请求_mkgmtime32()，它来自msvcrt.dll，它是在DLL的第7版中引入的，而且它显然不存在于Windows附带的DLL中。

我也意识到，我想使用C++17的操作系统已经有近20年的历史了，但它仍然非常流行，至少在第三世界是如此。有人对此有洞察力吗？

摘要

在使用MinGW64时是否有方法链接到静态多线程VC运行时库

在visual中使用/MT时等效的MinGW64标志是什么？