GHC on OS X does not compile 64-bit

[Axman6]

Not much to say other than GHC does not compile as a 64-bit program on OS X, even on 64-bit systems (all shipping macs are 64-bit, and have been for somewhere up to a year).

I've tried to see if i can get it to compile 64-bit, and I haven't had any luck at all. configure doesn't seem to take any notice of CFLAGS etc.

[chak]

I agree that it would be interesting to get this to work. But this won't be done with a couple of CFLAGS. There is more involved, such as getting the runtime system compile for 64bit. All the required code should already be in there (for 64bit support on other archs), but the Mac build currently assumes 32bit. So, that should be split into two paths, one Mac 32bit and one Mac 64bit (and then there is Mac ppc of course).

[thoughtpolice]

There seems to already be support for the x86_64-apple-darwin target in configure.ac; running configure like so:

./configure --build=x86_64-apple-darwin

results in x86_64_HOST_ARCH being defined throughout.

The Stage1 compiler seems to mostly build after this; the first failure is in Adjustor.c because as Manuel said the runtime system isn't designed to handle 64bit OS X yet - the code path indeed needs to be split.

I'm taking over this ticket because I'm interested in getting it working; 64bit support is already there and it would be nice to have on OS X.

[simonmar]

I've added x86_64-apple-darwin to the list of Tier-2 platforms on Platforms (optimistically assuming that it works unregisterised, at least).

[pumpkin]

Replying to simonmar:

I've added x86_64-apple-darwin to the list of Tier-2 platforms on Platforms (optimistically assuming that it works unregisterised, at least).

I'm not sure it even works unregistered, actually. The unregistered OS X x86_64 ghc build that Ian Lynagh made a couple of months ago unfortunately included a bug that has since been fixed, that appeared (to Austin and me, at least) to prevent using it to build another GHC with it. And more recent attempts on my part to make a new unregistered build for x86_64 ran into several issues as described on #3472 . I've tried several times and have failed, but maybe my approach is incorrect, so I'd welcome it if anyone else on this CC list could try similar steps to see if it's PEBKAC :)

[chak]

Replying to simonmar:

I've added x86_64-apple-darwin to the list of Tier-2 platforms on Platforms (optimistically assuming that it works unregisterised, at least).

Since the release of Snow Leopard (Mac OS X 10.5.8) x86_64-apple-darwin is the default for Macs. Given the upgrade price for Snow Leopard and the typical adoption rate of Macs users, this will soon be the most widely used Mac platform.

[maeder]

Is there a workaround for template haskell (TH) code being compiled in 32bit mode? How does TH call ghc internally? (Adding "-optc-m32 -opta-m32 -optl-m32" to the installed ghci (and runghc?) did not help.)

 http://www.haskell.org/pipermail/haskell-cafe/2009-September/066009.html

[simonmar]

Ok, just to summarise the situation:

• 6.10.4 needs a tiny fix to work with Snow Leopard: add -optc-m32 -opta-m32 -optl-m32 to the script /usr/bin/ghc, or wherever ghc lives on your system. If there is a problem with TH, then please make a separate ticket.

• The 32-bit OS X distribution of GHC 6.12.1 will work on Snow Leopard without modification.

• A 64-bit port is being worked on by various people (see e.g. #3472; we will help with the porting effort)

• 64-bit OS X is, for the time being, a Tier-2 platform. That means we expect the community to support it, with guidance from GHC HQ. We don't hold up releases for it. (this is moot since there isn't even a working port at this stage, but still). However, depending on how much extra work is involved and the demand, we'll consider upgrading it to Tier-1 in the future.

[simonpj]

Just to add: what we would really like is for someone to step forward as the Maintainer of the X86_64 MacOS port of GHC. Then we really could make it a Tier-1 platform (see  http://hackage.haskell.org/trac/ghc/wiki/Platforms). In principle its not hard:

• MacOS is already in one Tier-1 platform (32 bit)
• x86_64 is already in another Tier-1 platform (Linux)

All we need to do is to put the two together -- and some folk are already working on that (#3472).

But for us to sign up to Tier-1-ness, we need someone (or a small group) to sign up to being the maintainers.

(Ben recently volunteered to be the maintainer for Sparc; thanks Ben.)

Simon

[pumpkin]

Replying to simonpj:

Just to add: what we would really like is for someone to step forward as the Maintainer of the X86_64 MacOS port of GHC. Then we really could make it a Tier-1 platform (see  http://hackage.haskell.org/trac/ghc/wiki/Platforms). In principle its not hard: * MacOS is already in one Tier-1 platform (32 bit) * x86_64 is already in another Tier-1 platform (Linux) All we need to do is to put the two together -- and some folk are already working on that (#3472). But for us to sign up to Tier-1-ness, we need someone (or a small group) to sign up to being the maintainers. (Ben recently volunteered to be the maintainer for Sparc; thanks Ben.) Simon

I would definitely be willing to "co-maintain" this with someone else, but as a relative newcomer to Haskell and GHC (who hasn't even succeeded in making an unregistered build for this platform yet) I don't think I'd be suitable as a sole maintainer. Any experts out there who'd be willing to help?

[geekiac]

Replying to pumpkin: I too would be happy to help to maintain this, however, I am also a relative newbie and would need assistance. If someone could point me in the right direction, I am a fast learner!!!!

Replying to simonpj:

Just to add: what we would really like is for someone to step forward as the Maintainer of the X86_64 MacOS port of GHC. Then we really could make it a Tier-1 platform (see  http://hackage.haskell.org/trac/ghc/wiki/Platforms). In principle its not hard: * MacOS is already in one Tier-1 platform (32 bit) * x86_64 is already in another Tier-1 platform (Linux) All we need to do is to put the two together -- and some folk are already working on that (#3472). But for us to sign up to Tier-1-ness, we need someone (or a small group) to sign up to being the maintainers. (Ben recently volunteered to be the maintainer for Sparc; thanks Ben.) Simon

I would definitely be willing to "co-maintain" this with someone else, but as a relative newcomer to Haskell and GHC (who hasn't even succeeded in making an unregistered build for this platform yet) I don't think I'd be suitable as a sole maintainer. Any experts out there who'd be willing to help?

[axman6]

It's my ticket, so i guess i could take some responsibility. I'm not sure how useful I could be, or how much time i could spend, at least not until the summer holidays here (December to February). I've also never looked into GHC's source, so I'd probably need help too. So anyway, sign me up as co-maintainer, and i'll see how i can help when I have time.

I'd also like to say thanks to everyone for the recent activity regarding this ticket. With Snow Leopard being the first Mac OS favouring 64-bit over 32, I think it's important that GHC move that way, so it doesn't feel left behind on the system.

Replying to pumpkin:

Replying to simonpj:

Just to add: what we would really like is for someone to step forward as the Maintainer of the X86_64 MacOS port of GHC. Then we really could make it a Tier-1 platform (see  http://hackage.haskell.org/trac/ghc/wiki/Platforms). In principle its not hard: * MacOS is already in one Tier-1 platform (32 bit) * x86_64 is already in another Tier-1 platform (Linux) All we need to do is to put the two together -- and some folk are already working on that (#3472). But for us to sign up to Tier-1-ness, we need someone (or a small group) to sign up to being the maintainers. (Ben recently volunteered to be the maintainer for Sparc; thanks Ben.) Simon

I would definitely be willing to "co-maintain" this with someone else, but as a relative newcomer to Haskell and GHC (who hasn't even succeeded in making an unregistered build for this platform yet) I don't think I'd be suitable as a sole maintainer. Any experts out there who'd be willing to help?

[chak]

Replying to simonpj:

Just to add: what we would really like is for someone to step forward as the Maintainer of the X86_64 MacOS port of GHC. Then we really could make it a Tier-1 platform (see  http://hackage.haskell.org/trac/ghc/wiki/Platforms). In principle its not hard: * MacOS is already in one Tier-1 platform (32 bit) * x86_64 is already in another Tier-1 platform (Linux) All we need to do is to put the two together -- and some folk are already working on that (#3472). But for us to sign up to Tier-1-ness, we need someone (or a small group) to sign up to being the maintainers. (Ben recently volunteered to be the maintainer for Sparc; thanks Ben.) Simon

The way I see it, as soon as GHC works as a 64 bit app on OS X, this will very soon be the main version for OS X and it's the maintenance of the 32 bit version that you need to worry about. I am currently listed (with Wolfgang Taller) as x86 platform maintainer. As soon as there is a 64 bit version of GHC on OS X, I will surely use that (as will most GHC users on Macs).

[simonmar]

I've removed Wolfgang as maintainer, as we haven't heard from him in a long time. That leaves you ;-) Any other interested maintainers, please add yourselves: Contributors.

Bear in mind that the 64-bit build will use twice as much memory, so I can imagine some people might still want the 32-bit version, especially since a large proportion of OS X machines are laptops.

[jeffschwab]

The work-around flags above are apparently no longer sufficient to install the Haskell platform on Snow Leopard (OS X 10.6.2). The error message is that "happy" is required. Given that one cannot build happy without Haskell, and cannot build Haskell without Happy, it seems one is completely out of luck. MacPorts? gives an error message for both happy and ghc:

Error: Target org.macports.fetch returned: ghc is not yet supported on Mac OS X 10.6.x (SnowLeopard?)

I know next to nothing about either Haskell or MacPorts?, but I'd be happy to spend a weekend or two wrestling with it, if someone can point me in the right direction.

[jeffschwab]

Happy is apparently included in the 32-bit binary platform download; configure and make work with these instructions:

 http://obvioushints.blogspot.com/2009/09/running-haskell-ghc-on-snow-leopard.html

Sadly, make install fails with an error in mtl (a "monad transformer library," whatever that is):

haskell-platform-2009.2.0.2$ make install
scripts/install.sh
Installing mtl-1.1.0.2...

Error:
The mtl-1.1.0.2/Setup script does not exist or cannot be run
make: *** [install] Error 2

The script does exist, but apparently has unresolved dependencies:

haskell-platform-2009.2.0.2$ ghc packages/mtl-1.1.0.2/Setup.hs
Undefined symbols:
  "___stginit_Cabalzm1zi6zi0zi3_DistributionziSimple_", referenced from:
      ___stginit_Main_ in Setup.o
  "_Cabalzm1zi6zi0zi3_DistributionziSimple_defaultMain_closure", referenced from:
      _Main_main_info in Setup.o
      _ZCMain_main_info in Setup.o
      _Main_main_srt in Setup.o
      _ZCMain_main_srt in Setup.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

I don't know who mangled those "_Cabalzm1zi6zi..." names, but the XCode 3 default c++filt does not seem to recognize them.

[simonmar]

Jeff: add the --make flag to GHC when compiling Setup.hs.

[jeffschwab]

Thanks; ghc --make Setup.hs enables the creation of a stand-alone Setup executable, but "make install" still fails. It's not just mtl; most of the packages do not have Setup scripts. I think the problem is that ${platform}/scripts/build.sh is not completing normally. I've tried running it manually:

haskell-platform-2009.2.0.2$ scripts/build.sh Platform package mtl-1.1.0.2 is already installed. Skipping... Building "/usr/bin/ghc" "--make" "Setup" "-o" "Setup" "-package" "Cabal-1.6.0.3" Linking Setup ... "./Setup" "configure" "--package-db=../../packages/package.conf.inplace" "--prefix=/Users/jeff/opt/haskell" "--with-compiler=/usr/bin/ghc" "--with-hc-pkg=/usr/bin/ghc-pkg" "--with-hsc2hs=/usr/bin/hsc2hs" "--with-happy=../happy-1.18.4/dist/build/happy/happy" "--happy-options=--template=../happy-1.18.4" "--with-alex=../alex-2.3.1/dist/build/alex/alex" "--with-cabal-install=../cabal-install-0.6.2/dist/build/cabal/cabal" "--enable-library-profiling" unrecognized option `--with-cabal-install=../cabal-install-0.6.2/dist/build/cabal/cabal'

Error: Configuring the happy-1.18.4 package failed

By the way, during the initial make (before make install), I see an awful lot of warnings about unused variables, compatibility issues, and deprecation. Is that normal?

[jeffschwab]

Sorry, the formatting of that post got screwed up a bit by the wiki. The salient error message is:

unrecognized option `--with-cabal-install=../cabal-install-0.6.2/dist/build/cabal/cabal' Error: Configuring the happy-1.18.4 package failed

[ChrisKuklewicz]

Will the arrival of the LLVM backend make OS X 64-bit code generation easier? Could this be used to bootstrap some of the runtime?

[simonmar]

Replying to ChrisKuklewicz:

Will the arrival of the LLVM backend make OS X 64-bit code generation easier? Could this be used to bootstrap some of the runtime?

Probably not, I expect our x86-64 code generator should work well enough. The OSX ABI is a little different from Linux in that IIRC -fPIC is the default, but our code generator already handles this I believe.

[igloo]

I think #4163 is far enough along that we'll be able to use cross-compilation to bootstrap 6.14.1 on OSX 64.

[gidyn]

Replying to simonmar:

Bear in mind that the 64-bit build will use twice as much memory, so I can imagine some people might still want the 32-bit version, especially since a large proportion of OS X machines are laptops.

Pointers might be twice as long, but the data shouldn't magically double in size.

[simonmar]

Replying to gidyn:

Pointers might be twice as long, but the data shouldn't magically double in size.

Ordinary Haskell data structures do double in size on a 64-bit machine with GHC. The only data structures that do not double in size are things like unboxed arrays, vectors, ByteStrings, and Text. These are the majority in some programs, but I expect not in most programs.

[maeder]

This ticket can be closed. ghc-6.10.4 from macports gives you a 64bit compiler that can be used to create a ghc-7.0.1 64bit compiler. (Just ghc-6.12.3 does not support 64bit.)

[edwardamsden]

Will this be merged into any revision of GHC 6.12?

[simonmar]

Replying to edwardamsden:

Will this be merged into any revision of GHC 6.12?

Probably not, we don't maintain the 6.12 branch any more. If someone were to submit a patch, we could push it to the branch though.

[Sharpie]

Replying to maeder:

This ticket can be closed. ghc-6.10.4 from macports gives you a 64bit compiler that can be used to create a ghc-7.0.1 64bit compiler. (Just ghc-6.12.3 does not support 64bit.)

Any chance the binary distribution will become 64 bit native in the near future? Installing macports to compile GHC, then compiling it again and cleaning up afterwords is quite a roundabout way of getting the job done.

[maeder]

You may try my binary-dist (for Snow Leopard only)  http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-mac/ghcs/ghc-7.0.1-x86_64-apple-darwin.tar.bz2

Maybe someone else can create a framework for the official download page.

[Syzygies]

A word of gratitude for this closed thread, and everyone who helped make 64-bit OS X GHC possible.

This wasn't simply about memory. Some things have historically been hard to install on Mac OS X, typically depending on gtk. The package manager Homebrew for OS X builds 64 bit binaries (because that is OS X's native tongue) and in my experience, everything that was hard before "just works" with Homebrew. In particular, I now for the first time have threadscope up on a Mac. Thanks to 64-bit GHC, and its increased compatibility with third-party efforts. As word gets out that Homebrew should be the default choice for cabal prerequisites, more Mac users will be installing 64-bit GHC, whatever their installed memory.