plugins package unknown symbol when using cabal

Viewed 494

I'm messing around with the plugins package however I bumped into a problem.

Here's the code:

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)

This all works fine then compiling with ghc. Building with Cabal works fine as well, but when I run the executable I get this 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.)

My very minimalistic cabal file:

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

Now I assume the problem is that it can't find the "ErrUtils" module which is part of the ghc package installed in /usr/lib/ghc-7.x.x. Since it's using cabal it'll use the $HOME/.cabal/lib/ instead.

Now I obviously wouldn't want to use /usr/lib if I wanted to make it distributable. Sadly I'm not very familiar with how packages are managed nor am I familiar with the plugins package.

I have a feeling this is extremly nooby but I wasn't able to find a solution myself.

So a few questions:

  1. How can I get my dependencies to work in a way to make this distributable?
  2. It seems I'll need to know beforehand what my Plugin.o files will depend on before actually being able to use them (If I understand correctly). Is there a way to package a .o files that I wouldn't have to worry about this problem? (Sorry if this question is too vague, feel free to ignore)

Thanks in advance!

2 Answers
Related