My patch for the underlying linker bugs on 64 bit Snow Leopard were accepted upstream last week. The changes introduced to support position independent code broke the Mach-O linker. The original author of the linker having left the project, a lot of reverse engineering was necessary.

The problematic relocations were specific to 64 bit platforms. The ghc binary installer from the main ghc web page was actually built on Leopard. It would run fine, but it wasn't possible to build a usable 64 bit ghc for 6.12.x or the upcoming 7.0.1 until last week.

I hope to update ghc within the next week or two. Depends on how many build patches are needed -- the build system is much improved from 6.10, but there will certainly be changes required for MacPorts.

My patch for the underlying linker bugs on 64 bit Snow Leopard were accepted upstream last week. The changes introduced to support position independent code broke the Mach-O linker. The original author of the linker having left the project, a lot of reverse engineering was necessary.

The problematic relocations were specific to 64 bit platforms. The ghc binary installer from the main ghc web page was actually built on Leopard. It would run fine, but it wasn't possible to build a usable 64 bit ghc for 6.12.x or the upcoming 7.0.1 until last week.

I hope to update ghc within the next week or two. Depends on how many build patches are needed -- the build system is much improved from 6.10, but there will certainly be changes required for MacPorts.

Very interesting, thanks for the update. Clearly, it has required a lot of work. I thought something like what you wrote might be the case, but had trouble finding mention of it online anywhere.

I've been working on updating the portfiles for GHC 7.4.2, I've decided to do it a slightly different way
than the last guy. I'm going to create a port the installs the binary distribution of GHC, then
I'll create a port that depends on that which will compile using the binary-distro as the bootstrap
compiler. This will (hopefully) be less brittle and make the process relatively easy to maintain.
The current GHC Port file is a bit of a mess (although a lot of this is because of patching that is
no longer required)

I've attached my ghc-bootstrap portfile, I'll keep working on the GHC portfile that depends on it.
the ghc-bootstrap file is quite straight forward, except for post-destroot code that fixes some
install_name problems.

I think this approach is more feasible than the current one. However, you might want to run sudo port -v -y rev-upgrade after installing this port to discover more problems with linking. Remember rev-upgrade is by default automatically run after each installation since 2.1.0 and problems in your ghc-bootstrap port will cause rev-upgrade to mark consider it broken and attempt to re-install (which won't change anything, because you're installing from binaries).

I'm seeing:

Could not open /usr/local/lib/ghc-7.4.2/ghc-prim-0.2.0.0/libHSghc-prim-0.2.0.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/integer-gmp-0.4.0.0/libHSinteger-gmp-0.4.0.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/base-4.5.1.0/libHSbase-4.5.1.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/array-0.4.0.0/libHSarray-0.4.0.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/deepseq-1.3.0.0/libHSdeepseq-1.3.0.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/containers-0.4.2.1/libHScontainers-0.4.2.1-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/filepath-1.3.0.0/libHSfilepath-1.3.0.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/old-locale-1.0.0.4/libHSold-locale-1.0.0.4-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/old-time-1.1.0.0/libHSold-time-1.1.0.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/bytestring-0.9.2.1/libHSbytestring-0.9.2.1-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/unix-2.5.1.1/libHSunix-2.5.1.1-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/directory-1.1.0.2/libHSdirectory-1.1.0.2-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/pretty-1.1.1.0/libHSpretty-1.1.1.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/process-1.1.0.1/libHSprocess-1.1.0.1-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/bin-package-db-0.0.0.0/libHSbin-package-db-0.0.0.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/binary-0.5.1.0/libHSbinary-0.5.1.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/bin-package-db-0.0.0.0/libHSbin-package-db-0.0.0.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/bin-package-db-0.0.0.0/libHSbin-package-db-0.0.0.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/ghc-7.4.2/libHSghc-7.4.2-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/hoopl-3.8.7.3/libHShoopl-3.8.7.3-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/ghc-7.4.2/libHSghc-7.4.2-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/hpc-0.5.1.1/libHShpc-0.5.1.1-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/ghc-7.4.2/libHSghc-7.4.2-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/template-haskell-2.7.0.0/libHStemplate-haskell-2.7.0.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/ghc-7.4.2/libHSghc-7.4.2-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/time-1.4/libHStime-1.4-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/haskell98-2.0.0.1/libHShaskell98-2.0.0.1-ghc7.4.2.dylib)

Note that these are probably not the only locations where the missing files in /usr/local are referenced; rev-upgrade only prints the first occurrence for each.

I'm still going to leave the ghc-bootstrap version as 7.0.4
because that's the current haskell platform version and it seems
free of the freaky linking problems and ghc does a 2-stage
bootstrap anyway.

The good part: I think the important stuff built successfully. The bad part: The build fails when building the users guide (which I guess only happens if you have dblatex, xsltproc and latex installed). I'm attaching the log for you to take a look. Maybe there's an option to disable building the users guide?

The good part: I think the important stuff built successfully. The bad part: The build fails when building the users guide (which I guess only happens if you have dblatex, xsltproc and latex installed). I'm attaching the log for you to take a look. Maybe there's an option to disable building the users guide?

Thanks cal, I'll try and have a look at that later in the week, one would expect there to be an option to disable the
building of the users guide.

Long answer, in ghc 7.4.2 this .o file is replaced with a .dylib. I believe having this .o file around
is actually a way for ghc to perform non-standard static-linking. That being said, I'm really not quite
sure why it's there, but I am quite sure it is necessary.

If the warning really annoys you, you can deactivate (or uninstall) ghc-bootstrap when you are not
actively building ghc.

I'm attaching the Portfile with some modifications (you don't have to define some of the variables in phases explicitly).

I think the value of having a current ghc outweighs the dblatex problem, so I'm probably going to commit this soon. The easiest way to disable building PDF/PS documentation would probably be to patch configure.ac to always set BUILD_DOCBOOK_PS=NO and BUILD_DOCBOOK_PDF=NO (lines 778 and following), but maybe instead of disabling building the documentation we should fix the problem with building it.

Do you want to be listed as maintainer for this port? If yes, please state which email address you want me to put into the Portfile. Also please decide whether you want openmaintainer to be added (as described in ​http://guide.macports.org/#project.update-policies).

I'm not sure what to do with the ghc-devel port. I guess leaving it around with the older version isn't the way to go, so I'd probably make it a stub port and mark it replaced_by ghc.

I'm attaching the Portfile with some modifications (you don't have to define some of the variables in phases explicitly).

Thanks!

I think the value of having a current ghc outweighs the dblatex problem, so I'm probably going to commit this soon. The easiest way to disable building PDF/PS documentation would probably be to patch configure.ac to always set BUILD_DOCBOOK_PS=NO and BUILD_DOCBOOK_PDF=NO (lines 778 and following), but maybe instead of disabling building the documentation we should fix the problem with building it.

Sure, I like the idea of fixing it, although this is entirely outside of my expertise, I literally know nothing about any of those tools,
perhaps I could ask on the haskell mailing list/IRC channel. I'll try and do this (at least the patch) over the weekend...

In your opinion is using that patch as opposed to wiping doc/user_guide/ghc.mk
worth the dependency on autoconf? Or is that dep implicit?

Do you want to be listed as maintainer for this port? If yes, please state which email address you want me to put into the Portfile. Also please decide whether you want openmaintainer to be added (as described in ​http://guide.macports.org/#project.update-policies).

Sure, that sounds great, kitchen.andy+macports@… would be my email address. adding openmaintainer would be best.

I'm not sure what to do with the ghc-devel port. I guess leaving it around with the older version isn't the way to go, so I'd probably make it a stub port and mark it replaced_by ghc.

In the next few weeks I'd like to do a ghc-devel port for 7.5, mainly in preparation for 7.6 which has a lot of features
that I am excited about (deferred type errors and holes). The current nightly seemed to compile from source
with no babysitting, so touch wood, it should be straight forward.

My version of the Portfile seems to miscompile ghc. I don't yet know why, I'll try to have a look tomorrow.

I've setup the Portfile with a test phase, to help debug the mis-compilations.
For me on gcc47 I get 6 unexpected failures 4 look harmless, 2 look iffy but are in
the objective-c bridge, which doesn't seem very popular. I'll try and ask about
7.4.2 and the objective-c bridge on the IRC channel. It's possible
that these features have only really be tested with apple-gcc42.
Perhaps, I should add a variant for that.

I've attached a patch that will disable building PDF documentation with dblatex even if it's installed. Since the patch changes configure and not configure.in we don't need to add a dependency on autotools.

However, a build-dependency on libxslt is needed, because it is being used to generate HTML documentation.

I've added the patch and dependency and fixed some minor issues (trailing whitespace, unneeded use of tags in distfiles) and attached another version of the Portfile.

My wording on "miscompiles ghc" could probably have been better. I didn't want to say "ghc compiles but doesn't work correctly", but "ghc doesn't compile at all". I haven't found out why this is happening, and even more strange, it seems to work for you. I'll attach my main.log, maybe you have an idea why it fails?

I've attached a patch that will disable building PDF documentation with dblatex even if it's installed. Since the patch changes configure and not configure.in we don't need to add a dependency on autotools.

Awesome, thanks heaps.

However, a build-dependency on libxslt is needed, because it is being used to generate HTML documentation.

Thanks heaps for that too.

I've added the patch and dependency and fixed some minor issues (trailing whitespace, unneeded use of tags in distfiles) and attached another version of the Portfile.

Thanks again.

My wording on "miscompiles ghc" could probably have been better. I didn't want to say "ghc compiles but doesn't work correctly", but "ghc doesn't compile at all". I haven't found out why this is happening, and even more strange, it seems to work for you. I'll attach my main.log, maybe you have an idea why it fails?

Well, not sure exactly, but I've noticed compilation failures on occasion, that's why I disabled parallel builds.
For me these errors were totally spurious and annoyingly seem to go away just by running make again.
So try running 'port -kv install ghc' multiple times, does it stop at the same point or get further each time?

These seemingly non-deterministic failures could likely come from unspecified dependencies in the make
file. If these dependencies are produced as a by-product of other rules, the success or failure of the
make file could depend on the order the products were build, but still mostly work. I am as yet
unable to reproduce these build errors.

Also this looks like a plumbing problem in the build system
(it looks like it's generating a dep file to be included in some other makefile)
as opposed to the problem being somewhere inside haskell code.
I'm on lion, so my system make is reasonably new: GNU Make 3.81
This is probably one of the large system dependent variables, perhaps
compiling with the macports gmake 3.82 could do the trick?

This error is caused by the fact that in the binary distribution,
the ghc runtime libraries are built against the old system libiconv,
but for some reason the gcc that ghc is using to do its linking
is picking up a newer version of libiconv somewhere on the search path.

I've tried putting /usr/lib on the front of LIBRARY_PATH, but maybe
this isn't strong enough.

Perhaps something even stronger like LD_FLAGS='-Z -L/usr/lib'
could do the trick?

So it seems when using gcc, which is /opt/local/bin/gcc and pointing to /opt/local/bin/gcc-mp-4.6 on my system /opt/local/include is automatically in the include path, turning any iconv_open to libiconv_open.

Removing or re-creating the /opt/local/bin/gcc has no effect on the problem with the ghc port, though.

I ran this from within ghc's ${worksrcpath} with and without LIBRARY_PATH set to /usr/lib:/opt/local/lib. Apparently the order of paths in this variable doesn't matter, the linking always fails. Shouldn't that be working correctly? Is this a bug in the linker or am I doing something wrong here?

In a discussion in IRC, Brandon suggests we stick to what is shipped in the Haskell Platform package, as this is what upstream encourages to ship. This would mean installing ghc 7.4.1 and updating a number of other packages at the same time:

Wait, ghc 7.4.2? Are we joining the list of folks who figure abandoning the Haskell Platform that is the standard Haskell development target is somehow a good idea?

Hi allbery, please be more polite, I have spent a quite a few precious Sunday afternoons getting the kinks ironed out of
these port files for you and other haskell users. Considering how much work needs to be done, tracking the haskell platform
is not a priority for me at this time. Perhaps if the haskell platform is important to you, you can spend some time
updating the ports from the list that cal has generously provided.

In a discussion in IRC, Brandon suggests we stick to what is shipped in the Haskell Platform package, as this is what upstream encourages to ship. This would mean installing ghc 7.4.1 and updating a number of other packages at the same time:
It seems those updates would be pretty straightforward.

Hi Cal,

From a utilitarian perspective I don't think tracking the Haskell Platform is the best use
of resources, basically I think what is most sorely missing is a high quality package that
tracks the normal ghc releases with some patches to keep things ticking along.

I don't see the logic in holding back a bugfix release, a large virtue
of a package management system with auto updating is that bugfixes
can be pushed down stream quickly and easily.

I see three basic demographics, people who need nothing more than
the platform can use the official .pkg releases. People who develop ghc
can compile straight form source tarballs, possibly using the macports
ghc as a bootstrap compiler. Which leaves people in the middle who need
a high quality GHC release for development where bugs are fixed reasonably
quickly.

One major benefit of the haskell platform is the stable base it provides
and I think that this is best serviced by the haskell platform .pkg releases.
The macports ghc is going to be linked against different libraries
and compiled by a different compiler, so this removes one of the major
benefits of the haskell platform.

I think that a future project to closely mirror the haskell platform in macports
is an ok idea, but should be low priority because there is already a reasonably
high quality haskell platform release.

My suggestion would be to drop ghc-devel, make the ghc package track
the normal stable releases and add ad new hs-platform-ghc that conflicts
with ghc that can be kept down at whatever the platform release is.
We can also hold off patching the hs-platform-ghc so that users can be
sure exactly what bugs they will get too.

I hardly know the Haskell community, so I'll have to rely on what people are telling me. I can just comment on the MacPorts side of things here.

I think we can move the current state of the ghc port into hs-platform-ghc, mark it conflicting with ghc, replace the dependencies in the hs-platform packages and update ghc. This would preserve the current state of the haskell-platform packages in MacPorts (although I'm not sure it's worth the effort, because I don't know whether anybody still uses haskell-platform 2009.2.0.2).

I also think using gcc47 as the default variant is justified, because it causes less test failures.

Meanwhile, I've forked the haskell-platform and hs-platform-* packages into my private repository to work on updating them. If you want to help out, have a look at source:/users/cal/ports/devel.

Can you submit a version of the Portfile with the maintainer and default variant changed? I've been modifying my copy locally and have lost track of the diffs to the versions discussed here.

I hardly know the Haskell community, so I'll have to rely on what people are telling me. I can just comment on the MacPorts side of things here.

I find the community can be a bit risk adverse sometimes. I think it's best to have fast rolling releases.

I think we can move the current state of the ghc port into hs-platform-ghc, mark it conflicting with ghc, replace the dependencies in the hs-platform packages and update ghc. This would preserve the current state of the haskell-platform packages in MacPorts (although I'm not sure it's worth the effort, because I don't know whether anybody still uses haskell-platform 2009.2.0.2).

I also think using gcc47 as the default variant is justified, because it causes less test failures.

Meanwhile, I've forked the haskell-platform and hs-platform-* packages into my private repository to work on updating them. If you want to help out, have a look at source:/users/cal/ports/devel.

I've already updated enough packages to get the newest version of cabal-install through macports,
I'll attach those files as well.

Can you submit a version of the Portfile with the maintainer and default variant changed? I've been modifying my copy locally and have lost track of the diffs to the versions discussed here.

Done, I would really like commit access, because I've just updated a bunch of octave ports as well.

On your devel.tar.gz, I'll have a look soon, but some of the ports in there are not openmaintainer or nomaintainer and I can't thus just update them per our update policies (​http://guide.macports.org/#project.update-policies). I'll try to update those that are open- or nomaintainer, but for the others, we'll need to file tickets.

I still haven't touched the ghc-devel port. Should I mark it obsolete and transition it to the ghc port for now?

I still haven't touched the ghc-devel port. Should I mark it obsolete and transition it to the ghc port for now?

ghc bleeding-edge is really for ghc developers only, almost nothing from cabal really
works meaning that it's almost useless for other development. So yeah,
definitely mark ghc-devel as obsolete.

Thanks for your work so far.

Thank you cal, people like you make me want to contribute more to MacPorts.

Also, I'm muchly embarassed, but I just got some build failure warnings
from the macports buildbot, I realised that I accidentally set parallel compiles
on in the port I posted, this is wrong, it should definitely be off.

Again, my apologies about that and also about the patch.

On your devel.tar.gz, I'll have a look soon, but some of the ports in there are not openmaintainer or nomaintainer and I can't thus just update them per our update policies ( ​http://guide.macports.org/#project.update-policies). I'll try to update those that are open- or nomaintainer, but for the others, we'll need to file tickets.

Ok, I'll post the ticket right now (I'll just do one for all the updates)
Let's do it reasonably quickly because without cabal-install (hs-cabal) ghc is useless for real development.

Also, I'm muchly embarassed, but I just got some build failure warnings
from the macports buildbot, I realised that I accidentally set parallel compiles
on in the port I posted, this is wrong, it should definitely be off.