tags:

views:

2610

answers:

3

When we compile a dll using __stdcall inside visual studio 2008 the compiled function names inside the dll are.

FunctionName

Though when we compile the same dll using GCC using wx-dev-cpp GCC appends the number of paramers the function has, so the name of the function using Dependency walker looks like.

FunctionName@numberOfParameters or == FunctionName@8

How do you tell GCC compiler to remove @nn from exported symbols in the dll?

+2  A: 

__stdcall decorates the function name by adding an underscore to the start, and the number of bytes of parameters to the end (separated by @).

So, a function:

void __stdcall Foo(int a, int b);

...would become _Foo@8.

If you list the function name (undecorated) in the EXPORTS section of your .DEF file, it is exported undecorated.

Perhaps this is the difference?

Roger Lipscombe
Thanks roger for the reply, it turned out that the problem was that another developer placed a DEF file into the project. This DEF file told the linker the naming conventions to use inside the DLL. This is the reason why we were getting a different library name even with the same calling convention.The solution turned out that one of our developers had removed WINAPI from the header file when creating his own DLL for a project. This caused windows visual studio to revert back to its default calling convention of __cdecl (/Gd).
Chad
A: 

Just use -Wl,--kill-at on the gcc command line, which will pass --kill-at to the linker.

References:

CesarB
A: 

Hello Chad, I got a problem that my dll is compiled with GCC/G++, now I want to use it in MS VS2005. While compile dll, I do not placed DEF file or calling conversion prefix a API declaration,how can I use my dll in VS2005?

coanor
Hi Coanor, you have two options here. First is you can build a Lib file, and also a header file to tell Visual Studio 2005 what function addresses to import when loading the dll. The second option is to load your dll via LoadLibrary, and then load the function's via the GetProcAddresses.I hope this helps your problem. Please note, you will have to make sure when loading the dlls via LoadLibrary and GetProcAddress you load with the correct calling convention or your stack will get screwed up.
Chad