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