ANNOUNCE: GHC version 6.10.1 - MacOS installer

Jason Dagit dagit at
Fri Nov 21 10:22:09 EST 2008

On Fri, Nov 21, 2008 at 6:56 AM, Gregory Wright <gwright at> wrote:
> 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> wrote:
>>> Jason Dagit:
>>> On Wed, Nov 5, 2008 at 5:36 PM, Manuel M T Chakravarty
>>> <chak at> 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> 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/
>>>>> 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
>>>> This is not a big drama on MacOS, as MacOS encourages the distribution
>>>> of
>>>> software packages as "bundles":
>>>> 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 version, but I had some
>> annoying experiences that I can share.
>> So, the page here:
>> 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 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.

I've had a history of bad experiences with MacPorts and I remain fully
skeptical of its use.  In particular, I've seen too many darcs users
get bitten by macport builds when a build from source "just works",
every copy of emacs that I've built from macports has started
segfaulting when Apple send their next update, and ghc builds can take
a day (6-10 hours realistically).  Other more minor problems I'd had
include it wasting space without a good clean up option, confusing me
and one other problem that someone showed me how to fix today so maybe
I won't mention it.  I also do not like the MacPort philosophy of
requiring the end user to build the requested package along with
recursively building/installing all the dependencies.  In this regard,
I would prefer Fink except that software in fink tends to ridiculously

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

The error was rather simple and I don't expect you'll be interested in
it as it was the result of a cabal-install when using the Christian
Maeder's ghc build.  But, here it is just in case I'm wrong:
$ cabal install "zlib >= 0.5"
Resolving dependencies...
'zlib-' is cached.
Configuring zlib-
Preprocessing library zlib-
ld: library not found for -lgmp
collect2: ld returned 1 exit status
linking dist/build/Codec/Compression/Zlib/Stream_hsc_make.o failed
command was: /usr/bin/gcc -lz
-L/Users/dagit/lib/ghc-6.10.1 -lm -lffi -lgmp -ldl
dist/build/Codec/Compression/Zlib/Stream_hsc_make.o -o
cabal: Error: some packages failed to install:
zlib- failed during the building phase. The exception was:
exit: ExitFailure 1


More information about the Glasgow-haskell-users mailing list