[Mono-devel-list] export "C" issues

Marcus mathpup at mylinuxisp.com
Sun May 1 00:56:42 EDT 2005

I do not fully understand what you are asking, but I can try to help. I'm not 
familiar with directive 'export "C" ', although I have used `extern "C"'.

In any case, when a library is compiled as C++, the symbols in the resulting 
binary will be mangled. For example, _Z16freyjaCSharpTestv looks like the 
kind of mangled name that GCC >= 3.0 generates. It varies from compiler to 
compiler. The Mono runtime does not know about mangling, so with

[DllImport(libname, EntryPoint="freyjaSpawn")]
public extern static void run();

the runtime looks for a name "freyjaSpawn" and does not find it because the 
actual symbol in the library appears as _Z.... [mangled name].

The mangling varies from compiler to compiler (MS's C++ compilers mangle 
symbols very differently from GCC) and from version to version. GCC prior to 
3.0 mangled symbols in a completely different way from GCC since 3.0. But 
even within the 3.x series of GCC there have been changes to mangling (due to 
misinterpretations of the mangling documentation, as far as I know).


On Saturday 30 April 2005 10:42 pm, Mongoose wrote:
> I have confirmed it.  C export won't work with
> DllImport.
> C#
> ------------
> 	[DllImport(libname,
> EntryPoint="_Z16freyjaCSharpTestv")]
> 	public extern static void run2();
> 	[DllImport(libname, EntryPoint="freyjaSpawn")]
> 	public extern static void run();
> C++
> -------------
> export "C" {
>    void freyjaSpawn();
> }
> void freyjaCSharpTest();
> Test() imports and Spawn() doesn't.  Test is actually
> a C++ function that calls Spawn, so I guess I can use
> mangled symbols for binary releases until mono is
> fixed.  I may write an auto demangler in C# if it's
> too much work to resymbol every build.  =)

More information about the Mono-devel-list mailing list