Unfortunately, I'm not getting a simple example program from this open gl tutorial to work.
ghc --make gfx.hs
Could not find module ‘Graphics.UI.GLUT’
[..]
Then I tried the following:
cabal install GLUT
Warning: The package list for 'hackage.haskell.org' is 44.1 days old.
Run 'cabal update' to get the latest list of available packages.
Resolving dependencies...
Configuring OpenGLRaw-3.2.2.0...
Failed to install OpenGLRaw-3.2.2.0
Build log ( /home/m/.cabal/logs/OpenGLRaw-3.2.2.0.log ):
Configuring OpenGLRaw-3.2.2.0...
setup-Simple-Cabal-1.22.5.0-x86_64-linux-ghc-7.10.3: Missing dependency on a
foreign library:
* Missing C library: GL
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
cabal: Error: some packages failed to install:
GLURaw-2.0.0.2 depends on OpenGLRaw-3.2.2.0 which failed to install.
GLUT-2.7.0.10 depends on OpenGLRaw-3.2.2.0 which failed to install.
OpenGL-3.0.1.0 depends on OpenGLRaw-3.2.2.0 which failed to install.
OpenGLRaw-3.2.2.0 failed during the configure step. The exception was:
ExitFailure 1
It looks like the missing C library is the problem. I'm using nixOS, does anybody know which steps I'd have to do in order to get this running?
If you want to use nix-shell:
$ nix-shell -p 'haskellPackages.ghcWithPackages (p: [ p.GLUT ])'
will give you a shell with ghc that know GLUT
I've try with this code (from the wiki page you mentioned)
import Graphics.UI.GLUT
main :: IO ()
main = do
(_progName, _args) <- getArgsAndInitialize
_window <- createWindow "Hello World"
displayCallback $= display
mainLoop
display :: DisplayCallback
display = do
clear [ ColorBuffer ]
flush
But the more preferable way is to create shell.nix so you don't need to remember it. To use shell.nix, just call nix-shell without argument in the directory where it is or nix-shell /path/to/shell.nix anywhere.
shell.nix adopted from the manual
{ nixpkgs ? import <nixpkgs> {} }:
with nixpkgs;
let
ghc = haskellPackages.ghcWithPackages (ps: with ps; [
GLUT
]);
in
stdenv.mkDerivation {
name = "my-haskell-env";
buildInputs = [ ghc ];
shellHook = "eval $(egrep ^export ${ghc}/bin/ghc)";
}
For a bigger project you might want to use cabal or stack but I think that would be another story.
In nixos, libraries aren't usually available on the path where cabal expects them to be. Try the following:
nix-shell -p libGL libGLU freeglut
cabal install GLUT
On Linux (Nix is a Linux distribution) the LSB specifies that libGL is part of the desktop profile. That means having at least the X11 client libraries installed. libGL is a bit special though and is permitted to be overridden by the graphics driver installation.
What this boils down to is: Install the graphics drivers for your GPU. If you're using an Intel or a AMD GPU install the Mesa drivers. If your system has a NVidia GPU I recommend the proprietary NVidia drivers.
Related
I'm developing a Haskell program using Cabal in a nix-shell. I would like to have as many dependencies of the build installed by Nix as possible.
The simple.cabal file seems fairly standard (it was initially produced by stack). The full contents are here: https://pastebin.com/3wd8j0pp The only place alex and happy appear in the .cabal file are in the build-tool-depends sections.
I tried to keep the shell.nix file as simple as possible (but I'm also inexperienced in Nix):
{ pkgs ? import <nixpkgs> {}}:
let
ghc = pkgs.haskellPackages.ghcWithPackages (p:[
p.array
p.base
p.bound
p.containers
p.deriving-compat
p.haskeline
p.logict
p.mtl
p.text
p.unification-fd
p.alex
p.happy
p.BNFC
p.cabal-install
]);
alex = pkgs.haskellPackages.alex;
happy = pkgs.haskellPackages.happy;
in
pkgs.mkShell {
buildInputs = [ ghc pkgs.haskellPackages.alex pkgs.haskellPackages.happy pkgs.pkg-config];
buildTools = [ pkgs.haskellPackages.alex pkgs.haskellPackages.happy];
buildToolDepends = [pkgs.haskellPackages.alex pkgs.haskellPackages.happy];
ALEX="${alex}/bin/alex";
HAPPY="${happy}/bin/happy";
}
I saved environment variables to reference the locations of alex and happy.
Finally, I tried to tell cabal where to find alex and happy by specifying them in the extra-prog-path section of a cabal.project file. However, that didn't work, so I tried hard-coding in their location
packages: simple.cabal
extra-prog-path:
/nix/store/PATH-TO-ALEX/bin/alex
/nix/store/PATH-TO-HAPPY/bin/happy
Finally, on building to enter the nix-shell, nix-shell --pure shell.nix and then cabal build
The cabal tool build finds all the ghc library packages installed with ghcWithPackages correctly -- it requires none of them to be built. However, it seems to not know about alex nor happy. The output looks like this.
In order, the following will be built (use -v for more details):
- alex-3.2.6 (exe:alex) (requires build)
- happy-1.20.0 (exe:happy) (requires build)
I can also confirm that the version of alex and happy in the nix store are alex-3.2.6 and happy-1.20.0.
On the other hand, cabal v1-build does pick up alex and happy as installed. cabal v1-build
Resolving dependencies...
Configuring simple-0.1.0.0...
Preprocessing library for simple-0.1.0.0..
Building library for simple-0.1.0.0..
and the build completes successfully only compiling the source files in the local package.
It seems like one should favor v2-build or new-build. How can I get cabal to know where to find and also to use the alex and happy versions installed by Nix, or alternatively how to tell Nix what to do so that v2-build or new-build can find alex and happy?
I have a stack-based project that depends on a couple C libraries. One of these C libraries, zlib, is available from a native NixOS package and I can put into the nix section of stack.yaml:
nix:
enable: true
packages:
- "zlib"
The other is not part of nixpkgs. The stack documentation suggests that the alternative to using the nix section in stack.yaml is to "write a shell.nix" without elaborating much.
So I wrote one, sticking to zlib as an example:
{ pkgs ? import <nixpkgs> { } }:
pkgs.mkShell {
buildInputs = [
pkgs.pkgconfig
pkgs.zlib
pkgs.stack
];
}
This gives me a working pkg-config for zlib:
[nix-shell:~/Work/PrivateStorage/PaymentServer]$ pkg-config --modversion zlib
1.2.11
However, it doesn't appear to make stack able to find the library:
[nix-shell:~/Work/PrivateStorage/PaymentServer]$ stack build
zlib-0.6.2: configure
Progress 1/7
-- While building package zlib-0.6.2 using:
/home/exarkun/.stack/setup-exe-cache/x86_64-linux-nix/Cabal-simple_mPHDZzAJ_2.4.0.1_ghc-8.6.5 --builddir=.stack-work/dist/x86_64-linux-nix/Cabal-2.4.0.1 configure --with-ghc=/nix/store/zfpm9bai9gj8vs09s2i2gkhvgsjkx13z-ghc-8.6.5/bin/ghc --with-ghc-pkg=/nix/store/zfpm9bai9gj8vs09s2i2gkhvgsjkx13z-ghc-8.6.5/bin/ghc-pkg --user --package-db=clear --package-db=global --package-db=/home/exarkun/.stack/snapshots/x86_64-linux-nix/lts-14.1/8.6.5/pkgdb --libdir=/home/exarkun/.stack/snapshots/x86_64-linux-nix/lts-14.1/8.6.5/lib --bindir=/home/exarkun/.stack/snapshots/x86_64-linux-nix/lts-14.1/8.6.5/bin --datadir=/home/exarkun/.stack/snapshots/x86_64-linux-nix/lts-14.1/8.6.5/share --libexecdir=/home/exarkun/.stack/snapshots/x86_64-linux-nix/lts-14.1/8.6.5/libexec --sysconfdir=/home/exarkun/.stack/snapshots/x86_64-linux-nix/lts-14.1/8.6.5/etc --docdir=/home/exarkun/.stack/snapshots/x86_64-linux-nix/lts-14.1/8.6.5/doc/zlib-0.6.2 --htmldir=/home/exarkun/.stack/snapshots/x86_64-linux-nix/lts-14.1/8.6.5/doc/zlib-0.6.2 --haddockdir=/home/exarkun/.stack/snapshots/x86_64-linux-nix/lts-14.1/8.6.5/doc/zlib-0.6.2 --dependency=base=base-4.12.0.0 --dependency=bytestring=bytestring-0.10.8.2 --extra-include-dirs=/nix/store/a54skdf3xksiqvcvr75bjpdl1jx8dgbk-gmp-6.1.2-dev/include --extra-include-dirs=/nix/store/br7kq0kvbn73rhzl17js0w3pprphhzv1-git-2.19.2/include --extra-include-dirs=/nix/store/ghzg4kg0sjif58smj2lfm2bdvjwim85y-gcc-wrapper-7.4.0/include --extra-include-dirs=/nix/store/zfpm9bai9gj8vs09s2i2gkhvgsjkx13z-ghc-8.6.5/include --extra-lib-dirs=/nix/store/br7kq0kvbn73rhzl17js0w3pprphhzv1-git-2.19.2/lib --extra-lib-dirs=/nix/store/ghzg4kg0sjif58smj2lfm2bdvjwim85y-gcc-wrapper-7.4.0/lib --extra-lib-dirs=/nix/store/kggcrzpa5hd41b7v60wa7xjkgjs43xsl-gmp-6.1.2/lib --extra-lib-dirs=/nix/store/zfpm9bai9gj8vs09s2i2gkhvgsjkx13z-ghc-8.6.5/lib
Process exited with code: ExitFailure 1
Logs have been written to: /home/exarkun/Work/PrivateStorage/PaymentServer/.stack-work/logs/zlib-0.6.2.log
Configuring zlib-0.6.2...
Cabal-simple_mPHDZzAJ_2.4.0.1_ghc-8.6.5: Missing dependency on a foreign
library:
* Missing (or bad) header file: zlib.h
* Missing (or bad) C library: z
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.If the
library file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
If the header file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
For zlib, there's no particular need to go this route, but as far as I can tell, I cannot put my non-nixpkgs package into the nix.packages list in stack.yaml.
How do I get stack to find these libraries?
Apparently a case of end-of-the-day documentation-reading-fail. This morning, it didn't take long to find the stack documentation that explains how to use a custom shell.nix. The stack docs do elaborate on how this works, including an example which shows it's not at all like the shell I thought was expected:
{ghc}:
with (import <nixpkgs> {});
haskell.lib.buildStackProject {
inherit ghc;
name = "myEnv";
buildInputs = [ glpk pcre ];
}
Adapting my shell to use buildStackProject instead of mkShell:
{ ghc }:
with (import <nixpkgs> { overlays = [ (import ./overlay.nix) ]; });
haskell.lib.buildStackProject {
inherit ghc;
name = "PrivacyPass";
# extra-library made available via the overlay.
# overlay probably not strictly necessary here, either.
buildInputs = [ zlib extra-library ];
}
and then pointing stack at it in stack.yaml:
nix:
enable: true
shell-file: "stack-shell.nix"
results in a successful build.
My haskell installation can not find bytestring module installed by operating system
$ ghci
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :m +Data.ByteString.Lazy
<no location info>:
Could not find module `Data.ByteString.Lazy'
It is not a module in the current program, or in any known package.
But I have installed this module using yum:
$ rpm -ql ghc-bytestring
/usr/lib64/ghc-7.6.3/bytestring-0.10.0.2
/usr/lib64/ghc-7.6.3/bytestring-0.10.0.2/libHSbytestring-0.10.0.2-ghc7.6.3.so
/usr/share/doc/ghc-bytestring
/usr/share/doc/ghc-bytestring/LICENSE
What is wrong?
If this is happening, you should be able to figure out more via ghc-pkg list. This could happen, for example, if the binary package provided by your software repository was broken; ghc-pkg list would report that. In general, either GHC is not looking for packages in /usr/lib64/ghc-7.6.3/ or else that directory has a package.cache which was not updated to reflect the new package.
One thing that could cause GHC to look in the wrong place is if there are multiple GHCs on the machine: for example if which ghc reveals /usr/local/bin/ghc then you probably compiled GHC from source at some point and its packages are occupying some /usr/local/lib/ghc-7.6.3/package.conf.d/ folder, while your repository has installed /usr/bin/ghc which is looking in the folder you want.
Anyway, fixes: if the package.cache file exists and has a valid entry for the file, then you can run ghc -package-conf /path/to/package.cache ... to add those packages to your executable. If you have further problems, ghc -v ... is a great resource for debugging "which version of that package is being used here?" types of problems.
If the package.cache file does not exist then you've got a bigger problem, and probably the easiest way to move forward is to look for a directory under /home which appears on ghc-pkg list. Install the required package to that directory and GHC should pick up on it even though it doesn't understand these bigger contexts. You could also start working with a cabal sandbox of local packages to your project.
Situation here is similiar to C++ you have libraries used during dynamic linking stage and header used for compilation. In Fedora packages like ghc-bytestring are only libraries without headers. To install headers I had to install ghc-bytestring-devel package.
An example on Fedora 24:
server.hs:7:8:
Could not find module ‘Data.Text’
Perhaps you meant Data.Set (from containers-0.5.5.1)
Locations searched:
Data/Text.hs
Data/Text.lhs
So change to user root, then:
What packages are there?
# dnf search ghc|grep text
ghc-text.x86_64 : An efficient packed Unicode text type
ghc-boxes.x86_64 : 2D text pretty-printing library
ghc-pango.x86_64 : Binding to the Pango text rendering engine
ghc-css-text.x86_64 : CSS parser and renderer
ghc-hgettext.x86_64 : Haskell binding to libintl
ghc-attoparsec.x86_64 : Fast combinator parsing for bytestrings and text
ghc-text-devel.x86_64 : Haskell text library development files
ghc-blaze-textual.x86_64 : Fast rendering of common datatypes
ghc-css-text-devel.x86_64 : Haskell css-text library development files
ghc-hgettext-devel.x86_64 : Haskell hgettext library development files
ghc-blaze-textual-devel.x86_64 : Haskell blaze-textual library development files
So what's installed?
# rpm --query ghc-text
ghc-text-1.1.1.3-3.fc24.x86_64
# rpm --query ghc-text-devel
package ghc-text-devel is not installed
So let's install the devel package.
# dnf install ghc-text-devel
Installed:
ghc-text-devel.x86_64 1.1.1.3-3.fc24
...and compilation succeeds after that.
I first set up Haskell from https://www.haskell.org/platform/ but ghc-mod had problems with sandboxes and to update it I needed a newer cabal which needed a newer ghc. Or something like that. (https://stackoverflow.com/a/28049104/131227 ??)
So I deleted everything, and installed from http://ghcformacosx.github.io/.
Then some strange failure setting up a new sandbox was because something didn't properly have a dependancy for happy. (https://github.com/haskell-suite/haskell-src-exts/issues/14)
Ok. Installed happy. Now trying (again) to install ghc-mod and I get a giant mess (below).
Should I use http://www.stackage.org/?
I've seen some people mention ghc-pkg recache or cabal install cabal-install... Are those things I need to do?
Mess:
Resolving dependencies... Configuring ghc-mod-5.2.1.2... Building ghc-mod-5.2.1.2... Failed to install ghc-mod-5.2.1.2 Build log ( /Users/mark/.cabal/logs/ghc-mod-5.2.1.2.log ): Configuring ghc-mod-5.2.1.2... Building ghc-mod-5.2.1.2... Preprocessing library ghc-mod-5.2.1.2...
Language/Haskell/GhcMod/Convert.hs:1:51: Warning:
-XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS [ 1 of 38] Compiling Language.Haskell.GhcMod.Read ( Language/Haskell/GhcMod/Read.hs, dist/build/Language/Haskell/GhcMod/Read.o ) [ 2 of 38] Compiling Language.Haskell.GhcMod.Cabal21 ( Language/Haskell/GhcMod/Cabal21.hs, dist/build/Language/Haskell/GhcMod/Cabal21.o ) [ 3 of 38] Compiling Language.Haskell.GhcMod.Cabal18 ( Language/Haskell/GhcMod/Cabal18.hs, dist/build/Language/Haskell/GhcMod/Cabal18.o ) [ 4 of 38] Compiling Language.Haskell.GhcMod.Cabal16 ( Language/Haskell/GhcMod/Cabal16.hs, dist/build/Language/Haskell/GhcMod/Cabal16.o ) [ 5 of 38] Compiling Language.Haskell.GhcMod.GHCChoice ( Language/Haskell/GhcMod/GHCChoice.hs, dist/build/Language/Haskell/GhcMod/GHCChoice.o ) [ 6 of 38] Compiling Language.Haskell.GhcMod.Error ( Language/Haskell/GhcMod/Error.hs, dist/build/Language/Haskell/GhcMod/Error.o )
Language/Haskell/GhcMod/Error.hs:12:1: Warning:
Module ‘Control.Monad.Error’ is deprecated:
Use Control.Monad.Except instead
Language/Haskell/GhcMod/Error.hs:40:10: Warning:
In the use of type constructor or class ‘Error’
(imported from Control.Monad.Error, but defined in Control.Monad.Trans.Error):
Deprecated: "Use Control.Monad.Trans.Except instead"
Language/Haskell/GhcMod/Error.hs:40:10: Warning:
In the use of type constructor or class ‘Error’
(imported from Control.Monad.Error, but defined in Control.Monad.Trans.Error):
Deprecated: "Use Control.Monad.Trans.Except instead" [ 7 of 38] Compiling Language.Haskell.GhcMod.Utils ( Language/Haskell/GhcMod/Utils.hs, dist/build/Language/Haskell/GhcMod/Utils.o )
Language/Haskell/GhcMod/Utils.hs:15:1: Warning:
The import of ‘Control.Applicative’ is redundant
except perhaps to import instances from ‘Control.Applicative’
To import instances alone, use: import Control.Applicative()
Language/Haskell/GhcMod/Utils.hs:45:51: Warning:
In the use of ‘strMsg’
(imported from Language.Haskell.GhcMod.Error, but defined in Control.Monad.Trans.Error):
Deprecated: "Use Control.Monad.Trans.Except instead" [ 8 of 38] Compiling Language.Haskell.GhcMod.Types ( Language/Haskell/GhcMod/Types.hs, dist/build/Language/Haskell/GhcMod/Types.o ) [ 9 of 38] Compiling Language.Haskell.GhcMod.Gap ( Language/Haskell/GhcMod/Gap.hs, dist/build/Language/Haskell/GhcMod/Gap.o )
Language/Haskell/GhcMod/Gap.hs:256:18:
Not in scope: data constructor ‘ExposePackageId’
Perhaps you meant ‘ExposePackage’ (imported from DynFlags) cabal: Error: some packages failed to install: ghc-mod-5.2.1.2 failed during the building phase. The exception was: ExitFailure 1
After applying the accepted answer (which seemed to install ghc-mod), running gch-mod gives the following:
> ghc-mod check x.hs
cabal-helper-wrapper: Installing a private copy of Cabal, this might take a
while but will only happen once per Cabal version.
If anything goes horribly wrong just delete this directory and try again:
/Users/mark/.ghc-mod/cabal-helper
If you want to avoid this automatic installation altogether install version
1.22.0.0 of Cabal manually (into your user or global package-db):
$ cabal install Cabal-1.22.0.0
...In order, the following would be installed:
filepath-1.3.0.1 (latest: 1.4.0.0) (new version)
directory-1.2.2.1 (new version)
process-1.2.3.0 (reinstall) changes: directory-1.2.2.0 -> 1.2.2.1,
filepath-1.4.0.0 -> 1.3.0.1
Cabal-1.22.0.0 (latest: 1.22.2.0) (new version)
cabal: The following packages are likely to be broken by the reinstalls:
ghc-7.10.1
Cabal-1.22.2.0
Use --force-reinstalls if you want to install anyway.
cabal-helper-wrapper: Installing Cabal version 1.22.0.0 failed.
nYou have two choices now:
- Either you install this version of Cabal in your globa/luser package-db
somehow
n- Or you can see if you can update your cabal-install to use a different
version of the Cabal library that we can build with:
$ cabal install cabal-install --constraint 'Cabal > 1.22.0.0'
nTo check the version cabal-install is currently using try:
$ cabal --version
ghc-mod: readCreateProcess: /Users/mark/.cabal/libexec/cabal-helper-wrapper "/Users/mark/work/haskell/ixberg/dist" "entrypoints" "source-dirs" "ghc-options" "ghc-src-options" "ghc-pkg-options" "--with-ghc=ghc" "--with-ghc-pkg=ghc-pkg" "--with-cabal=cabal" (exit 1): failed
Strangely, it wants the version of Cabal that is currently installed:
> cabal --version
cabal-install version 1.22.0.0
using version 1.22.0.0 of the Cabal library
Edit (August 2015) Better fix
A better command line tool for installing Haskell binaries and libraries by the awesome FPComplete group called stack means you can install ghc-mod with stack install ghc-mod (outside a project to make it global) and it will just work. The binary will be installed to ~/.local/bin and should be put on your path so your editor can find it.
I will leave the below for anyone who wishes to know what cabal Hell really meant.
Problem With DanielG's Fork
I asked on the Haskell reddit and NihillstDandy explained that the GHC for Mac OS X does not register the Cabal library. This is not true for your install from http://ghcformacosx.github.io/. It does register the Cabal library.
ghc-mod needs the cabal library to work, but it does not compile with the cabal library. Instead it compiles with cabal-helper and that looks to see if you have a registered version of the cabal library. If it does not find any then cabal-helper-wrapper will install a private copy and in this case it tired to install the same version as what cabal-install was compiled with, cabal-1.22.0.0.
When I installed DanielG's Fork it worked for my current project, but after testing it in other projects I am getting the same error you are. This is a problem with the fork and not Haskell (as far as I can tell).
Original Answer
So, while I was putting this post together ghc-mod was fixed for GHC-7.10. Thanks to DanielG!
git clone https://github.com/DanielG/ghc-mod
cd ghc-mod
cabal install -j4
And if you get errors that say "setup-Simple-Cabal-1.22.2.0-x86_64-osx-ghc-7.10.1: The program 'happy' version
>=1.17 is required but it could not be found."
cabal install happy -j4
The same for any other problems and it should work. (Although you have happy installed, so it should just work).
The rest of the post is on how to downgrade the cabal executable, also known as cabal-install, to version 1.20.0.3. Although you could really use this to downgrade to any version. Since there is a working fork of ghc-mod that works with GHC-7.10 and cabal-1.22 you do not need to downgrade to fix ghc-mod.
I'm just leaving the rest of the post up here since, unfortunately, this is a problem with Haskell as a whole. Halcyon and nix are ways to deal with Haskell's shortcomings in this regard.
How to downgrade Cabal in Haskell
When I wrote this post ghc-mod, nor any fork, compiled with GHC-7.10 and versions below 7.10 broke with cabal-1.22 sandboxes.
However, even if you compile ghc-mod with GHC-7.8.4 (the version before 7.10) and cabal-1.20.0.3 you still cannot use ghc-mod inside a sandbox created by cabal-1.22 and above. So the only way to use ghc-mod is to either downgrade your entire system to cabal-1.20.0.3 or don't use sandboxes. This means you can still use GHC-7.10, but you have to use the older version of cabal. That is unless you want to wait until the convener or someone else fixes it for GHC-7.10. Its been over a week already, but some kind Haskell programmer fixed it in a fork (see above).
If this is something you still want here is how to compile ghc-mod with GHC-7.8.4 and cabal-1.20.0.3. Also, I replace the executable cabal-1.22 with the older cabal-1.20.0.3. Note, it does not matter what directory you download the sources to.
download GHC-7.8.4 source for your OS from here
tar -xf path_to_zipped_source
cd path_to_ghc-7.8.4
The next steps will install ghc-7.8.4 as ghc-7.8.4 in the same folder as ghc-7.10 is install for you. The -j4 is to tell make to use 4 threads to compile it.
./configure
make install -j4
To get the correct version of cabal we can just ask cabal to get it.
cabal get cabal-install-1.20.0.3
cd cabal-install-1.20.0.3
Now to install cabal with ghc-7.8.4. Here cabal-1.22 will pull all the decencies and should give you some warning about installing another version of the cabal library (not to be confused with cabal-install), this should not cause problems.
cabal --with-compiler=ghc-7.8.4 install
So now you should have cabal-1.20.0.4 installed, but not on your path. It will be in ~/.cabal/bin. We need to make this global, so remove cabal-1.22 (it only removes the symlink).
rm `which cabal`
And create the symlink to cabal-1.20.0.4. Btw, you will need to remove any sandboxes you made with cabal-1.22 and remake them with cabal-1.20.0.4.
If you do not have realpath you can just type in the full path of cabal. I use it for connivence.
cd ~/.cabal/bin
ln -s `realpath cabal` /usr/local/bin
Now this is how I compiled ghc-mod on my mac (you may run into your own problems). I'm not sure why cabal couldn't do it in one call, but this worked in the end.
cabal --with-compiler=ghc-7.8.4 install happy
cabal --with-compiler=ghc-7.8.4 install haskell-src-exts-1.16.0.1
cabal --with-compiler=ghc-7.8.4 install hlint-1.9.19
cabal --with-compiler=ghc-7.8.4 install ghc-mod
Now you should be able to call ghc-mod from anywhere. To test it just type ghc-mod after you have cabal sandbox init. If it does not throw any errors then your in the clear.
The version of executable cabal that is used to configure this project should be the same as the version of the global Cabal package.
It's easier to install a compatible version of cabal-install than Cabal as follows:
$ ghc-pkg list | grep Cabal
Cabal-1.22.2.0
$ cabal install cabal-install-1.22.2.0
Or build one in sandbox and replace/shadow the original one.
Then don't forget to re-configure the project with the new cabal:
$ cabal clean && cabal configure
Now the ghc-mod should works.
If Cabal-1.22 isn't registered (ghc-pkg list cabal), the cabal-helper-wrapper will install a private copy because it needs the library installed to work, but it doesn't want to stomp on anything you have that might break by upgrading Cabal directly.
GHC for Mac OS X doesn't register the Cabal library, it comes bundled with a version of cabal-install built against it.
I tried to install system-fileio to my global package db and failure was :
c:\Haskell\2013.2.0.0\bin>cabal-1.20.0.1.exe install system-fileio
Resolving dependencies...
Configuring system-fileio-0.3.13...
Building system-fileio-0.3.13...
Failed to install system-fileio-0.3.13
Last 10 lines of the build log ( C:\Users\bitli\AppData\Roaming\cabal\logs\system- fileio-0.3.13.log ):
The import of `System.IO.Error' is redundant
except perhaps to import instances from `System.IO.Error'
To import instances alone, use: import System.IO.Error()
lib\hssystemfileio-win32.c: In function 'hssystemfileio_copy_permissions':
lib\hssystemfileio-win32.c:10:17:
error: storage size of 'st' isn't known
lib\hssystemfileio-win32.c:11:2:
warning: implicit declaration of function '_wstat64'
cabal-1.20.0.1.exe: Error: some packages failed to install:
system-fileio-0.3.13 failed during the building phase. The exception was:
ExitFailure 1
I tried it on Windows 7.
I just ran into this same problem on Windows 7 with system-fileio-0.3.13, using both the windows command line with Haskell Platform 2013.2.0.0's built-in mingw and also inside msys with a newer mingw64. The problem appears to be caused by a change introduced between system-fileio-0.3.12 and system-fileio-0.3.13. system-fileio's git repo doesn't seem to have a web interface to link to, but 0.3.12's lib\hssystemfileio-win32.c uses:
struct _stat st;
int rc = _wstat(old_path, &st);
while 0.3.13's hssystemfileio-win32.c has changed to:
struct _stat64 st;
int rc = _wstat64(old_path, &st);
Copying 0.3.12's hssystemfileio-win32.c over top of 0.3.13's does seem to allow it to build, though I don't know if it actually functions correctly.
I don't know if this will work for you, but I'm trying to build yesod on Windows 7 (inside a sandbox with an upgraded cabal-install from the one in the Haskell Platform) and I extracted a system-fileio 0.3.13 tarball from Hackage, copied 0.3.12's hssystemfileio-win32.c over, and then did a cabal sandbox add-source ../system-fileio-0.3.13 inside my yesod sandbox. My cabal install of yesod could then proceed and seems to have worked. If you're doing a system install of system-fileio, you probably should be able to just build in the extracted and modified system-fileio-0.3.13 directory directly.
I'm sure someone who knows something about Haskell and cabal will be able to provide a proper solution instead of this hack.