[Haskell-cafe] Re: Installing Haskell on OSX
Giuseppe Luigi Punzi
glpunzi at lordzealon.com
Mon Jun 21 14:26:29 EDT 2010
Sorry for my ignorance but..why install with +universal? i didn't use this in any port.
Sudish Joseph <sudish at gmail.com> wrote:
>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
><glpunzi at lordzealon.com> wrote:
>> 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 <sudish at gmail.com> wrote:
>>
>>>Antoine Latter <aslatter at gmail.com> writes:
>>>> On Sun, Jun 20, 2010 at 12:53 PM, Giuseppe Luigi Punzi Ruiz
>>>> <glpunzi at lordzealon.com> 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
>>
More information about the Haskell-Cafe
mailing list