0

I'm using a 3rd party COM-based library called Engine in a native WinRT component which should later act as a wrapper for the 3rd party lib. An Engine.lib and a Engine.h file for the 3rd party lib is setup in my project.

I'm getting the LNK2019 for my following cpp file:

#include "pch.h"
#include "Engine.h"

void Component::Init()
{
ComPtr<IEngine> spEngine;
Settings settings;
CreateEngine(&settings, &spEngine);
}

The code compiles fine and the Engine.lib is setup in the project settings of VS2012. Also does DUMPBIN /EXPORTS for the Engine.lib show that CreateEngine is exposed. I can also use other types defined in the Engine.h, but as soon as CreateEngine is called, a linker error is raised:

Error   1   error LNK2019: unresolved external symbol CreateEngine@8 referenced in function "public: virtual void __cdecl

Engine.h defines CreateEngine like this:

STDAPI CreateEngine(
    _In_ Settings * pSettings,
    _Outptr_ IEngine **ppEngine );

Where the STDAPI is the usual macro:

#define STDAPI   extern "C" HRESULT __stdcall

Any ideas?

Rene Schulte
  • 2,962
  • 1
  • 19
  • 26
  • 1
    Does Engine.lib present in your linker's command line? (VS2012 allows to see linker's command-line parameters) Does dumpbin show `CreateEngine@8` (with the trailing `@8`) ? – nullptr Jun 21 '13 at 11:24
  • No, dumpbin shows just CreateEngine. And yes, the linker command line shows the Engine.lib as part of the OUT parameter. Other types defined in Engine.lib like IEngine or Settings compile and link just fine. – Rene Schulte Jun 21 '13 at 11:30
  • What did that trailing "@" mean? (It's been a while since I did native coding ;) Do you think there's a mismatch between the .lib and the .h file since DUMPBIN /EXPORTS shows just CreateEngine as export? – Rene Schulte Jun 21 '13 at 11:36
  • 1
    The trailing `@8` is from `stdcall` convention, `8` means that the function must pop 8 bytes from stack after it returns. This is default name decoration for `stdcall` for most C compilers. But the .lib file doesn't contain `@8`, and that produces the error. Maybe you should specify the WinRT project type somewhere (would it disable decoration?), or maybe the .lib file was compiled with a different compiler. – nullptr Jun 21 '13 at 12:13
  • Thanks a lot. The WinRT project type should be right I think. I use Windows Phone. I will contact the vendor of that 3rd party lib and ask for a better build. – Rene Schulte Jun 21 '13 at 12:24

1 Answers1

0

Figured it out with the help of Inspired: I was using the lib built for ARM with an x86 build configuration. After changing that it was linking fine.

Rene Schulte
  • 2,962
  • 1
  • 19
  • 26