How does SFML link to the CRT (in Visual Studio)?

[Astrof]

Ok, so I'm trying to limit the number of dlls my exe uses (I for some reason prefer static linking over dynamic linking).  Also I want to use the SPARK particle library thing and it won't link statically.  If I link the SPARK library dynamically, it asks for SFML to also be linked dynamically.  I then realized that maybe the problem was a /MT vs /MD thing.  However, when I compile with the /MT I get a bunch of "already defined" linker errors.  I now use /nodefaultlib and then I get over 9000 linker errors (well like 81).  They all say stuff like:

Code: [Select]


Error 1 error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __thiscall std::_Mutex::_Lock(void)" (__imp_?_Lock@_Mutex@std@@QAEXXZ) sfml-window-s.lib blank


now my question is, in Visual Studio, does SFML link against the dynamic CRT, even as a static library?  How can I fix this error?  What libraries do I need when I use /nodefault lib?  I know this is more of a visual studio question, but any help would be greatly appreciated.  

On another note, how is Code::Blocks?  If I cannot remedy this situation, I wouldn't mind using Code::Blocks, I just have a few questions:
What are Code::Blocks' dependencies?
If it's not like VC++ (as it has the "visual" part removed) does it create leaner, faster programs?
I'm sure that if I use Code::Blocks it would make my project more easily cross platform.  

Anyway I've been struggling with this static CRT vs Dynamic thing forever and just want to get to work on my game...

[Astrof]

anybody?

would manually building SFML (under MT and not MD settings fix this?)

[Nexus]

SFML links to dynamic CRT. As far as I know, static linking is currently not possible (I had the same request some time ago, and didn't find any solution - you can search my thread if you want to... ). I deliver the MSVC++ DLL files in my application folder...

But what is definitifely a misbelief is the assumption that it wouldn't be possible to program portably on MSVC++. If your code doesn't depend on the language extensions, you can remain plattform-independent as well. And why do you think the programs would become leaner or faster on Code::Blocks?

[Astrof]

Well I'm trying to limit the use of DLLs.  At first it wasn't an issue with just the MSVC++ DLL files, but now that I am trying to use frifron's Spark Particle lib, I can't link the library statically for some reason.  I think its because of this dynamic over static linking thing (when I try to link it statically it expects everything to be linked statically and vice versa).  At least that's my take on the issue (I've spent a good week or two trying to get it set up; I thought it would be as simple as the SFML set up.  It wasn't.  Boost seemed to have a slightly different way of linking as well). Either way I only got SPARK working when linked dynamically and when I linked SPARK dynamically it expected SFML to also be linked dynamically.  So it seems that if I want to continue using Visual Studio I have to make everything dynamic.  Now I don't know the specifics of dynamic vs static (all I know is dynamic splits it into dlls while static puts everything into the exe thus making the exe larger) but I seem to like static linking better (as I'm only dealing with one exe file).  

The reason I mentioned code::blocks is code::blocks doesn't require any DLLs to be added...does it?  Could I statically link everything more easily with Code::Blocks (or dev C++, etc, just not Visual Studio)? Or how do I make my program not dependent on MSVC++ dlls?  

My ultimate plan is once I get my project working on Windows to move it over to linux.


EDIT:  Phew, after writing this post, it got me thinking.  Instead of recompiling SFML could I recompile SPARK?  Sure enough one of the static libs linked to the CRT statically.  The rest of the static libs seemed to link dynamically.  So that solves my problem finally.  

My question about code::blocks and/or removing the dll dependency using visual studio still stands, for curiosity's sake.