[Haskell-cafe] GHC 6.12 on OS X 10.5

Aaron Tomb atomb at galois.com
Mon Dec 21 17:39:01 EST 2009

I've come across the issue with iconv, as well.

The problem seems to be that some versions of iconv define iconv_open  
and some related functions as macros (that then call libiconv_open,  
etc.), and some versions of iconv have exported functions for  
everything. In particular, the iconv bundled with OS X (1.11) defines  
iconv_open, but the iconv installed with MacPorts (1.13) does not. The  
binary package for GHC 6.12.1 seems to have been compiled on a system  
without MacPorts, and therefore references iconv_open (etc.) from the  
Apple-distributed version of the library.

If you set up an installation of GHC 6.12 on OS X (I've only tried  
10.5) with no references to /opt/local/lib, everything works fine. If  
you include /opt/local/lib in the extra-lib-dirs field of your .cabal/ 
config file, it tries to link with the MacPorts version and fails with  
undefined references.

If you don't have that entry in your .cabal/config, but include the  
extra library directory on the command line while installing a  
particular package, the library directory will be registered with that  
package and added to the search path if you compile a program that  
uses that package. This seems to mean that you can't build any Haskell  
package that depends on C libraries installed via MacPorts, or the  
build will fail with undefined references from the iconv library.

I'm going to do some digging to see whether I can solve this without  
modifying GHC.


Aaron Tomb
Galois, Inc. (http://www.galois.com)
atomb at galois.com
Phone: (503) 808-7206
Fax: (503) 350-0833

On Dec 21, 2009, at 2:32 AM, Conor McBride wrote:

> 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- will be downloaded and installed.
> network- will be downloaded and installed.
> Cabal is already installed and the version is ok.
> mtl- will be downloaded and installed.
> HTTP-4000.0.8 will be downloaded and installed.
> zlib- will be downloaded and installed.
> Downloading parsec-
> % 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-
> "_iconv", referenced from:
>     _hs_iconv in libHSbase-
> "_iconv_open", referenced from:
>     _hs_iconv_open in libHSbase-
> 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- 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  
> 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
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

More information about the Haskell-Cafe mailing list