GHC 6.8.1 on Mac OS X 10.5 (Leopard)

[Manuel M T Chakravarty]

Christian Maeder:
> Manuel M T Chakravarty wrote:
>> I wasn't expecting any backwards compatibility from Leopard-built
>> software to Tiger, but then I am also a Mac-noob and maybe there are
>> ways to achieve that that I don't know of.  Any suggestions?
>
> Could you, or someone else with Leopard, check if my Tiger binary
> distribution is useable? (or what the problems are?)

I didn't try, but I guess, it would lead to the same problems as your  
GHC 6.6.1 distribution caused on Leopard (ie, linker error complaining  
about _environ).  The problem there was, I think, the GMP framework.

>
>> What we really need is a proper .mpkg, but at the moment, I don't  
>> have
>> time for that.
>
> I've found that page
> http://s.sudre.free.fr/Stuff/PackageMaker_Howto.html
>
> It would help if we could at least agree on using frameworks or dylibs
> for readline and gmp. That'll be important for any installer.
>
> Maybe ghc could also support private frameworks
> (in conjunction with http://hackage.haskell.org/trac/ghc/ticket/1798).
>
>> The above binary first of all was meant to help
>> bootstrapping GHC for people who upgraded to Leopard and have  
>> problems
>> (which it seemed on irc, there were a few of).
>
> Fair enough, but the current state under
> http://www.haskell.org/ghc/download_ghc_681.html#macosxintel
> is worse compared to version 6.6.1 when
> http://hackage.haskell.org/trac/ghc/ticket/1540
> was created.

I agree, we need to do something about that.  There are two reasons  
why I haven't done anything yet.  Firstly, I have been to busy with  
other things, but that hopefully changes when all my teaching  
obligations for this year are discharged (ie, in about two weeks).   
Secondly, the really unsatisfactory thing about frameworks for  
readline and gmp is that it entails that programs compiled with GHC  
will also depend on at least the GMP framework.

I'd really like to have a story that extends nicely to programs built  
with GHC.

Otherwise, if we produce a mpkg, I don't it doesn't matter much what  
the internal structure is.  An mpkg can contain sub-packages for  
frameworks internally (which will be automatically installed) if not  
yet present.

Manuel