Hi, after installing http://lambda.galois.com/hp-tmp/2010.2.0.0/haskell-platform-2010.2.0.0.i386.... and various more libraries using cabal, we get the following linker error below. A simple hello program compiles and links fine and uses /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) as shown by "otool -L". Does someone have an explanation or solution? Cheers Christian Linking dist/build/hets/hets ... Undefined symbols: "_iconv_close", referenced from: _hs_iconv_close in libHSbase-4.2.0.2.a(iconv.o) "_iconv_open", referenced from: _hs_iconv_open in libHSbase-4.2.0.2.a(iconv.o) "_iconv", referenced from: _hs_iconv in libHSbase-4.2.0.2.a(iconv.o) ld: symbol(s) not found collect2: ld returned 1 exit status
Am 02.11.2010 11:48, schrieb Christian Maeder:
Hi,
after installing http://lambda.galois.com/hp-tmp/2010.2.0.0/haskell-platform-2010.2.0.0.i386.... and various more libraries using cabal, we get the following linker error below.
A simple hello program compiles and links fine and uses /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) as shown by "otool -L".
Does someone have an explanation or solution?
adding "-L/usr/lib" as first argument to ghc solved the problem. Another cabal-package (gtk and friends) used /opt/local/lib under library-dirs:. Are there better workarounds? C.
Cheers Christian
Linking dist/build/hets/hets ... Undefined symbols: "_iconv_close", referenced from: _hs_iconv_close in libHSbase-4.2.0.2.a(iconv.o) "_iconv_open", referenced from: _hs_iconv_open in libHSbase-4.2.0.2.a(iconv.o) "_iconv", referenced from: _hs_iconv in libHSbase-4.2.0.2.a(iconv.o) ld: symbol(s) not found collect2: ld returned 1 exit status
Hello, On Tue, Nov 02, 2010 at 01:03:04PM +0100, Christian Maeder wrote:
... Are there better workarounds?
I am not sure about that, I assume that you have looked at http://hackage.haskell.org/trac/ghc/ticket/4068?
...
Best regards Thorkil
Am 02.11.2010 18:03, schrieb Thorkil Naur:
Hello,
On Tue, Nov 02, 2010 at 01:03:04PM +0100, Christian Maeder wrote:
... Are there better workarounds?
I am not sure about that, I assume that you have looked at http://hackage.haskell.org/trac/ghc/ticket/4068?
no, I found Simon Michael's message http://www.mail-archive.com/haskell-cafe@haskell.org/msg81961.html by chance. I did not try out his extra-lib-dirs proposal, since all cabal packages were already installed. And I agree with him that it should be documented somewhere more prominent and that avoiding macports is no (good) solution. I'll add his proposal to your (closed) ticket to increase the hit rate. Cheers Christian
...
Best regards Thorkil
On Wed, Nov 3, 2010 at 9:55 AM, Christian Maeder
Am 02.11.2010 18:03, schrieb Thorkil Naur:
Hello,
On Tue, Nov 02, 2010 at 01:03:04PM +0100, Christian Maeder wrote:
... Are there better workarounds?
I am not sure about that, I assume that you have looked at http://hackage.haskell.org/trac/ghc/ticket/4068?
no, I found Simon Michael's message http://www.mail-archive.com/haskell-cafe@haskell.org/msg81961.html by chance.
I did not try out his extra-lib-dirs proposal, since all cabal packages were already installed.
And I agree with him that it should be documented somewhere more prominent and that avoiding macports is no (good) solution.
I'll add his proposal to your (closed) ticket to increase the hit rate.
Cheers Christian
His proposed solution works until you try to link a Haskell project to a macports lib that requires libiconv. It's also inconvenient that you'll sometimes need to unpack hackage code and manually edit the .cabal file. If you want to use macports, the only real solution is to build a GHC+libs that prefers /opt/local/ to the system-installed locations. The macports GHC does this, or you can try to compile it yourself with appropriate flags to configure (whatever they may be). John
participants (3)
-
Christian Maeder -
John Lato -
Thorkil Naur