[GHC] #14537: Do not link to msvcrt.dll

GHC ghc-devs at haskell.org
Tue Nov 28 18:23:31 UTC 2017


#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


More information about the ghc-tickets mailing list