I'm trying to load my .hs file but when I import Data.Numbers.CReal, it gives me the error Failed to load interface for 'Data.Numbers.CReal'. I have runned cabal install numbers and if I cabal list --installed the number pkg appears, but if I ghc-pkg list it doesn't (also if I ghc-pkg checkit gives LOTS of haddock warnings). Is it related to my non-loading file? How can I solve this?
Ps. I know how to import packages, but I'm not sure if I am importing this one properly.
Thanks and sorry if I didn't explained myself correctly.
Two hypotheses spring to mind:
cabalis choosing a different version ofghcand its attending toolsuite than your shell is. You can check for this discrepancy by running these two commands:Do they say the same thing? If so, reject this hypothesis. Otherwise you should decide whether you like the shell's choice or cabal's choice better (I recommend preferring your shell's choice).
If you like
cabal's choice better, you can use a specific version of GHC (and other GHC tools) by appending-<version>to the command; e.g. tryghc-pkg-7.10.3 listto see what is in the package database for version 7.10.3, orghci-7.10.3to run a specific version of the REPL. You can make these changes permanent by adding symlinks or similar to yourPATH.If you like your shell's choice better, you can ask
cabalto use that version withcabal configure -w ghc; or if you are worried thatcabaland your shell will resolveghcdifferently, you could ask for a specific version withcabal configure -w ghc-7.10.3or similar.Your shell agrees with
cabalabout what version of GHC to use, but you are in a cabal sandbox.cabal list --installedis telling you what's installed in the sandbox, butghc-pkg listis telling you what's installed in your user package database. You can check for discrepancies between these two commands:(If you have a newish cabal -- not sure which version this appeared in -- you could also try
cabal hc-pkg listinstead ofcabal exec -- ghc-pkg list. This is likely to be the more forward-compatible way, so a good habit to develop.)If these print the same things, reject this hypothesis. Otherwise you should decide whether you want to continue using a sandbox or not (I recommend continuing to use a sandbox).
If you want to stop using a sandbox, you can pass
--ignore-sandboxtocabal. To make this permanent, look in thecabal.sandbox.configfile, which will contain a pointer to the actual sandbox (usually.cabal.sandbox). Delete both the config and the sandbox. You can also globally ignore sandboxes by addingignore-sandbox: Trueto your~/.cabal/config, but I strongly recommend against this.If you want to keep the sandbox, you will need to use
cabal execfor all of your GHC toolsuite needs to make sure the correct package database is selected. For example, trycabal exec ghcito run the REPL with access to the sandbox package database.These hypotheses are not mutually exclusive: both may happen. In that case I strongly recommend choosing the final solution ("use
cabal execfor all GHC toolsuite executions"), as it handles both problems transparently: the standard GHC toolsuite commands will be rewritten to refer to explicitly versioned ones (e.g.cabal exec ghcwill actually executeghc-7.10.3) and the environment will be set up to point at the correct package database.