[Haskell-cafe] GHC 6.12 on OS X 10.5

Conor McBride conor at strictlypositive.org
Mon Dec 21 05:32:47 EST 2009


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



More information about the Haskell-Cafe mailing list