GHC fails to compile with gcc 4.2.0

[ismail@…]

From Debian  bug #428060, I can also reproduce this with Pardus Linux (gcc 4.2.0) :

Trying to build ghc6 with gcc-4.2 as gcc results in:

...
------------------------------------------------------------------------
== /usr/bin/make all -wr -f Makefile;
in /var/tmp/build/stuff/ghc6-6.6.1/libraries/base
------------------------------------------------------------------------
../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude
-"#include" HsBase.h -funbox-strict-fields -package-name  base-2.1.1
-O -Rghc-timing -fgenerics  -fgenerics -split-objs    -c
Data/Typeable.hs-boot -o Data/Typeable.o-boot  -ohi
Data/Typeable.hi-boot
<<ghc: 15624572 bytes, 5 GCs, 98272/98272 avg/max bytes residency (1
samples), 18M in use, 0.00 INIT (0.00 elapsed), 0.11 MUT (1.09
elapsed), 0.02 GC (0.04 elapsed) :ghc>>
../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude
-"#include" HsBase.h -funbox-strict-fields -package-name  base-2.1.1
-O -Rghc-timing -fgenerics  -fgenerics -split-objs    -c
Data/Dynamic.hs-boot -o Data/Dynamic.o-boot  -ohi Data/Dynamic.hi-boot
<<ghc: 11938524 bytes, 4 GCs, 98224/98224 avg/max bytes residency (1
samples), 18M in use, 0.01 INIT (0.00 elapsed), 0.06 MUT (0.36
elapsed), 0.03 GC (0.03 elapsed) :ghc>>
../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude
-"#include" HsBase.h -funbox-strict-fields -package-name  base-2.1.1
-O -Rghc-timing -fgenerics  -fgenerics -split-objs    -c
GHC/Err.lhs-boot -o GHC/Err.o-boot  -ohi GHC/Err.hi-boot
<<ghc: 18035540 bytes, 5 GCs, 99228/99228 avg/max bytes residency (1
samples), 18M in use, 0.01 INIT (0.00 elapsed), 0.12 MUT (0.59
elapsed), 0.03 GC (0.03 elapsed) :ghc>>
../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude
-"#include" HsBase.h -funbox-strict-fields -package-name  base-2.1.1
-O -Rghc-timing -fgenerics  -fgenerics -split-objs    -c GHC/Base.lhs
-o GHC/Base.o  -ohi GHC/Base.hi
GHC/Base_split/.o::Base(void):(.data+0x0): multiple definition of
`base_GHCziBase_zeze_closure'
GHC/Base_split/Base__1.o:(.data+0x0): first defined here
GHC/Base_split/.o::Base(void): In function `base_GHCziBase_zeze_info':
ghc14747_0.hc:(.text+0xc): multiple definition of `base_GHCziBase_zeze_info'
GHC/Base_split/Base__1.o:ghc14747_0.hc:(.text+0xc): first defined here
GHC/Base_split/Base__3.o:(.data+0x0): multiple definition of
`base_GHCziBase_zeze_closure'
GHC/Base_split/Base__1.o:(.data+0x0): first defined here
GHC/Base_split/Base__3.o: In function `base_GHCziBase_zeze_info':
ghc14747_0.hc:(.text+0xc): multiple definition of `base_GHCziBase_zeze_info'
GHC/Base_split/Base__1.o:ghc14747_0.hc:(.text+0xc): first defined here
[more of the same elided]

The reason is that the split markers (__STG_SPLIT_MARKER in
includes/Stg.h) that the ghc compiler inserts into
C code are emitted differently into assembler with gcc-4.1 and gcc-4.2.
The latter seems to kind of delay them, so part of actual assembler code
is now before the first emitted split marker, which then is erroneously
taken as prologue material and copied into every split assembler source
resulting in lots of duplicate definitions.

As a temporary workaround, a build with --with-gcc=gcc-4.1 succeeds.

[igloo]

Thanks for the report. We know why this happens, but we haven't worked out how best to fix it yet.

[guest]

for me (BulatZ), support of newer gcc versions is important as far as gcc provides better speed than via-asm compilation

[duncan]

This is currently the number one most reported Gentoo Haskell bug. Most of our users who are installing ghc-6.6.1 at the moment have gcc-4.2.x.

[Isaac Dupree]

now that gcc-4.2.1 is out, gcc-4.2's adoption will keep increasing amongst normal users... possibly such as me

[simonmar]

I'm going to look at this.

[simonmar]

Fixed:

Tue Aug 21 16:15:53 BST 2007  Simon Marlow <simonmar@microsoft.com>
  * FIX #1427, #1569: gcc 4.2.x needs -fno-toplevel-reorder