
[ 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.