[GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL)

[GHC]

#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