#14537: Do not link to msvcrt.dll -------------------------------------+------------------------------------- Reporter: johndoe | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: invalid | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => invalid Comment: Yes, MSVCRT IS a system component, and that is EXACTLY why you can depend on it being available. It is the only C runtime you can guarantee to be available on every version of Windows. Which is why we and GCC link against it by default. Historically (up until Vista) the Windows Driver Toolkits used their own compilers which linked against msvcrt as well. This to provide a backwards compatible way to write drivers and other system utilities. That is not to say the msvcrt.dll in Windows today is the same as it was before. It gets patched quite often. You have misunderstood the links you provided. The first off, the numbered versions are a component of the newer Visual Studio C++ Runtimes. Hence the versions. Each release is tied directly to a visual studio release. We do not have the rights to redistribute these files, so we cannot link against them by default. Also we don't know which one is available to use so portable distributions will not work. This is why applications compiled with Visual Studio typically *need* an installer. This would break workflows such as stack based ones, and require admin rights to install GHC. Your second link says this clearly at the top: {{{ Historically, Windows ports of gcc have used Microsoft's msvcrt.dll as the only available C runtime. This is not necessarily a bad idea, as it considerably simplifies deployment, and it gives gcc-compiled application the classical UNIX guarantee that all code in a given process shares the same version and instance of the C runtime library. However, the use of msvcrt.dll in Windows ports of gcc (Cygwin first, then MinGW) came with a large number of misconceptions. This article will attempt to correct them. }}} The MingW compilers use `msvcrt.dll` by default. Your third link even shows this. If you still don't believe that, this is the GCC source code for the mingw32 backend https://github.com/gcc- mirror/gcc/blob/trunk/gcc/config/i386/mingw32.h#L142 We do not rely on the runtime for newer functionaly (such as C99 functions). We explicitly link against `libmingwex` for this exact reason. However we still need to link against the runtime to get basic things like `malloc`. Just like GCC, your own applications don't have to depend on this. We use GCC for the final compilation, so the exact same workaround GCC uses can be used for your own programs. e.g. you have to provide GCC with a custom SPEC file to tell it what you want to link against. You however cannot get GHCi to do this, since we load system libraries which have a transitive dependency on msvcrt. And you can't mix and match these libraries as each contain different allocators. Lastly: {{{ it should be either msvcrVERSION.dll if you're using dynamic linkage or nothing if you're using static. }}} Is wrong. See https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx You always need a C runtime. for static linking with Microsoft compilers when you specify `/MT` (e.g. static linking) you get `libcmt.lib` linked in, which is the static version of the runtime. Dynamic linking `/MD` gets you `msvcrt.lib` which is an import library pointing to the appropriate version of the numbered msvcrt. However, again we compile with GCC which does not provide a statically linked runtime for Windows. (GLIBC doesn't work on Windows). And unless we switch our compiler to the Microsoft ones we cannot use the ones distributed with the compilers. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14537#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler