Let me provide a few comments about the C++ linking story.... Sven Panne wrote:
No, it is not: A library has no "runtime system", it's usually the startup code [...]. And you get the correct startup code for the language you are using (C vs. C++) "under the hood" when linking your application together.
On Mac OS X, Windows/Mingw32 and RedHat Linux 8, you get the same startup code no matter whether you use gcc or g++. The only difference between the gcc and g++ linker drivers is that g++ adds -lstdc++. On Mac OS X, every dynamic library gets it's own startup code (haven't checked on Linux or Windows, but I guess it's the same). Daan Leijen:
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.
A small mixed C++ & Haskell test program, runs fine on Mac OS X, Windows and RedHat 8 when I add -lstdc++ to the command line. On Windows, there's of course the problem that GHC includes it's own copy of GCC, but no C++ includes, but I happen to have another copy of them :-). While being short, my test program uses static constructors and destructors, and it calls the C++ standard library (iostream and string, to be exact), and everything works perfectly. What kinds of problems did you experience? GHCi, on the other hand, cannot currenlty load C++ object files (nor can it currently load the C++ standard library on systems where it's a static library), so using dynamic libraries is definitely necessary at least during development. Of course, it would be nice if I could just statically link my wxHaskell application when I'm done, but GHCi is more important. Cheers, Wolfgang