On Sun, Feb 1, 2009 at 4:07 PM, Duncan Coutts
[re-sending the cc to -cafe as I sent from the wrong address the first time]
On Sun, 2009-02-01 at 12:43 -0600, Antoine Latter wrote:
After a bit of digging, I saw this snippet in the .cabal file for the iconv package on hackage:
> -- We need to compile via C because on some platforms (notably darwin) -- iconv is a macro rather than real C function. doh! ghc-options: -fvia-C -Wall <<<<<
But it looks like the 'iconv' package is broken in the exact same way for me - I get the same crazy linker errors.
Yes, the workaround of using -fvia-C stopped working in ghc-6.10. I will have to adapt the iconv package to use a C wrapper.
Someone said that it is just the macports version of iconv that has this problem but I don't understand that at all. If we're using default ghc/gcc then we should not be looking in any non-standard include directories at all.
The pcre library isn't installed by default, so an OS X users might get it from MacPorts (which installs it in /opt/local/lib). And when building the Haskell pcre-light package, they'd do something like cabal install pcre-light --extra-lib-dirs=/opt/local/lib But then any other package that depends on pcre-light will also get the same linker option.
The other thing that makes no sense is that the /usr/lib/libiconv.dywhatever file apparently contains both _iconv_open and _libiconv_open so why can't we link to the ordinary _iconv_open one?
The problem is that with -L/opt/local/lib (which is now passed to any package depending on pcre-light), the linker uses /opt/local/lib/libiconv.* and ignores /usr/lib/libiconv.* altogether. Hope that helps explain it better, -Judah