[GHC] #11223: Dynamic linker on Windows is unable to link against libmingwex

[GHC]

#11223: Dynamic linker on Windows is unable to link against libmingwex
-------------------------------------+-------------------------------------
        Reporter:  Phyx-             |                Owner:  Phyx-
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:  8.2.1
       Component:  Runtime System    |              Version:  7.10.3
  (Linker)                           |
      Resolution:                    |             Keywords:
Operating System:  Windows           |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  crash                              |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #10726            |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Phyx-):

 It seems the RTS already has an import for `__mingw_raise_matherr` so just
 re-exporting it works.

 I also need to satisfy a few other symbols:

 {{{
       SymI_HasProto_redirect(_fputwc_nolock, fputwc)     \
       SymI_HasProto_redirect(_fgetwc_nolock, fgetwc)     \
       SymI_HasProto_redirect(fileno        , _fileno)    \
       SymI_HasProto_redirect(strdup        , _strdup)    \
 }}}

 Along with

 {{{
       SymI_HasProto(__mingw_raise_matherr)               \
       SymI_NeedsProto(mingw_app_type)                    \
 }}}

 Though I need to find a better solution for redirecting the `nolock`
 version of `fputwc` and `fgetwc` to the locking versions.

 Now I've reached a fork in the road: Some libraries like `base` require a
 few symbols in `mingwex`, however they don't seem to specify the libraries
 in their `package.conf`.

 Because packages are pre-loaded by the rts then the symbols aren't weak
 anything. Which means that again, `libmingwex` can't be linked.

 This leaves me with 3 options:

 1. Fix the entire dependency chain from packages like `base` on up. This
 is a large change but would be consistent.

 2. Add all symbols to the RTS as weak symbols in `ocGetNames_PEi386`.
 Which means every library we load will accept duplicate symbols. So long
 the symbols haven't been used yet. This would also "fix" #6107 . Doing
 this will allow you to link in `libmingwex` by just simply adding
 `-lmingwex -lgcc` to the compiler. This would also make `libmingw32` work.

 {{{
 Loading object (static archive)
 E:/msys64/home/Tamar/ghc2/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingwex.a
 ... done
 Loading object (static archive)
 E:/msys64/home/Tamar/ghc2/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/libgcc.a
 ... done
 final link ... done
 }}}

 3. Pre-load `libmingwex` and `libgcc` during the `initLinker` calls for
 `GHCi` as weak symbols. This will ignore the symbols we already have
 loaded (they come from `mingwex` anyway). This will fix `GHCi` as in,
 there's no change needed to use all symbols in `libmingwex`, but
 `libmingw32` won't work as it will fail on a duplicate symbols.

 These are the three options I currently see.

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