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

[Wolfgang Thaller]

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