i386/OSX build broken
benl at ouroborus.net
Wed Sep 15 03:44:20 EDT 2010
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?
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.
More information about the Cvs-ghc