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
--
Aaron Tomb
Galois, Inc. (http://www.galois.com)
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-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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
