ghci: can't load .so/.DLL for: m (addDLL: could not load DLL)

[jeffz1]

On Windows, when attempting to use Hipmunk from ghci, it produces the error:

ghci: can't load .so/.DLL for: m (addDLL: could not load DLL)

To reproduce:

cabal install Hipmunk
ghci
:m + Physics.Hipmunk
initChipmunk

Presumably this has something to do with there being no libm on Windows.

[igloo]

Thanks for the report.

The hipmunk cabal file unconditionally says

Extra-Libraries: m

so this is a bug in hipmunk, not GHC.

[jeffz1]

Ah, if it's a bug in hipmunk, do you have any idea of the correct approach?

I tried modifying Hipmunk's .cabal to instead be:

if !os(windows) {

Extra-Libraries: m

}

cabal configure, cabal build, cabal install in ghci, if I try initChipmunk again, I get:

Loading package syb ... linking ... <interactive>: C:\Program Files\Haskell\Hipm unk-0.2.2\ghc-6.10.2\HSHipmunk-0.2.2.o: unknown symbol `_fmodf' : unable to load package `syb'

So I guess that isn't correct either. GHC works fine with m or without m, it's just ghci that has the issue.

[meteficha]

Hello, igloo!

I'm Hipmunk's maintainer and it has been almost two months since you've closed this bug saying that this is a bug in Hipmunk but not saying what should be done on Hipmunk's side. I'm reopening it because I too believe that this is a bug on GHCi's side. I'll be happy to "fix" Hipmunk if you say how to do so, though.

Thanks, Felipe.

[igloo]

I'm afraid I don't know how to do this on Windows, but I still don't see a GHC bug here: If you tell GHC that you need a library that doesn't exist then you will get the above error message.

Please reopen this ticket and give more details if you believe that there is a GHC bug causing this problem.

[jwlato]

I'm reopening this because I'm getting the same behavior with ghc-7.0.1 and the package "ieee-0.7", which also specifies a dependency on "m".

It appears that libm is distributed as part of the MinGW stuff with ghc; I see the file "/e/ghc/ghc-7.0.1/mingw/lib/libm.a". Compiling with ghc passes the flag "-lm" during the linking step and works properly. It's only when using ghci that the library can't be found. If I install the ieee package without the libm dependency programs still build with ghc, but ghci complains about missing symbols.

[fryguybob]

After a little investigation I have discovered that on MinGW libm.a is dummy library to satisfy -lm. The desired code is in libmingwex.a which gets linked when compiling with ghc. Changing to Extra-Libraries: mingwex does not help as ghci looks for DLL to satisfy that. I'm not sure how to get libmingwex.a to load with ghci. If you turn libmingwex.a into a dll:

ar -x libmingwex.a
gcc -shared *.o -o mingwex.dll

Then everything works.

[keloglan2011]

fryguybob's solution worked. Thanks fryguybob. :)

(renaming mingwex.dll to m.dll and putting it in your path solves it without recompiling anything )

[simonmar]

I think this should work with 7.4.1. Loading .a files in GHCi on Windows now works (it didn't before). Please re-open if you find there's still a bug.

[schernichkin]

The problem still exists on Windows. Mostly caused by ieee754 and other libraries refered m. Compiler works just fine the problem only with ghci.

[simonmar]

Can you give us instructions to reproduce the problem please?

[schernichkin]

Replying to simonmar:

Can you give us instructions to reproduce the problem please?

Sure.

1. Install any library relying on m. Lets take ieee754. 2. Start GHCi, import Numeric.IEEE. 3. Type "minNormal :: Float"

You will get following output:

Loading package ieee754-0.7.3 ... <interactive>: m: The specified module could not be found. can't load .so/.DLL for: m.dll (addDLL: could not load DLL)

I got it on GHCi, version 7.4.1, but I believe the bug exists on more recent versions to.

[nus]

MinGW's libm is a dummy object file to satisfy unix'ish linkers,the actual symbols are provided by the C runtime library (msvcrt.dll),which gets linked in both when compiled/dynamically loaded by GHCI. There's no need to mention libm in 'extra-libraries'. The patch was tested on GHC 7.4.2.

[nus]

Pardon, the patched Hipmunk library was tested. The test was

import Physics.Hipmunk

main = initChipmunk

which didn't fail.

[nus]

Turns out that besides msvcrt also mingwex carries some actual symbols needed for IEEE754 compliance (f.e. 'copysignf'). When we mention libm in 'extra-libraries'(which is not necessary), the dummy libm.a gets linked in, but the symbols references are satisfied by both mingwex/msvcrt. In the compiled case the libraries are introduced into the linkage by the built-in gcc specs. In the ghci case the linkage succeeds if the symbols references get satisfied by msvcrt (which is always preloaded by ghci), and fails if the symbols happen to live in mingwex (which ghci knows nothing about). Also see ticket #1883.

[nus]

The reference to an undefined symbol _copysignf is a result of a foreign import in IEEE.hs:

$ nm ieee754-0.7.3/ghc-7.4.2/HSieee754-0.7.3.o |grep copysignf
         U _copysignf
[..snip...]

ieee754-0.7.3/Numeric/IEEE.hs:
[...snip...]
foreign import ccall unsafe "copysignf"
[...snip...]

$ cabal build
[...snip...]
Building ieee754-0.7.3...
[...snip...]
compile: input file .\Numeric\IEEE.hs
[...snip...]
*** Stg2Stg:
*** CodeGen:
*** CodeOutput:
*** Assembler:
"C:\mnt\data1\ghc32b\lib/../mingw/bin/gcc.exe" "-fno-stack-protector" "-Wl,--hash-size=31" "-Wl,--reduce-memory-overheads" "-I.\Numeric" "-Idist\build" "-Idist\build\autogen" "-Idist\build" "-c" "C:\Users\adm\AppData\Local\Temp\ghc3328_0\ghc3328_0.s" "-o" "dist\build\Numeric\IEEE.o"
[...snip...]

$ grep _copysignf /tmp/ghc3588_0/ghc3588_0.s
        call _copysignf
        call _copysignf

$ nm dist/build/Numeric/IEEE.o |grep copysignf
         U _copysignf
00000078 D _ieee754zm0zi7zi3_NumericziIEEE_czucopysignf_closure
00001038 T _ieee754zm0zi7zi3_NumericziIEEE_czucopysignf_info