Yup, that's the problem all right. Recompiling ghc with --with-gcc=/usr/bin/gcc-3.3 (on Debian) gives small executables. Thanks, Ian! What a relief -- I was running multiple instances of hnop and it was chewing up all of my memory ;-) Perhaps an hnop server might be a useful future direction... Mike Ian Lynagh wrote:
On Fri, Jun 30, 2006 at 03:45:57PM -0700, mvanier wrote:
I'm at a loss here. Somehow, the SplitObjs option doesn't seem to be doing the job. Any suggestions would be appreciated.
It looks like gcc 4.1 is floating all the
__asm__("\n__stg_split_marker:");
results to the top of the file, so the splitter sees only a number of empty sections followed by one large one. Results of
echo 'module Foo where' > Foo.hs for i in `seq 1 10`; do echo "foo$i = 'c'" >> Foo.hs; done mkdir Foo_split ghc -O -split-objs -c Foo.hs -v -keep-tmp-files
are attached, using
$ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)
Amd64 doesn't seem to be afflicted.
Thanks Ian