ANNOUNCE: GHC version 6.10.1 - MacOS installer

[Gregory Wright]

Hi Jason,

On Nov 21, 2008, at 8:09 AM, Jason Dagit wrote:

> On Wed, Nov 19, 2008 at 1:28 AM, Manuel M T Chakravarty
> <chak at cse.unsw.edu.au> wrote:
>> Jason Dagit:
>>
>> On Wed, Nov 5, 2008 at 5:36 PM, Manuel M T Chakravarty
>> <chak at cse.unsw.edu.au> wrote:
>>>
>>> Ian Lynagh:
>>>>
>>>> On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery  
>>>> KF8NH wrote:
>>>>>
>>>>> On 2008 Nov 4, at 20:26, Jason Dagit wrote:
>>>>>>
>>>>>> On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty
>>>>>> <chak at cse.unsw.edu.au> wrote:
>>>>>>>
>>>>>>> Are you sure it does deinstall the 6.8 compiler?
>>>>>>>
>>>>>>> After installing 6.10, there should be a 608/ and a 610/
>>>>>>> directory.  This
>>>>>>> certainly happens on my Mac and I am not aware of an option to
>>>>>>> change that
>>>>>>> behaviour.
>>>>>
>>>>> I expect if you used the OSX installer then /Library/Receipts is
>>>>> screwing you (it wipes the old files listed in the .bom file).   
>>>>> Try
>>>>> finding and removing the receipt directory and bom file before
>>>>> installing.
>>>>
>>>> The only file I can see that looks relevant is
>>>>  /Library/Receipts/boms/ 
>>>> org.haskell.glasgowHaskellCompiler.ghc.pkg.bom
>>>>
>>>> Wouldn't removing it make uninstall impossible?
>>>>
>>>> In fact, if you did manage to get 2 versions installed, how would
>>>>  /Library/Frameworks/GHC.framework/Tools/Uninstaller
>>>> know which version to uninstall? Wouldn't it only know how to  
>>>> uninstall
>>>> the version it came with? I'd suggest that the overlapping file
>>>> "Uninstaller" could be why the older version gets removed, but that
>>>> wouldn't explain why Manuel can install both at once.
>>>
>>> A current limitation of the MacOS package system is that it does not
>>> support uninstalling of packages; cf
>>>
>>>
>>> http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_7.html#/ 
>>> /apple_ref/doc/uid/10000145i-CH6-DontLinkElementID_29
>>>
>>> This is not a big drama on MacOS, as MacOS encourages the  
>>> distribution of
>>> software packages as "bundles":
>>>
>>>
>>> http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/CFBundles.html
>>>
>>> This essentially means that instead of sprinkling files all over  
>>> the file
>>> system (as is common in other OSes), MacOS applications and  
>>> frameworks
>>> (Mac-speak for libraries) are kept in a single directory.   
>>> Uninstalling then
>>> means doing an rm -rf on that directory.
>>>
>>> Unfortunately, some applications (including GHC and Apple's Xcode  
>>> IDE)
>>> can't be entirely contained in a single directory.  In the case of  
>>> GHC, we
>>> want symlinks in /usr/bin.  The established way of uninstalling such
>>> applications is by supplying an Uninstaller script, just as I did  
>>> for GHC.
>>> (Apple does the same for Xcode.)
>>>
>>> The purpose of the Uninstaller script is too completely remove
>>> GHC.framework from a machine - not just to remove one version.  In  
>>> fact, if
>>> more than one version of GHC is installed, the Uninstaller will  
>>> refuse to
>>> run and require the manual removal of all versions, but the  
>>> current (easily
>>> achieved by a "rm -rf
>>> /Library/Frameworks/GHC.framework/Versions/<version>").  The main  
>>> feature of
>>> the Uninstaller script is to get rid of all symlinks pointing into
>>> GHC.framework.  The framework itself is just deleted by a "rm -rf"  
>>> as
>>> expected.  (It also removes the above mentioned receipt file.)
>>>
>>> So, to directly answer the above questions:
>>> * The package manger (which uses the receipts) can't uninstall and  
>>> the
>>> uninstaller script doesn't need the receipt.  So, even after  
>>> deleteing the
>>> receibt, you can still uninstall.
>>> * The Uninstaller can uninstall any version (at least as long as no
>>> symlinks are put into new directories outside of the bundle that the
>>> Uninstaller doesn't know about).
>>
>> Is there an update on this thread?  I would still like to have my  
>> cake and
>> eat it too, meaning ghc 6.8.3 and ghc 6.10.1.  As far as I know the
>> installer hasn't been updated and if I try again I will lose my  
>> copy of
>> 6.8.3.
>>
>> Sorry, but for the moment, my (rather limited knowledge) of the
>> MacOS packaging system is exhausted, and currently I don't have the  
>> time to
>> search the web or experiment to try to learn more.  It would be  
>> helpful to
>> have the input of somebody who has more experience with MacOS  
>> packages.
>> Manuel
>
> Okay.  That's fine, the OSX installer system sounds odd.  I don't want
> to fight with it myself.  I just want to upgrade ghc and I was getting
> pressure to do so and I tried the .tar.bz version, but I had some
> annoying experiences that I can share.
>
> So, the page here:
> http://www.haskell.org/ghc/download_ghc_6_10_1.html#macosxintel
>
> Has only this as installation instructions:
> This is a binary distribution for Mac OS X 10.5 (Leopard), prepared by
> Christian Maeder. It needs libedit.2.dylib, libncurses.5.dylib and
> libgmp.3.dylib under /opt/local/lib/.
>
> I had no idea how to do the install or how to satisfy the
> requirements.  By pestering others I learned that you install
> libraries into /opt/local using MacPorts.  The next challenge was
> learning what to do with the .tar.bz file once it was downloaded.  I
> found an INSTALL file inside the tarball with some instructions
> thankfully.  I wish the download page said something about this.  It
> was quite a mystery.  I only looked in the tarball because I was
> frustrated.  I don't like downloading and untarring things if i don't
> know what to expect inside them.
>
> But, I still think I did something wrong because the first thing I
> tried to build with 6.10 complained that -lgmp was not found.  I have
> checked, it's installed and I saw the ./configure script for the 6.10
> installation find it.
>
> Quite baffling.
>
> I guess I'm stuck on 6.8.3 for a while longer.
>
> Jason

The latest MacPorts ghc 6.10.1 fixes a number of build bugs and might  
work
for you.  It builds on ppc/Tiger, i386/Leopard and i386/Tiger.  ppc/ 
Leopard still
fails, but I now have an account on a machine that I can use to test  
and debug.

If you could send a detailed log of the failure to find "-lgmp" I  
would appreciate it.
I've fixed two different bugs involving the library path that caused  
this symptom.
It would be good to know if your failure is covered by the existing  
patches.

I'll send the patches upstream along with bug tickets in the next few  
days.

Best Wishes,
Greg