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
pgpWsXpdLAq9y.pgp
Description: PGP signature
------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
_______________________________________________ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
