building GHC for Slackware/Salix
I'm making a GHC package for Salix 14 (which is backwards-compatible with Slackware, so this will be a Slackware package, too). The main thing I'd be grateful for advice on is the overall approach I'm taking to the package. Others I've seen (such as the Arch package) just assume GHC is already present. My build script unpacks the binary distribution for "unknown linux" and builds GHC against that. (Both are version 7.4.2.) I have avoided installing anything else (such as the Haskell Platform) so as to keep as close as possible to the ideal of a package as a transparent, reproducible process that only depends on the source. As far as I can tell from the build prerequisites http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Tools the only consequence is that documentation is only created as html, not pdf and ps as well. Though everything seems to work ok, the build as it stands fails three tests: Unexpected failures: lib/Time T5430 [bad stdout] (normal) perf/compiler parsing001 [stat not good enough] (normal) simplCore/should_compile spec-inline [stderr mismatch] (optasm) That is after running the fast version of the test suite, which the documentation says should pass 100%. My second question is, do these results suggest anything as to where the problem may lie, and how important it is? When I then installed the new package and built the Haskell Platform against it (using the build script at http://slackbuilds.org), although the installation nonetheless appeared to be succesful, the build script failed at the very end where it tries to do ghc-pkg recache When I did this manually, I discovered root permissions were needed. Is that normal?
I've now tried a build strictly according to the instructions, which
is to say, I installed the binary distribution, then haskell-platform
on top of it, before building GHC from source. I get the same errors,
plus a few more (I did the quick build rather than the fully optimized
default build, so maybe that's why; most of the extra failures are
from perf/compiler and say "stat not good enough").
Out of curiosity, I unpacked the bindist tarball afresh and ran the
failed tests on it. They also failed (the third one in a few more
ways):
Unexpected failures:
lib/Time T5430 [bad stdout]
(normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded)
lib/Time T5430 [bad stdout or stderr] (ghci)
All this makes me think there is something wrong with my setup. I'd be
very grateful if anyone has any suggestions - or if this is the wrong
place for these questions, where would be a better place.
Tim
On 09/12/2012, tim.beech
I'm making a GHC package for Salix 14 (which is backwards-compatible with Slackware, so this will be a Slackware package, too).
The main thing I'd be grateful for advice on is the overall approach I'm taking to the package. Others I've seen (such as the Arch package) just assume GHC is already present.
My build script unpacks the binary distribution for "unknown linux" and builds GHC against that. (Both are version 7.4.2.) I have avoided installing anything else (such as the Haskell Platform) so as to keep as close as possible to the ideal of a package as a transparent, reproducible process that only depends on the source. As far as I can tell from the build prerequisites
http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Tools
the only consequence is that documentation is only created as html, not pdf and ps as well.
Though everything seems to work ok, the build as it stands fails three tests:
Unexpected failures: lib/Time T5430 [bad stdout] (normal) perf/compiler parsing001 [stat not good enough] (normal) simplCore/should_compile spec-inline [stderr mismatch] (optasm)
That is after running the fast version of the test suite, which the documentation says should pass 100%.
My second question is, do these results suggest anything as to where the problem may lie, and how important it is?
When I then installed the new package and built the Haskell Platform against it (using the build script at http://slackbuilds.org), although the installation nonetheless appeared to be succesful, the build script failed at the very end where it tries to do
ghc-pkg recache
When I did this manually, I discovered root permissions were needed. Is that normal?
Hi Tim, On Sun, Dec 09, 2012 at 11:53:32AM -0300, tim.beech wrote:
My build script unpacks the binary distribution for "unknown linux" and builds GHC against that. (Both are version 7.4.2.) I have avoided installing anything else (such as the Haskell Platform) so as to keep as close as possible to the ideal of a package as a transparent, reproducible process that only depends on the source. As far as I can tell from the build prerequisites
http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Tools
the only consequence is that documentation is only created as html, not pdf and ps as well.
You don't need the haskell-platform to build the docs; I suspect you're missing dblatex.
Unexpected failures: lib/Time T5430 [bad stdout] (normal) perf/compiler parsing001 [stat not good enough] (normal) simplCore/should_compile spec-inline [stderr mismatch] (optasm)
That is after running the fast version of the test suite, which the documentation says should pass 100%.
My second question is, do these results suggest anything as to where the problem may lie, and how important it is?
You'd need to look at how the tests failed. If you add TEST="T5430 parsing001 spec-inline" to the command you were running the testsuite with then it'll run just those tests, which will make it easier to see what's happening.
When I then installed the new package and built the Haskell Platform against it (using the build script at http://slackbuilds.org), although the installation nonetheless appeared to be succesful, the build script failed at the very end where it tries to do
ghc-pkg recache
When I did this manually, I discovered root permissions were needed. Is that normal?
I'm not familiar with the HP build script, I'm afraid. Thanks Ian
Dear Ian, Thanks for your response. Here is the output of the bad tests: http://pastebin.com/iepNQPf0 Since first posting to the haskell-users list, I have tried several other builds with similar results. This one simply unpacks the unknown-linux bindist of GHC (as well as building the versions of gmp and libffi it needs) and builds from the GHC source against that. Here is what's passed to configure: ./configure --prefix=/usr --libdir=/usr/lib${LIBDIRSUFFIX} --mandir=/usr/man --docdir=/usr/doc/$pkgname-$pkgver --with-ghc=$startdir/src/stage_0_build/usr/bin/ghc For what it's worth, here is the whole thing - but I doubt it's relevant: http://people.salixos.org/mimosa/packages/ghc/7.4.2/SLKBUILD.new Unless there is an absolute necessity, I'd prefer to build it without any other Haskell bits and pieces. But if this isn't possible, what *is* needed? I have already established that the Haskell Platform alone isn't sufficient to make these errors go away. The problem with the build script for Haskell Platform turns out to be an error in the script, nothing to do with needing to be root to execute the recache command. You are also right that Haskell Platform makes no difference to the way the documentation is built. I saw dblatex on the page about build prerequisites, but I can't find it for Slackware/Salix. In any case, the html documentation is good enough. My main concern is getting a robust, usable build of GHC itself. So far I'm only a Haskell user in the sense that my WM is XMonad, and this build of GHC certainly hasn't caused any trouble in that department. Tim
Dear Ian, I'm not sure if I mentioned that the binary distribution fails those tests too, and several others on top: http://pastebin.com/E45cTqvy To get from thirteen failures to three is at least an improvement! Tim
participants (3)
-
Ian Lynagh -
Tim Beech -
tim.beech