OS X: ghc broken on Snow Leopard

changed weight to 5

closed

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.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

mentioned in issue #3471 (closed)

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 (closed) (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.

reopened

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.)

Trac metadata

Trac field	Value
Version	6.10.4 → 6.11
Resolution	ResolvedFixed → Unresolved

changed milestone to %6.12.1

changed weight to 7

Trac metadata

Trac field	Value
Priority	normal → high

assigned to @mchakravarty

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

closed

The testsuite works now. Five tests are currently failing:

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

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

reopened

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?

Trac metadata

Trac field	Value
Resolution	ResolvedFixed → Unresolved

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.

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

Replying to [ticket:3400#comment:36653 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.

assigned to @trac-igloo and unassigned @mchakravarty

Trac metadata

Trac field	Value
CC	korpios@korpios.com → korpios@korpios.com, pierreetienne.meunier@gmail.com

closed

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

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

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

Replying to [ticket:3400#comment:37162 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.

Trac metadata

Trac field	Value
TypeOfFailure	- → OtherFailure
CC	korpios@korpios.com, pierreetienne.meunier@gmail.com → filcab+ghc@gmail.com, korpios@korpios.com, pierreetienne.meunier@gmail.com

mentioned in issue #5448

mentioned in issue #9421 (closed)

added Phigh label

OS X: ghc broken on Snow Leopard

Trivial source:

Direct build broken:

Via-C build broken:

Child items ...

Activity

Trac field	Value
Version	6.10.4
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture