how can I build cabal-install on eeePc 701 / Ubuntu Netbook Remix 1.6 (Lucid)

Question

Not a programming question, but the first time I see something like this.
UNR 1.6 (based on Ubuntu 10.04) installs the 6.12.1 version of GHC.
So, in order to build cabal-install-0.8.2, I have to install
the libghc6- packages of parsec, mtl, network and zlib.
Then, after launching 'sh ./bootstrap.sh', I get:

Checking installed packages for ghc-6.12.1...
parsec is already installed and the version is ok.
network is already installed and the version is ok.
Cabal is already installed and the version is ok.
mtl is already installed and the version is ok.
HTTP is already installed and the version is ok.
zlib is already installed and the version is ok.
[1 of 1] Compiling Main ( Setup.hs, Setup.o )
Linking Setup ...
Configuring cabal-install-0.8.2...
Preprocessing executables for cabal-install-0.8.2...
Building cabal-install-0.8.2...
[ 1 of 40] Compiling Distribution.Client.BuildReports.Types ( Distribution/Client/BuildReports/Types.hs, dist/build/cabal/cabal-tmp/Distribution/Client/BuildReports/Types.o )
[ 2 of 40] Compiling Distribution.Client.Utils ( Distribution/Client/Utils.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Utils.o )

... two warnings about not used addPackageExcludeConstraint and response ...

[39 of 40] Compiling Distribution.Client.Install ( Distribution/Client/Install.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Install.o )
[40 of 40] Compiling Main ( Main.hs, dist/build/cabal/cabal-tmp/Main.o )
Linking dist/build/cabal/cabal ...
collect2: ld terminated with signal 9 [Processus arrêté]

Error during cabal-install bootstrap:
Building the cabal-install package failed

Between linking and collect2 (a minute or so), the LED of my hard drive twinkles
as if a lot of files are written or read.

I don't know if it's relevant but here are the versions of the dependencies
Cabal-1.8.0.2
HTTP-4000.0.6
mtl-1.1.0.2
network-2.2.1.7
parsec-2.1.0.1
zlib-0.5.2.0

Andino

9 is SIGKILL - how much memory is ld using when it gets killed? Perhaps this is an OOM situation? – Encephalogram

Indeed, eeePc 701 has 512Mo Ram and my swap is configured for 256Mo and all is used 100% before the crash. But why isn't the linking step as clever as the compiling step (25% Ram, 40% swap) ? – Andino

It also fails miserably on OLPC XO-1s, due to the 256 mb of RAM. I've tried everything I can think of to get cabal-install to build. – Huntress

Ends up in page swapping hell. The folks in #haskell were helpful, but no solution could be found. GHC is a beast which requires 1gb, minimum. Hugs works, though, however that's not a solution for my needs. – Huntress

Guess you'll have to find a binary package... its a bit surprising that Ubuntu doesn't already have one. – Encephalogram

@TomMD: thanks, they have cabal-install (0.8.0-1) and I should have checked! (but still it's a pity it can't be build on a small machine). – Andino

Answer 1

I have the same issue. I add splitobjs=NO at anytime in ghc-..ebuild. then I rebuild ghc, but cabal-install still can't pass ld. because my gentoo box has no swap partition. So I use my 2G usb disk to create one temporary swap partition. then I can build cabal-install success. I found it will use extra 100M swap space and my eeepc has 512M memory. So I think you can use one usb disk that has more than 100M space. just: mkswap /dev/sd* swapon /dev/sd*

Kirkland

Good job, QinGW, I'd never have thought about creating a usb swap space! – Andino

Answer 2

What is happening is that the kernel is killing the ld linker process because it is using too much memory.

The reason ld is using so much memory is because of a feature called "split objs" which has the consequence that standard libraries like libHSbase.a contain 10s of thousands of tiny little .o files. The linker is not optimised for this use-case and ends up using a lot of memory.

The "split objs" feature is intended to make compiled programs much smaller by linking in only the bits of the standard libraries that are actually used. It works by splitting each compiled Haskell module into a separate .o file for each function.

So this is obviously a problem for systems with less memory, like your netbook. It is likely to happen with anything you link, not just cabal. It is possible to build ghc from source with the splitobjs feature turned off. For example, Gentoo does this automatically for machines with 512Mb of RAM or less. So if you want to use ghc reliably on your netbook you'll probably need to build it from source without splitobjs. You can build ghc on a slightly more powerful machine and then transfer it to your netbook.

In future this problem will go away when we switch to using shared libraries by default on Linux.

Morette

Answer 3

dd if=/dev/zero of=/swapfile bs=1024 count=2048k mkswap /swapfile swapon /swapfile

Roscoeroscommon