On Dec 22, 2009, at 9:36 PM, wren ng thornton wrote:
Aaron Tomb wrote:
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.
Is this a problem with *versions* of iconv, or with branches/forks?
If it's versions, then it seems like migrating to >=1.13 would be
good for everyone. If it's just branches, do you know whether this
afflicts Fink users as well as MacPorts users, or should I be the
guinea pig to test that?
It's a problem with versions. I checked that the official iconv
repository does indeed make the change between 1.11 and 1.13 that
causes the problem. The issue is that OS X includes an old version. So
migrating to >=1.13 means convincing Apple to upgrade what they
include with the system. If we can accomplish that, I'd be thrilled.
But it hasn't happened yet as of 10.6.
Fink comes with 1.12. I'm not sure whether 1.12 is more like 1.11 or
1.13.
Aaron
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
