如何避免使用MinGW64编译`msvcrt.dll`？ 我有一些C++代码，我编译到各种平台，即Linux 32/64位，Windows 32/64位。对于Windows部分，我使用mingw-w64包提供的最新gcc编译器。我遇到的问题是，32位编译会拖拽Microsoft通过msvcrt.dll提供的libc API，而该dll存在一些问题： 不可分发（它随Windows提供，不可替换） 有版本（每个Windows版本都有不同的版本，并添加了功能） 它依赖于其他Windows DLL，这意味着围绕特定版本的DLL的库生态系统也是系统的一部分

mingw使用特定的版本，因此默认情况下不会在旧版本上运行，例如在Windows XP中：它将需要指向不存在的API的入口点

我尝试了静态链接，但没有成功，msvcrt.dll总是被拖拽（-static，-static libgcc，-static libstdc++，随便你说）

我相当坦率地尝试用一个在更新版本的Windows中工作的msvcrt.dll替换Windows XP附带的msvcrt.dll，但这会阻止Windows XP启动

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

我尝试修补我的可执行文件，使其调用相同的DLL，但名称不同，从而愚弄Windows仅为我的可执行文件加载较新的版本，这是第一步，但它开始了一场无法满足的DLL依赖性噩梦，因为它将引入其他系统库，如ntdll.dll，这些库也必须进行修补等等

我试着在这里和不同的论坛上浏览关于这个主题的几个问题，但所有问题都归结为msvcrt.dll是一个您不应该担心的库，但这根本不是真的，它有太多的兼容性问题

我知道mingw正在慢慢地抛弃像windowsxp这样的旧操作系统，但我真的很想找到一个解决问题的方法，这个问题不应该像看起来那么复杂。我首先将mingw-w64-i686-libwinpthread和mingw-w64-i686-winpthreads从当前的7.0.5325降级到不远的7.0.0.5273，以避免调用GetTickCount64（），这是Vista中引入的API。一旦我修复了这个问题，它会要求我从msvcrt.dll中获取_mkgmtime32（），它是在dll的第7版中引入的，而在Windows XP附带的dll中显然不存在

我也知道，我想将C++17与一个已经有近20年历史的操作系统一起使用，但它仍然非常流行，至少在第三世界是如此。有人对此有什么见解吗

总结 使用

MinGW64

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

MinGW64

时，visual Studio中的

/MT

标志等效于什么

最新的Visual Studio 2019仍然支持带有特殊vc141_XP“工具集”的Windows XP。您可以在XP上使用最新的“通用CRT”

MinGW能够链接-您根本不需要使用旧的msvcrt.dll，您可以按照上面链接中的说明链接任何msvcrXX.dll或现代ucrtbase.dll，它将在Windows XP上工作

---

MinGW代表“极简GNU”，其设计理念是以标准库支持的方式提供尽可能少的支持，更倾向于重定向到其他库实现，如msvc。如果你想要一个独立于msvcrt的完整实现（编译器和库），那么mingw不是你想要的项目。你在这方面有什么进展吗？@Royi:没有，我放弃了，对不起。我尝试了很多方法，但都没有成功：(