On Sun, Feb 1, 2009 at 4:07 PM, Duncan Coutts <duncan.cou...@worc.ox.ac.uk> wrote: > [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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe