tn23, build 64, Failure

[Simon Marlow]

On 23/06/2010 01:56, Builder wrote:
> ld: warning codegen in _stg_ap_pppppp_fast (offset 0x000000A4) prevents image from loading in dyld shared cache
> ld: warning codegen in _stg_ap_pppppp_fast (offset 0x000000C3) prevents image from loading in dyld shared cache
> ld: warning codegen in _stg_ap_pppppp_fast (offset 0x000000EA) prevents image from loading in dyld shared cache
> ld: warning codegen in _stg_ap_pppppp_fast (offset 0x00000117) prevents image from loading in dyld shared cache
> ld: warning codegen in _stg_ap_pppppp_fast (offset 0x00000147) prevents image from loading in dyld shared cache
> ld: warning codegen in _stg_ap_pppppp_fast (offset 0x00000163) prevents image from loading in dyld shared cache
> ld: absolute addressing (perhaps -mdynamic-no-pic) used in _stg_ap_0_fast from rts/dist/build/Apply.dyn_o not allowed in slidable image
> collect2: ld returned 1 exit status
> make[1]: *** [rts/dist/build/libHSrts-ghc6.13.20100623.dylib] Error 1
> make: *** [all] Error 2

This is OS X, right?  Was this build working before?  I think this 
failure might be due to a change I made recently:

Thu Jun 17 07:00:25 PDT 2010  Simon Marlow <marlowsd at gmail.com>
   * disable -fPIC for the GC for performance reasons
   see comment for details

     M ./rts/ghc.mk +28

http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20100617140025-12142-113c10c855704bfbd753cfbc4def3efa7a3888c9.gz


The problem I encountered was that the GC is much slower (50%) on x86 
with -fPIC, due to the extra register pressure.  On x86/Linux it works 
to just omit -fPIC, and let the GC be linked dynamically at load-time. 
I also did the same trick for some of the other performance-critical 
pieces in the RTS, like Updates.cmm and Apply.cmm (where the above 
symbols are defined).

Perhaps omitting -fPIC doesn't work on OS X?  If not, we have a slight 
problem... the performance hit due to -fPIC on x86 is much too high to 
use it by default.

Cheers,
	Simon