haskell - mac - Complementos paquete símbolo desconocido al usar cabal

haskell core download

Question

Estoy jugando con el paquete de complementos, sin embargo, me encontré con un problema.

Aquí está el código:

Util / Header.hs

module Util.Header(PT(..)) where

data PT a = PT a deriving Show

Plug.hs

module Plug(helloPlugin) where
import Util.Header
helloPlugin :: PT Int
helloPlugin = PT 1

Main.hs

module Main where

import Util.Header
import System.Plugins

main :: IO ()
main = do
    mv <- load "Plug.o" ["."] [] "helloPlugin"
    case mv of
        LoadFailure msg -> print msg
        LoadSuccess _ v -> print $ show (v :: PT Int)

Todo esto funciona bien y compilando con ghc. Construir con Cabal también funciona bien, pero cuando ejecuto el ejecutable obtengo este error:

plugintest: /home/kevin/.cabal/lib/plugins-1.5.4.0/ghc-7.6.3/HSplugins-1.5.4.0.o: unknown symbol `ghczm7zi6zi3_ErrUtils_zdsinsertzuzdsgo5_info''
plugintest: user error (resolvedObjs failed.)

Mi muy cabalístico archivo minimalista:

name:                plugintest
version:             0.1.0.0
license-file:        LICENSE
build-type:          Simple
cabal-version:       >=1.8

library
  hs-source-dirs: src
  exposed-modules: Util.Header
  build-depends:  base ==4.6.*, plugins ==1.5.*

executable plugintest
  main-is: Main.hs
  build-depends:  base ==4.6.*, plugins ==1.5.*, plugintest == 0.1.0.0
  hs-source-dirs: src

Ahora supongo que el problema es que no puede encontrar el módulo "ErrUtils" que es parte del paquete ghc instalado en /usr/lib/ghc-7.xx. Como usa cabal, usará $ HOME / .cabal / lib / en su lugar.

Ahora, obviamente, no me gustaría utilizar / usr / lib si quisiera hacerlo distribuible. Lamentablemente, no estoy muy familiarizado con la forma en que se administran los paquetes ni estoy familiarizado con el paquete de complementos.

Tengo la sensación de que esto es extremadamente novedoso, pero no pude encontrar una solución yo mismo.

Entonces algunas preguntas:

1. ¿Cómo puedo hacer que mis dependencias funcionen de manera de hacer que esto sea distribuible?
2. Parece que necesitaré saber de antemano de qué dependerán mis archivos de Plugin.o antes de poder usarlos realmente (si lo entiendo correctamente). ¿Hay alguna manera de empaquetar un archivo .o que no tenga que preocuparme por este problema? (Lo siento si esta pregunta es demasiado vaga, no dude en ignorarla)

¡Gracias por adelantado!

Answer 1

Debes declarar tus módulos exported- y other- para que Cabal pueda empaquetarlos todos juntos. Por ejemplo (de https://github.com/tel/happstack-heroku-test )

name:                hktest         -- note the name here names
                                    -- the *library* which is a package name
                                    -- in scope when building the executable

...

library
  exposed-modules:     
    HKTest
  other-modules:
    -- there aren''t any, but there could be some
  build-depends:       base                >= 4.6    && <4.7

                       ...

                     , mtl                 >= 2.1.2
  hs-source-dirs:      src

executable server
  main-is:             Server.hs
  other-modules:
    -- there might be some use to having these here,
    -- but they''ll be harder to get into GHCi, so I wouldn''t
    -- recommend it---just put them in the library part
  build-depends:       base >=4.6 && <4.7
                     , hktest                  -- note that I grab all the hktest
                                               -- modules here  
  hs-source-dirs:      exe

Si omito uno de esos módulos, es probable que obtenga un error de compilación cuando Cabal compile archivos que esperan poder encontrar símbolos que no se hayan empaquetado.

En su caso, dado que está construyendo un ejecutable, el patrón común ejemplificado anteriormente es poner todo su código en una biblioteca y luego hacer que el lado ejecutable dependa de esa biblioteca. Por ejemplo, en este ejemplo, el texto completo de exe/Server.hs es

module Main where

import qualified HKTest as HK

main :: IO ()
main = HK.main

Answer 2

Bien, entonces tuve exactamente el mismo problema. Aquí hay una solución que encontré

Cambiar la llamada de carga a

load "Plug.o" [".","dist/build/plugintest/plugintest-tmp"] [] "testplugin"

Asegúrese de compilar la cosa con -c o usando la biblioteca "make" de los complementos.

Muy molesto por esto ... El error sugiere que está teniendo problemas para vincularse con las librerías estándar, entonces ¿por qué mostrarlo estos archivos .o lo corrige? De todos modos, esto funcionó para mí, y no requirió mucha tontería con los archivos .cabal.