Opened 9 years ago

Closed 7 years ago

Last modified 6 years ago

#2965 closed feature request (fixed)

GHC on OS X does not compile 64-bit

Reported by: Axman6 Owned by: igloo
Priority: normal Milestone: 7.0.1
Component: Compiler Version:
Keywords: 64bit Cc: filcab+ghc@…, mxcantor@…, geekiac@…, silversys@…, steven.smith@…, emertens@…, mad.one@…, pumpkingod@…, bayer@…, dbueno@…, jcpetruzza@…, lennart@…, johanliesen@…, ionfish@…, ghc2965@…, thomasdrake1@…, amock@…, leather@…, njloof@…, adam@…, sudish@…, c.chryssochoidis@…, skrap+haskell@…, mokus@…, ghc@…, barney_stratford@…, philip.weaver@…, takanori.nakanowatari@…, adhocrocker@…, marco.comini@…, khalsah@…, jeff@…, aleator, source@…, infracyan@…, dbkirk@…, marius@…, michael@…, kramer@…, patperry@…, middleton.ted@…, edwardamsden@…
Operating System: MacOS X Architecture: x86_64 (amd64)
Type of failure: Installing GHC failed Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

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.

Change History (79)

comment:1 Changed 9 years ago by 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).

comment:2 Changed 9 years ago by igloo

difficulty: Unknown
Milestone: 6.12 branch

comment:3 Changed 9 years ago by thoughtpolice

Cc: mad.one@… added
Keywords: 64bit added
Owner: set to thoughtpolice
Version: 6.10.1

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.

comment:4 Changed 9 years ago by pumpkin

Cc: pumpkingod@… added

comment:5 Changed 9 years ago by Syzygies

Cc: bayer@… added

comment:6 Changed 9 years ago by dbueno

Cc: dbueno@… added

comment:7 Changed 9 years ago by jcpetruzza

Cc: jcpetruzza@… added

comment:8 Changed 9 years ago by augustss

Cc: lennart@… added

comment:9 Changed 9 years ago by liesen

Cc: johanliesen@… added

comment:10 Changed 9 years ago by beastaugh

Cc: ionfish@… added

comment:11 Changed 8 years ago by ChrisKuklewicz

Cc: ghc2965@… added

comment:12 Changed 8 years ago by tadr

Cc: thomasdrake1@… added

comment:13 Changed 8 years ago by amock

Cc: amock@… added

comment:14 Changed 8 years ago by spl

Cc: leather@… added

comment:15 Changed 8 years ago by guest

Cc: emertens@… added

comment:16 Changed 8 years ago by guest

Cc: njloof@… added

comment:17 Changed 8 years ago by sekl

Cc: skluft@… added

comment:18 Changed 8 years ago by 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).

comment:19 Changed 8 years ago by wmealing

Cc: wmealing@… added

comment:20 Changed 8 years ago by geekiac

Cc: geekiac@… silversys@… steven.smith@… added

comment:21 in reply to:  18 Changed 8 years ago by 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 :)

comment:22 in reply to:  18 Changed 8 years ago by 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.

comment:23 Changed 8 years ago by 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

comment:24 Changed 8 years ago by 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.

comment:25 Changed 8 years ago by 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

comment:26 in reply to:  25 ; Changed 8 years ago by 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?

comment:27 in reply to:  26 Changed 8 years ago by 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?

comment:28 in reply to:  26 Changed 8 years ago by 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?

comment:29 Changed 8 years ago by adamd

Cc: adam@… added

comment:30 Changed 8 years ago by sudish

Cc: sudish@… added

comment:31 Changed 8 years ago by christosc

Cc: c.chryssochoidis@… added

comment:32 Changed 8 years ago by agerdes

Cc: alex@… added

comment:33 in reply to:  25 Changed 8 years ago by 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).

comment:34 Changed 8 years ago by 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.

comment:35 Changed 8 years ago by skrap

Cc: skrap+haskell@… added

comment:36 Changed 8 years ago by mokus

Cc: mokus@… added

comment:37 Changed 8 years ago by j0ni

Cc: ghc@… added

comment:38 Changed 8 years ago by barney_stratford

Cc: barney_stratford@… added

comment:39 Changed 8 years ago by pweaver

Cc: philip.weaver@… added

comment:40 Changed 8 years ago by guest

Cc: wmealing@… removed

comment:41 Changed 8 years ago by nakanowatari

Cc: takanori.nakanowatari@… added

comment:42 Changed 8 years ago by tty645

Cc: adhocrocker@… added

comment:43 Changed 8 years ago by marco.comini

Cc: marco.comini@… added

comment:44 Changed 8 years ago by korpios

Cc: korpios@… added

comment:45 Changed 8 years ago by mxc

Cc: mxcantor@… added
Type of failure: None/Unknown

comment:46 Changed 8 years ago by filcab

Cc: filcab+ghc@… added

comment:47 Changed 8 years ago by khalsah

Cc: khalsah@… added

comment:48 Changed 8 years ago by jeffschwab

Cc: jeff@… added
Type of failure: None/UnknownInstalling GHC failed

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.

comment:49 Changed 8 years ago by 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.

comment:50 Changed 8 years ago by simonmar

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

comment:51 Changed 8 years ago by 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?

comment:52 Changed 8 years ago by 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

comment:53 Changed 8 years ago by aleator

Cc: aleator added

comment:54 Changed 8 years ago by 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?

comment:55 in reply to:  54 Changed 8 years ago by 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.

comment:56 Changed 8 years ago by igloo

Milestone: 6.12 branch6.12.3

comment:57 Changed 8 years ago by Sharpie

Cc: source@… added

comment:58 Changed 7 years ago by ahihi

Cc: infracyan@… added

comment:59 Changed 7 years ago by igloo

Milestone: 6.12.36.14.1
Priority: normallow

comment:60 Changed 7 years ago by igloo

Priority: lowhighest

comment:61 Changed 7 years ago by dkirk

Cc: dbkirk@… added

comment:62 Changed 7 years ago by marius

Cc: marius@… added

comment:63 Changed 7 years ago by igloo

Owner: changed from thoughtpolice to igloo
Priority: highestnormal

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

comment:64 Changed 7 years ago by mndrix

Cc: michael@… added

comment:65 Changed 7 years ago by reto

Cc: kramer@… added

comment:66 Changed 7 years ago by patperry

Cc: patperry@… added

comment:67 Changed 7 years ago by tedm

Cc: middleton.ted@… added

comment:68 Changed 7 years ago by sekl

Cc: skluft@… removed

comment:69 Changed 7 years ago by agerdes

Cc: alex@… removed

comment:70 Changed 7 years ago by korpios

Cc: korpios@… removed

comment:71 in reply to:  34 ; Changed 7 years ago by 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.

comment:72 in reply to:  71 Changed 7 years ago by 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.

comment:73 Changed 7 years ago by edwardamsden

Cc: edwardamsden@… added

comment:74 Changed 7 years ago by maeder

Resolution: fixed
Status: newclosed

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

comment:75 Changed 7 years ago by edwardamsden

Will this be merged into any revision of GHC 6.12?

comment:76 in reply to:  75 Changed 7 years ago by 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.

comment:77 in reply to:  74 Changed 7 years ago by 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.

comment:78 Changed 7 years ago by 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.

comment:79 Changed 6 years ago by 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.

Note: See TracTickets for help on using tickets.