Re: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX
On Sun, Feb 1, 2009 at 12:01 PM, Thomas Davie tom.da...@gmail.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX
On Sun, Feb 1, 2009 at 12:04 PM, Antoine Latter aslat...@gmail.com wrote: On Sun, Feb 1, 2009 at 12:01 PM, Thomas Davie tom.da...@gmail.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX
On 1 Feb 2009, at 19:43, Antoine Latter wrote: On Sun, Feb 1, 2009 at 12:04 PM, Antoine Latter aslat...@gmail.com wrote: On Sun, Feb 1, 2009 at 12:01 PM, Thomas Davie tom.da...@gmail.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX
On Sun, Feb 1, 2009 at 10:04 AM, Antoine Latter aslat...@gmail.com wrote: On Sun, Feb 1, 2009 at 12:01 PM, Thomas Davie tom.da...@gmail.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX
[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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX
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
Re: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
