Haskell, GHC, win32, cairo

Tengo un problema con ghci + cairo en windows. Cuando intento cargar, por ejemplo como este "Cairo ghci -package de" falla con el siguiente error:Haskell, GHC, win32, cairo

 
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'

Incluso los programas más simples no funcionan en modo interactivo, como por ejemplo 'Text.hs' que viene con el paquete de cairo Sin embargo compiló con 'ghc --make' todo funciona como se esperaba, por lo que no es un problema de "falta dll": todo está en su lugar.

Utilicé 'filemon' para ver qué carga "ghci" y en el registro puedo ver 'libcairo-2.dll' (y esta biblioteca tiene el símbolo '_cairo_surface_destroy' definido) que se encuentra y se carga con éxito, por lo que Realmente entiendo, ¿qué más quiere?

Fuente

2011-02-01 dilettant

¿Quizás sea un problema de "subprocesamiento"? Hubo un hilo reciente de Haskell-cafe sobre la biblioteca de gráficos SOE que muestra un comportamiento similar "Código de Haskell School of Expression Hanging" - http://www.haskell.org/pipermail/haskell-cafe/2011- enero/88697.html. Lo siento, no sé la resolución. –

¿Por casualidad libcairo-2.dll está en una ubicación con espacios en la ruta? También podría publicar qué versión de ghci está utilizando (esto parece un error de enlazador en cualquier caso). –

Podría ser un desajuste 'stdcall' /' ccall'. ¿El nombre del símbolo en el DLL tiene un sufijo como '@ 4'? –

Por favor, ejecute cheque GHC-paquete para ver si es compatible

Fuente

2011-02-04 13:30:22 Hartmut

Es consistente. – dilettant

Sospecho que se está ejecutando en muchas de las cuestiones que acabo de hacer.

Intenté hacer algo recientemente con Haskell y ZeroMQ en Windows. GHC se ejecuta en Windows, y ZeroMQ tiene un puerto MingW32, y hay un paquete ZeroMQ Cabal estándar, así que pensé que esto funcionaría.

Sin embargo:

GHC solamente tiene soporte parcial para la vinculación dinámica en Windows. Ver here.
El paquete ZeroMQ Cabal depende de la versión estática de libzmq.
GHC en Windows usa las convenciones MingW32 para sus bibliotecas y dll.
ZeroMQ solo crea un .dll dinámico en su puerto MingW32, no un archivo estático .a.

No pude unir todas las piezas juntas, por lo que no hay codificación basada en Haskell ZeroMQ en mi caja de Windows.

Fuente

2012-09-28 17:08:54 NovaDenizen

Respuesta

Cuestiones relacionadas