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
#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`). 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