#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-): Loading the symbols earlier seems like it will work. The issue now is that a horrible design decision with `libmingwex` is causing us to have to link in far more than expected. [http://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/4FDD7839.... libmingwex] has a depencency on the symbol `__mingw_raise_matherr`. This symbol is defined in `libmingw32` which is where the fun begins.. We also end up needing the `ld` symbol `__image_base__` because of these dependencies and ultimately `libmingw32` also requires `wWinMain` which is the only symbol I don't know what to do about. The list of needed libraries: * libgcc.a * libws2_32.a * libmingw32.a * user32.dll * Advapi32.dll I'll keep looking, but we may want to consider re-distributing `msvcrt120.dll` which would also have all the symbols we need. It seems like the license for `Visual Studio 2013 C++ Redistributables` might [https://msdn.microsoft.com/en-us/vstudio/dn501987 allow] this now. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11223#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler