On 14/09/2010, at 8:50 PM, Simon Peyton-Jones wrote:

> This is serious: can't build GHC on MacOS.  
> 
> Failing when building the .o file for GHCi.  Looks like #3260.
> 
> Short term hacks:
>  a) remove codegens for all except the actual target arch

This didn't work. I #ifdefed out the appropriate things and removed the modules 
from the cabal file, but trying to build without the SPARC, PPC and Alpha 
codegen still gives the same error.


>  b) compile with -fPIC  

Nope. Setting -fPIC in SRC_HC_OPTS just yields the same error. 

The object files are also bigger with than without. For example, the stage2 
Bag.o file is 84k with PIC but 74k without.


>  c) reordering modules in .cabal?

I had a few goes by hand, but it didn't help, and I don't think it's going to. 

I've been poking through the source of MacOS ld, and the header file 
/usr/include/mach-o/reloc.h mentioned in the original ticket. From what I 
understand, the field that is overflowing is the offset from the start of the 
section (text or data) to the thing that is being relocated. The field is only 
24bits long, which limits the relocatable contents of each section to 16MB. The 
field is not the offset between the source and target symbols, so reordering 
modules won't help.

I don't know what the difference between "relocatable contents" and "the whole 
.o file" is, or how many sections we're using. In my build tree from Sept 9th 
the resulting file is 44MB and it made that ok.


>  d) use two .o files?

Maybe. 

So while digging I noticed the recent switch to Data.Map has also caused a 
space blowout in some files.

In the build of today CmmStackLayout.o is 458k
  desire:ghc-head-incoming benl$ ls -l compiler/stage2/build/CmmStackLayout.o
  -rw-r--r--  1 benl  staff  458788 15 Sep 17:17 
compiler/stage2/build/CmmStackLayout.o

But back on Sept 9th it was only 145k
  desire:ghc-head-validate benl$ ls -l compiler/stage2/build/CmmStackLayout.o
  -rw-r--r--  1 benl  staff  145056 15 Sep 17:17 
compiler/stage2/build/CmmStackLayout.o

I'm guessing this is just over-aggressive inlining.

Most of the files are also a bit bigger, but I'm not sure if this is type 
inferencer or Data.Map related. I can dig more tomorrow.


Ben.

_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to