[wxhaskell-users] Re: [GUI] RE: Announce: wxHaskell 0.2
Daan Leijen
daanleijen at xs4all.nl
Wed Sep 17 12:52:30 EDT 2003
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
>
>
More information about the GUI
mailing list