OS X: ghc broken on Snow Leopard

[bbb]

I downloaded GHC-6.10.4-i386.pkg and installed it on a OS X 10.6 Snow Leopard seed. gcc in Snow Leopard defaults to x86_64. This breaks even trivial builds with GHC since it passes either no or incompatible flags.

GHC should either produce proper x86_64 assembly or pass "-arch i386" to force a 32-bit build.

An example follows.

Trivial source:

$ cat Foo.hs
main = do
     putStrLn "Foo!"

Direct build broken:

$ ghc --make Foo.hs -v3
Glasgow Haskell Compiler, Version 6.10.4, for Haskell 98, stage 2 booted by GHC version 6.10.3.20090628
Using package config file: /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/./package.conf
hiding package base-3.0.3.1 to avoid conflict with later version base-4.1.0.0
wired-in package ghc-prim mapped to ghc-prim-0.1.0.0
wired-in package integer mapped to integer-0.1.0.1
wired-in package base mapped to base-4.1.0.0
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0.1.0
wired-in package syb mapped to syb-0.1.0.1
wired-in package template-haskell mapped to template-haskell-2.3.0.1
wired-in package dph-seq mapped to dph-seq-0.3
wired-in package dph-par mapped to dph-par-0.3
Hsc static flags: -static
*** Chasing dependencies:
Chasing modules from: *Foo.hs
Stable obj: []
Stable BCO: []
Ready for upsweep
  [NONREC
      ModSummary {
         ms_hs_date = Fri Jul 24 11:35:52 PDT 2009
         ms_mod = main:Main,
         ms_imps = []
         ms_srcimps = []
      }]
compile: input file Foo.hs
Created temporary directory: /var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24470_0
*** Checking old interface for main:Main:
[1 of 1] Compiling Main             ( Foo.hs, Foo.o )
*** Parser:
*** Renamer/typechecker:
*** Desugar:
    Result size = 10
*** Simplify:
    Result size = 8
*** Tidy Core:
    Result size = 8
*** CorePrep:
    Result size = 10
*** Stg2Stg:
*** CodeGen:
*** CodeOutput:
*** Assembler:
gcc -I. -c /var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24470_0/ghc24470_0.s -o Foo.o

/var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24470_0/ghc24470_0.s:36:0:
    suffix or operands invalid for `push'

/var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24470_0/ghc24470_0.s:83:0:
    suffix or operands invalid for `push'

/var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24470_0/ghc24470_0.s:130:0:
    suffix or operands invalid for `push'

/var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24470_0/ghc24470_0.s:156:0:
    32-bit absolute addressing is not supported for x86-64

/var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24470_0/ghc24470_0.s:156:0:
    cannot do signed 4 byte relocation

/var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24470_0/ghc24470_0.s:159:0:
    32-bit absolute addressing is not supported for x86-64

/var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24470_0/ghc24470_0.s:159:0:
    cannot do signed 4 byte relocation
*** Deleting temp files:
Deleting: /var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24470_0/ghc24470_0.s
*** Deleting temp dirs:
Deleting: /var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24470_0

Via-C build broken:

$ ghc --make Foo.hs -v3 -fvia-c
Glasgow Haskell Compiler, Version 6.10.4, for Haskell 98, stage 2 booted by GHC version 6.10.3.20090628
Using package config file: /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/./package.conf
hiding package base-3.0.3.1 to avoid conflict with later version base-4.1.0.0
wired-in package ghc-prim mapped to ghc-prim-0.1.0.0
wired-in package integer mapped to integer-0.1.0.1
wired-in package base mapped to base-4.1.0.0
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0.1.0
wired-in package syb mapped to syb-0.1.0.1
wired-in package template-haskell mapped to template-haskell-2.3.0.1
wired-in package dph-seq mapped to dph-seq-0.3
wired-in package dph-par mapped to dph-par-0.3
Hsc static flags: -static
*** Chasing dependencies:
Chasing modules from: *Foo.hs
Stable obj: []
Stable BCO: []
Ready for upsweep
  [NONREC
      ModSummary {
         ms_hs_date = Fri Jul 24 11:35:52 PDT 2009
         ms_mod = main:Main,
         ms_imps = []
         ms_srcimps = []
      }]
compile: input file Foo.hs
Created temporary directory: /var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24479_0
*** Checking old interface for main:Main:
[1 of 1] Compiling Main             ( Foo.hs, Foo.o )
*** Parser:
*** Renamer/typechecker:
*** Desugar:
    Result size = 10
*** Simplify:
    Result size = 8
*** Tidy Core:
    Result size = 8
*** CorePrep:
    Result size = 10
*** Stg2Stg:
*** CodeGen:
*** CodeOutput:
*** C Compiler:
gcc -x c /var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24479_0/ghc24479_0.hc -o /var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24479_0/ghc24479_0.raw_s -DDONT_WANT_WIN32_DLL_SUPPORT -mdynamic-no-pic -march=i686 -fno-defer-pop -fomit-frame-pointer -fno-builtin -DSTOLEN_X86_REGS=4 -fwrapv -mno-omit-leaf-frame-pointer -fno-unit-at-a-time -ffloat-store -fno-strict-aliasing -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=610 -DTABLES_NEXT_TO_CODE -I . -I /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/base-4.1.0.0/include -I /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/include
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5646~6/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5646)
 /usr/libexec/gcc/i686-apple-darwin10/4.2.1/cc1 -quiet -v -I . -I /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/base-4.1.0.0/include -I /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/include -imultilib x86_64 -D__DYNAMIC__ -DDONT_WANT_WIN32_DLL_SUPPORT -DSTOLEN_X86_REGS=4 -D__GLASGOW_HASKELL__=610 -DTABLES_NEXT_TO_CODE /var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24479_0/ghc24479_0.hc -quiet -dumpbase ghc24479_0.hc -mmacosx-version-min=10.6.0 -mdynamic-no-pic -march=i686 -mno-omit-leaf-frame-pointer -m64 -auxbase-strip /var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24479_0/ghc24479_0.raw_s -O -Wimplicit -version -fno-defer-pop -fomit-frame-pointer -fno-builtin -fwrapv -fno-unit-at-a-time -ffloat-store -fno-strict-aliasing -o /var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24479_0/ghc24479_0.raw_s
ignoring nonexistent directory "/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../../../i686-apple-darwin10/include"
#include "..." search starts here:
#include <...> search starts here:
 .
 /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/base-4.1.0.0/include
 /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/include
 /usr/local/include
 /usr/lib/gcc/i686-apple-darwin10/4.2.1/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.

/var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24479_0/ghc24479_0.hc:1:0:
     error: CPU you selected does not support x86-64 instruction set
GNU C version 4.2.1 (Apple Inc. build 5646) (i686-apple-darwin10)
	compiled by GNU C version 4.2.1 (Apple Inc. build 5646).
GGC heuristics: --param ggc-min-expand=150 --param ggc-min-heapsize=131072
*** Deleting temp files:
Deleting: /var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24479_0/ghc24479_0.raw_s /var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24479_0/ghc24479_0.hc
Warning: deleting non-existent /var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24479_0/ghc24479_0.raw_s
*** Deleting temp dirs:
Deleting: /var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24479_0

[igloo]

Thanks for the report. This should be fixed by:

Sat Aug  8 23:25:37 BST 2009  Ian Lynagh <igloo@earth.li>
  * Pass -m32 to gcc on i386 and ppc OS X
  This makes GHC work even if you are actually running it in 64bit mode,
  e.g. on OS X 10.6 Snow.

[Syzygies]

I'm posting some links of interest, for the many of us finding this ticket on Snow Leopard's release day.

This ticket is closely related to ticket #2965 (new feature request)  GHC on OS X does not compile 64-bit One can show one's support for this request by adding one's email to its cc: list.

There is an active Haskell Cafe thread, with more detailed directions on the fix given here:  Snow Leopard Breaks GHC

One sees comments elsewhere, e.g. on reddit posts, to the effect of "aren't most OS X users just 2 core tourists on 2 GB MacBooks?"? Meanwhile, as GHC emerges as the only credible choice for a parallel language (add a couple of lines of code, and it just works), what I've seen makes OS X appear to be the only credible choice for a parallel operating system:  No "last core parallel slowdown" on OS X

OS X self-identifies as a 64-bit operating system, yet GHC support is limited to 32-bits. It would be nice if there was a status somewhere between (closed) and (new feature request) in tone, that recognized the outdated state of GHC support for OS X.

[chak]

I just verified that the patch quoted above is not sufficient to build GHC on Snow Leopard. Validate dies on the first file that the stage1 compiler tries to compile. (BTW, GHC does not run in 64 bit mode on SL. It's just that the Apple's compiler tool chain builds 64 bit binaries by default.)

[chak]

Just pushed

Thu Sep 17 14:41:21 EST 2009  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Fix build on Mac OS 10.6 (Snow Leopard)
  - We have -m32 as machine-dependent option for gcc for a 32 bit build
  - Like on OpenBSD, SL requires -fno-stack-protector to avoid triggering the
    stack smashing checks inserted by gcc by default on this platform.

which fixes the build on SL and also validates on Leopard.

NB: This fixes the build. However, the testsuite doesn't work as SL comes with Python 2.6.1, which apparently has a bug in on of its libraries that is tickled by GHC's testsuite. The error message is

Traceback (most recent call last):
  File "../../driver/runtests.py", line 112, in <module>
    maj = int(re.sub('[^0-9].*', '', maj))
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/re.py", line 150, in sub
    return _compile(pattern, 0).sub(repl, string, count)
TypeError: expected string or buffer

[chak]

The testsuite works now. Five tests are currently failing:

Unexpected failures:
   TH_repE2(normal)
   TH_repPrim(normal)
   ann01(normal)
   ffi018_ghci(ghci)
   prog002(ghci)

[GregoryCollins]

I don't think that the advice on the mailing list is enough to fix all of the issues, which is why you're seeing test failures with FFI. I'm using the stock 6.10.4 OSX binary release on Snow Leopard, with the shell script wrappers patched to add "-optc-m32 -opta-m32 -optl-m32".

I can't get zlib to build properly, I keep getting "incompatible zlib version" errors. After pounding my head at it for a while, and confirming "yes, I'm linking to the correct zlib" and "yes, this is a 32-bit executable", I decided to get to the bottom of it. I built a version of the C zlib in debugging mode and set a breakpoint on the init function. It's failing here (inflate.c line 152):

    if (version == Z_NULL || version[0] != ZLIB_VERSION[0] ||
        stream_size != (int)(sizeof(z_stream)))
        return Z_VERSION_ERROR;

In gdb:

(gdb) print stream_size
$3 = 112
(gdb) print sizeof(z_stream)
$4 = 56

Hmm, that isn't right. Here's the relevant snippet of Stream.hsc:

c_inflateInit2 :: StreamState -> CInt -> IO CInt
c_inflateInit2 z n =
  withCAString #{const_str ZLIB_VERSION} $ \versionStr ->
    c_inflateInit2_ z n versionStr (#{const sizeof(z_stream)} :: CInt)

Looks like that "sizeof" is being executed in a 64-bit context by hsc2hs; I haven't seen this mentioned on the mailing list but I think users also need to patch /usr/bin/hsc2hs to read:

exec /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/hsc2hs $tflag $HSC2HS_EXTRA --cflag="-m32" --lflag="-m32" ${1+"$@"} "$Iflag"

Does the aforementioned patch address this issue?

[duncan]

This looks like the right explanation for the symptoms when using zlib. The program compiled by hsc2hs does need to be using the same environment as everything else.

[simonmar]

Manuel, can this ticket be closed now? Does hsc2hs pass the correct flags to gcc when invoked from Cabal?

[chak]

Replying to simonmar:

Manuel, can this ticket be closed now? Does hsc2hs pass the correct flags to gcc when invoked from Cabal?

No, hsc2hs doesn't get the right flags. Specifically, what is missing is that if we have i386_TARGET_ARCH and darwin_TARGET_OS, we need to pass -m32 to the compile and link flags that hsc2hs passes to gcc.

[igloo]

Fixed by

Sat Nov  7 11:44:49 PST 2009  Ian Lynagh <igloo@earth.li>
  * Add C and linker flags to hsc2hs; fixes trac #3400

[guest]

It doesn't seem to allow linking with 64-bit OSX libraries like XLib (e.g. for xmonad). Am I right ?

[chak]

Replying to guest:

It doesn't seem to allow linking with 64-bit OSX libraries like XLib (e.g. for xmonad). Am I right ?

The libraries on Snow Leopard are shipped as universal binaries containing code for PPC, i386, and x86_64. When a 32-bit GHC invokes the linker, it will automatically pick the 32-bit version of the library.