1

I'm using vs2012 to create a small wrapper dll, linking against another dll (.lib) which was built with VC6.

I get link errors like:

error LNK2019: unresolved external symbol __imp__functionName@8

I added the lib file supplied with the vc6 dll to the link line, as I've done in the past... is there some version problem here? The vc6 dll header file declares the functions in what I think is the standard way:

#define DLLIMPORT extern "C" __declspec(dllimport)
DLLIMPORT ULONG WINAPI functionName(...);

Using dumpbin /exports on the vc6 lib file shows "functionName" without the imp prefix and "@8".. not sure if that's a problem or just dumpbin being nice and demangling for me.

I'm not a windows person and have no idea why the linker isn't finding the symbols...help!

Tyler Daniel
  • 656
  • 6
  • 15
  • Send it back, you don't want it. You'd have to drop DLLIMPORT and WINAPI but that's very unlikely to be correct if it appears in the .h file. – Hans Passant Dec 14 '13 at 16:37
  • Um, thanks for the comment, but why would I have to drop DLLIMPORT and WINAPI? DLLIMPORT is telling the compiler/linker that the function I'm referencing will be provided in a dll, which is correct. WINAPI is the calling convention, also correct.. – Tyler Daniel Dec 14 '13 at 20:31
  • DLLIMPORT says that the DLL has an *extra* export whose name starts with __imp. WINAPI says that the calling convention is __stdcall which produces the extra @8. Since you can't find these with dumpbin.exe, you want to send it back, it is of no use to you. – Hans Passant Dec 14 '13 at 20:38
  • Those same H and LIB where OK when used in another project?, or is the first time you try to use them? – manuell Dec 15 '13 at 18:21

1 Answers1

4

Solved! There were two problems:

1) dumpbin /exports doesn't show all of the symbols. Using /all instead shows symbols of the form __imp_functionName@8.

2) the linker was looking for symbols of the form __imp__ not __imp_ as provided by the vc6 lib. google tells me that this is the difference between 32-bit and 64-bit builds, so the vc6 library was a 64 bit build while mine was 32.

Changing my wrapper dll to 64-bit solved the problem!

That was half a day well spent! Maybe. Probably... not. It's times like these when I love being a programmer!

Tyler Daniel
  • 656
  • 6
  • 15
  • A 64-bit VC6 library? I suppose there may have been an amd64 targeting version of `cl.exe` 12.xx distributed with some Windows SDK when x64 was just starting out. But even if that compiler did exists, it seems like a library built with it would be an unlikely thing to have to deal with today. – Michael Burr Dec 16 '13 at 07:51
  • 1
    The import lib header file claims that the compiler is vc6... I dunno. Just happy that it works now. – Tyler Daniel Dec 16 '13 at 18:39
  • Interesting. I do think that it would be nice if the linker could let you know when you're mixing and matching x86 with x64. This kind of question isn't all that uncommon, and it makes no sense to me that the clue to the solution has to be a missing or added underscore in the name the linker is complaining about. – Michael Burr Dec 17 '13 at 18:32