Build issue with dynamic linking on Windows

Hello! I’m somewhat new to Cinder, C++, and Windows development, which is making for a fun series of challenges. I’m using VS 2015 on Windows 10.

I have a c++/cuda dependency that must be linked dynamically, so I’m trying to switch my VS project from static to dynamic linking. Cinder is my only other dependency right now. I made these changes:

  • Project properties > C/C++ > Code Generation > Runtime Library: Changed Multi-threaded (/MT) to Multi-threaded DLL (/MD)
  • Linker Additional Library Directories: Changed ..\vendor\Cinder\lib\msw\$(PlatformTarget)\$(Configuration)\$(PlatformToolset)\ to ..\vendor\Cinder\lib\msw\$(PlatformTarget)\$(Configuration)_Shared\$(PlatformToolset)\ (in other words, use Release_Shared instead of Release)
  • Opened cinder.sln and built the Release_Shared target

(I’m only using Release configurations for now.)

The build fails with a few linker errors:

Error LNK2001 unresolved external symbol "private: static class std::mersenne_twister_engine<unsigned int,32,624,397,31,2567483615,11,4294967295,7,2636928640,15,4022730752,18,1812433253> cinder::Rand::sBase"

Error LNK2001 unresolved external symbol "private: static class std::uniform_real_distribution<float> cinder::Rand::sFloatGen" (?sFloatGen@Rand@cinder@@0V?$uniform_real_distribution@M@std@@A)

There’s another similar unresolved symbol error for my other dependency, but I don’t think those details are relevant here.

Help of any sort, even vague guesses or clues, would be greatly appreciated!

Just a quick question, is there anything stopping you from linking against Cinder statically and other libs dynamically? You might have to modify Cinder’s Runtime Library to be /MD.

Nothing except my lack of experience, I suppose… how would I go about doing that?

FWIW, I’ll tie up this thread. I worked around the linker issue by creating my own implementation of (some of) Cinder’s Rand. This works well enough because my app isn’t making heavy use of random numbers.

Somewhat related: because of the difficulty of making a debug build of one of my dependencies, I’m sticking to Release, with debugging enabled: Compiler optimization means that sometimes the debugger is wrong, but it’s been an acceptable compromise for my project so far.

Regarding Andrew’s question (thanks for that)… that is something I can try. I think I’d use the Debug or Release configurations (not _Shared) but use /MD. That might fix the above linker issue.

I couldn’t reproduce those linker error and have no issue using ci::Rand in a shared build.

It seems that you are missing the preprocessor definition CINDER_SHARED which turns all CI_API into the right import directives. You might want to give it a second shot by following this small guide.

If this doesn’t help, it would be interesting to see some code to help reproduce what you’re seeing.