Unresolved External Symbol with Static Linking /MT

[Acumen]

So I have been tried everything I can think of but cannot figure this thing out.

I can compile fine static with /MD and the 2.0 RC. With my own cmake build of the latest snapshot (g86897a8) with SFML_USE_STATIC_STD_LIBS on, /MT in Visual Studio 2010, it gives me these errors:

1>main.obj : error LNK2001: unresolved external symbol "public: __thiscall sf::Window::Window(class sf::VideoMode,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,unsigned int,struct sf::ContextSettings const &)" (??0Window@sf@@QAE@VVideoMode@1@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@IABUContextSettings@1@@Z)

1>smflInput.obj : error LNK2001: unresolved external symbol "public: void __thiscall sf::Window::create(class sf::VideoMode,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,unsigned int,struct sf::ContextSettings const &)" (?create@Window@sf@@QAEXVVideoMode@2@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@IABUContextSettings@2@@Z)

My window code is this:

sf::ContextSettings settings;
settings.depthBits = 24;
settings.stencilBits = 8;
settings.antialiasingLevel = 4;
settings.majorVersion = 3;
settings.minorVersion = 2;

sf::Window window(sf::VideoMode(800, 600), "Name of Program", sf::Style::Default, settings);

I have the static pre-processor flags in, linked to the static libraries. Like I said it build fine with /MD and 2.0 RC. I would like to be able to build with /MT so people will not have to install the Visual Studio extensions.

[Acumen]

So I was including the RC instead of the snapshot. Switched the include to snapshot and got rid of one error, left with this:

main.obj : error LNK2001: unresolved external symbol "public: __thiscall sf::Window::Window(class sf::VideoMode,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,unsigned int,struct sf::ContextSettings const &)" (??0Window@sf@@QAE@VVideoMode@1@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@IABUContextSettings@1@@Z)

Just to clarify, I have SFML_STATIC, GLEW_STATIC set in preprocessor. And additional dependencies:

glew32s.lib
sfml-window-s.lib
sflm-graphics-s.lib
sfml-system-s.lib
sfml-main.lib
opengl32.lib
glu32.lib

[Laurent]

Which snapshot? If it's the latest sources, this function doesn't exist anymore. The second argument is now a sf::String.

[Acumen]

Yes, the latest g86897a8. So if I understand correctly, I changed my code to:

sf::String windowName = "Window Name";
sf::Window window(sf::VideoMode(800, 600), windowName, sf::Style::Default, settings);

And I still get this error:

main.obj : error LNK2001: unresolved external symbol "public: __thiscall sf::Window::Window(class sf::VideoMode,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,unsigned int,struct sf::ContextSettings const &)" (??0Window@sf@@QAE@VVideoMode@1@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@IABUContextSettings@1@@Z)

[Laurent]

Your headers don't match the libraries. You have several versions of SFML mixed together.

[Acumen]

My additional include directories are:

glew-1.9.0\include
SFML-86897a8\include (latest snapshot, same one I built the .lib's from)
glm-0.9.4.3\glm
and my project directory

#include <GL/glew.h>
#include <SFML/Graphics.hpp>
#include <SFML/Window.hpp>
#include <SFML/OpenGL.hpp>
#include <glm.hpp>
#include <ext.hpp>
#include <iostream>

Am mixing them together? Can you explain where? I was in my original post, but I thought I fixed that with the first reply prior to yours.

[Laurent]

I don't know what you've done, but it's clear that the linker still looks for the old definition of the function, which can only mean that you include the old version of the header.

[Acumen]

I am stumped. Does any of this help? Any other ideas?

[Laurent]

Open Window/Window.cpp with a text editor and make sure that the constructor takes a sf::String and not a std::string.
Then rename the header and make sure that the compiler complains (to make sure that it's this Window.hpp header that is used, and not another one).

If these two steps are successful, make a "rebuild all".

[Acumen]

Thank you so much for your help. I would never have had the patience to work through all the things I just did if you were not replying so quickly. I made a stupid mistake early on in development that I did not realize I even did until now. At some point I changed the properties of my main.cpp to include my SFML 2.0 RC directory instead of inheriting from the project, I probably thought I had the project selected. Thus when I changed my project include to the snapshot build, main.cpp was still bringing in the RC. Hopefully this thread will help save someone else the time I spent over this.

Thanks again!

[Acumen]

In the same light, I think this might save people some time as well, and might be a good side note in the tutorial:

To compile SFML statically for release with /MT so windows users will not have to install the visual studio extension:

- Build SFML from the latest snapshot using CMake with SFML_USE_STATIC_STD_LIBS set and BUILD_SHARED_LIBS off.
- Link to the SFML snapshot include folder and the libraries you built with CMake.
- Define SFML_STATIC in the preprocessor.
- If using glew set GLEW_STATIC and include glew32s.lib.
- Set C/C++ -> Code Generation -> Runtime Library to Multi Threded /MT

If you can correct or clarify anything I just wrote I think people would appreciate it as well. I found many threads on many forums with partial information about doing this and think a quick little rundown somewhere would help.

[eXpl0it3r]

I think this might save people some time as well, and might be a good side note in the tutorial

It's all there in the tutorial, one just has to read precisely and understand what it means.
Besides that, static linking is not always recommended and one really needs to know, what one is getting themselves into.

windows users will not have to install the visual studio extension:

You mean the Visual Studio runtime libraries/redistributables.

- If using glew set GLEW_STATIC and include glew32s.lib.

This is not nesecary if you work with SFML only, since SFML includes glews binary object into the sfml-graphics module library. (Yes Laurent you should still change that, pretty please. )

I found many threads on many forums with partial information about doing this and think a quick little rundown somewhere would help.

The problem here is, that many don't understand what their tools are doing and just randomly click around. The tutorial essentially explains everything, but since they don't understand what is really going on, they don't understand what the tutorial is teaching.
Giving a step-by-step dummy explanation, will let them compile it, but they won't learn much about the used tools and will again face a wall, when they try to build another library.

[Acumen]

You are of course correct on all the aspects you touched upon, and most Visual Studio users will probably know or assume the libraries were built using /MD and that to use /MT requires a new build. It is not really in the scope of SFML to deal with those things. But SFML does attract self taught users unfamiliar with some of the finer points of build environments less likely to be covered in primers and whatnot like myself. But like I said hopefully this thread might help someone.

Thanks again for SMFL!