Hi I thought I'd record my upgrade exerience (so far) in case anyone else finds it useful, and (more selfishly) in case anyone has some helpful advice. Summary of situation * I got 6.12 working. * It took a lot of fumbling around. * The eventual "fix" (renaming /opt/local/lib/libiconv.dylib) was a bit dodgy, but is holding for now. Long rambling narrative follows. Various features of GHC 6.12 made it very tempting to go for an earlier upgrade than I normally would. (SHE really needs GADT-style data families; everything I do needs deriving Traversable (deriving HalfZip would be nice too!).) Already there was a handy installer for Intel+Leopard macs (is anybody on the PPC+Leopard case? if not, I will be soon...). I thought "go for it". Installation, no problem. Compiling something: whoops, no mtl. OK, cabal install mtl: whoops, no acceptable cabal. Fair dos, if I'd read the warnings I'd have known that my cabal-install would be useless and tried to build the new one. QUESTION: Is the sensible upgrade path to build cabal-install 0.8 with your old GHC, before installing 6.12? Does this even work? At one point, I tried this and had some peculiar issues involving zlib... Anyhow, I've got 6.12 and I need cabal-install 0.8. Can I find it? Tricky, and http://haskell.org/cabal/ didn't help much. I'm very tolerant of busy people not quite getting round to it, and I can use google, so I find the darcs version and get cracking. This happens: ----------------------------------------------------------------------------- bash-3.2$ ./bootstrap.sh Checking installed packages for ghc-6.12.1... parsec-2.1.0.1 will be downloaded and installed. network-2.2.1.5 will be downloaded and installed. Cabal is already installed and the version is ok. mtl-1.1.0.2 will be downloaded and installed. HTTP-4000.0.8 will be downloaded and installed. zlib-0.5.2.0 will be downloaded and installed. Downloading parsec-2.1.0.1... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 15430 100 15430 0 0 12743 0 0:00:01 0:00:01 --:--:-- 19312 [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking Setup ... Undefined symbols: "_iconv_close", referenced from: _hs_iconv_close in libHSbase-4.2.0.0.a(iconv.o) "_iconv", referenced from: _hs_iconv in libHSbase-4.2.0.0.a(iconv.o) "_iconv_open", referenced from: _hs_iconv_open in libHSbase-4.2.0.0.a(iconv.o) ld: symbol(s) not found collect2: ld returned 1 exit status Error during cabal-install bootstrap: Compiling the Setup script failed ----------------------------------------------------------------------------- At lthis point, I suspected a linker/dylib problem, but foolishly, I wanted the problem to be pretty much anything else, so I spent far too long looking the wrong way. I thought that if I could just get cabal-install working somehow, I'd be ok. I tried installing parsec with runhaskell Setup.hs {configure,build,install} but each of these commands appeared content to do precisely nothing: I found this perplexing. I tried reverting to 6.10.4 and compiling cabal-install. This made more progress, but died with some sort of zlib version snafu. (I'm sorry, I should have recorded the details but didn't.) The zlib-0.5.2.0 package did install successfully, but somehow the build for cabal-install itself went awry with an "even though this is the right version I can't find X" sort of a problem. I uninstalled 6.10.4, deleted my .cabal directory, nuked a few other relics showing up from what's probably a dumb choice of PATH setting. I had another go at 6.12, and this time I tried compiling a wee program of my own with no exciting package dependencies. Should have done that straight away, of course. Same iconv problem. This left no alternative. I found I had a /usr/lib/libiconv.dylib etc and an /opt/local/lib/libiconv.dylib etc, so I renamed the latter to opt/local/lib/moolibiconv.dylib, and suddenly, GHC became capable of linking stuff. The darcs version of cabal-install then built just fine; SHE rebuilt ok; Epigram needed a few extra LANGUAGE pragmas, but no trouble. I'm almost back where I was. I worry about this. (1) What have I broken by shifting the opt/local/lib copy of libiconv? (2) Why did that break things anyway? (3) How come I ended up with a broken library setup? (4) What else is broken? (What's worse than finding a maggot in your apple? Finding half a maggot in your apple.) I'm not at all a mac expert (I use a mac because I'm too stupid to maintain a linux installation -- the Nottingham grad students (all grown up now) told me they were fed up fixing my computer back in 04.) This dylib nonsense seems quite common. Is it MacPorts messing things up? Is there a more principled fix than the brutal thing I did? I wonder if it might be possible to build some sort of diagnostic tool to check paths and libraries for conflicts and omissions. Anyhow, sorry for the dreariness of this story, but it ends in an acceptable configuration, for the moment. I hope it can be of some small help. Happy hols Conor