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
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.
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*
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With