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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users