#3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------+-------------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Revisions: ---------------------------------+-------------------------------- Changes (by WrenThornton): * priority: normal => high * cc: wrengr (added) Comment: @oerjan Yes, I've long known about and documented this problem in the INSTALL/README file for the logfloat package. It's always been there in the repo and tarball, but hopefully is more visible now that Hackage has links to readme files. There used to be another ticket for this problem, though I lost the ticket number over the years so the readme only gives a short description of the problem (i'll add this ticket number to the readme once I get home). The long description of the situation so far as I'm aware/concerned is: For *compiled* code, everything works perfectly fine— without the need for Cygwin or Mingw/Msys or any of that. The problem is specifically with GHCi. The C functions that logfloat needs live in what posix calls "libm", thus we have "Extra-Libraries: m" in the cabal file. However, as nus mentions, MinGW's so-called "libm" file (which ships with GHC) is just a dummy header with no actual content; therefore the cabal file is useless here. The actual symbols/C-code lives in the libmingwex.a library (which also ships with GHC). When compiling, libmingwex.a is picked up automagically and so everything works; whereas when using the interpreter, libmingwex.a is ignored and the loading error is generated. This bug has been a thorn in my side for years. I don't use Windows, but I have many users who do and who have to work around the problem on a daily basis. The only feasible workaround at present is to compile logfloat without FFI support (thereby eliminating most of the precision which is the entire point of the library) in order to do any sort of interactive debugging or development, and then hopefully remembering to recompile logfloat and everything that depends on it (to get precision) before shipping. I really wish we could just get this fixed already so I don't have to explain the sorry state of things to yet another machine learning / natural language processing person just trying out Haskell. This really makes a terrible impression on folks :( -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/3242#comment:35 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler