[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
wren at freegeek.org
Sun Jun 7 20:51:32 EDT 2009
Mark Wassell wrote:
> 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 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.
 As of version 0.12.0.3 which is available from darcs:
The only differences between 0.12.0.3 and 0.12.0.1 are in the metadata
files: INSTALL, TODO, VERSION.
More information about the Haskell-Cafe