My computer is a celeron 1.3GHz with 160MB RAM (128+32) and 400MB swap. The kernel I have is 2.6.9. The command "emerge ghc" fails when building libHSbase.a (from _lots_ of files) because the computer gets out of resources and the kernel starts killing programs. Here is the error: /usr/bin/ar: creating libHSbase.a xargs: /usr/bin/ar: terminated by signal 15 Is there any solution so that the building of the library places less strain on the machine so that ghc can be compiled on weaker machines? Thanks, radu Reproducible: Always Steps to Reproduce: 1. reduce RAM to 160MB and swap to 400MB 2. emerge ghc Actual Results: /usr/bin/ar: creating libHSbase.a xargs: /usr/bin/ar: terminated by signal 15 Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.9-gentoo-r1 i686) ================================================================= System uname: 2.6.9-gentoo-r1 i686 Intel(R) Celeron(TM) CPU 1300MHz Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux-headers-2.4.21-r1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=i686 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=i686 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="ftp://ftp.lug.ro/gentoo http://ftp.lug.ro/gentoo/ http://ftp.roedu.net/pub/mirrors/gentoo.org/ ftp://ftp.roedu.net/pub/mirrors/gentoo.org/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X apm arts avi berkdb bitmap-fonts crypt cups encode f77 fam foomaticdb fortran gdbm gif gnome gpm gtk gtk2 imlib java jpeg junit kde libg++ libwww mad mikmod motif mozilla mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl slang spell ssl svga tcpd tetex tiff truetype x86 xml2 xmms xv zlib"
It could be that inserting SplitObjs=NO into your build.mk file would work. If you look at the ebuild, this is already done on amd64 and ppc. If you remove the architecture-specific conditional on that line, it might just work for you. With the new eclass allowing hardware-checks, we might be able to automatize this step. But I'd first like feedback on whether this works. Cheers, ks
moonpix root # swapoff -a moonpix root # logout desrt@moonpix desrt $ ./oom Killed desrt@moonpix desrt $ cat oom.c #include <stdlib.h> int main( void ) { char *b; int i; while(1) { b = malloc( 4096 * 1024 ); for( i = 0; i < 1024; i++ ) b[i*4096]='\0'; } } In short: when the OOM killer kills something, it sends signal 9 (Killed). Not signal 15 (Terminated). xargs: /usr/bin/ar: terminated by signal 15 This is strange.
"SplitObjs=NO" worked. Thanks.
My Thinkpad T20 with 128 megs RAM, 1G swap, also experienced exactly the same problem, and adding SPLITOBJS=no solved it.
This should now be fixed in ghc-6.4.1-r2. We now automatically use "SplitObjs=NO" when the machine has less than 200Mb of RAM. So I'm closing this bug. If anyone finds this value of 200Mb is too low then feel free to re-open this bug.
