0

Following on from my previous question regarding debugging of native code, I decided to create a simple test from a console app as I wasn't getting anywhere with debugging the service directly.

So I created a vc6 console app, added the dll project to the workspace and ran it.

Instead of executing as expected it spat out the following linker errors:

 main.obj : error LNK2001: unresolved external symbol "int __stdcall hmDocumentLAdd(char *,char *,long,char *,char *,long,long,long,long *)" (?hmDocumentLAdd@@YGHPAD0J00JJJPAJ@Z)
 main.obj : error LNK2001: unresolved external symbol "int __stdcall hmGetDocBasePath(char *,long)" (?hmGetDocBasePath@@YGHPADJ@Z)
 Debug/HazManTest.exe : fatal error LNK1120: 2 unresolved externals

This seems to be a simple case of forgetting something in the linker options: However everything seems to be normal, and the lib file, dll and source is available. If I change the lib file to load to nonsense it kicks up the fatal error LNK1104: cannot open file "asdf.lib", so that isn't a problem.

I have previously linked to dll and they have just worked, so what I have forgotton to do?

Update: As per this thread I looked to see if I could find out any additional information. This is what dumpbin from VS2005 gives me.

> dumpbin /linkermember Hazardman.lib | findstr "DocumentLAdd"
     F6DC __imp__hmDocumentLAdd@36
     F6DC _hmDocumentLAdd@36
       5B __imp__hmDocumentLAdd@36
       5B _hmDocumentLAdd@36

Then running it through undname results in:

> undname ?_hmDocumentLAdd@36
Microsoft (R) C++ Name Undecorator
Copyright (C) Microsoft Corporation. All rights reserved.

Undecoration of :- "?_hmDocumentLAdd@36"
is :- "?_hmDocumentLAdd@36"

Which is wrong. If I put in the mangled name from the IDE it gives the lot better result of:

> undname ?hmDocumentLAdd@@YGHPAD0J00JJJPAJ@Z
Microsoft (R) C++ Name Undecorator
Copyright (C) Microsoft Corporation. All rights reserved.

Undecoration of :- "?hmDocumentLAdd@@YGHPAD0J00JJJPAJ@Z"
is :- "int __stdcall hmDocumentLAdd(char *,char *,long,char *,char *,long,long,l
ong,long *)"

Now I have this information, what can I do with it? It seems from this Raymond Chen article I can manually fix it but tweaking an option, but my I can't discern from my results what option is needed (is there an 'ignore all parameters' checkbox?!).

So it seems that it is looking for non-existant functions or the parameters of the function have been left off (or dumpbin doesn't like VC6 libs), but it stil doesn't get me nearer my goal of fixing my problem.

Community
  • 1
  • 1
graham.reeds
  • 16,230
  • 17
  • 74
  • 137
  • Did you make the console app dependent on the library? – EvilTeach Mar 29 '10 at 14:07
  • Yep. The dll compiles before the app does. – graham.reeds Mar 29 '10 at 14:12
  • and are you doing anything with 'c' interfaces extern 'c' and the like? – EvilTeach Mar 29 '10 at 15:50
  • Nothing like that. The project compiles and works with half a dozen other projects - none of which has this problem. One other guy in the office has taken a look at it and he can't figure it out either. – graham.reeds Mar 30 '10 at 07:48
  • Well then I would advise, falling back to a previous version where it did work, and move forward from there – EvilTeach Mar 30 '10 at 16:18
  • That's the thing: This is a small test application written from scratch. I've recreated it twice and both times I get the same error. I've tried differing types of console (those that support MFC and those that don't) but none seem to work. – graham.reeds Mar 31 '10 at 07:47

1 Answers1

1

Are you using the correct calling convention? Your library appears to use stdcall. Maybe your test code is using cdecl (appears to be the default).

According to this page, the linker name decorations differ between the caling conventions so this can explain the symptoms you are seeing.

foraidt
  • 5,519
  • 5
  • 52
  • 80