#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

#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: | -------------------------------------+------------------------------------- Comment (by Phyx-):

Well, I think you do. Not only vc-redist installers, but even separate files, if you need. According to ​https://msdn.microsoft.com/en- us/library/ms235299.aspx:

But MSVCRT.DLL is not C runtime: ​https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273 So

Yes and how would this work? You could call `ghc foo.hs` and the resulting `foo.exe` would not run because the required DLLs are not on your path. Doing this is a major deployment issue. And you're confusing two things. These are the distributable files. There's not enough for the compiler. For the compiler you'd need the appropriate import libraries as well which I don't think are in those packages (I haven't checked.). The licensing issue comes from the fact that we don't just use them to run, we also need to be able to link against them. So we need to redistribute some form of static code. linking to it is against MS guidance. The link explicitly says it's not the Visual C/C++ runtime. It is most definitely however a C runtime. Also I don't consider a blog post about it official policy. If Raymond Chen doesn't want people to link against it, he should provide a reasonable alternative.

But ok, I am not going to make holy war from it. My problem is that in my system MSVCRT.DLL just does not contain required exports (but 'numbered' msvcr90.dll does)

Then this is a bug in your application. GHC by default does not produce binaries that use symbols not provided by the dll. The mingw-w64 project goes to great lengths to make sure the import libraries for msvcrt do not contain symbols not available in as far back as XP. So either you hit a bug in their import library (which is certainly possible and has happened and should report it there with a repro) or the application is doing something weird. If you think it's us that are linking against a symbol that shouldn't be available by default, then that's a separate issue that I'm perfectly willing to address. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14537#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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: | -------------------------------------+------------------------------------- Comment (by johndoe):

That said, if you have an application that does not explicitly request to use this symbol you say is missing I'd be happy to take a look at this given a repro.

My application is Pandoc 2 (https://github.com/jgm/pandoc/) In imports table it has msvcrt.dll\_wsplitpath_s. msvcrt.dll in windows XP does not have this function (but has plain "_wsplitpath"). Pandoc built with old version of GHC does hot have this issue. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14537#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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: | -------------------------------------+------------------------------------- Comment (by Phyx-): Sorry for the delay, haven't had much time to spend on GHC. As you know we depend on GCC which gets it's crt definitions from the mingw-w64 project. As far as I am aware of, they were supposed to support XP until v5 of the crt release https://sourceforge.net/p/mingw-w64/mailman/message/35465862/ but this function was added in 2010: {{{ commit f532681f435090c3a0812bf02969821b211d5ca1 Author: Jonathan Yong <10walls@gmail.com> Date: Mon Aug 2 06:59:06 2010 +0000 2010-07-26 Jonathan Yong * lib32/msvcrt.def: Added secure and locale type symbols from Win7. * lib64/msvcrt.def: Likewise. git-svn-id: svn+ssh://svn.code.sf.net/p/mingw-w64/code/trunk@3079 4407c894-4637-0410-b4f5-ada5f102cad1 }}} Which is why it's using it. But while that means I could in theory have a workaround for XP for this, it won't do you much good. Starting with 8.6 we're going to use system APIs only available in Windows Vista SP1 and higher (which is our minimum supported version, but we'll likely be moving this to Windows 7 too). As @refold said we don't support XP anymore, and I don't think it's feasible for us to, it requires too many workarounds in the runtime, and in some cases just not having a feature. So while I could solve this particular issue, I'm sure it still won't be useable. Sorry. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14537#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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: | -------------------------------------+------------------------------------- Comment (by johndoe): I still want to resolve my issue. So I need to specify `-specs=<file>` in gcc commandline. How can I do it now? Is there some ghc config, or environment variable? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14537#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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: | -------------------------------------+------------------------------------- Comment (by johndoe): Well, I tried to modify `specs` directly, but project failed to build: I've got messagebox that `setup.exe` crashed. That was on my local machine, but the same you can see on appveyor: https://ci.appveyor.com/project/johnd0e/pandoc/build/1.0.79 I am not sure, maybe my `specs` file is not good: https://github.com/johnd0e/pandoc/blob/master/specs But it worked well with other project (not GHC). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14537#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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: | -------------------------------------+------------------------------------- Comment (by johndoe): Could you tell where exactly I should add `-v3`, as I do not call ghc directly? I can use `stack` or `cabal install`, but I simply do not know if I need to add `-v3` somewhere in config files, or specify in commandline. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14537#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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: | -------------------------------------+------------------------------------- Comment (by johndoe): Thanks. See log here https://ci.appveyor.com/project/johnd0e/pandoc/build/1.0.95 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14537#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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: | -------------------------------------+------------------------------------- Comment (by Phyx-): The specs file is fine: {{{ $ ghc -optl-specs=msvcrt100.specs test.hs -fforce-recomp [1 of 1] Compiling Main ( test.hs, test.o ) Linking test.exe ... }}} and checking {{{

dumpbin /imports test.exe | findstr msvcrt* msvcr100.dll msvcrt.dll }}}

You will need to change as I mentioned before `lib\package.conf.d\` the `base-*.conf` and the `ghc-prim-*.conf` files changing the extra-libraries part. To get rid of the remaining references to `msvcrt.dll`. I see you're replacing the default spec file, but the new one is quite small, so Id'd try just passing it to the compiler as an argument. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14537#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler