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