0

I am using a dll exporting a function that returns a shared_ptr.

The code from the dll project:

#ifdef _WRAPPER
    #define WRAPPER_DLL_EXT __declspec(dllexport)
#else
    #define WRAPPER_DLL_EXT __declspec(dllimport)
#endif


std::shared_ptr<int> WRAPPER_DLL_EXT func()
{
    return std::make_shared<int>(5);
}

The code from the project using the dll:

std::shared_ptr<int> myPointer = func();

I get error LINK2019: unresolved external symbol for func().

The dll project is compiled using Visual Studio 2013 Toolset, whereas the project using the dll is using Visual Studio 2010 Toolset.

Compiling the dll using VS2010 toolset prevents the error, but I am using VS2013 features in the implementation so I cannot actually compile the dll with VS2010. Note that I cannot upgrade the using project to VS2013.

How can I make it work using VS2013 toolset for the project using the dll?

Edit: it works if I change shared_ptr to unique_ptr (but, of course, it's not what I need).

Or B
  • 1,675
  • 5
  • 20
  • 41

1 Answers1

3

Short answer:

use pure-C API for your dll OR use the same toolset versions for the DLL and the executable

Long answer:

C++ is not ABI-compatible across different compiler versions. This means that different versions of toolsets will not produce compatible binaries. C++ names can be mangled differently, memory layout is different etc – this will either lead to the linker not being able to find the right functions, or some dire runtime errors. The only way to be sure stuff is ABI-compatible is to use a language that is guaranteed to be ABI-stable between toolset versions, and that is C.

This is basically the reason why Windows APIs that are exposed through DLLs are C functions with plain C structures and stuff.

Some more info on StackOverflow.

ivanmoskalev
  • 2,004
  • 1
  • 16
  • 25