[Haskell-cafe] ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) / is there a libm.dll for Windows

[wren ng thornton]

Mark Wassell wrote:
> Hello,
> 
> I get this when using the logfloat package via ghci on Windows. For example
> 
> *Main> :m + Data.Number.LogFloat
> *Main Data.Number.LogFloat> logFloat (1.0::Float)
> Loading package syb ... linking ... done.
> Loading package array-0.2.0.0 ... linking ... done.
> Loading package logfloat-0.12.0.1 ... can't load .so/.DLL for: m 
> (addDLL: could not load DLL)
> *Main Data.Number.LogFloat>
> 
> When compiling the program using ghc, it works fine. This was previously 
> reported as a ghc bug http://hackage.haskell.org/trac/ghc/ticket/3242 
> where the reporter was getting the message using hipmunk. The ticket was 
> closed as the issue was deemed to be a bug in hipmunk, not GHC.
> 
> As the ticket reporter asked, what is the correct approch to get around 
> this? I have tried specifying -lm on ghci startup line but my system 
> doesn't seem to have a libm.dll or anything similar. Is there such a thing?


I don't know about a general solution, but I'd love to hear one.

This is a known issue for the logfloat package using GHCi on Windows, 
documented[1] in the ./INSTALL file under the Windows FFI section. When 
using the compiler, the C functions are provided by libmingwex.a which 
is bundled with GHC, but for some reason the interpreter doesn't find 
the same library.

If you need to run code in GHCi and want a workaround, you can recompile 
the library disabling the use of the FFI by passing the -f-useFFI flag 
to `runhaskell Setup.hs configure`. (I'm not sure how to do that if 
you're using the cabal-install tool.) This will degrade the precision of 
miniscule LogFloat values, but should otherwise work fine.


[1] As of version 0.12.0.3 which is available from darcs:

     http://community.haskell.org/~wren/logfloat

The only differences between 0.12.0.3 and 0.12.0.1 are in the metadata 
files: INSTALL, TODO, VERSION.

-- 
Live well,
~wren