ghc missing variable definitions in 10.6

[snc@…]

The portfile only defines variables in the post-patch for various versions of the OS. However, 10.6 (darwin 10) isn't defined yet, so building of this port cannot occur yet.

--->  Applying patches to ghc
Error: Target org.macports.patch returned: can't read "ghc_bootversion": no such variable
Error: The following dependencies failed to build: ghc
Error: Status 1 encountered during processing.

[snc@…]

Lowering priority since 10.6 is not yet out.

[gwright@…]

GHC is unlikely to work out of the box when SnowLeopard arrives because of the need for a compatible bootstrap compiler. This is a known issue, and I hope to resolve it as soon as possible.

[dsturnbull@…]

Cc Me!

[macports.org@…]

Cc Me!

[brianm@…]

Cc Me!

[me@…]

Cc Me!

[kevin.way@…]

Cc Me!

[kevin.way@…]

Cc Me!

[macports@…]

Cc Me!

[bts@…]

Cc Me!

[hong.rich@…]

Cc Me!

[david.darais@…]

Cc Me!

[skluft@…]

Cc Me!

[psarge@…]

Cc Me!

[jdfrens@…]

Cc Me!

[mietek+macports@…]

Until this is fixed, you can install the official GHC 6.10.4 binary, and apply a small workaround.

The binary can be found on  the official download page.

The only problem is that GHC generates 32-bit code, and the GCC toolchain on 10.6 defaults to 64-bit, as detailed in  a Haskell Cafe thread.

The thread describes a workaround to get the official 6.10.4 binary working. Simply add the following flags to /usr/bin/ghc and /usr/bin/ghci:

-optc-m32 -opta-m32 -optl-m32

According to  GHC ticket #3400 this fix is already applied to the HEAD, so hopefully we can expect an updated port soon.

[mietek@…]

Cc Me!

[smanek@…]

Cc Me!

[mellon85@…]

Cc Me!

[marco.comini@…]

Cc Me!

[maik@…]

Cc Me!

[pedronbvasconcelos@…]

Cc Me!

[lambda@…]

Cc Me!

[marcin.zalewski@…]

Cc Me!

[mike@…]

Cc Me!

[mike@…]

Cc Me!

[nchaimov@…]

Cc Me!

[rdreyer@…]

Cc Me!

[league@…]

Cc Me!

[kowey@…]

Cc Me!

[gwright@…]

It seems as if I can run Snow Leopard under VMWare Fusion, so I should be able to test this out this week. For work reasons I need to keep my current machine running Leopard for the moment. How long it takes mostly depends on whether it's easy to get a reliable bootstrap compiler running quickly.

I'll have access to an additional Leopard machine soon, so the VMWare kludge ought not to be required for long.

Thanks to all for your patience.

[hvitved@…]

Cc Me!

[dpkatz@…]

Cc Me!

[tumdum@…]

Cc Me!

[brecht.hoflack@…]

Cc Me!

[alex@…]

While I appreciate the efforts being made to ensure that GHC works with 64-bit capability, is it not possible to edit this 'work-around' in the meantime?

I might be wrong, but my Mac doesn't support 64-bit, so if I could get past this informative message, I expect GHC would run fine. Even for those with 64-bit capable Macs, I expect most have abandoned this portfile and used the work-around described in Comment 19, so why not implement the work-around in the portfile until it can be fixed properly?

I don't know how to edit portfiles, otherwise I'd be happy to suggest the changes that need including to do this. However, I'd really appreciate any assistance in getting this portfile installed, if only to test my theory.

[mfisher@…]

Cc Me!

[j.e.miyake@…]

Cc Me!

[takaaki.kato@…]

Cc Me!

[alex@…]

Cc Me!

[jbolden1517@…]

Cc Me!

[cryptix@…]

Cc Me!

[a.sewall.ford@…]

Cc Me!

[john_owens@…]

Cc Me!

[rvr@…]

CC Me!

[marco.comini@…]

I personally agree with the request of Alex. It seems, at least to me, a quite reasonable request. If it is not, one of the maintainers could have simply said so! It takes just a minute to say something like "Sorry, it's not that simple, it takes almost the same time as resolving the issue properly".

Now, 3 weeks had already passed and (at least in this Ticket) Alex has been completely ignored... quite sad.

I'm also looking forward to have a running GHC (64 or only 32 is not that problem) in order to *use* it and have back Darcs, Alex, Happy & BNFC (just to mention some).

I was not considering installing the binaries as an option, but also staying months without GHC is not an option :(

Could somebody say us if the discussion has moved somewere?

Thanks folks

[h8spawn@…]

Cc Me!

[t.kunishi@…]

Cc Me!

[fm2209@…]

I badly need this one too, also considering the fact that hugs doesn't work too...

[fm2209@…]

Cc Me!

[tobi_m@…]

Cc Me!

[adrian@…]

Cc Me!

[larsko@…]

Cc Me!

[mdippery@…]

Cc Me!

[arto.bendiken@…]

Cc Me!

[akborder@…]

Cc Me!

[john_owens@…]

GHC 6.12.1 released 2 weeks ago, "GHC now works (as a 32bit application) on OS X Snow Leopard" [per release notes].

[torsneyt@…]

Cc Me!

[anonymous.lion@…]

Cc Me!

[Martin.Buchmann@…]

Cc Me!

[dports@…]

Cc Me!

[Jens_Abraham@…]

Cc Me!

[email@…]

Cc Me!

[sanssecours@…]

Cc Me!

[sanssecours@…]

Cc Me!

[sanssecours@…]

Cc Me!

[erik@…]

Cc Me!

[ecronin@…]

* Some help for ghc users:

The latest 6.12.1 binary package ( http://www.haskell.org/ghc/dist/6.12.1/) is fixed for snow leopard, but introduces some incompatibilities in the base libraries that make e.g. macports darcs not build.

The previous 6.10.4 binary package ( http://www.haskell.org/ghc/dist/6.10.4/) doesn't work out of the .pkg on 10.6 because of the gcc architecture issue (see  http://hackage.haskell.org/trac/ghc/ticket/3400). If you apply the 3 patches I'm attaching after you've installed the ghc 6.10.4 package it will work correctly on snow leopard. cd to /usr/bin first.

**HACK TIME** Because the binary package installs ghc in /usr/bin, macports can find it in its path. Therefore any port that has a build depend on ghc can be built using /usr/bin/ghc by replacing the dependency port:ghc with bin:ghc:ghc. assuming you know your way around $EDITOR, sudo port edit portname will open up the Portfile, where you can search for port:ghc and replace it. Because ghc has a runtime with it this is fragile and not the MacPorts way. As soon as the ghc port is fixed I strongly suggest anyone going down this route de-install the binary ghc package (sudo /Library/Frameworks/GHC.framework/Tools/Uninstaller) and rebuild any ports that depend on ghc.

* some help for the maintainer:

modifying the leopard bootstrap ghc/hsc2hs the same way allows them to work fine on snowleopard. Copying the darwin 9 i386 block to darwin 10 i386 works fine.

The dependent libraries (gmp,ncurses,iconv) need to be installed +universal, there's no good way to enforce this though

ghc itself needs at least build_arch=i386 passed in, e.g. sudo port install ghc build_arch=i386, but there are some places in ./configure it's still using x64 gcc... I ran out of time to follow this path any further.

[ecronin@…]

patch for binary GHC 6.10.4 install (ghc)

[ecronin@…]

patch for binary GHC 6.10.4 install (ghci)

[ecronin@…]

patch for binary GHC 6.10.4 install (hsc2hs)

[ryandesign@…]

Replying to ecronin@…:

The dependent libraries (gmp,ncurses,iconv) need to be installed +universal, there's no good way to enforce this though

There's the archcheck portgroup. See how the wine-devel port does it.

[ecronin@…]

Replying to ryandesign@…:

There's the archcheck portgroup. See how the wine-devel port does it.

aha! I was trying to remember what port it was I'd recently installed that had similar i386-only requirements. I would definitely suggest using wine-devel as a template, since ghc will be 32-bit only for a while still it seems...

[mietek@…]

Cc Me!

[ecronin@…]

partial update to fix Snow Leopard compat

[ecronin@…]

I cleaned up my attempts at making the build from bootstrap work. It compiles the stage-1 ghc successfully, but then when it goes to build ghc using the stage-1 compiler instead of the bootstrap compiler it fails...

[mike@…]

Cc Me!

[easieste@…]

Cc Me!

[easieste@…]

Cc Me!

[macports@…]

Cc Me!

[rs573@…]

Cc Me!

[larry.velazquez@…]

Cc Me!

[khalsah@…]

Cc Me!

[h8spawn@…]

Cc Me!

[tomas.znamenacek@…]

Cc Me!

[roland@…]

Cc Me!

[mike.vasiljevs@…]

Cc Me!

[gwright@…]

OK, I seem to have 6.10.4 building completely on Snow Leopard now. However, there have been some odd crashes during the build. I've been building on Snow Leopard server running virtualized under VMware Fusion (for business reasons I can't yet switch my main machine to Snow Leopard). Nothing seems to stress Snow Leopard Server/VMWare liking building ghc --- sometimes the whole virtual machine will lock up.

So I am asking for help from someone who is running Snow Leopard natively and would like to try the port. Just leave a message on the bug report. Note that you should have some experience messing with Portfiles; this will require adding two additional ports required to get the bootstrap compiler running on Snow Leopard. It will also take three to six hours of build time, depending on the speed of your machine. If someone is interested, let me know.

[sanssecours@…]

Cc Me!

[easieste@…]

Cc Me!

[easieste@…]

Replying to gwright@…: ]

So I am asking for help from someone who is running Snow Leopard natively and would like to try the port. Just leave a message on the bug report. Note that you should have some experience messing with Portfiles; this will require adding two additional ports required to get the bootstrap compiler running on Snow Leopard. It will also take three to six hours of build time, depending on the speed of your machine. If someone is interested, let me know.

I have a MacBook Pro running Snow Leopard natively. GHC used to take a long time to build, so this might not be the fastest machine to help ou with. Where should I start? What are the two additional ports?

[mellon85@…]

Cc Me!

[ryandesign@…]

Replying to gwright@…:

So I am asking for help from someone who is running Snow Leopard natively and would like to try the port. Just leave a message on the bug report.

I can give it a try.

[marco.comini@…]

Replying to gwright@…:

So I am asking for help from someone who is running Snow Leopard natively and would like to try the port. Just leave a message on the bug report. Note that you should have some experience messing with Portfiles; this will require adding two additional ports required to get the bootstrap compiler running on Snow Leopard. It will also take three to six hours of build time, depending on the speed of your machine. If someone is interested, let me know.

I absolutely volunteer!

I have a (minimal) experience with portfiles (I wrote a couple for my personal use), could it suffice?

I have a Mac Pro 8/2.8. On leopard it took less than an hour with a make -j10 so I could do several tryouts, just let me know.

[gwright@…]

OK, I will send tarballs with instructions to Ryan and Marco. I will have to upload the bootstrap compiler to the haskell.org web site. This might take a while. I should be able to email Ryan and Macro this evening with everything needed. Thanks.

[gwright@…]

An update: there appears to still be a real bug in the code produced by the stage2 compiler (the haddock built by the stage2 compiler crashes with an abort trap).

The situation right now is the compiler build finishes, but some of the utilities built by the generated compiler crash. Some of the utilities seem to work, which suggests that the underlying problem is limited.

Thanks to Ryan Schmidt and Marco Comini for volunteering to test.

[gwright@…]

Further update: ghc built to completion last night and seems to work. Today I will run the testsuite and it should be uploaded in the next day or two if everything tests OK.

There was in fact just one serious problem. I had made an error backporting the Makefile for the run time system from 6.12.1 to 6.10.4, which caused stack protection to be included. GHC does not use C style stack layout, and checking the stack canary caused a crash. Cleaning up a number of other warning messages over the weekend revealed this.

The snow leopard port uses a 6.10.4 bootstrap compiler built on Leopard. The portfile includes changes suggested by Ryan Schmidt who tested the earlier (buggy) version.

[snc@…]

I can test your next round of changes: i've got intel 10.5 10.6 and ppc 10.5 platforms.

[jsg8pitt@…]

Cc Me!

[gwright@…]

Further update: here's my plan. I've built the 32 bit version three times successfully now. I have also verified that I can build a 32 bit compiler with the 64 bit patches in place. Today I will test building the 64 bit version. I'd like to have the 64 bit version as the default. For users that need a 32 bit compiler (for example, to make binaries that will run both on Leopard and Snow Leopard) I will make a new port, ghc-sl32. You will be able to install both ports simultaneously. (My original idea of making a 32 bit compiler on Snow Leopard a variant made it impossible to have both compilers at the same time.)

As soon as I get access to the haskell ftp site I'll start having people test. The write permissions got changed on some of the directories and I can't upload the bootstrap compiler yet.

If anyone has a strong opinion about how to handle the 32/64 bit issue on SL, please attach a comment.

[mike.vasiljevs@…]

its good idea to have 64bit default - and perhaps its possible to have 32bit as a variant (selected automatically in 10.5?) I dont think anyone minds any more the overhead in size of the universal binaries, the only downside is waiting twice as much for compilation.

[gwright@…]

You'll only get 64 bits on Snow Leopard; Leopard will only be 32 bits. So the default will be a compiler that builds the preferred native executable. The reason for having a 32 bit compiler on Snow Leopard is to generate binaries that will run on Leopard. If you generate a 64 bit executable, you'll only be able to run it on Snow Leopard.

Unfortunately, ghc's build system is fragile and can't handle things like a 64 bit compiler executable building 32 bit executable. At the moment, the only practical option is a 32 bit ghc executable that makes 32 bit binaries, or a 64 bit ghc executable that makes 64 bit binaries. My plan is to make the 64 bit ghc the default on Snow Leopard. I'll make a separate port for a 32 bit ghc generating 32 bit executables that is only for Snow Leopard. GHC by itself can not produce universal binaries.

[thomas.hutchinson@…]

Cc Me!

[macports.org@…]

Replying to gwright@…:

You'll only get 64 bits on Snow Leopard; Leopard will only be 32 bits. So the default will be a compiler that builds the preferred native executable. The reason for having a 32 bit compiler on Snow Leopard is to generate binaries that will run on Leopard. If you generate a 64 bit executable, you'll only be able to run it on Snow Leopard.

That simply isn't true. OSX has been able to run CLI 64b processes since OSX 10.4 "Tiger" (by layering a 64b UNIX subsystem allowing 64b processes and servers on top of a 32b kernel), so unless you have a GUI (or are using new APIs), 64b processes will run without any issue on any Intel Mac running Tiger.

Leopard added support for 64b GUI software as long as it's Cocoa-based, and 10.6 moved the system, kernel, drivers and kernel extensions to 64b as well (optionally), and removed support for PPC machines.

[ryandesign@…]

Replying to mike.vasiljevs@…:

its good idea to have 64bit default - and perhaps its possible to have 32bit as a variant (selected automatically in 10.5?) I dont think anyone minds any more the overhead in size of the universal binaries, the only downside is waiting twice as much for compilation.

Variants are not the way we handle building for different architectures in MacPorts. We have the build_arch and universal_archs variables in macports.conf for that.

Replying to gwright@…:

I'd like to have the 64 bit version as the default. For users that need a 32 bit compiler (for example, to make binaries that will run both on Leopard and Snow Leopard) I will make a new port, ghc-sl32. You will be able to install both ports simultaneously. (My original idea of making a 32 bit compiler on Snow Leopard a variant made it impossible to have both compilers at the same time.)

Instead of making a separate ghc-sl32 port, can't you make the ghc port respect the build_arch and universal_archs variables and do it the way every other port in MacPorts does it?

[gwright@…]

Replying to gwright@…:

I'd like to have the 64 bit version as the default. For users that need a 32 bit compiler (for example, to make binaries that will run both on Leopard and Snow Leopard) I will make a new port, ghc-sl32. You will be able to install both ports simultaneously. (My original idea of making a 32 bit compiler on Snow Leopard a variant made it impossible to have both compilers at the same time.)

Instead of making a separate ghc-sl32 port, can't you make the ghc port respect the build_arch and universal_archs variables and do it the way every other port in MacPorts does it?

No, it is unfortunately not yet possible to make ghc do this. The underlying problem is that ghc cooks its host platform into the code generator. You can't, for example, output 64 bit code using a ghc that was built as a 32 bit binary (and vice versa).

This is a known problem. An old cross-compilation system that never worked and has been ripped out. Parts of a new one are in 6.12.x, but are not working yet.

At the moment, the only way to generate binaries for both 32 and 64 bit platforms is to have two compilers.

I have mentioned these problems to the upstream maintainers and they have given it somewhat more attention of late. But most of their efforts are going to parallelism and type hackery.

[thomas.hutchinson@…]

Replying to gwright@…:

Replying to gwright@…:

I'd like to have the 64 bit version as the default. For users that need a 32 bit compiler (for example, to make binaries that will run both on Leopard and Snow Leopard) I will make a new port, ghc-sl32. You will be able to install both ports simultaneously. (My original idea of making a 32 bit compiler on Snow Leopard a variant made it impossible to have both compilers at the same time.)

Instead of making a separate ghc-sl32 port, can't you make the ghc port respect the build_arch and universal_archs variables and do it the way every other port in MacPorts does it?

No, it is unfortunately not yet possible to make ghc do this. The underlying problem is that ghc cooks its host platform into the code generator. You can't, for example, output 64 bit code using a ghc that was built as a 32 bit binary (and vice versa). This is a known problem. An old cross-compilation system that never worked and has been ripped out. Parts of a new one are in 6.12.x, but are not working yet. At the moment, the only way to generate binaries for both 32 and 64 bit platforms is to have two compilers. I have mentioned these problems to the upstream maintainers and they have given it somewhat more attention of late. But most of their efforts are going to parallelism and type hackery.

I think there is a miscommunication going on.

The idea is to have 32 bit functionality be in the main ghc port. It would be an exclusive choice. Either ghc is 32 bit or it's 64 bit. The ghc port would read the build_arch variable and act accordingly. The resulting compiler would (only) produce 32 bit or 64 bit binaries.

Maybe there is a detail of the ghc bootstrapping that I'm not understanding (or I simply misread the comments on this ticket). Still, a user should not have to install a different port.

Please note: there are many of us who use Snow Leopard on 32-bit architectures. For instance, I have a MacBook Pro with a Core Duo processor. It would be nice to be able to simply "sudo port install ghc".

I see that you are trying to be able to have both 32 and 64 bit versions be installed at the same time. Do any haskell ports need this? Are there ports of other compilers that have a similar layout?

It sounds like you are trying to solve a harder problem than necessary. Getting the ghc port working at all looks like difficult task. I think installing one "flavor" of ghc is sufficient. Maybe that's naïve of me.

[maik@…]

Cc Me!

[gwright@…]

I think there is a miscommunication going on. The idea is to have 32 bit functionality be in the main ghc port. It would be an exclusive choice. Either ghc is 32 bit or it's 64 bit. The ghc port would read the build_arch variable and act accordingly. The resulting compiler would (only) produce 32 bit or 64 bit binaries. Maybe there is a detail of the ghc bootstrapping that I'm not understanding (or I simply misread the comments on this ticket). Still, a user should not have to install a different port. Please note: there are many of us who use Snow Leopard on 32-bit architectures. For instance, I have a MacBook Pro with a Core Duo processor. It would be nice to be able to simply "sudo port install ghc".

The user will get a ghc the runs natively on his or her machine. What I'm wrestling with is how to provide a mechanism to produce universal binaries. Since the ghc compiler itself can only produce one kind binary, we need two compilers to do this (and you need to be running 64 bit Snow Leopard). As mentioned one of the previous comments, if you avoid GUI libraries and bundle up an app with the appropriate 64 bit libraries, you can run 64 bit code on a 32 bit platform. But this constraint is too stringent for general use.

With two compilers, at least it will be possible to build a universal binary. This is just the bare mechanism; the haskell ports in MacPorts won't be able to be built universal for a while.

It sounds like you are trying to solve a harder problem than necessary. Getting the ghc port working at all looks like difficult task. I think installing one "flavor" of ghc is sufficient. Maybe that's naïve of me.

As of this morning, I can build both 32 and 64 bit versions on Snow Leopard. The average user will get the correct ghc automatically. The hard part has always been making everything "just work" and hide the infelicities of the ghc build system.

[gwright@…]

r64764 should make ghc on Snow Leopard. I'll leave the ticket open for a few days in case there are problems.

[rs573@…]

Replying to gwright@…:

r64764 should make ghc on Snow Leopard. I'll leave the ticket open for a few days in case there are problems.

As of Wed 17 Mar 2010, I can confirm that ghc can be built on Snow Leopard.

Thanks.

[gwright@…]

I've reports of success on both 32 and 64 bit Snow Leopard, so I am closing this ticket. Thanks to all those who helped test, and to everyone for their patience.