Boncey
Boncey

Reputation: 157

Random unresolved external symbols that shouldn't be there

I'm used to compiling for Linux so this .lib stuff is a bit weird for me. With my program under Visual Studio I keep getting random unresolved external symbol for other libs and even Microsoft Runtimes.

1>glfw3.lib(init.c.obj) : error LNK2019: unresolved external symbol __imp__vsnprintf referenced in function __glfwInputError
1>MSVCRTD.lib(vsnprintf.obj) : error LNK2001: unresolved external symbol __imp__vsnprintf
1>glfw3.lib(context.c.obj) : error LNK2019: unresolved external symbol __imp__sscanf referenced in function _parseVersionString
1>MSVCRTD.lib(vsnprintf.obj) : error LNK2001: unresolved external symbol __imp___vsnprintf
1>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\OLDNAMES.lib : warning LNK4272: library machine type 'UNKNOWN' conflicts with target machine type 'X86'

I am only including these libraries and I can confirm they are being found:

x86/glew32s.lib
x86/glfw3.lib
x86/glfw3dll.lib
opengl32.lib

With their inherited values:

kernel32.lib
user32.lib
gdi32.lib
winspool.lib
comdlg32.lib

I can confirm that this is the exact order. I have tried installing and re-installing Windows 7 SDK and Visual Studio - I am also on Windows 7.

Any help regarding this issue would be appreciated and I am happy to give out more information if required.

Thanks, Boncey

Upvotes: 12

Views: 16972

Answers (3)

Gurjot Bhatti
Gurjot Bhatti

Reputation: 977

You can also add an additional library to your linker input i.e, legacy_stdio_definitions.lib

Go to Properties > Linker > Input.

And in Additional Dependencies add the above mentioned library.

Upvotes: 19

Dan
Dan

Reputation: 13190

The problem is that your glfw static libs were built with a different version of Visual Studio than the one you're using. As of spring 2015, the prebuilt ones on glfw.org are not compatible with Visual Studio 2015 RC (which you appear to be using).

Fortunately, GLFW is a small codebase released under a permissive license, so the easiest solution is just to create a new project for it in your solution. The steps will go something like this:

  1. Create a new empty project GLFW in your solution.
  2. Copy in the include, deps/GL, and create a src folder.
  3. Copy all the source files into the src folder for platforms you intend to support. For windows, this is everything with a win or wgl prefix, or no prefix. You can ignore all the cmake stuff.
  4. Create a file in src called glfw_config.h containing #defines of _GLFW_WIN32, _GLFW_WGL, and _GLFW_USE_OPENGL. If you want to support more than just windows, you'll have to conditionally define the options you want in this file. All the options are described in src/glfw_config.h.in.
  5. Add all the relevant files to the Visual Studio project.
  6. In the project options, set Configuration Type to static lib. Under C/C++ > General, make sure SDL Checks is disabled. And under Preprocessor, add _GLFW_USE_CONFIG_H to the definitions.
  7. Set your main project to depend on the GLFW project (in the right-click menu). Finally, add the correct GLFW lib to your linker dependencies. (I have the output directory for GLFW set up so the correct lib is just $(SolutionDir)GLFW\$(Platform)\$(Configuration)\glfw.lib.)

Upvotes: 9

Mark Morrison
Mark Morrison

Reputation: 101

It looks like there's a misconnect between dynamic and static runtime library linking. The "__imp" prefix on the symbols means your code is looking for something from a DLL, but the libraries you're linking in are probably expecting static runtime libraries.

Bring up the project property pages (under Build->Properties), and look for the C++ category on the left. Under "Code Generation" there should be an entry called "Runtime Library". This is probably currently set to Multi-threaded Debug DLL (/MDd), since it looks like you're compiling in debug mode. Change this to Multi-threaded Debug (/MTd), and recompile everything. See if that now works.

Upvotes: 2

Related Questions