Opened 5 years ago

Last modified 19 months ago

#3242 new bug

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

Reported by: jeffz1 Owned by:
Priority: normal Milestone: 7.6.2
Component: GHCi Version: 7.4.1
Keywords: Cc: felipe.lessa@…, jwlato@…
Operating System: Windows Architecture: x86
Type of failure: None/Unknown Difficulty: Unknown
Test Case: Blocked By: #3658
Blocking: Related Tickets: #7097

Description (last modified by igloo)

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.

Attachments (1)

hipmunk-mingw.patch (519 bytes) - added by nus 21 months ago.

Download all attachments as: .zip

Change History (25)

comment:1 Changed 5 years ago by igloo

  • Difficulty set to Unknown
  • Resolution set to invalid
  • Status changed from new to closed

Thanks for the report.

The hipmunk cabal file unconditionally says

Extra-Libraries: m

so this is a bug in hipmunk, not GHC.

comment:2 Changed 5 years ago by 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.

comment:3 Changed 5 years ago by meteficha

  • Resolution invalid deleted
  • Status changed from closed to reopened

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.

comment:4 Changed 5 years ago by meteficha

  • Cc felipe.lessa@… added

comment:5 Changed 5 years ago by igloo

  • Description modified (diff)

comment:6 Changed 5 years ago by igloo

  • Resolution set to invalid
  • Status changed from reopened to closed

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.

comment:7 Changed 3 years ago by jwlato

  • Resolution invalid deleted
  • Status changed from closed to new
  • Type of failure set to None/Unknown
  • Version changed from 6.10.2 to 7.0.1

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.

comment:8 Changed 3 years ago by jwlato

  • Cc jwlato@… added

comment:9 Changed 3 years ago by igloo

  • Milestone set to 7.0.3

comment:10 Changed 3 years ago by 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.

comment:11 Changed 3 years ago by keloglan2011

  • Status changed from new to patch

fryguybob's solution worked. Thanks fryguybob. :)

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

comment:12 Changed 3 years ago by igloo

  • Milestone changed from 7.2.1 to 7.4.1

comment:13 Changed 2 years ago by simonmar

  • Resolution set to fixed
  • Status changed from patch to closed

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.

comment:14 Changed 2 years ago by schernichkin

  • Resolution fixed deleted
  • Status changed from closed to new
  • Version changed from 7.0.1 to 7.4.1

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

comment:15 follow-up: Changed 2 years ago by simonmar

  • Milestone changed from 7.4.1 to 7.4.2

Can you give us instructions to reproduce the problem please?

comment:16 in reply to: ↑ 15 Changed 2 years ago by 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.

comment:17 Changed 23 months ago by igloo

  • Milestone changed from 7.4.2 to 7.4.3

Changed 21 months ago by nus

comment:18 Changed 21 months ago by nus

  • Status changed from new to patch

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.

comment:19 Changed 21 months ago by nus

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

import Physics.Hipmunk

main = initChipmunk

which didn't fail.

comment:20 Changed 21 months ago by nus

  • Status changed from patch to new

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.

comment:21 Changed 21 months ago by 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

comment:22 Changed 21 months ago by nus

comment:23 Changed 20 months ago by igloo

  • Blocked By 3658 added

comment:24 Changed 19 months ago by igloo

  • Milestone changed from 7.4.3 to 7.6.2
Note: See TracTickets for help on using tickets.