问题
I have some C++ code that I compile to various platforms, namely Linux 32/64 bits, Windows 32/64 bits. For the Windows part, I use the latest gcc compiler provided by mingw-w64 package. The trouble I am having is that the 32-bit compilation drags the libc API that Microsoft provides through msvcrt.dll, and that DLL has some problems:
- is not distributable (it comes with Windows and is not replaceable)
- has versions (every Windows version has a different one, with added functionality)
- it depends on other Windows DLLs, meaning the ecosystem of libraries that are around that particular version of the DLL, that are part of the system too.
mingw uses a specific version, so it won't run by default on older versions, for example in Windows XP: it will require entry points to non-existent APIs.
I tried linking statically, but to no avail, msvcrt.dll always gets dragged (-static, -static-libgcc, -static-libstdc++, you name it).
I tried, rather candidly, replacing the msvcrt.dll that comes with Windows XP with one that works in a more recent Windows version, but that prevents Windows XP from booting at all.
I tried copying the correct msvcrt.dll to my executable path, but as it is a library everybody uses, it's already loaded and Windows won't load another instance from a different file.
I tried patching my executable so it will call the same DLL but with a different name and so fool Windows to load a more recent version only for my executable, and that first step works, but it starts a nightmare of DLL dependencies that can never be satisfied, because it will bring in other system libraries like ntdll.dll that also have to be patched and so on.
I tried browsing through several questions on this topic here and in different forums regarding this same problem, but everything boils down to the idea that msvcrt.dll is a library that you should not worry about, but that is simply not true, there is a plethora of compatibility problems about it.
I am aware that mingw is slowly leaving behind older operating systems like Windows XP, but I would really like a solution to a problem that should not to be as complicated as it seems. I started by downgrading mingw-w64-i686-libwinpthread and mingw-w64-i686-winpthreads from the current 7.0.0.5325 down to a not so far away 7.0.0.5273 to avoid a call to GetTickCount64(), an API introduced in Vista. Once I fixed that, it asks me for _mkgmtime32(), from msvcrt.dll, that was introduced in version 7 of the DLL, and that obviously is not present in the DLL that comes with Windows XP.
I am aware as well that I want to use C++17 with an operating system that is almost 20 years old, but it is overwhelmingly popular still, at least in the third world. Anyone has any insight about this?
Summary
Is there a way to link to the static multi threaded VC Runtime Library when using MinGW64?
What's the equivalent of /MT flag in visual Studio when using MinGW64?
回答1:
- Latest Visual Studio 2019 still supports Windows XP with special vc141_xp "toolset". You are able to redistribute latest "Universal CRT" on XP.
- MinGW is able to link with Universal CRT - you no need to use old msvcrt.dll at all, you can link with any msvcrXX.dll or modern ucrtbase.dll as described on link above and it will work on Windows XP.
来源：https://stackoverflow.com/questions/55728544/how-to-avoid-msvcrt-dll-compiling-with-mingw64