Haskell, GHC, win32, cairo
Asked Answered
J

2

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?

Jimenez answered 1/2, 2011 at 10:53 Comment(7)
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" - haskell.org/pipermail/haskell-cafe/2011-January/088697.html. I'm sorry I don't know the resolution.Protohuman
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)?Lining
Could be a stdcall/ccall mismatch. Does the symbol name in the DLL have a suffix like @4?Soluble
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.Jimenez
As for library, nm for this symbol gives: "68df9f58 T _cairo_surface_destroy". I see nothing wrong and symbol is defined. Library is taken fromJimenez
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: hackage.haskell.org/trac/ghc/ticket/3951Sparge
What if you use ghci after compiling it, and loading the compiled code?Henshaw
C
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.

Caldeira answered 28/9, 2012 at 17:8 Comment(0)
S
0

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

Sallyanne answered 4/2, 2011 at 13:30 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.