Re: RE: Announce: wxHaskell 0.2

[ Removed Haskell list from Cc:, it's becoming a bit wxHaskell specific... ]

Daan Leijen wrote:
>>  * You need `-package parsec' for linking wxdirect nowadays.
> 
> Thanks for the hints. I'll look into it for a future version.
> I will not actively support CVS GHC's though -- that will be too much
> work :-)

Well, if you like it or not: You'll have to handle versionitis somehow. The
upcoming GHC 6.2 will need that flag, too.

>>  * When HelloWorld terminates, it segfaults in wxVariant()'s 
>>destructor. [...]
> I am quite sure that this has nothing to do with C vs. C++ :-)
> (I am not linking at all with C++ directly -- instead I am using extern C
> wrappers that are used in a separate dynamic link library with their own
> C++ runtime system. This is just like calling any other systems library.)

No, it is not: A library has no "runtime system", it's usually the startup
code which cares for things like global constructors/destructors, sets up
exception handling, initializes the memory allocator, etc. And you get the
correct startup code for the language you are using (C vs. C++) "under the
hood" when linking your application together. At least that's the story for
*nix systems I'm aware of, I don't have a clue on WinDoze. One of the
problems with wxHaskell currently is that the applications are linked together
(via GHC) with a C compiler, not a C++ one.

> The segfault is really weird though -- it might be that you started
> "main" twice from GHCi (a known bug in wxGTK),

Nope, I used GHC and started the resulting executable directly.

> that your GHC is broken,

The usual "help desk" answer... ;-)

> that you use an old GTK,

I'm on the bleeding edge already, doing regular online updates of my SuSE
system.

> anything really.... :-(

Another suspect is casting: I'm not quite sure what you are doing in the
low-level parts, but I see a lot of casts. The problem is: In C++, casting
is not necessarily value preserving for pointers in the presence of multiple
inheritance (or virtual base classes, IIRC).

>>  * The package configuration should include linker flags for 
>>the path of libwxc.so, otherwise a non-superuser has to fiddle around
>> with LD_LIBRARY_PATH and the like.
> 
> I am fairly hesitant here -- this means that I need two different package
> description files -- one for binary installs and one for developer installs.
> I'll look into it, but since I am not a real unix wizard, maybe you can
> tell me offline what you exactly need/want.

I was thinking of something like an -rpath option for the linker, so that the
resulting executable would automatically find the dynamic library. BTW, do we
really need a *dynamic* library here?

Cheers,
    S.