6
votes

I am trying to install Haskell Platform 2014.2.0.0 from source on Red Hat Enterprise Linux 6.5. I have a functional install of Haskell Platform 2012.4.0.0 and GHC 7.4.2 from two years ago, plus a recently-installed Haskell Platform 2013.2.0.0 and GHC 7.6.3 from JustHub.

I've built GHC 7.8.3 from source, but it keeps coming up with seven failures in the test suite. I have no idea if these test failures are innocuous or not. (The test failures are not relevant to my question, but they may become significant later.)

I unpack the source tarball of 2014.2.0.0, read the README. It says that the way to build this iteration of Haskell is with a shell script, which is invoked:

./platform.sh $PATH_TO_GHC_BINDIST_TARBALL

I don't have a GHC binary distribution tarball. So far as I am able to tell, there is no binary distribution tarball of GHC 7.8.3 for any version of Red Hat Enterprise Linux. I have a built GHC 7.8.3. How do I tell platform.sh -- or whatever is underneath it -- that there is no tarball, and it should just use what's in $PATH? Alternately, how do I pack up my existing install of GHC 7.8.3 so that platform.sh will accept it?

The built GHC does not have a 'cabal' command, so the cabal commands in platform.sh are falling back to $PATH, which I can configure to be either of the other installed versions (2013.2/7.6.3 or 2012.4/7.4.2). It doesn't seem to make a difference: neither one recognizes 'cabal --sandbox'. Both result in complaints that I should run 'cd hptool ; cabal install --only-dependencies', which I've done, repeatedly. platform.sh never gets past that point.

If I run the commands in platform.sh by hand, I get to 'cd hptool; cabal build', which errors out: "cabal-1.16.0.2: Run the 'configure' command first.". But there is no 'configure' command available in the hptool directory.

I'm now stuck. How do I build Haskell Platform 2014 on RHEL 6?

2
You should try to build hptool without using platform.sh (hptool is just a cabal package - cabal configure; cabal build should work, if you have GHC and cabal working). hptool itself seems to require a GHC binary distribution, so I don't know if that will work. If it doesn't work, HP is just a bunch of packages - go to the packages directory in the HP tarball and cabal configure; cabal install those packages. If that still doesn't work, either GHC or cabal aren't working.user2407038
That got me somewhat further. I've run the configure/build/install sequence in each subdirectory under packages, but a number of the configure sequences throw errors, many of which have to do with missing modules. Some of the missing bits are internal dependencies to this specific version of Haskell Platform 2014 (such as vector-0.10.9.1 wanting primitive-0.5.2.1). I presume that hptool knows the order of things, and can deal with feeding one package the dependencies it needs from another. Is there some way to package up my built GHC 7.8.3 in a path structure that hptool can use?M B
I've never had to build HP from source so I can't tell you how to package your own GHC into a format which hptool will accept. primitive is not internal to hptool or HP, it is a regular cabal package which you can get with cabal install primitive.user2407038

2 Answers

1
votes

You need to use your GHC sources to make your own "bindist." Directions at https://ghc.haskell.org/trac/ghc/wiki/MakingReleases

1
votes

I managed to get Haskell Platform installed, and functional. I ended up abandoning platform.sh and just hand-installed all the packages in the Haskell Platform tarball -- and their dependencies -- with manual cabal commands. Along with the broken platform.sh, I ran into many problems on the way.

The ones that I remember:

  • platform.sh will never succeed if you have the stock Haskell Platform 2013 or previous installed. It wants a cabal that recognizes the '--sandbox' option, and cabal 1.18 doesn't know that option. You must have a newer cabal installed than Haskell Platform 2013 provides. (GHC 7.4 or 7.6 appears to be fine, though.)

  • I had an existing .cabal and .ghc directory, which had incompatible builds and/or versions of various packages. I deleted both directories numerous times while testing things.

  • cabal install --global behaves rather differently from the default cabal install --user. .cabal contained something useful after I did 'cabal install cabal-install'. It took two or three tries at that to figure out where the new cabal binary went.

  • ghc and cabal pick up new libraries in .ghc and .cabal, but not new binaries.

  • Neither GHC nor cabal install default to --enable-shared, except when something wants it. I had to go rebuild everything before that -- all the way back to GHC 7.8.3 itself -- with --enable-shared once that happened.

  • haddock is ridiculously tightly bound to the version of GHC it was built with. I had to rebuild it to get --enable-documentation to work for anything built with GHC 7.8.3.

  • The test packages and the text package are so tightly integrated that they have circular dependencies if you try to do 'cabal install text --enable-tests'. Even after installing the most recent version of text and the test packages, cabal still wouldn't run the text test suite, so I gave up and installed text without testing it.

  • My default environment includes 'LC_ALL=C'. This trips a known bug in cabal -- apparently in all versions -- that breaks some package builds. To work around it, I had to shift it to 'LC_ALL=en_US.utf8'. I have no idea if the packages affected will work if you have LC_ALL, or any of the other locale variables such as LANG or LC_<anything else>, set to C.

  • cabal install --global is terribly inconsistent about where packages get stored. We split out individual packages into their own subdirectories, and then build a symlink tree in a known place out of all those subdirectories. So ghc is in its own subdirectory of /usr/sup/ghc-7.8.3; Haskell Platform is in another subdirectory, /usr/sup/haskell-platform-2014.2.0.0. I consistently used --prefix=/usr/sup/haskell-platform-2014.2.0.0 on every 'cabal install' command, but even then, some libraries ended up in /usr/sup/ghc-7.8.3.

  • Both GHC and Haskell Platform have a dictionary of what's built and where it is -- perhaps as a workaround for the install location inconsistency -- in /usr/sup/ghc-7.8.3/lib/ghc-7.8.3/package.conf.d/package.cache. If that package dictionary isn't world-readable, ghc breaks. What it should do is look at the actual file structure to find things. Given that ghc breaks if the dictionary isn't available, the file shouldn't be called 'cache', as a cache miss shouldn't cause catastrophic failure. Perhaps rename it to 'package-mandatory-dictionary'?

Ultimately, it all installed, but I have to wonder about the damage I did from so much banging my head on the wall.