[Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX

Judah Jacobson judah.jacobson at gmail.com
Sun Feb 1 20:10:48 EST 2009

On Sun, Feb 1, 2009 at 4:07 PM, Duncan Coutts
<duncan.coutts at 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,

More information about the Haskell-Cafe mailing list