[GHC] #13093: Runtime linker chokes on object files created by MSVC++

[GHC]

#13093: Runtime linker chokes on object files created by MSVC++
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  Phyx-
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.2.1
       Component:  Runtime System    |              Version:  8.0.1
  (Linker)                           |
      Resolution:                    |             Keywords:
Operating System:  Windows           |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  GHCi crash        |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #13103            |  Differential Rev(s):  Phab:D3026
       Wiki Page:                    |  Phab:D3027 Phab:D3082 Phab:D3028
-------------------------------------+-------------------------------------

Comment (by Ben Gamari <ben@…>):

 In [changeset:"41e54b4b1a2934364759edcf77ba1f5b03a4098f/ghc"
 41e54b4b/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="41e54b4b1a2934364759edcf77ba1f5b03a4098f"
 Load dependent dlls.

 When the `GCC` driver envokes the pipeline a `SPEC` is used to determine
 how to configure the compiler and which libraries to pass along.

 For Windows/mingw, this specfile is
 https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/mingw32.h

 This has a lot of interesting things that we need to emulate in order to
 be able to link as many things out of the box as GCC. In particular this
 is why you never need to specify `-lgcc_s` when compiling, but you do
 when using `GHCi`.

 Unfortunately due to time constraints I can't set up the framework
 required in `GHC` to do this before the feature freeze.

 So I suggest this alternate implementation:
 When we load a dll, also bring it's dependencies into scope of the
 interpeter.

 This has pros and cons. Pro is, we'll fix many packages on hackage which
 specify just `-lstdc++`. Since this points to `libstdc++-6.dll` which
 will bring `libgcc` into scope.

 The downside is, we'll be more lenient than GCC, in that the interpreter
 will link much easier since it has implicit dependencies in scope.
 Whereas for compilation to work you will have to specify it as an
 argument to GHC.

 This will make the Windows runtime linker more consistent with the unix
 ones. The difference in semantics came about because of the differences
 between `dlsym` and `GetProcAddress`.  The former seems to search the
 given library and all it's dependencies, while the latter only searches
 the export table of the library. So we need some extra manual work to
 search the dependencies which this patch provides.

 Test Plan:
 ```
 ./validate
 ```
 ```
 $ echo :q | inplace/bin/ghc-stage2.exe --interactive +RTS -Dl -RTS
 -lstdc++ 2>&1 | grep "Loading dependency"
 ```

 ```
 $ echo :q | ../inplace/bin/ghc-stage2.exe --interactive -lstdc++ +RTS
 -Dl -RTS 2>&1 | grep "Loading dependency"
 Loading dependency *.exe -> GDI32.dll.
 Loading dependency GDI32.dll -> ntdll.dll.
 Loading dependency *.exe -> KERNEL32.dll.
 Loading dependency KERNEL32.dll -> KERNELBASE.dll.
 Loading dependency *.exe -> msvcrt.dll.
 Loading dependency *.exe -> SHELL32.dll.
 Loading dependency SHELL32.dll -> USER32.dll.
 Loading dependency USER32.dll -> win32u.dll.
 Loading dependency *.exe -> WINMM.dll.
 Loading dependency WINMM.dll -> WINMMBASE.dll.
 Loading dependency *.exe -> WSOCK32.dll.
 Loading dependency WSOCK32.dll -> WS2_32.dll.
 Loading dependency WS2_32.dll -> RPCRT4.dll.
 Loading dependency libstdc++-6.dll -> libwinpthread-1.dll.
 Loading dependency libstdc++-6.dll -> libgcc_s_seh-1.dll.
 ```

 Trac tickets: #13093, #13189

 Reviewers: simonmar, rwbarton, austin, bgamari, erikd

 Reviewed By: bgamari

 Subscribers: rwbarton, RyanGlScott, thomie, #ghc_windows_task_force

 Differential Revision: https://phabricator.haskell.org/D3028
 }}}

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13093#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler