[wxhaskell-users] haskell-platform-2010.1.0.0, MacPorts & wxHaskell works w/ work

[Eric Y. K. <eri...@gm...>]

Hi everyone,

Here's a user report with some good and bad news.  If somebody from
the wxHaskell Team could bless or comment on this, I might forward it
along to Haskell-Café.

I'm Bcc'ing Gregory Wright from the MacPorts team as I think he may
be interested.

First the good: with MacOS X 10.6 (but 32 bit), the new wxHaskell
packages by Daniel Fischer seem to work fine with GHC 6.12 and the
latest Haskell Platform.

And now the bad news: you have to work a little to get there if
you're using MacPorts.

Summary
=======
1. No more MacPorts wxWidgets; build one yourself
2. Don't forget to --enable-unicode
3. Don't forget grab your wxWidgets and not the system one
4. Or maybe wait for haskell-platform-2010.x to arrive in MacPorts

1. no more macports wxwidgets
=============================
you may see this error message (see Conor McBride's suffering on
http://www.haskell.org/pipermail/haskell-cafe/2009-December/071117.html ).

Undefined symbols:
 "_iconv_close", referenced from:
     _hs_iconv_close in libHSbase-4.2.0.0.a(iconv.o)
 "_iconv", referenced from:
     _hs_iconv 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)
ld: symbol(s) not found
collect2: ld returned 1 exit status

As I vaguely understand the issue, the problem is that
 (a) new libHSbase gets built using iconv.h and the like from -I/usr/include,
     but
 (b) having *any* package that introduces a -L/opt/local/lib in there (eg. a
     MacPorts-friendly Haskeline) 
and that some sort of difference between the two versions of iconv make (a) and
(b) an unhappy combination.

Having your wxHaskell be linked against your MacPorts wxWidgets causes similar
trouble if you have MacPorts iconv as well.

I didn't want to think about this any harder, so I just took MacPorts out of
the equation altogether by building my own wxWidgets 2.8.10 from source
http://www.wxwidgets.org/downloads/#latest_stable (Hooray for stow)

2. Don't forget to --enable-unicode when configuring wxWidgets
==============================================================
After untarring the wxWidgets source, I did this, the main point being the
Unicode stuff; the stow related business being extra details to make life
easier:

  port install stow
  ./configure --prefix=/usr/local/stow/wxMac-2.8.10 --enable-unicode
  make && sudo make install
  cd /usr/local/stow
  sudo stow wxMac-2.8.10

If you forget to enable Unicode, everything will build fine, but you'll get
widgets with only one letter on them.

3. Don't forget to build wxHaskell against YOUR wxWidgets
=========================================================
I did this:

  PATH=/usr/local/bin:$PATH cabal install wx

If you do not temporarily re-order the path, the Setup.lhs file in wxcore
will pick up the system wxWidgets which does not have the wxThread symbols
wxHaskell wants (so says the wiki for OS X 10.4), and when you launch your
application you'll be greeted by lots of annoying dialogue boxes that you
have to chase away.  Other things may break.

  http://www.haskell.org/haskellwiki/WxHaskell/MacOS_X

I wish there was some way we could just use the system wxWidgets with maybe
some sort of way of filling in the missing bits :-(

4. Maybe just wait for MacPorts haskell-platform to catch up
============================================================
Perhaps that would be the path of least resistance.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9