ghc-6.6 under sparc-sun-solaris

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Tue Oct 17 15:35:30 EDT 2006


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



More information about the Glasgow-haskell-users mailing list