Duncan Coutts schrieb:
So "ghc -split-objs" works now with either -optc-mcpu=v8 or -opta-mcpu=v9 (or even -opta-mcpu=ultrasparc).
Where should I place what so that my stage1 inplace-compiler works without "SplitObjs=NO" in mk/build.mk?
Try SRC_HC_OPTS = -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc
With this I've produced a binary saying: -bash-3.00$ ghc --version ghc-6.6: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'? Two further questions: 1. Without "SplitObjs=NO" in mk/build.mk, will every file be compiled as if -split-objs were on ghc's command line? 2. Will the options given in SRC_HC_OPTS be burned into the final stage2 compiler or will I have to supply these options explicitely again? Thanks Christian P.S. building under solaris requires over 2GB memory (and takes a day)
On Tue, 2006-10-17 at 12:15 +0200, Christian Maeder wrote:
Duncan Coutts schrieb:
So "ghc -split-objs" works now with either -optc-mcpu=v8 or -opta-mcpu=v9 (or even -opta-mcpu=ultrasparc).
Where should I place what so that my stage1 inplace-compiler works without "SplitObjs=NO" in mk/build.mk?
Try SRC_HC_OPTS = -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc
With this I've produced a binary saying: -bash-3.00$ ghc --version ghc-6.6: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'?
Yes! I get exactly the same under sparc linux for ghc-6.6. We need to file a bug report on this. I wouldn't normally complain too loudly about sparc linux since it's a bit of a niche market, but if this same issue affects sparc solaris then that's a bigger user base (lots of students at several unis).
Two further questions: 1. Without "SplitObjs=NO" in mk/build.mk, will every file be compiled as if -split-objs were on ghc's command line?
Not "as if", the build system really does add -split-objs and does some other magic when "SplitObjs=NO" is not in mk/build.mk.
2. Will the options given in SRC_HC_OPTS be burned into the final stage2 compiler or will I have to supply these options explicitely again?
No, they will not be 'burned' into the final compiler. To do that you'll want to modify the ghc wrapper script. In the Gentoo ghc ebuild we do that with: # Modify the ghc driver script to use GHC_CFLAGS echo "SCRIPT_SUBST_VARS += GHC_CFLAGS" >> "${S}/driver/ghc/Makefile" echo "GHC_CFLAGS = ${GHC_CFLAGS}" >> "${S}/driver/ghc/Makefile" before the ./configure and other parts of the build get started.
P.S. building under solaris requires over 2GB memory (and takes a day)
It takes 12 hours on my old 500Mhz sparc with 1GB ram. I know split-objs takes lots of memory when building the archive, but 2GB seems excessive. Duncan
Duncan Coutts schrieb:
Try SRC_HC_OPTS = -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc With this I've produced a binary saying: -bash-3.00$ ghc --version ghc-6.6: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'?
Yes! I get exactly the same under sparc linux for ghc-6.6.
I've tried the same on a different machine (with another gcc) and now it works! It works with gcc_4.0.3_s10 on "SunOS leo 5.10 Generic_118833-20 sun4u sparc SUNW,Sun-Fire-280R" -bash-3.00$ compiler/stage2/ghc-6.6 ghc-6.6: missing -B<dir> option -bash-3.00$ ldd compiler/stage2/ghc-6.6 librt.so.1 => /lib/librt.so.1 libdl.so.1 => /lib/libdl.so.1 libreadline.so.5 => /usr/local/lib/libreadline.so.5 libncurses.so.5 => /usr/local/lib/libncurses.so.5 libm.so.2 => /usr/local/lib/libm.so.2 libgmp.so.3 => /usr/local/lib/libgmp.so.3 libpthread.so.1 => /lib/libpthread.so.1 libc.so.1 => /lib/libc.so.1 libaio.so.1 => /lib/libaio.so.1 libmd5.so.1 => /lib/libmd5.so.1 libm.so.2 => /lib/libm.so.2 /platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1 /platform/SUNW,Sun-Fire-280R/lib/libmd5_psr.so.1 It crashes as above on "SunOS cni 5.10 Generic_118833-24 sun4u sparc SUNW,Sun-Fire-V240" with gcc_3.4.4_s10. -bash-3.00$ compiler/stage2/ghc-6.6 ghc-6.6: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'? -bash-3.00$ ldd compiler/stage2/ghc-6.6 librt.so.1 => /lib/librt.so.1 libdl.so.1 => /lib/libdl.so.1 libreadline.so.5 => /usr/local/lib/libreadline.so.5 libncurses.so.5 => /usr/local/lib/libncurses.so.5 libm.so.2 => /usr/local/lib/libm.so.2 libgmp.so.3 => /usr/local/lib/libgmp.so.3 libpthread.so.1 => /lib/libpthread.so.1 libc.so.1 => /lib/libc.so.1 libaio.so.1 => /lib/libaio.so.1 libmd5.so.1 => /lib/libmd5.so.1 libm.so.2 => /lib/libm.so.2 /platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1 /platform/SUNW,Sun-Fire-V240/lib/libmd5_psr.so.1
Christian, I've reported this bug here: http://hackage.haskell.org/trac/ghc/ticket/951 Please add any further info you think necessary. Duncan On Wed, 2006-10-18 at 11:21 +0200, Christian Maeder wrote:
Duncan Coutts schrieb:
Try SRC_HC_OPTS = -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc With this I've produced a binary saying: -bash-3.00$ ghc --version ghc-6.6: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'?
Yes! I get exactly the same under sparc linux for ghc-6.6.
I've tried the same on a different machine (with another gcc) and now it works!
Duncan Coutts schrieb:
1. Without "SplitObjs=NO" in mk/build.mk, will every file be compiled as if -split-objs were on ghc's command line?
Not "as if", the build system really does add -split-objs and does some other magic when "SplitObjs=NO" is not in mk/build.mk.
My stage2 compiler (created without "SplitObjs=NO") works without any further options. But as soon as I add -split-objs I also have to add -opta-mcpu=ultrasparc. I wonder when -split-objs is in effect? Only during building? Or never under solaris if not supplied explicitely? Christian
Duncan Coutts schrieb:
On Tue, 2006-10-17 at 12:15 +0200, Christian Maeder wrote:
P.S. building under solaris requires over 2GB memory (and takes a day)
It's only have half of this. I've mixed up "du -s" (showing Blocks) and "du -sh". My tree also included a binary-dist. -bash-3.00$ du -s 2266972 . -bash-3.00$ du -sh 1.1G . -bash-3.00$ cd ghc-6.6/ #this is the binary-dist only -bash-3.00$ du -sh 331M .
It takes 12 hours on my old 500Mhz sparc with 1GB ram. I know split-objs takes lots of memory when building the archive, but 2GB seems excessive.
Judging from the first and last created files (below) it took 9 hours on my machine: Model: Sun Fire 280R Memory Size (MB): 3072 Processor Speed (MHz): 900 -bash-3.00$ ll utils/mkdependC/mkdependC -rwxr-xr-x 1 maeder wimi 6057 Oct 20 16:54 utils/mkdependC/mkdependC -bash-3.00$ ll compiler/stage2/ghc-6.6 -rwxr-xr-x 1 maeder wimi 21069118 Oct 21 01:52 compiler/stage2/ghc-6.6 Cheers Christian fast 3:30 hours took: Hardware Architecture: pc Operating System: solaris10 Model: AMD Athlon-64 Memory Size (MB): 1024 Processor Speed (MHz): 2000 -bash-3.1$ ll utils/mkdependC/mkdependC -rwxr-xr-x 1 maeder wimi 6054 Nov 2 13:21 utils/mkdependC/mkdependC -bash-3.1$ ll compiler/stage2/ghc-6.6 -rwxr-xr-x 1 maeder wimi 20629720 Nov 2 16:49 compiler/stage2/ghc-6.6
participants (2)
-
Christian Maeder -
Duncan Coutts