Ticket #74 (new defect)

Opened 5 years ago

Last modified 5 years ago

Haskeline can't link against MacPorts' libiconv

Reported by: judah Owned by:
Priority: major Milestone: 0.7
Version: 0.6 Keywords:
Cc: duncan@…

Description

On OS X, the following fails (where Test.hs is from the examples folder):

$ ghc --make Test.hs -L/opt/local/lib -I/opt/local/include -fforce-recomp
[1 of 1] Compiling Main             ( test.hs, test.o )
Linking test ...
Undefined symbols:
  "_iconv_open", referenced from:
      _s2e5_info in libHShaskeline-0.6.0.1.a(IConv.o)
  "_iconv_close", referenced from:
      _iconv_close$non_lazy_ptr in libHShaskeline-0.6.0.1.a(IConv.o)
  "_iconv", referenced from:
      _s2oc_info in libHShaskeline-0.6.0.1.a(IConv.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status

Reported by Antoine Latter.

The problem is that MacPorts' iconv typedefs the iconv functions rather than defining them directly. This will affect any program linking against a library in MacPorts, even if it intends to use the OS X system libiconv.

Change History

Changed 5 years ago by judah

One workaround: if a package depends on, for example, haskeline and pcre-light, you can build it with

cabal configure --extra-lib-dirs=/usr/lib

to force a link against the system libiconv.

Changed 5 years ago by guest

  • cc duncan@… added

I suggest it'd be better to depend on the Haskell iconv package and we can localise the platform-specific hacks to just the one package.

Is there any reason not to use the Haskell iconv package?

Changed 5 years ago by judah

Letting the iconv package take care of this issue would be definitely be preferable.

The problem is that it exclusively uses lazy bytestrings, which aren't really suited for Haskeline's incremental input reader (which in the common case reads one character at a time). We'd probably need something like openPartialDecoder from http://code.haskell.org/haskeline/System/Console/Haskeline/Backend/IConv.hsc . I'm not sure what a generic API for that functionality would look like, though.

Actually, taking another look at the iconv package, Codec.Text.IConv.convertLazily might be good enough; I'm worried about efficiency, though, since for each chunk of input (usually 1-5 characters) it would call iconv_open and allocate a 32k buffer. But I haven't profiled it yet to know whether that's actually a concern.

Changed 5 years ago by judah

  • milestone set to 0.7

As a quick fix, I've made Haskeline able to link against MacPorts' libiconv:

Fri Feb  6 12:09:27 PST 2009  judah.jacobson@gmail.com
  * Add a libiconv flag for explicitly linking against the libiconv library.

Fri Feb  6 12:07:00 PST 2009  judah.jacobson@gmail.com
  * Correctly link against libiconv when iconv_open et al are actually macros.

Current plans are to use the iconv package in the next major release of Haskeline (0.7).

Note: See TracTickets for help on using tickets.