GHCi and C++.

[Lemmih]

On Fri, 25 Feb 2005 13:58:52 -0500, Wolfgang Thaller
<wolfgang.thaller at gmx.net> wrote:
> > During my ongoing research on "doing whatever I feel like", I
> > discovered that using C++ libaries in GHCi (no problems with GHC)
> > wasn't as pleasant as I had hoped.
> > Apparently C++ sources requires to be linked with crtbegin.o and
> > crtend.o (and others?) and I was wondering how to solve this nicely.
> > Any hints or pointers would be greatly appreciated.
> 
> I think the files crtbegin.o and crtend.o are Linux-specific or maybe
> GNU-binutils-specific. Different platforms tend to have different
> strange requirements for C++ code.
> 
> Loading shared libraries that happen to be written in C++ into GHCi
> shouldn't be a problem (or is it? definitely works on Mac OS X).
> Loading C++ .o files is a different story.
> 
> Generally speaking, there are at least two things that set C++ .o files
> apart from "normal" C .o files:
> 
> *) static constructors/destructors
> 
> Sometimes there are pieces of code that expect to be called before
> main() or at program termination. The GHCi Linker doesn't support this,
> so some code may crash because things haven't been initialised
> properly.
> 
> *) multiple definitions
> 
> There is often some code in C++ header files (e.g. templates, inline
> functions, class members declared in the class declaration). These
> pieces of code are sometimes inlined, but sometimes they are not; in
> that case, gcc generates code for them in every .o file that uses them
> and counts on the linker to just include one version in the final
> executable. The GHCi linker will probably just abort and complain about
> multiply-defined symbols.
> 
> The above is just theory, there might be even more problems in practice
> :-( .

I've written a binding to a C++ library where I use a simple wrapper
file to overcome the name mangling (extern "C" functions calling C++,
nothing fancy). Is there a way to make that more GHCi friendly or
should I explore other options?

-- 
Friendly,
  Lemmih