#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