【发布时间】：2019-09-07 18:13:02
【问题描述】：
我有一些 C++ 代码可以编译到各种平台，即 Linux 32/64 位、Windows 32/64 位。对于 Windows 部分，我使用 mingw-w64 包提供的最新 gcc 编译器。我遇到的麻烦是32位编译拖了微软通过msvcrt.dll提供的libc API，而且那个DLL有一些问题：
- 不可分发（Windows 自带且不可更换）
- 有版本（每个 Windows 版本都有不同的版本，具有附加功能）
- 它依赖于其他 Windows DLL，即围绕特定版本 DLL 的库生态系统，它们也是系统的一部分。
mingw 使用特定版本，因此默认情况下它不会在旧版本上运行，例如在 Windows XP 中：它将需要不存在的 API 的入口点。
我尝试静态链接，但无济于事，msvcrt.dll 总是被拖拽（-static、-static-libgcc、-static-libstdc++，你可以命名它）。
我相当坦率地尝试将 Windows XP 附带的 msvcrt.dll 替换为可在更新的 Windows 版本中运行的 msvcrt.dll，但这会阻止 Windows XP 启动。
我尝试将正确的 msvcrt.dll 复制到我的可执行路径，但由于它是每个人都使用的库，它已经加载，Windows 不会从不同的文件加载另一个实例。
我尝试修补我的可执行文件，以便它调用相同的 DLL，但名称不同，因此愚弄 Windows 仅为我的可执行文件加载更新的版本，第一步有效，但它开始了 DLL 依赖项的噩梦永远不能满足，因为它会引入其他系统库，比如 ntdll.dll 也需要打补丁等等。
我尝试在此处和不同论坛中浏览有关此主题的几个问题，但都归结为 msvcrt.dll 是一个您不应该担心的库的想法，但这根本不是真的，有很多兼容性问题。
我知道 mingw 正在慢慢抛弃 Windows XP 等较旧的操作系统，但我真的想要一个不应该像看起来那么复杂的问题的解决方案。我首先将 mingw-w64-i686-libwinpthread 和 mingw-w64-i686-winpthreads 从当前的 7.0.0.5325 降级到不远的 7.0.0.5273 以避免调用 GetTickCount64()，这是 Vista 中引入的 API。一旦我解决了这个问题，它就会要求我提供来自 msvcrt.dll 的 _mkgmtime32()，它是在 DLL 的第 7 版中引入的，并且显然不存在于 Windows XP 附带的 DLL 中。
我也知道我想在一个已经有将近 20 年历史的操作系统上使用 C++17，但它仍然非常流行，至少在第三世界是这样。有人对此有任何见解吗？
总结
在使用MinGW64 时，有没有办法链接到静态多线程 VC 运行时库？
使用 MinGW64 时，Visual Studio 中 /MT 标志的等价物是什么？
【问题讨论】：
-
MinGW 代表“minimalist GNU”，它的设计理念是提供尽可能少的标准库支持的方式，宁愿重定向到其他库实现如msvc。如果您想要一个独立于 msvcrt 的完整实现（编译器和库），那么 mingw 不是要查看的项目
-
你在这方面有什么进展吗？
-
@Royi：不，我放弃了，对不起。我尝试了无数的东西，没有一个奏效:(
标签： dll windows-xp static-linking mingw-w64 msvcrt