Haskeline, pcre-light, iconv and Cabal on OSX

older
cabal list can't find Glob.cabal...

Antoine Latter

1 Feb 2009 1 Feb '09

12:57 p.m.

Funny story, If I do the following three things, I get errors on my Intel Mac OS 10.5: * Build an executable with Cabal * Have the executable have a build-dep of pcre-light in the .cabal * use haskeline in the executable itself I get crazy linker errors relating to haskeline and libiconv: Shell output:

...

...
...
...
...
$ cabal clean && cabal configure && cabal build cleaning... Configuring test-0.0.0... Preprocessing executables for test-0.0.0... Building test-0.0.0... [1 of 1] Compiling Main ( test.hs, dist/build/test/test-tmp/Main.o ) Linking dist/build/test/test ... Undefined symbols: "_iconv_open", referenced from: _s9Qa_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: _sa0K_info in libHShaskeline-0.6.0.1.a(IConv.o) ld: symbol(s) not found

collect2: ld returned 1 exit status <<<<<

But all three above conditions need to be true - if I build using 'ghc --make' everything works great, even if the executable imports pcre-light and haskeline. If I have build-deps on haskeline and pcre-light, but don't actually import haskeline, everything also works great. Here are the files I've used: test.hs:

...

...
...
...
...
import System.Console.Haskeline

main :: IO () main = print "Hello!" <<<<< test.cabal

...

...
...
...
...
Name: test version: 0.0.0 cabal-version: >= 1.2 build-type: Simple

Executable test main-is: test.hs build-depends: base, haskeline, pcre-light>=0.3 <<<<< Is there some way I need to be building haskeline on OS X to make this work? Thanks, Antoine more details:

...

...
...
...
...
$ cabal --version cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library <<<<<

...

...
...
...
...
$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.0.20081007 <<<<<

links: pcre-light: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/pcre-light haskeline: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskeline

Show replies by date

Thomas Davie

1 Feb 1 Feb

1:01 p.m.

This is caused by OS X's libiconv being entirely CPP macros, the FFI has nothing to get hold of. IIRC there's a ghc bug report open for it. Bob On 1 Feb 2009, at 18:57, Antoine Latter wrote:

...

Funny story,

If I do the following three things, I get errors on my Intel Mac OS 10.5:

* Build an executable with Cabal * Have the executable have a build-dep of pcre-light in the .cabal * use haskeline in the executable itself

I get crazy linker errors relating to haskeline and libiconv:

Shell output:

...
...
...
...
...
$ cabal clean && cabal configure && cabal build cleaning... Configuring test-0.0.0... Preprocessing executables for test-0.0.0... Building test-0.0.0... [1 of 1] Compiling Main ( test.hs, dist/build/test/test- tmp/Main.o ) Linking dist/build/test/test ... Undefined symbols: "_iconv_open", referenced from: _s9Qa_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: _sa0K_info in libHShaskeline-0.6.0.1.a(IConv.o) ld: symbol(s) not found

collect2: ld returned 1 exit status <<<<<

But all three above conditions need to be true - if I build using 'ghc --make' everything works great, even if the executable imports pcre-light and haskeline. If I have build-deps on haskeline and pcre-light, but don't actually import haskeline, everything also works great.

Here are the files I've used:

test.hs:

...
...
...
...
...
import System.Console.Haskeline

main :: IO () main = print "Hello!" <<<<<

test.cabal

...
...
...
...
...
Name: test version: 0.0.0 cabal-version: >= 1.2 build-type: Simple

Executable test main-is: test.hs build-depends: base, haskeline, pcre-light>=0.3 <<<<<

Is there some way I need to be building haskeline on OS X to make this work?

Thanks, Antoine

more details:

...
...
...
...
...
$ cabal --version cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library <<<<<

...
...
...
...
...
$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.0.20081007 <<<<<

links: pcre-light: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/pcre-light haskeline: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskeline _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Antoine Latter

1:04 p.m.

On Sun, Feb 1, 2009 at 12:01 PM, Thomas Davie wrote:

...

This is caused by OS X's libiconv being entirely CPP macros, the FFI has nothing to get hold of. IIRC there's a ghc bug report open for it.

Bob

So why does it sometimes work? I can write and compile executables using haskeline, both with 'ghc --make' and 'cabal configure && cabal build'. This sounds like something I can patch haskeline to account for, then? Thanks, Antoine

Antoine Latter

1:43 p.m.

On Sun, Feb 1, 2009 at 12:04 PM, Antoine Latter wrote:

...

On Sun, Feb 1, 2009 at 12:01 PM, Thomas Davie wrote:

...
This is caused by OS X's libiconv being entirely CPP macros, the FFI has nothing to get hold of. IIRC there's a ghc bug report open for it.

Bob

So why does it sometimes work? I can write and compile executables using haskeline, both with 'ghc --make' and 'cabal configure && cabal build'.

This sounds like something I can patch haskeline to account for, then?

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. Thanks, Antoine

Thomas Davie

2:01 p.m.

On 1 Feb 2009, at 19:43, Antoine Latter wrote:

...

On Sun, Feb 1, 2009 at 12:04 PM, Antoine Latter wrote:

...
On Sun, Feb 1, 2009 at 12:01 PM, Thomas Davie wrote:

...
This is caused by OS X's libiconv being entirely CPP macros, the FFI has nothing to get hold of. IIRC there's a ghc bug report open for it.

Bob

So why does it sometimes work? I can write and compile executables using haskeline, both with 'ghc --make' and 'cabal configure && cabal build'.

This sounds like something I can patch haskeline to account for, then?

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.

Yep, darwin is OS X :) Bob

Duncan Coutts

7:07 p.m.

[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 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? Duncan

Judah Jacobson

8:10 p.m.

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

Duncan Coutts

9:16 p.m.

On Sun, 2009-02-01 at 17:10 -0800, Judah Jacobson wrote:

...

...
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.

Yes. Sigh. A limitation of the C linker search path model.

...

...
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,

Yes, thanks. I wonder if it wouldn't be better to search the standard lib dirs first. I'm sure the whole issue is a can of worms. Duncan

Judah Jacobson

2:09 p.m.

On Sun, Feb 1, 2009 at 10:04 AM, Antoine Latter wrote:

...

On Sun, Feb 1, 2009 at 12:01 PM, Thomas Davie wrote:

...
This is caused by OS X's libiconv being entirely CPP macros, the FFI has nothing to get hold of. IIRC there's a ghc bug report open for it.

Bob

So why does it sometimes work? I can write and compile executables using haskeline, both with 'ghc --make' and 'cabal configure && cabal build'.

This sounds like something I can patch haskeline to account for, then?

The OS X system libiconv is actually OK; it's the MacPorts libiconv that has the CPP macros. When the cabal package depends on pcre-light it pulls in all of pcre-light's options; and like me, you probably compiled pcre-light to link against /opt/local/lib. To confirm this I ran "ghc --make -L/opt/local/lib test.hs" on my OS X machine and saw the same error as you. Thanks for the report; I'm not sure of what the right solution is, but I opened a ticket on Haskeline's bug tracker: http://trac.haskell.org/haskeline/ticket/74 Feel free to add comments, propose a fix or suggest a workaround. -Judah

Yitzchak Gale

2 Feb 2 Feb

7 a.m.

Thomas Davie wrote:

...

...
...
This is caused by OS X's libiconv being entirely CPP macros, the FFI has nothing to get hold of. IIRC there's a ghc bug report open for it.

Judah Jacobson wrote:

...

The OS X system libiconv is actually OK; it's the MacPorts libiconv that has the CPP macros... Thanks for the report; I'm not sure of what the right solution is, but I opened a ticket on Haskeline's bug tracker

Perhaps there should also be a ticket on MacPort's bug tracker? -Yitz

Antoine Latter

1 Feb 1 Feb

2:53 p.m.

On Sun, Feb 1, 2009 at 11:57 AM, Antoine Latter wrote:

...

Funny story,

If I do the following three things, I get errors on my Intel Mac OS 10.5:

* Build an executable with Cabal * Have the executable have a build-dep of pcre-light in the .cabal * use haskeline in the executable itself

I get crazy linker errors relating to haskeline and libiconv:

Shell output:

...
...
...
...
...
$ cabal clean && cabal configure && cabal build cleaning... Configuring test-0.0.0... Preprocessing executables for test-0.0.0... Building test-0.0.0... [1 of 1] Compiling Main ( test.hs, dist/build/test/test-tmp/Main.o ) Linking dist/build/test/test ... Undefined symbols: "_iconv_open", referenced from: _s9Qa_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: _sa0K_info in libHShaskeline-0.6.0.1.a(IConv.o) ld: symbol(s) not found

collect2: ld returned 1 exit status <<<<<

But all three above conditions need to be true - if I build using 'ghc --make' everything works great, even if the executable imports pcre-light and haskeline. If I have build-deps on haskeline and pcre-light, but don't actually import haskeline, everything also works great.

Here are the files I've used:

test.hs:

...
...
...
...
...
import System.Console.Haskeline

main :: IO () main = print "Hello!" <<<<<

test.cabal

...
...
...
...
...
Name: test version: 0.0.0 cabal-version: >= 1.2 build-type: Simple

Executable test main-is: test.hs build-depends: base, haskeline, pcre-light>=0.3 <<<<<

Is there some way I need to be building haskeline on OS X to make this work?

Thanks, Antoine

more details:

...
...
...
...
...
$ cabal --version cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library <<<<<

...
...
...
...
...
$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.0.20081007 <<<<<

links: pcre-light: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/pcre-light haskeline: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskeline

For folks following along at home, the above example starts working again if I hard-code some LD flags into my example .cabal file:

...

...
...
...
...
Name: test version: 0.0.0 cabal-version: >= 1.2 build-type: Simple

Executable test main-is: test.hs build-depends: base, iconv, pcre-light>=0.3 ld-options: -L/usr/lib -L/opt/local/lib <<<<< This way I make sure that I'm linking against the "good" version of iconv instead of the Mac Ports version. I'm not sure what a general solution is. -Antoine

5953

Age (days ago)

5954

Last active (days ago)

List overview

Download

10 comments

5 participants

participants (5)

Antoine Latter
Duncan Coutts
Judah Jacobson
Thomas Davie
Yitzchak Gale

Haskeline, pcre-light, iconv and Cabal on OSX

tags

participants (5)