[wxhaskell-users] Re: [GUI] RE: Announce: wxHaskell 0.2

[Daan Leijen]

Hi Sven,

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

Yes, I will handle versionitis :-) Just not CVS heads.

> > I am quite sure that this has nothing to do with C vs. C++ :-)
> > [snip]
>
> No, it is not: A library has no "runtime system", it's 
> [snip]

I am quite sure that the startup code is correctly executed as all the
C++ code is in a separate dynamic link library, and not linked in as an 
object file. One reason that I think it is ok is that I am using the 
same system as the wxEiffel people and they have used this on many unix 
and windows systems, even with the LCC compiler to compile their eiffel
C code, and GCC to compile the C++ code. The wxPython project also
combines it in the same kind of way.

So, that is why I think we should first look at other causes for
your segfault. Especially since no such problems have occurred on my
test platforms: Red hat linux, Gentoo linux, and FreeBSD with GTK 1.2
and 2+.

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

Oh yeah, it is terrible on the low-level. My own extensions already use
a typed interface without casting. However, remember that this is
code that comes directly from the wxEiffel project and has been
tested quite well over the years (and is semi-automatically generated).
(and they are not "real" casts: just "void*" to class* -- not casts
between classes).

Maybe one day, the wx.NET binding gets far enough -- this is a 
somewhat cleaner binding that also lends itself well to automatic
marshalling generation.

> 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?

Yes! otherwise we *do* get all those C vs. C++ linking problems that
you describe. Actually, on most platforms you can't even link in C++
code
due to all kinds of linking errors with the standard C libraries (stdc
vs. stdc++)

Maybe GHC can be convinced to use the C++ compiler to compile all its
stuff?? That would surely solve our problems.

For now, the user just has to fiddle with dynamic libraries but I'll
look into
the -rpath option. For the MacOSX installer, we just fix the path :-) 
(/usr/local/wxhaskell) (just as the GHC installer does btw).

Question: I do use the "--soname" option when linking everything, maybe
I
can just put a full install path over there?

Cheers,
 Daan.

> 
> Cheers,
>     S.
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> wxhaskell-users mailing list
> wxhaskell-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
>