#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