Building a Windows DLL with MinGW

Question

C++ / C#

I'm trying to create a simple COM application, I did everything according to the tutorial.
Programming in Netbeans using MinGW. Both the client and the server itself (dll) compile perfectly. After some trouble with __stdcall, __cdecl and .def files, we even managed to register the dll in the registry. I collected the same code in VS2008, everything also compiles, registers and even works correctly.
First, I checked the dump of exported functions using objdump - everything is ok. Then, using the gendef tool, it automatically generated a .def file for the created dll. It came out like this:

LIBRARY "libCOMdll2.dll"
EXPORTS
CLSID_Component2 DATA
DllCanUnloadNow
[email protected]
[email protected]
DllRegisterServer
DllUnregisterServer

At first I thought that the problem was in postfixes,

"@"

and one of them is after the name DllMain, from where the dll starts its work. After generating a .def file with another dll made in VS, I got exactly the same result - but everything works!
In VS, in the project settings, I saw that in the calling convention settings there is __cdecl, but the functions still use their calls.
Please tell me how to correctly compile dll in MinGW. I will be glad to help.

Answer 1

The client created on MinGW cannot connect to the dll.
Moreover, it connects to a dll created on VisualStudio. Tobish the client works correctly.
I just really want to figure out what the “dog is buried” in.

Answer 2

GNU ld has many options regarding DLLs, but we shall only focus on four (help information follows):
--add-stdcall-alias Export symbols with and without @nn
--kill-at Remove @nn from exported symbols
--out- implib Generate import library
--output-def Generate a .DEF file for the built DLL

Answer 3

In addition to __cdecl, it may be necessary to wrap prototypes in extern "C" { }

Answer 4

As far as I understand, suffixes @8, etc. are added to functions for which the call format is specified stdcalland indicate the stack size. It depends on the compiler actually, but both MSVC and mingwhere are the same. If such a function is supposed to be exported from the resulting DLL, an alias is additionally created without a suffix, which we actually see here:

DllCanUnloadNow = @ILT+450([email protected]0)

I don't like the difference in DllMain- @8and @12correct, judging by the specification - three pointers are @12passed, but then one goes somewhere. Does it take DllMainexactly three parameters for you?

Answer 5

no, shows @12 after DllMain and @12 after DllGetClassObject