Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer

On Fri, Nov 21, 2008 at 6:56 AM, Gregory Wright 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 wrote:

...

Jason Dagit:

On Wed, Nov 5, 2008 at 5:36 PM, Manuel M T Chakravarty 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 > 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/SoftwareD...

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

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.

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

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-0.5.0.0' is cached. Configuring zlib-0.5.0.0... Preprocessing library zlib-0.5.0.0... 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/bytestring-0.9.1.4 -L/Users/dagit/lib/ghc-6.10.1/base-3.0.3.0 -L/Users/dagit/lib/ghc-6.10.1/syb-0.1.0.0 -L/Users/dagit/lib/ghc-6.10.1/base-4.0.0.0 -L/Users/dagit/lib/ghc-6.10.1/integer-0.1.0.0 -L/Users/dagit/lib/ghc-6.10.1/ghc-prim-0.1.0.0 -L/Users/dagit/lib/ghc-6.10.1 -lm -lffi -lgmp -ldl dist/build/Codec/Compression/Zlib/Stream_hsc_make.o -o dist/build/Codec/Compression/Zlib/Stream_hsc_make cabal: Error: some packages failed to install: zlib-0.5.0.0 failed during the building phase. The exception was: exit: ExitFailure 1 Thanks, Jason