linking problems in vc 6.0 and vs2005

Hot Topic

Linking-Error with VSC++ 8.0
executing windows commands from vc++(eg: net user)
How do I debug secondary executables on Visualc++6.0
How to pass a LPTSTR value into a structure's LPWSTR parameter?
Express and VS Standard
visualizing #include tree graph dependency
Header File Inclusion problem?
warning C4441: calling convention of '__stdcall ' ignored; '__clrcall ' used instead
Microsoft Visual C++ Runtime Library error question
Replacing Once

Visual C++

vc++8.0 bug: access violation upon call of any CImageList methods
Problem with DLL MFC initialization in mixed managed/unmanaged C++
How to create log file using mfc?
Problem seeing my window
Linking-Error with VSC++ 8.0
How can I get the system informatin??? use in MFC
cfiledialog
Vertex buffers and textures
Porting-to-Unicode Issues
SSE and MSVS2005

linking problems in vc 6.0 and vs2005

dear all,

I'm facing a problem with linking of a dll( prepared in vs 2005 ), with the vc 6.0.

Here are the details,

I have some funcions defined in a win32 dll project (vs 2005).

it looks like :

int __declspec(dllexport) login(string userId, string passwd)

{

//code goes here

}

when I build the project it generates a dll, a lib and a def file.

when I use the lib (put in settings>link>input additional libs), and putting the .dll in the current directory, I'm getting the linker error as unresolved symbol _login@48, where as the lib file contains the symbol as _login@96.

Answer this question

linking problems in vc 6.0 and vs2005

  • JPNMN

    The function name is getting mangled because it is using the __stdcall calling-convertion instead of the __cdecl calling convention. The __stdcall calling convertion requires that the compiler adds a suffix to the name that is the count in bytes of the size of the arguments being passed. In this case this is a "good thing" as it shows that the size of string has changed between these releases and therefore even if this code did link (say if you had used the __cdecl calling convention instead) it would almost certainly fail at runtime with a failure that would be much harder to track down than a linker error.

  • hansv

    Try extern "C" to prevent C++ name mangling.

  • Gold333

    Please show us the complete error message you get.

    Also you should know that passing STL objects through the stack from one module to anothr requires:
    1. Usage of the same CRT linked as DLL
    2. Reqires the exact same version of the STL and compiler.

    I would never try to pass those complex objects like the STL objects through an DLL interface unless I am sure that DLL and EXE are a fixced unit and never updated or compiled seperately.

    Just my 2 cents



  • Piotr Smolanski

    Thank you Alex,but we tried extern "C" as well.

    Thank you Martin, but I would like to know why shouldn't I pass the STL objects as arguments. Even when I specify the extern "C" to avoid name mangling, why the function us actually getting mangled .

    From the answer can I draw that, c++ libraries generated with one compiler can't be used in another c++. (i.e. c++ lib generated using gcc, can't be used with vc++ compiler ), please clarify me.

    Thanks,

    Pratap.
  • linking problems in vc 6.0 and vs2005
Answer this question