[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