0

I asked this question yesterday about using the Cygwin compiler to produce a C++ DLL that can be used by .NET: Using C++ app in .NET

The solution was to compile the C++ application using Visual C++ rather than Cygwin i.e. I was able to call a C++ function from .NET.

Why am I able to do this in Visual C++ and not Cygwin? The code can be found in my linked question. Here is a screen shot of Dependancy Walker for the Visual C++ DLL in case it helps answer my question:

enter image description here

Community
  • 1
  • 1
w0051977
  • 15,099
  • 32
  • 152
  • 329
  • 1
    Probably the issue relates to cygwin dependencies failing to be resolved at DLL load time. Or perhaps the cygwin DLL does not like being hosted in a managed process. – David Heffernan Mar 02 '13 at 11:04
  • 2
    Duplicate of [Reference a GNU C (POSIX) DLL built in GCC against Cygwin, from C#/NET](http://stackoverflow.com/questions/2710465/reference-a-gnu-c-posix-dll-built-in-gcc-against-cygwin-from-c-net) This question appears to describe a scenario identical to yours. I expect that this answers your question. – David Heffernan Mar 02 '13 at 11:06

1 Answers1

0

Name mangling schemes are different in gcc/mingw/cygwin and msvs. You'll have to use the pure-C interface if you want to share DLLs between compilers.

Alternatively, you could use .def files as is described in the bottom answer to this question: How to use libraries compiled with MingW in MSVC?

Community
  • 1
  • 1
john.pavan
  • 910
  • 4
  • 6
  • Thanks, but doesn't the screenshot I have provided show that the function name is not manged i.e. it is: hello.? – w0051977 Mar 02 '13 at 12:29
  • Ahh, you have two issues then, the first is that when you come from mingw, there is a name mangling problem, the second is calling unmanaged code from managed code. The second is straightforward, but annoying. This article is a few years old, but shows what to do: http://www.c-sharpcorner.com/uploadfile/tanmayit08/unmanaged-cpp-dll-call-from-managed-C-Sharp-application/ – john.pavan Mar 02 '13 at 12:51
  • Thanks, your last comment says: "there is a name mangling problem". Doesn't the screenshot in my question show that there is not? I am new to C++ interoperability so I am obviously missing something. – w0051977 Mar 02 '13 at 13:03
  • You may not have that problem if it's an 'extern "C"' export from the DLL. But if the export is a member variable or a class, there should be a problem linking against it from another family of compilers. From your screenshot, you could certainly use LoadLibrary and GetProcAddress to get to 'hello'. Personally, I try to stick to a C-style interface (rather than a C++ style interface) for DLL exports to avoid the name mangling problem. – john.pavan Mar 02 '13 at 13:13
  • Sorry, by C-style I mean pretty much a global function export. by C++-style I mean an object or a member of an object. – john.pavan Mar 02 '13 at 13:14