On 19 May 2011 00:03, Eric Y. Kow <eric.kow@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