[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-):

 Thanks for the experiment. I was attempting to get an interim version out
 for GHC `8.0` hence the attempt to re-use weak-symbols to get specifically
 `libmingwex` to link.

 As I have missed that Window anyway I will instead target `8.2` and do a
 proper fix of the link behavior along with other changes that are required
 for other tickets.

 The behavior you described is correct, `ld` is using `libBFD` for symbol
 resolving. So the resolution behavior is described there.
 http://ftp.gnu.org/old-gnu/Manuals/bfd-2.9.1/html_mono/bfd.html#SEC149
 Describes how the different kind of symbols are resolved.

 Also you can just ask `ld` directly. `--print-map` will print out how it's
 resolving symbols. (If called via `GCC` use `-Wl,--print-map`).

 > I think because of this 2nd difference we end up with all kinda strange
 unresolved symbols like __image_base and similar which cause so much
 problems.

 We'll have to resolve this symbol in any case. `__image_base` is an `ld`
 symbol that it inserts during linking, if we want to load `mingw` object
 files we have to deal with it. This is easy to resolve anyway. It's just
 `IMAGE_DOS_HEADER` in the final link.

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