Dynamic linking problem

[slotdev]

Hi

I've recompiled the latest SFML to link dynamically (I normally use static linking, but I'm doing tests with sfe::Movie stuff) and I get a lot of linker errors. I have a game engine library (GRID.lib) which I have also recompiled, but this is the kind of stuff I get:

GRID.lib(XSymbol.obj) : warning LNK4049: locally defined symbol ?setColor@Sprite@sf@@QAEXABVColor@2@@Z (public: void __thiscall sf::Sprite::setColor(class sf::Color const &)) imported

Does anyone have any ideas why this occurs?

Thanks!

[slotdev]

Also a load of other errors (which probably explain more):

1>sfml-graphics-d-2.lib(RenderTarget.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall sf::NonCopyable::NonCopyable(void)" (__imp_??0NonCopyable@sf@@IAE@XZ)
1>sfml-graphics-d-2.lib(RenderTextureImplDefault.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall sf::NonCopyable::NonCopyable(void)" (__imp_??0NonCopyable@sf@@IAE@XZ)
1>sfml-graphics-d-2.lib(RenderTextureImplFBO.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall sf::NonCopyable::NonCopyable(void)" (__imp_??0NonCopyable@sf@@IAE@XZ)

[eXpl0it3r]

Well you don't really specify how you've linked what. Depending on the complexity of dependencies, I suggest to link everything dynamically.

So how did you build SFML? (i.e. how's the runtime linked?)
How do you link GRID to SFML?
How did you build GRID?
How do you link grid to your application (& SFML)?

What compiler are you using?

[slotdev]

Sorry, I should explain more.

Compiler is VS2010 (Express).

SFML is built with these options:
BUILD_SHARED_LIBS is false
SFML_USE_STATIC_STD_LIBS is also false

GRID is built as a DLL, using /MDd (as I'm only trying to get Debug build working first of all). I used to static link GRID but now I changed it to dynamic, added the SFML .libs to the linker input...and now I get a load more errors here, e.g. 1>Timer.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class sf::Time __thiscall sf::Clock::restart(void)" (__imp_?restart@Clock@sf@@QAE?AVTime@2@XZ)

Then, GRID & SFML .lib files are incorporated in the linker input of the game application.

Thanks

[eXpl0it3r]

Well you've compiled SFML statically (BUILD_SHARED_LIBS is false), but try to link it dynamically, right? Which obviously fails, since VS will look for the dynamic symbols, but you give it only the static ones.
Anyways you should either go with static linkage or dynamic linkage. Mixing both will mostly fail, especially if you don't know enough on the topic of linking libs.

[slotdev]

Sorry, I checked again, BUILD_SHARED_LIBS is actually set to true.

Everything is built dynamically, that I can see.

I much prefer static linking everything (and it is much better for what we do, as we work on many systems with different msvcrt versions, etc.) but because I need to use sfe::Movie project, which does not support static linking, I have to go back to dynamic linking............and hence I get all these problems

[eXpl0it3r]

Sorry, I checked again, BUILD_SHARED_LIBS is actually set to true.

I see...

I much prefer static linking everything (and it is much better for what we do, as we work on many systems with different msvcrt versions, etc.)

As soon as the complexity of dependencies goes up, you won't be able to link everything statically in a good way. But it's true, that Microsofts runtime library is a pain to distribute, it's way nicer with GCC, just ship libstdc++ and libgcc and you're mostly covered.
I've quickly asked on IRC and googled a bit, but it doesn't seem like you could just include the needed DLLs for MSVC's runtime library...

but because I need to use sfe::Movie project, which does not support static linking, I have to go back to dynamic linking............and hence I get all these problems

In theory you might be able to link sfe::Movie statically, but you'd then run into licensing issues and you'd have to modify the build script on your own and some codec might not even support static linkage.
It can be a pain to get used to, but it's worth the efford for a larger project (guess why about all games ship with all those DLLs).
In a perfect world, we'd all be using something some sort of package manager...

If you need help, you could provide all the needed files (yeah this time we'd need everything) and I might take a look at it.

[slotdev]

Yeah, the problem is, we use fixed platforms, some are W7, some XP, some XP Embedded.......and we also have our source code checked for each game by a Government agency (I am not joking, either) so having different versions of stuff for each platform is just impossible.

Maybe I need to look at sfe::Movie as a static build, the licencing issues aren't a problem for us. We have legal people to deal with that

[eXpl0it3r]

Maybe I need to look at sfe::Movie as a static build, the licencing issues aren't a problem for us. We have legal people to deal with that

Well then you could also change SFML's build system to link statically against OpenAl & sndfile (if you use the audio module)...

[slotdev]

Well then you could also change SFML's build system to link statically against OpenAl & sndfile (if you use the audio module)...

I could, but I am not that crazy

[eXpl0it3r]

I could, but I am not that crazy

Well I can tell you, that SFML CMake script is way easier to change, than sfe::Movies build script...
You'd only have to compile OpenAL and sndfile statically as well, which could yield some further issues.