10

I have problem with ghci+cairo on windows. When I try to load, for example like this "ghci -package cairo" it fails with the following error:

Loading package random-1.0.0.2 ... linking ... done.
Loading package haskell98 ... linking ... done.
Loading package syb-0.1.0.2 ... linking ... done.
Loading package base-3.0.3.2 ... linking ... done.
Loading package mtl-1.1.0.2 ... linking ... done.
: C:\Users\alexeys\AppData\Roaming\cabal\cairo-0.12.0\ghc-6.12.3\HScairo-0.12.0.o: unknown symbol `_cairo_surface_destroy'
Loading package cairo-0.12.0 ... linking ... : unable to load package `cairo-0.12.0'

Even simplest programs don't work in interactive mode, like for example 'Text.hs' that comes with cairo package. However compiled with 'ghc --make' everything works as expected, so its not a "missing dll" problem - everything is in place.

I used 'filemon' to look what "ghci" loads and in the log I can see 'libcairo-2.dll' (and this library has '_cairo_surface_destroy' symbol defined) being found and loaded successfully, so I don't really understand - what more does it wants?

dilettant
  • 399
  • 2
  • 6
  • Maybe it as a 'threading' problem? There was a recent Haskell-cafe thread about the SOE graphics library exhibiting similar behaviour "Code from Haskell School of Expression Hanging" - http://www.haskell.org/pipermail/haskell-cafe/2011-January/088697.html. I'm sorry I don't know the resolution. – stephen tetley Feb 01 '11 at 12:28
  • By any chance is libcairo-2.dll in a location with spaces in the pathname? Also could you please post which version of ghci you're using (this looks like a linker bug in any case)? – John L Feb 01 '11 at 16:46
  • 1
    Could be a `stdcall`/`ccall` mismatch. Does the symbol name in the DLL have a suffix like `@4`? – Simon Marlow Feb 01 '11 at 21:26
  • I'm using ghc 6.12.3 which comes with HaskellPlatform 2010.2.0.0. 'libcairo-2.dll' is in C:\GTK\bin, no spaces or anything. More, I looked with 'filemon' at what ghci does and in there it is can be seen that it loads this library in the process - so probably not a library location problem. – dilettant Feb 04 '11 at 15:43
  • As for library, nm for this symbol gives: "68df9f58 T _cairo_surface_destroy". I see nothing wrong and symbol is defined. Library is taken from – dilettant Feb 04 '11 at 15:47
  • Can you use nm to check if the symbol is defined in one of the .o files (probably Graphics/Rendering/Cairo/Internal/Surfaces/Surface.o) but not in HScairo-0.12.0.o? Your bug report looks similar to this one: http://hackage.haskell.org/trac/ghc/ticket/3951 – Jason Dagit Sep 18 '11 at 18:48
  • What if you use ghci after compiling it, and loading the compiled code? – Theo Belaire Oct 22 '11 at 19:51

2 Answers2

2

I suspect you're running into many of the issues I just did.

I tried to do something recently with Haskell and ZeroMQ on windows. GHC runs on Windows, and ZeroMQ has a MingW32 port, and there is a standard ZeroMQ Cabal package, so I thought this would work.

However:

  • GHC only has partial support for dynamic linking on Windows. See here.
  • The ZeroMQ Cabal package depends on the static version of libzmq.
  • GHC on Windows uses MingW32 conventions for its libraries and dll's.
  • ZeroMQ only builds a dynamic .dll in their MingW32 port, not a .a static archive.

I could not make all the pieces fit together, so no Haskell-based ZeroMQ coding on my windows box.

NovaDenizen
  • 5,089
  • 14
  • 28
0

Please run ghc-pkg check to see if it is consistent

Hartmut Pfarr
  • 5,534
  • 5
  • 36
  • 42