[Moving to haskell-cafe] OK, after going through this several times, here's what I've found: 1) The Debian linux build of haskell produces large executables. 2) The generic x86 binary distribution produces smallish executables (383765 bytes; still kind of large; stripped it's 191584 bytes). 3) I removed my entire source distribution, and recompiled from scratch with this build.mk file: SRC_HC_OPTS = -H64m -O2 GhcLibHcOpts = -O2 -fgenerics SplitObjs = YES I did an "autoreconf; configure; make; make install" and then recompiled hnop from scratch. I got large executables (2838528 bytes unstripped, 1540072 stripped). I'm at a loss here. Somehow, the SplitObjs option doesn't seem to be doing the job. Any suggestions would be appreciated. Mike Donald Bruce Stewart wrote:
Hmm. Did you build from scratch? Perhaps the libraries didn't get rebuilt with split objs ?
mvanier:
I've tried doing a manual build with SplitObjs set to YES, but without success; either the compiler was broken or it would still generate large executables. So as a sanity check, I installed the debian unstable build. But that one also gives me a huge executable:
% ls -l total 2720 -rw-r--r-- 1 mvanier mvanier 818 Jun 29 20:48 LICENSE -rw-r--r-- 1 mvanier mvanier 308 Jun 30 04:59 Main.hi -rw-r--r-- 1 mvanier mvanier 80 Jun 29 20:48 Main.hs -rw-r--r-- 1 mvanier mvanier 1928 Jun 30 04:59 Main.o -rw-r--r-- 1 mvanier mvanier 43 Jun 29 20:48 Makefile -rwxr-xr-x 1 mvanier mvanier 2756151 Jun 30 04:59 hnop -rw-r--r-- 1 mvanier mvanier 807 Jun 29 23:56 hnop.tar.gz
Am I the only person in the world with this problem?
Also, for some inexplicable reason, debian puts ghci into /usr/X11R6/bin, though ghc is in the more sensible /usr/bin/ghc.
TIA,
Mike
Donald Bruce Stewart wrote:
mvanier:
Nope, just ghc-6.4.2 that I compiled myself on a Dell x86 laptop (Pentium M). I didn't use any strange configure options. Is there a special configure flag for split objects? If not, how is this determined? Ah ha! You need to add -split-objs to the build.mk used by ghc to build its libraries, as described here: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/~checkout~/fptools/ghc/HACKING?con...
You want: SplitObjs = YES
in mk/build.mk
It's not enabled by default, since it doesn't work on every platform. The ghc that is distributed in the debian package system does have split objs on, though.
Cheers, Don
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
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
[resending as the original seems to have been silently eaten; attachements are at http://urchin.earth.li/~ian/splitting/ ] 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
On Sat, 2006-07-01 at 16:36 +0100, Ian Lynagh wrote:
[resending as the original seems to have been silently eaten; attachements are at http://urchin.earth.li/~ian/splitting/ ]
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.
http://hackage.haskell.org/trac/ghc/ticket/809 this is now fixed by ghc passing -fno-unit-at-a-time to gcc
Amd64 doesn't seem to be afflicted.
because it was already using -fno-unit-at-a-time Duncan
participants (3)
-
Duncan Coutts -
Ian Lynagh -
mvanier