[Haskell-cafe] wxHaskell on Mac (Was: Status of Haskell + Mac + GUIs & graphics)

[Jeremy O'Donoghue]

On 19 May 2011 00:03, Eric Y. Kow <eric.kow at gmail.com> wrote:

> On Wed, May 18, 2011 at 15:06:02 -0400, Tom Murphy wrote:
> > Is there a way to build an installer that would make this process easier?
>
> I've sent a pull request to the maintainer of homebrew.
> Hopefully it should then just be a matter of brew install wxmac
>
> Homebrew's wxWidgets already builds 32 bit, but it omitted the
> enable-unicode, which is what my patch fixes)
>
> > > Unfortunately, this does not address Conal's issue about using
> wxHaskell
> > > with GHCi on Mac.  I do wish somebody had a free week to concentrate on
> > > the issue.  Maintainer Jeremy made some progress on it, the last time I
> > > checked...
> >
> > Do you have the link for the progress so far?
>
> Jeremy's blog seems to talk about this:
>  http://wewantarock.wordpress.com/
>
>
> I remember that the impression that Brian Lewis was also looking into
> this at some point
>
> http://www.mail-archive.com/wxhaskell-users@lists.sourceforge.net/msg00744.html
>
> If anybody knows what this "unknown symbol `__dso_handle'" means and
> what we can do about it, it could be a great help
>

It is a handle for a dynamic shared object. It is required for the case
where __cxa_atexit() is called, which is when a shared library is unloaded.
It is specifically required because there are C++ statics on which
destructors should be called. The documentation says that __dso_handle
should be unique to the shared library instance.


> I wonder if GHC 7 makes any of this easier...
>

GHC7 may (should) fix the problem linking libstdc++.dll on Windows.

The static destructor problem probably requires 'true' dynamic loading and
unloading of the wxWidgets DLL from within part of the wxcore wrapper code.
Loading wxwidgets dll with dlopen() (Unix) or LoadLibrary() (Windows) will
give us a DLL handle, and unloading with dlclose()/UnloadLibrary() will
ensure that the destructors are called.

The problem is that doing this means that you only know the address of
wrapper functions after they have been loaded (need to do a
dlsym()/GetProcAddr() to fetch this info), and doing this for the several
thousand functions in wxHaskell will require some automation to extract the
information to generate the code to do this. The code should probably live
in wxDirect, but I loose the will to live whenever I go digging there :-(

Regards
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110520/07b5c913/attachment.htm>