Re: Installing Haskell on OSX

I died in more dependencies. One, ige-mac-integration. To avoid possible problems I uninstall all ports last night to reinstall full gtk2 with quartz.
For now, i'm solving all of this and I hope to get it working this night.
Sudish Joseph
Antoine Latter
writes: On Sun, Jun 20, 2010 at 12:53 PM, Giuseppe Luigi Punzi Ruiz
wrote: Hi again,
Yes, you are right, but now, "cabal install leksah" I get:
[...]
Undefined symbols: "_iconv_close", referenced from: _hs_iconv_close in libHSbase-4.2.0.0.a(iconv.o) "_iconv_open", referenced from: _hs_iconv_open in libHSbase-4.2.0.0.a(iconv.o) "_iconv", referenced from: _hs_iconv in libHSbase-4.2.0.0.a(iconv.o) ld: symbol(s) not found
This one is a bummer, and I see it all the time when I try to build a package linked against macports.
This is caused by the two libiconv's in the system being ABI-incompatible, sadly. The ghc pkg available for download from haskell.org is linked against the system /usr/lib/libiconv.dynlib, which has iconv_open() as a function. Macports has GNU libiconv which #defines iconv_open to libiconv_open() in /opt/local/include/iconv.h.
This then blows up as above when linking against other libraries in macports - the linker pulls in GNU libiconv which lacks the symbols needed as you see above.
One workaround is to link GHC itself against the macports version of libiconv (and libgmp) and have cabal-install link all subsequent libraries against macports. I did just that this weekend and now have a working threadscope using the Quartz backend for gtk2, which is very nice (no need to run the X server).
Recipe for reproducing this build is included below (and I can also provide the resulting ghc-6.12.3 pkg file if needed).
Another possible option is to use Homebrew to install gtk2 and other dependencies. Homebrew prefers to use the system-provided libraries and will not pull in GNU libiconv, so this should work with the existing GHC pkg in theory. I didn't pursue this since the homebrew 'gtk+' package didn't seem to have the option to use Quartz instead of X11 as its backend.
Steps for linking the ghc runtime against macports:
- Specify EXTRA_CABAL_CONFIGURE_FLAGS in mk/build.mk as mentioned at the bottom of http://www.haskell.org/ghc/download_ghc_6_12_3.html
EXTRA_CABAL_CONFIGURE_FLAGS = --extra-include-dirs=/opt/local/include \ --extra-lib-dirs=/opt/local/lib
- Use the --with-iconv-* and --with-gmp-* flags when configuring ghc.
./configure --with-iconv-includes=/opt/local/include \ --with-iconv-libraries=/opt/local/lib \ --with-gmp-includes=/opt/local/include \ --with-gmp-libraries=/opt/local/lib
- This produces a GHC runtime and libraries linked against macports:
% otool -L ghc ghc: /opt/local/lib/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0) /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.0.0) /opt/local/lib/libgmp.10.dylib (compatibility version 11.0.0, current version 11.1.0)
% nm HSbase-4.2.0.2.o | fgrep iconv 001ff7f0 T _hs_iconv 001ff7e0 T _hs_iconv_close 001ff800 T _hs_iconv_open U _libiconv U _libiconv_close U _libiconv_open
ghc and included libraries use the macports libiconv, so linking against other libraries in macports (gtk2!) will work.
- Have cabal-install use macports as well for packages it installs by editing ~/.cabal/config and setting:
extra-include-dirs: /opt/local/include extra-lib-dirs: /opt/local/lib
- This gives, for e.g., threadscope linked against macports:
% otool -L ~/.cabal/bin/threadscope | egrep '(gtk|iconv)' /opt/local/lib/libgtk-quartz-2.0.0.dylib (compatibility version 2001.0.0, current version 2001.1.0) /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.0.0)
- Note that since the ghc runtime is still in 32-bit i386 mode, we need universal versions of most libraries in macports. Recent versions of macports (1.9 for sure, maybe 1.8) make it simple to switch from an x86_64 library to a universal one:
% port install gtk2 +universal
This will recompile gtk2 and *all* dependent libraries as universal libraries which is exactly what you need. You can then eliminate any inactive 64-bit libraries with:
% port -f uninstall inactive
Here's the last thread about with, with more links and discussion:
http://thread.gmane.org/gmane.comp.lang.haskell.general/18064/
The response by Jean-Marie Gaillourdet has worked for me in the past.
Antoine
Thanks for that link, I didn't think of overriding libiconv on a per-package basis.
-Sudish

Hi,
I ran into one problem worth mentioning while recompiling gtk and its
dependencies as universal libraries using macports: the pango port
refused to build with +universal (it fails when trying to merge the
i386 & x86_64 libs). The pango-devel port does work with one small
tweak as described at https://trac.macports.org/ticket/22801.
Essentially, I had to comment out the "PortGroup muniversal 1.0" line
in the Portfile to get a working universal library for pango.
-Sudish
On Mon, Jun 21, 2010 at 5:09 AM, Giuseppe Luigi Punzi
I died in more dependencies. One, ige-mac-integration. To avoid possible problems I uninstall all ports last night to reinstall full gtk2 with quartz.
For now, i'm solving all of this and I hope to get it working this night.
Sudish Joseph
wrote: Antoine Latter
writes: On Sun, Jun 20, 2010 at 12:53 PM, Giuseppe Luigi Punzi Ruiz
wrote: Hi again,
Yes, you are right, but now, "cabal install leksah" I get:
[...]
Undefined symbols: "_iconv_close", referenced from: _hs_iconv_close in libHSbase-4.2.0.0.a(iconv.o) "_iconv_open", referenced from: _hs_iconv_open in libHSbase-4.2.0.0.a(iconv.o) "_iconv", referenced from: _hs_iconv in libHSbase-4.2.0.0.a(iconv.o) ld: symbol(s) not found
This one is a bummer, and I see it all the time when I try to build a package linked against macports.
This is caused by the two libiconv's in the system being ABI-incompatible, sadly. The ghc pkg available for download from haskell.org is linked against the system /usr/lib/libiconv.dynlib, which has iconv_open() as a function. Macports has GNU libiconv which #defines iconv_open to libiconv_open() in /opt/local/include/iconv.h.
This then blows up as above when linking against other libraries in macports - the linker pulls in GNU libiconv which lacks the symbols needed as you see above.
One workaround is to link GHC itself against the macports version of libiconv (and libgmp) and have cabal-install link all subsequent libraries against macports. I did just that this weekend and now have a working threadscope using the Quartz backend for gtk2, which is very nice (no need to run the X server).
Recipe for reproducing this build is included below (and I can also provide the resulting ghc-6.12.3 pkg file if needed).
Another possible option is to use Homebrew to install gtk2 and other dependencies. Homebrew prefers to use the system-provided libraries and will not pull in GNU libiconv, so this should work with the existing GHC pkg in theory. I didn't pursue this since the homebrew 'gtk+' package didn't seem to have the option to use Quartz instead of X11 as its backend.
Steps for linking the ghc runtime against macports:
- Specify EXTRA_CABAL_CONFIGURE_FLAGS in mk/build.mk as mentioned at the bottom of http://www.haskell.org/ghc/download_ghc_6_12_3.html
EXTRA_CABAL_CONFIGURE_FLAGS = --extra-include-dirs=/opt/local/include \ --extra-lib-dirs=/opt/local/lib
- Use the --with-iconv-* and --with-gmp-* flags when configuring ghc.
./configure --with-iconv-includes=/opt/local/include \ --with-iconv-libraries=/opt/local/lib \ --with-gmp-includes=/opt/local/include \ --with-gmp-libraries=/opt/local/lib
- This produces a GHC runtime and libraries linked against macports:
% otool -L ghc ghc: /opt/local/lib/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0) /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.0.0) /opt/local/lib/libgmp.10.dylib (compatibility version 11.0.0, current version 11.1.0)
% nm HSbase-4.2.0.2.o | fgrep iconv 001ff7f0 T _hs_iconv 001ff7e0 T _hs_iconv_close 001ff800 T _hs_iconv_open U _libiconv U _libiconv_close U _libiconv_open
ghc and included libraries use the macports libiconv, so linking against other libraries in macports (gtk2!) will work.
- Have cabal-install use macports as well for packages it installs by editing ~/.cabal/config and setting:
extra-include-dirs: /opt/local/include extra-lib-dirs: /opt/local/lib
- This gives, for e.g., threadscope linked against macports:
% otool -L ~/.cabal/bin/threadscope | egrep '(gtk|iconv)' /opt/local/lib/libgtk-quartz-2.0.0.dylib (compatibility version 2001.0.0, current version 2001.1.0) /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.0.0)
- Note that since the ghc runtime is still in 32-bit i386 mode, we need universal versions of most libraries in macports. Recent versions of macports (1.9 for sure, maybe 1.8) make it simple to switch from an x86_64 library to a universal one:
% port install gtk2 +universal
This will recompile gtk2 and *all* dependent libraries as universal libraries which is exactly what you need. You can then eliminate any inactive 64-bit libraries with:
% port -f uninstall inactive
Here's the last thread about with, with more links and discussion:
http://thread.gmane.org/gmane.comp.lang.haskell.general/18064/
The response by Jean-Marie Gaillourdet has worked for me in the past.
Antoine
Thanks for that link, I didn't think of overriding libiconv on a per-package basis.
-Sudish
participants (2)
-
Giuseppe Luigi Punzi
-
Sudish Joseph